22 May 2024

How attackers can bypass MFA using AiTM, and how to defend against it

Multi-Factor Authentication (MFA) is essential for securing against social engineering and is now standard in onboarding and account creation. However, it has weaknesses, such as alert fatigue and SIM swapping. The industry has strengthened protections, but attackers continually adapt to these defenses.

Multi Factor authentication (MFA) has been a must have for securing against Social Engineering for years. Once a nice to have is more than likely now deployed as standard as part of any on boarding or account creation.

MFA has not been without its shortfalls and weaknesses:

  1. Alert Fatigue – The act of spamming a user with prompts until they accidentally press allow or allow it because they think the problem will go away
  2. Sim Swapping – The act of convincing a phone provider to allow a phone number to be swapped and used to bypass phone based MFA

As an industry, we have adapted to these weaknesses and re-enforced our protections. But, as with any advancement in our defences and protective measures, the offensive team adapts too to try and overcome them.

Gone Phishing

Traditional phishing sites relied on tricking users into clicking a link and then typing their credentials into a form. Once submitted, these credentials are then stored ready for an attacker to use. The attacker might then implement some automation and reuse the credentials straight away, tricking the user into allowing an MFA prompt if they are careless, or use alert fatigue in the hope that this will wear down the user into allowing them access.

As time moved on, this traditional method became easier to defend against. Users became educated against these threats and what to look for pre- and post-exploitation. Enter a new attack method: The Adversary in the Middle (AiTM).

A number of tools exist to perform AiTM attacks but this blog will concentrate on one of the more well known, EvilNginx.

Released in 2017, EvilNginx was quickly adopted by red teamers as a way to bypass MFA during engagements due to its ease of use and adaptability. EvilNginx has the ability to proxy phishing pages back to the legitimate logon page, capture the session token and then allow the red teamer to logon and bypass any second factor authentication that may have hampered them previously.

Microsoft Threat Intelligence

Fig.1 – Credit: Microsoft Threat Intelligence

These new AiTM attacks still rely on a certain level of trickery to convince the user that this is a legitimate link and they need to pay attention to it. EvilNginx helps with this somewhat by enabling HTTPS as default via a request to LetsEncrypt. However, a convincing URL is still needed. (A zip URL maybe?)

The rest is down to the attackers ability to craft a convincing “Phishlet”. Phishlets are small configuration files, used to configure Evilginx for targeting specific websites, with a goal of perform phishing attacks.

There are numerous blogs and guides available for setting up the tooling, so this article will focus on the results.

Demo Setup

  1. Platform - Azure
  2. OS - Ubuntu 22.04
  3. Domain - sentinel-lab.com
Fig 2

Fig. 2 – Office 365 lure created and sent out as part of a phishing or spear phishing campaign

UK_blog_Fig_3

Fig. 3 – MFA requested as normal

UK_blog_Fig_4

Fig. 4 – Redirected to Microsoft as expected. Notice the URL is still sentinel-lab.com and not passed direct to Microsoft. The session is still living inside the proxy.

UK_blog_Fig_5

Fig. 5 – Session token stolen ready for reuse

How to defend against AiTM attacks

Although this new generation of phishing is more advanced there are still protections that we can apply. Monitoring logs for these types of attacks is becoming easier as more log sources become available to us, but building our defences against AiTM attacks can take a number of different forms

Policy

  1. Conditional Access: Setting up a strict Conditional Access policy in EntraID (Azure Active Directory) goes a long way in restricting access to low hanging fruit. 
    - Allowed Countries – From where is your userbase most likely to log on? Only bypass this policy for short-term trips and confirmed business travel. 
    - Registered Devices – Only allow access to devices registered through Intune and EntraID. This can be tweaked to still allow personal devices or Bring Your Own Device (BYOD) policies.
  2. Fido2 Security Keys: Passwordless security keys are becoming more widespread and common in both enterprise and at home..
  3. Certificate based Authentication: Deployed using MDM or in-house deployment methods.

Training

  1. User education still needs to be the core of any internal security program. To reduce the success of phishing attacks, we can teach users to spot key indicators like:
    - URL – does it look phishy?
    - The language in the email – are there spelling or grammar mistakes?
    - Is this request expected or unexpected?
  2. Build a culture of trust. Phishing happens and mistakes happen. Ensure that users are open about what links they click reduces attempts to hide their mistakes and reduces the blast radius should the attack be successful. Users should be encouraged to report potential phishing, especially after they have fallen for the phish.

Detections

If you have EntraID P2, you can access the AADSingInEventsBeta table with Microsoft Sentinel and build out detections and hunting queries to discover and alert on this attack in real time.

Use the code below to do so:

let OfficeHomeSessionIds = AADSignInEventsBeta | where Timestamp > ago(1d) | where ErrorCode == 0 | where ApplicationId == "4765445b-32c6-49b0-83e6-1d93765276ca" //OfficeHome application | where ClientAppUsed == "Browser" | where LogonType has "interactiveUser" | summarize arg_min(Timestamp, Country) by SessionId; AADSignInEventsBeta | where Timestamp > ago(1d) | where ApplicationId != "4765445b-32c6-49b0-83e6-1d93765276ca" | where ClientAppUsed == "Browser" | project OtherTimestamp = Timestamp, Application, ApplicationId, AccountObjectId, AccountDisplayName, OtherCountry = Country, SessionId | join OfficeHomeSessionIds on SessionId | where OtherTimestamp > Timestamp and OtherCountry != Country

Building an adequate defence against phishing attacks requires a combination of people, process and technology. While AiTM attacks may be a new approach for attackers to bypass MFA, our defensive measures can be updated using the same principles – hardening policy controls, introducing better detection measures, and most importantly, training users to spot something phishy.

Get in touch to find out more about how Endpoint Detection and Response and Managed Detection and Response services can help bolster your defensive capabilities.