Advisory: Persistent MFA Circumvention in an Advanced BEC Campaign on Microsoft 365 Targets

Originally published by Mitiga.

Written by Mitiga's Research Team.

Mitiga spotted a sophisticated, advanced business email compromise campaign, targeting Microsoft 365 organizations, leveraging inherent weaknesses in Microsoft 365 MFA, Microsoft Authenticator, and Microsoft 365 Identity Protection.

These weaknesses effectively nullify the added security allegedly provided by multi-factor authentication (MFA), allowing for full compromise, even of accounts that have enabled MFA.

Background

We investigated an attempted Business Email Compromise (BEC) attack. While the alertness of the involved parties prevented the fraud, the attack indicated that the attacker had access to sensitive information that could only be obtained by compromising a user in the organization.

Indicators of Compromise Analysis

During the investigation, we identified unauthorized access to the Microsoft 365 user of an executive in the organization from multiple locations (including Singapore, Dubai, andSan Jose, California). The initial compromise leveraged an adversary-in-the-middle (AiTM) phishing technique for initial access, providing the attacker with access to the executive’s account and mailbox.

However, further investigation of the compromised account detected that a second Authenticator app had been set up for the user without their knowledge. This gave the attackers full persistency of the breached account and effectively nullified the value of MFA.

Read a full analysis of the entire attack.

Microsoft 365 MFA Weaknesses Analysis

While the AiTM technique already gives an attacker full access, there are (or rather, should be compensating controls to reduce the risk. One of the key controls to manage this risk is an MFA challenge – that is, requiring the second factor again in cases of suspected risk, such as when accessing resources from a new IP address, requesting elevated permissions, or accessing highly sensitive applications.

By default, Microsoft examines the existing token in the active session, and determines whether authentication is required. If the session has been previously authorized properly with MFA, Microsoft does not require a new MFA challenge. When looking through the justification in the sign-in logs, this appears with the statement: “Previously satisfied – MFA requirement satisfied by claim in the token.” Unfortunately, Microsoft does not give its customers any flexibility here (other than the duration of the MFA token). It is the Microsoft authentication engine that decides when the MFA challenge is needed, preventing customers from configuring enhanced controls to improve their security.

One of the most extreme (and surprising) examples of this is the Privileged Identity Management (PIM) feature. PIM is designed so that administrative users can work with non-administrative rights and only elevate their permissions to an administrator using this portal. Microsoft does not, however, allow the customer to require an MFA re challenge for this activity, despite its high risk. This means that even if you have PIM enabled, if the account is compromised the attacker can become an administrator by going to the PIM portal themselves (although, at least in this case, the user will get a notification that someone activated that privilege).

The second most surprising example of this, which is at the heart of this attack, is that Microsoft does not require an MFA re-challenge for accessing and changing user authentication methods in the Security Info section of the account profile. Through this portal, a user who has a Previously Satisfied token can add a new Authenticator app without an MFA re-challenge. This means that once an account has been compromised, even for an extremely short period of time, it is possible to create persistency using this technique, so an attacker can then reauthenticate with MFA when the session expires or is revoked. It is important to note that even if an organization puts a strict MFA expiration time of one day, it will still not prevent creating for the attacker with this technique.

The following logs, taken from our investigation, demonstrate this well. At 8:32:09 the attacker started a security info registration (creating a new Authenticator app) and completed the process within 5 seconds. No MFA is required to do so.

‍About half a minute earlier, at 8:31:27, the attacker logged into the “My Access” portal, which is where they edited authentication details. As shown below, accessing the “My Access” app requires MFA, which was successful via Conditional Access.

However, when examining the details, it is clear that no MFA actually took place during that session, as it was previously satisfied by the token.

While the solution for this is obvious, Microsoft does not provide it. There is no way, unfortunately, to configure your Microsoft 365 to require an MFA re challenge for this type of activity (or any other type of activity).

Note: Microsoft Identity Protection has identified some of these as risky sign-ins. However, unless an organization can withstand some of the false positives generated by Identity Protection, the default behavior is to require an MFA re-challenge, which is not effective at this point because the attacker already has the Authenticator app setup.

Conclusion & Recommendations

Over the past years, MFA has been regarded as a way to prevent phishing attacks and has become a de facto standard in most organizations. It is not surprising, then, that attackers have developed ways to overcome this added security through attacks such as AiTM. While preventing such an attack without additional controls is difficult, containing it and limiting its scope should be fairly easy — by requiring an MFA re challenge for security related activities and for risky sign ins. Unfortunately, Microsoft does not offer any of these capabilities at this point.

Given the accelerated growth of AiTM attacks (even without the persistency allowed by an attacker adding anew, compromised, authentication method), it is clear that we can no longer rely on multi-factor authentication as our main line of defense against identity attacks. We strongly recommend setting up another layer of defense, in the form of a third factor, tied to a physical device or to the employee’s authorized laptop and phone. Microsoft 365 offers this aspart of Conditional Access by adding a requirement to authenticate via an enrolled and compliant device only, which would completely prevent AiTM attacks.