The latest flavour of MFA bypass

Responding to Business Email Compromises (BECs), Multi-Factor Authentication (MFA) bypass is something that I often come across. In most cases, where users have MFA enabled, bypass is achieved through the use of legacy protocols which only support single factor authentication. In such cases the account credentials are typically obtained through brute-forcing or phishing.

However, a different 'flavour' of MFA bypass using an 'Adversary-in-The-Middle' (AiTM) or 'Man-in-The-Middle' (MiTM) methodology is becoming increasingly widespread whereby attackers are able to satisfy the MFA requirement with a stolen session cookie. Frustratingly for defenders, this technique works even if legacy protocols are disabled.

How do attackers get hold of a valid session cookie?

Phishing - of course! In the first phase of the attack, the attacker sends a phishing email or shares phishing document with the target which contains a link to an attacker-controlled server. 

In the wild I've seen these emails come from compromised domains with seemingly good email reputation from an address such as:

Microsoft@<compromised_domain>.com

When the link is clicked, the user establishes a connection with the attacker's server and presents them with a Microsoft 365 (M365) login page. The attacker's server essentially works as a Man in The Middle (MiTM), capturing and relaying the victim's username and password to the M365 tenant.

When the correct credentials are forwarded by the attacker's server, the user will be sent an authentic MFA challenge, either via SMS, Authenticator or a third-party application. When successfully completed by the user, they will be given a session cookie, which can be sniffed and captured by the attacker's MiTM server.

Once obtained, the attacker can use the cookie for as long as it is valid to access the resources available to the legitimate user in that session. By default, Azure Active Directory sessions are typically valid for 90-days, which is plenty of time for an attacker to learn about the victim and send out fraudulent invoices.

How it works (as a diagram)

What are the Indicators of Compromise?

Phishing email - The first Indicator of Compromise (IOC) you are likely to see is a phishing or spear-phishing email that contains a link to an attacker-controlled domain/server.

Impossible travel - The second IOC you are likely to see is one of impossible travel, that is a login from a geographic location inconsistent with other user activity. However, this IOC can be easy to write-off on first inspection as the User Agent is likely to be that of the legitimate user (and even a registered device) and can fool you into thinking it is legitimate user activity. 

Abnormal session usage - The third IOC is likely to be the presence of multiple User Agents and/or locations being associated with a single Session ID. According to Microsoft: "Multiple sessions shouldn't be possible for the same account with different locations (indicating that the session could be stolen)".

Abnormal account activity - The later IOCs are likely to include all those typical of a BEC: Unusual interaction with files and emails, the creation of inbox rules and ultimately the sending of fraudulent emails.

Conclusion

The use of AiTM MFA bypass is likely to increase as organisations increasingly look to roll out MFA for their users and as Microsoft start to block legacy protocols for Exchange Online by default. 

Stolen session cookie usage mitigation is possible by limiting session cookie duration in Conditional Access Policy. But the attack technique offers a reminder to defenders that MFA isn't bullet-proof - phishing emails will occasionally get past email security solutions, and end users will occasionally let you down by clicking a link (even after all their mandatory training). 

As defenders we need to ensure that we have anticipated these failings and have a robust set of alerting mechanisms to detect and allow a response to such compromises in the early stages of an attack, before your IOC is "Acme Corp just called, they haven't received the payment we made, and no they haven't changed their bank account details recently!".