Microsoft 365 (M365) has quickly become one of the most utilized email platforms and, thanks to a variety of productivity and communication applications deeply embedded in enterprise processes, it’s also a popular target for cyber criminals. Microsoft certainly understands that and has enabled extensive security mechanisms for M365, including multifactor authentication (MFA), which requires users to present more than one form of authentication before login. MFA is a fundamental security control frequently recommended by experts for its efficacy in preventing less sophisticated attacks, but like all controls, it’s not infallible.
This article examines three tactics that Kroll has observed threat actors leveraging to bypass MFA controls in M365, and examples of how their attacks play out in real life: authentication via legacy protocols, wireless guest network abuse and third-party MFA application providers for Azure.
Legacy Authentication
One tactic threat actors consistently use to bypass MFA is the use of legacy authentication. Legacy authentication can be used for mail protocols where MFA was historically not supported such as IMAP4, POP3 or SMTP, or for older Outlook and mobile clients that do not support MFA. Once a threat actor obtains credentials through phishing campaigns, from the dark web or other credential breaches and thefts, legacy authentication can be utilized to sign into an M365 email account, even if the user has MFA enabled and enforced.
As long as legacy authentication is enabled, the possibility that threat actors can log into an M365 account without satisfying MFA requirements may exist, allowing the threat actor full access to read, write and download a full copy of the impacted user’s mailbox to their local (threat actor controlled) system.
Kroll has identified this tactic leveraged within client M365 tenants. The following Microsoft unified audit log excerpt correlates to a user who had MFA enabled and enforced (Figure 1). The highlighted data indicates there were two logins in a short timespan; one geolocating to Indonesia and the other geolocating to the Netherlands. These unauthorized logins were not consistent with historical logins on the user’s account, as the user normally logged in from Pennsylvania-geolocated IP addresses. The method in which these logins used to connect to the user account was BAV2ROPC, a user agent string correlating to a connection via an Outlook mobile client, specifically, using non-modern authentication. The BAV2ROPC string has been observed by Kroll as indicative of mail client usage and consistently observed alongside the use of legacy protocols such as IMAP/POP3.
Figure 1 – Unified audit log indicating unauthorized access using legacy protocols
Wireless Guest Network
M365 provides administrators access to allowlist IP addresses as “named locations” so users with valid credentials can login with single authentication from trusted IP addresses, such as within corporate offices. Even if MFA is normally required for this user, within a named location, MFA is not required for authentication. This means a threat actor in the vicinity of the targeted company and in possession of valid credentials can connect to the wireless guest network, which often uses the same IP address as the corporate network, and sign into a M365 account without satisfying MFA requirements.
In addition, Kroll has observed threat actors circumvent legitimate geolocation blocks by identifying a hop point in the victim’s city and state location and utilizing the victim’s primary IP range that correlates to this location to connect to accounts and appear as legitimate access.
Third Party MFA Application Providers through Azure Conditional Access Policies
In the event a threat actor steals M365 administrator credentials within an M365 tenant by way of an administrator unknowingly approving the unauthorized login through an allow option on MFA, third-party MFA applications set up within the Azure portal as a Conditional Access policy can be utilized to bypass MFA requirements on additional accounts, such as Duo. If a Conditional Access policy has been created within the M365 tenant to enforce MFA utilizing third party MFA application providerss, a threat actor with unauthorized access to an administrator account can dismiss all risky logins for any user within the tenant, essentially overriding MFA requirements and gaining access to multiple accounts within the tenant. In addition, the threat actor can also change Conditional Access policies to exclude other accounts from MFA requirements, as well. Another tactic threat actors have used is to add an additional mobile device to the compromised user’s account to intercept MFA prompts. When the threat actor logs in, the MFA prompts will be routed to the threat actor’s mobile device and the unauthorized login is then approved by the threat actor.
A threat actor with unauthorized access to multiple accounts within an M365 tenant finds it much easier to carry out malicious activity, such as the redirection of wire transfers. If the threat actor can focus on an email thread where payment is owed and the threat actor has unauthorized access to several email accounts that approve payments, it is easier to target the user who normally releases the funds. The threat actor simply would send a reply approving the wire redirection from one of the compromised accounts the actor has access to. The user who releases the wire will do so, as the user believes the approval was from the legitimate individual.
Kroll encountered this tactic in a recent engagement where a user with global administrator privileges on their M365 account fell victim to a phishing email and entered their M365 credentials into a harvesting site unknowingly. Kroll’s analysis of the available Azure sign-in logs indicated that there were several logins from European countries which were not historically consistent with authorized access to the account. Further investigation into Azure audit logs indicated that this compromised global administrator account dismissed unauthorized logins for several other accounts within the M365 tenant, all from the same threat actor. In turn, the threat actor was able to exfiltrate communications and data from not only the global administrator account, but also the other accounts by abusing the delegated mailbox authority of the account.
Remediation
To prevent threat actors from utilizing these vulnerabilities, M365 tenant administrators can configure tenants in the following manner.
- Disable basic authentication and legacy protocols and enforce modern authentication
- Do not configure allowlisted, trusted IP addresses as “named locations”
- Enable the “Impossible Travel” report within the Microsoft Azure portal
- If a third-party MFA application Conditional Access policy is configured, ensure that the policy applies to “All Cloud Apps” rather than “Select Apps” (Figure 2)
Figure 2 – Remediation for third party application MFA vulnerability
If you are experiencing unauthorized access within your M365 tenant and have MFA enabled and enforced for all accounts, it is recommended to frequently review your Azure portal for risky sign-ins per user to ensure the locations the user(s) are signing in from are legitimate access. In addition, the unified audit logs, which are available to all M365 tenants with licensing, located within M365 Compliance Center should be reviewed for suspicious logins, inbox or forwarding rules, and add permission operations.
Conclusion
Although M365 provides several options for increased efficiency and productivity within the environment, it is imperative that administrators review security, configurations, and policies to avoid vulnerabilities that will allow threat actors to bypass MFA settings
