The Enabling Technologies Blog

Our team of Cloud Strategy Advisors, Solution Architects, Engineers and former C-Suite Executives work diligently to provide our vistors with the most pressing information.

Chris Stegh /

MFA is (Unconditionally) Not Enough

Microsoft has seen a trending number of instances whereby an Office 365 user is phished and has their O365 session hijacked. The adversary uses the victim's token to sidestep MFA, allowing the attacker into the victim's email where they can impersonate and ask for bogus wire transfers. This is the latest adversary/man in the middle attack that on its own cannot be foiled by Multifactor Authentication.

This trending attack proves again that defense in depth is a must. MFA is often thought of as minimally viable security, and there’s nothing vulnerable with MFA or Azure Active Directory itself. But MFA it can still be sidestepped by a well-crafted front. The announcement that Microsoft made public last week shows that conditional access and user training are also integral parts of securing identities.

Microsoft's article, in summary, says that an adversary sets up a website that looks just like an Office 365 page, but with a slightly dlfferent URL (dld you notlce?). They’ll send the URL to the victim in an email or other format, and if the user happens to have a real Microsoft site open in a browser, they'll skim the token from the session. The victim’s PC tells the adversary's website what the token was for the legitimate session, and the adversary uses that token to securely connect to the victim's Office 365 email or other resources.

What must be done?

1. Enable Conditional Access in Azure AD or other MFA solution. The conditions that would keep the adversary's computer from being able to spoof the victim could include:

a. IP address - if the session came from an untrusted country or unknown IP address, it would fail the conditional access check and be declined. However, it is hard to maintain a tight list of allowed IPs.
b. Machine compliance - this is the best of the options (if the machine were managed by MSFT Endpoint Manager/Intune). The adversary's device status (unfamiliar/unmanaged by the organization) would fail the CA check and be prompted to register with Intune. This would likely send the adversary off to hunt for easier targets. The AAD or Hybrid AAD join status will stall them as well.
2. Mitre also had some recommendations on the network to minimize the risk of

3. Train users
a. Hovering over the URL would expose a phishing URL
b. Accepting pop ups about certificate errors or visiting non-HTTPS sites are risky behaviors to avoid.

Why are tokens used anyway?

Most web applications use a login mechanism that generates a temporary session token to use for future requests to avoid requiring the user to type a password at every page. Once the attacker hijacks and can identify the session token for a user, they'll login again from their device, bypassing MFA, and use it to make requests as the user. The attacker does not need to spoof once they have a session token.

What are Azure AD's Conditional Access Options?

There are several conditions to help narrow in on a legitimate authentication request. Note, these are only available with Azure AD Premium 1 (part of EMS and/or M365 E3). Pictorially, the options are shown below.


In some detail, the conditions can be based on:

  • User or group membership
    • Policies can be targeted to specific users and groups giving administrators fine-grained control over access.
  • IP Location information
    • Organizations can create trusted IP address ranges that can be used when making policy decisions.
    • Administrators can specify entire countries/regions IP ranges to block or allow traffic from.
  • Device
    • Users with devices of specific platforms or marked with a specific state can be used when enforcing Conditional Access policies.
    • Use filters for devices to target policies to specific devices like privileged access workstations.
  • Application
    • Users attempting to access specific applications can trigger different Conditional Access policies.
  • Real-time and calculated risk detection
    • Signals integration with Azure AD Identity Protection allows Conditional Access policies to identify risky sign-in behavior. Policies can then force users to change their password, do multi-factor authentication to reduce their risk level, or block access until an administrator takes manual action.
  • Microsoft Defender for Cloud Apps
    • Enables user application access and sessions to be monitored and controlled in real time, increasing visibility and control over access to and activities done within your cloud environment.

And in the Azure AD Admin interface, the choices to block/allow based on the conditions is shown toward the right of the diagram.



The journey to Zero Trust is never complete, so take another step by configuring Conditional Access or verifying that the correct conditions and controls are in place. Adding device compliance to your conditions is the major step forward, and would keep untrusted devices from allowing the authentication to pass, even in situations where the session is hijacked in the middle.

Work with our team of Cloud Computing Consultants who have done this so many times they know all of the “minefields” to prevent missteps.