Intercepting MFA. Phishing and Adversary in The Middle attacks

3 of my last 5 business email compromise investigations have involved an Adversary in The Middle (AiTM) attack.

Even the more security-aware people with bolstered Microsoft 365 (M365) configurations are coming up blank as to how their comprehensive MFA policies have been bypassed.

It’s a technique we have been using in our Red Team engagements, typically to get access to client services.

With many organisations moving to using M365 SSO for all connections, including VPNs, Citrix NetScaler and other remote access services, the impact of compromising cloud credentials such as Azure/Entra ID credentials can be devastating.

In this post I’ll show you at a high level how attackers carry out such an attack. The main focus here is to understand what artefacts we look for when investigating these types of attacks in a DFIR capacity. I’ll also cover the steps you can take to increase your security to try and stop your team falling foul of them.

TL;DR

• Adversary in the Middle and email phishing attacks are re-purposed to steal MFA tokens from target users.
• Links to reverse proxy servers that relay a legitimate Microsoft sign-in pages are sent, usually with obfuscated links embedded in an email message or attachment.
• The attacker will then try to manipulate gaps in the target network’s conditional access policies, allowing them to masquerade as the user and gain a foothold before securing further access.
• Commonly, this attack then progresses into a fraudulent attempt to steal money internally, or from a third party related to the victim’s organisation in some business capacity. However, it is also being heavily abused by ransomware threat actors at APTs to gain initial access.
• MITRE ATT&CK Techniques:
  • Spearphishing Link (T1566.002)
  • Steal Application Access Token (T1528)
  • Adversary-in-The-Middle (T1557)

Methodology

This diagram describes each step in an AiTM attack. It’s based on figure 1 in the excellent Catching Transparent Phish: Analyzing and Detecting MITM Phishing Toolkits paper (by Brian Kondracki, Babak Amin Azad, Oleksii Starov, and Nick Nikiforakis) presented at ACM SIGSAC Conference on Computer and Communications Security (CCS) 2021:

1. In our investigations, an email or external Teams message is sent to target users. It is not unusual for these emails to come from trusted third-party companies that have been compromised, thereby passing through email security that might otherwise flag unseen or unusual external senders.
2. The victim will be encouraged to access a link and upon clicking that link will be directed toward the malicious proxy server.
3. The malicious server will proxy the traffic and present the victim with the legitimate sign on journey.
4. When the victim enters their credentials, the proxy server will forward them to the legitimate site, usually triggering an MFA request, which again, when entered will be forwarded to the legitimate service.
5. This then creates a session token, which is captured by the proxy service. The attacker then simply adds this to their browser and refreshes and they are then logged in as the user.

The proxy server is able to snoop on the credentials due to creating 2 separate TCP connections, 1 to the malicious proxy server, and the other to the legitimate website. Therefore, before repacking the credentials back up in TLS encryption, the proxy server has full sight of them from the victim. From the victims perspective the only element that is invalid is the domain. Everything else is dynamically proxied to the end user from the real service.

The following screenshot isn’t the real M365 service. It’s a legitimate Microsoft landing page served up through a malicious URL and proxy. If the target company had Azure AD branding setup on their tenant this would show up too:

Forensics

This is a simple email from a previously known third party company. Due to that trust relationship it was able to evade unconfigured Microsoft Defender’s filters:

Looking at M365 logs we can see what has happened. The victim signs in as usual, prior to the attack. The IP address, location, Device ID and compliancy status all check out.

At some point just before 13:30 an email is received and, unfortunately the link is clicked.
The two login events from the red IP address are the proxy server, with the first entry showing that Microsoft has interrupted the login and requested an MFA authentication.

Directly after, the events in blue suggest that the proxy has likely redirected the victim to the legitimate Microsoft login URL, encouraging them to sign in again. Unless the malicious URL has been spotted by this point, to the end-user there is  little evidence to give the game away that anything nefarious has taken place.

What we see afterwards in purple is the attacker using the session token to authenticate as the user and move throughout the client apps and resources that are now available to them. In this case they setup a series of forwarding rules to capture mail, and added an SMS MFA method to maintain access.

Note that the user agent has changed from some unusual pythonic reference (hinting at the AiTM toolkit in play) used to a different device and IP address. This also provides a little insight into the capability of the attacker and the degree of targeting being used. More advanced attackers would change the user agent to match the expected victim’s agent and would geographically locate their servers within the same country as the victim to hamper investigative efforts.

Querying the first malicious IP address, we  quickly see the staple 3128 port number, used by a whole bunch of web proxy servers, showing as open on the Shodan search engine:

Toolkits

These artefacts aren’t always so obvious, and as stated more advanced attackers will take steps to change user agents, use different ports and implement a whole host of domain cloaking and obfuscation.

The most common toolkit used for AiTM phishing is Evilginx, and version 3.0 of this tool offers Improved TLS certificate management, iFrame embedding and URL redirection through JavaScript. All aimed to offer a more seamless and less identifiable credential harvest.

It’s ridiculously simple to spin up an instance and find tailored “phishlets” or templates to target your website of choice. Phishlets for sites like Github, Facebook, Blockchain, Protonmail, Gmail and more were all readily available online.

Here is a basic demo I created to show credential captures from a locally running proxy:

Evilginx works by hosting its own DNS server and automatically creating all TLS certificates needed using the Let’sEncrypt API. This significantly lowers the barrier of entry for attackers, allowing even the least technically adept to launch their own phishing campaigns. This took me all of 5 minutes to build. This shows the Username and Password captured. You can also get Evilginx to display the session cookie which can then be added into your own browser:

Prevention

One of the most effective controls against this type of attack is a well trained workforce able to spot suspicious emails with non-standard URLs, though this is easier said than done when attacks can easily come from known email domains, and, aside from the URL, the login portals are effectively legitimate. Training your team to always be alert to attacks, especially those from external emails and attachments is simply critical!

There are some easy wins below that would have helped mitigate the above attack from taking place when applied to a comprehensive defence strategy.

Use a password manager

Provide a password manager to all staff to store and manage credentials. If you attempt to log-in to a phishing page hosted on a website that the password manager does not recognise, the password manager will warn you before entering your credentials.

Set geographical restrictions

Locations are key. Microsoft’s location resolving isn’t the best. But it can help filter out low hanging fruit. Using Conditional Access policies to restrict countries to just the UK can help. If your employees don’t travel, why allow login attempts from the USA for example?

Geographical restrictions can be enhanced further by enabling Microsoft Defender for Identity Protection (MDI). Over time Azure AD can build up a picture of regular behaviour of users based on uncommon location or source IP addresses, sign-in hours, device fingerprints etc. Any deviation in these patterns can raise the sign-in risk score, and determine the likelihood of an identify-based attack. Conditional Access (CA) policies can be then used to deny access, require MFA or even lock the account down, alert admins and trigger password reset commands.

Here’s an example of geographical tiering restrictions:

Going deeper into Conditional Access policies, the victim organisation in the example above had some solid coverage, including:

• Legacy Authentication had been disabled.
• MFA was enforced on all connection attempts to all resources.
• BYOD had been segregated with multiple policies in place to allow-list access to specific client apps.

It appeared though that browser access to applications such as Office.com and Outlook Web Access (OWA) was permitted on non-compliant devices and devices that are not enrolled onto the Azure AD/Entra ID. Although this is a reasonable approach to take within an organisation, in this instance it had enabled the threat actors to gain access to Office.com.

We can see in other audit logs that the malicious devices used in the attack were neither managed nor compliant, but yet they were still able to access company email and set auto-forwarding rules causing even greater damage.

Use pre-set anti-phishing polices

We can also look to enable Microsoft Defender for Office 365’s pre-set Anti-Phishing polices that will automatically shield users from these emails entering their inbox.

Setting the Phishing email threshold to “More Aggressive” and above can have a measured impact by stopping spoofed and impersonated emails slipping through. In addition, you can fine tune pre-sets and create custom policies to cater for certain user groups like administrators or executives.

Use URL filtering

Many organisations implement a URL filtering solution at the network boundary. It’s not bullet-proof, but even the basic options would provide allow/deny listing, and community sourced lists of malicious domains. If you’re prepared to invest in a premium solution, the learning algorithms adopted are able to spot and block phishing sites in real time, and they’re getting pretty good.

Enable safe links and attachments

Other options further down the chain can include enabling Safe Links and Attachments within M365. This won’t filter email, but rather detonate files and URLs at click time in a sandboxed environment, warning users before they proceed. These features can also extend to Teams, OneDrive and other Office apps, but do check your Microsoft licencing for this.

Apply FIDO standards

It’s worth sharing a few thoughts on Identity and Access Management (IAM) services and how they tackle this problem. Companies such as Okta offer a tonne of cloud-based identity assurance options, but they also utilise the FIDO family of standards for MFA and passwordless authentication.

FIDO2 is the newest set of specifications from the FIDO Alliance. It enables the use of common devices (such as apps, fingerprint readers and hardware security keys) to authenticate to online services using unique cryptographic login credentials for each individual site. Whereas currently, cloud services typically validate end users based on credentials in the form of login forms, FIDO2 essentially removes the need for a human to provide a password to authenticate.

This is facilitated by the use of “WebAuthn” API calls from FIDO2-enabled websites to end user web browsers. By performing authenticity checks automatically, this all but removes human decision making from the equation, flagging malicious websites up to an end user almost instantly.

The key benefit offered here is that even if credentials were to be passed to an attacker on a malicious AiTM website; the FIDO credentials are designated for that exact domain string ONLY. So they could never be used for a legitimate Microsoft app. This is called verifier impersonation resistance.

One of the most effective technical controls is to use FIDO2. FIDO2 is the newest set of specifications from the FIDO Alliance. It enables the use of common devices (such as apps, fingerprint readers and hardware security keys) to authenticate to online services using unique cryptographic login credentials for each individual site. Whereas currently, cloud services typically validate end users based on credentials in the form of login forms, FIDO2 essentially removes the need for a human to provide a password to authenticate.

Conclusion

We are seeing more of these AiTM attacks in our investigations, and effectively combatting them takes a multi-faceted approach. It’s up to an organisation AND its individuals to prioritize the implementation of protection mechanisms and security awareness to stop these attacks before they even pose a threat.

The tools in play are better than ever. Version 3 of Evilginx is a fully comprehensive, extensible phishing attack framework, even circumventing some of the forensic opportunities discussed above. Attacks often leave sysadmins dumbfounded as to why their MFA reinforcements have completely failed them.

But whilst preventing them is hard, with some mitigation we can make it harder to carry out and easier to spot when it does happen. Education is everything, and frequent briefings to employees about vigilance, non-complacency and dis-trust of any attachment or unexpected email is paramount.

Finally, a lot of protection can be added with a solid 365 configuration. Top-tier defences like FIDO2 identity mechanisms represent the next rung in methods used to combat authentication attacks. Commercial adoption will ensure its widespread use on all web services. It is a free open standard and most importantly takes the human out of the decision making.