Skip to main content

Bypassing MFA with Phishing, Part 2

· 4 min read

Following from the prior post discussing MFA use cases and bypasses, this post expands on the prior article and adds further ideas on protecting your users' identities.

Evolution of the reverse proxy: Adversary-in-the-middle

While use reverse proxy to steal MFA codes and authentication data is not new, the Adversary-in-the-middle attack is a refined approach.

The Microsoft article on Storm-1101 provides the full details.

In summary, the provision of MFA bypass systems is now in demand enough that there are attackers that just specialise in providing (and licensing!) software platforms to bypass MFA protections.

The article further provides the technical details and authentication flow - it is well worth at least a skim read.

For a defender, this means only that we can expect the volume of attempted MFA bypass to increase. The technical details are the same - the user is still subject to a social engineering attack and the final outcome is the theft of session cookies.

Post-access actions

Once MFA has been bypassed, the attacker will want to maintain that access. As repeated phishing/social engineering is costly and not 100% reliable, the attacker will want to alter the user's authentication methods to ensure their access is maintained.

This can include:

  • Disabling MFA completely
  • Adding a secondary, non-default MFA method that's controlled by the attacker
  • Adding OAUTH grants, mail forwarding rules, or similar configurations that persist even if access is lost

Defense in Depth / Zero Trust

As the above attack is a multi stage process, the defense is likewise required to be active at all the above points. The consideration should be that just because the user has valid credentials does not mean that they are trusted - are the logging in from a reasonable location? Device? Application?

Prevent

The defensive controls can be some of the following (written from an AzureAD view):

  • User security awareness training, efficient anti-phishing mail filtering, and complete email authentication (DMARC reject 100%) - these measures combined will reduce the number of phishing emails and the users' susceptibility to them
  • Use phishing resistant MFA methods such as FIDO2
  • If you must use App Notification MFA, ensure that your app includes the "number matching" or equivalent anti-fatigue feature (see the guidance here). Microsoft has stated they will enable this for all users as of 8th May 2023. For additional user help consider enabling the additional authentication context as documented here

Conditional Access​

In addition to the above, use Conditional Access Policies to implement suitable controls from the below:

  • Block access from all IPv4 ranges outside your typical use locations. (IPv6 support is now in place as of April 2023)
  • Block access from all legacy applications and protocols
  • Require compliant device
  • Other controls - refer to list of common policies

While Conditional Access is not ironclad, every control makes the attacker expend more effort.

Detect​

As described in the Microsoft article on Storm-1101, users of Sentinel can use this analytics template.

Additionally, Defender for Cloud Apps with Office 365 and Azure connectors will alert on stolen cookie usage - ensure that these (and "Possible AiTM phishing attempt") alerts are actioned.

Other​

In addition to specific prevention and detection tactics, consider also limiting the damage to/from a compromised account. Some suggested steps:

  • Alert on suspicious mail rules
  • Alert on MFA additional methods set-up (though note the false positive chance)
  • Alert on OAUTH grants

Summary

Despite the substantial benefits of MFA, it is not a 100% secure solution - no solution is 100% secure.

Keeping your users' identities protected requires reducing inbound phishing attempts and training your users to recognise them.

Assuming that a small percentage of users may be compromised anyway, the compromised credentials should be made difficult to use outside of the expected corporate location and device make-up.

Monitor for persistence activities such as alternative MFA and unexpected OAUTH grants.