Insights

While Adversary in the Middle (AiTM) phishing attacks are not new, we have noticed a recent increase in the use of AiTM phishing attacks from our Cyber Security Operations Centre (CSOC). We are publishing information to help further increase the awareness within the community.

In this article, we explain what an AiTM attack is and how organisations can utilise Microsoft 365 tooling to detect and respond, as well as mitigate this threat. We will also outline any differences in capabilities between Microsoft 365 licensing options.

While AiTM phishing is a fairly complicated attack, this article will not provide a technical deep dive. However, we have provided resources at the end of this article to link to relevant articles on the Microsoft Security blog.

We will not demonstrate how to perform an AiTM attack in this article, however we have an excellent demo video to show how it works – please get in touch if you would like to see it.

What is an Adversary in the Middle (AiTM) phishing attack?

Phishing is one of the most common techniques that an attacker will use in their attempts to gain initial access to an organisation. Multi-Factor Authentication (MFA) provides an additional layer of protection against credential theft, and it’s expected that MFA adoption will continue to rise, with many governments mandating it – for example, the UK Cyber Essentials standard requires MFA for all cloud services.

With MFA providing protection and more organisations adopting it, attackers are having to evolve and to find new ways to circumvent MFA.

All modern websites implement sessions with a user after a successful authentication, so that the user doesn’t require re-authentication at every new webpage they visit. This is implemented by using a session cookie that is provided during authentication, which is essentially proof that the user has completed authentication. In AiTM phishing attacks, an attacker attempts to steal their targets’ session cookie so that they can sign-in as their target and bypass the authentication process by re-using the cookie.

NOTE: AiTM does not mean that there is a vulnerability in MFA itself. AiTM phishing works by stealing the user’s legitimate session cookie and then re-using that cookie. MFA is still essential and a foundational security measure.

AiTM phishing attack overview. Source: Microsoft

How it works

An attacker will host a proxy server and will configure their malicious domain name to direct to the proxy server. In targeted attacks, it’s common for an attacker to purchase a domain name that is very similar to their organisation’s legitimate domain name. For example, if your organisation domain was contoso.com, an attacker may purchase conttoso.com.

We have also observed attackers creating a simple webpage that has a similar look and feel to the target organisations legitimate website.
The attacker will then create and send a phishing email to their target. The phishing email will be intended to look like a legitimate email, and may inform the user that they’ll need to sign in. Common examples of this are voicemails, or a file being shared.

The user clicks the link, and they are directed to the attacker’s web proxy, which immediately proxies the user to a legitimate sign-in page for Microsoft 365. The URL for this is login.microsoftonline.com, but as this attack is proxying via the web proxy, the URL will display as login.conttoso.com. We have also observed attackers using DNS CNAME records to further obfuscate the actual domain. An example of this is “login.loginmicrosoft365office.conttoso.com”. This will serve to hide the actual domain name, and make it harder for users to determine legitimate versus illegitimate. The user enters their credentials and completes MFA and are then directed to any other website. At this point, the attacker has retrieved the username, password, and MFA session cookie. The user is then likely not aware that they have just been breached, and in most cases, suspects that the link did not work, and continues their day.

The attacker will then proceed to sign-in as the user, using their session cookie to meet authentication requirements, including MFA requirements, and proceed to perform various malicious actions such as adding email inbox rules to hide their presence, target other individuals internally and externally, and possibly evolve to financial fraud, such as directing the finance department to make a payment.

The AiTM process can be fully automated using open-source phishing toolkits.

AiTM interception overview. Source: Microsoft

What’s the point in MFA then?

While this attack does allow an attacker to meet MFA requirements, it does not mean that MFA itself is flawed or unnecessary. MFA is a foundational component of identity security and that is not changing any time soon. The fact that AiTM attacks exist is testament to the strength of MFA, and the ever-increasing adoption of MFA. This attack did not exist before MFA was common, as it was never required.

How can I protect my organisation against AiTM attacks?

While there are specific items that will stop this type of attack dead in its tracks, security requires a multi-layered or defense in depth approach. While you could scroll down to the prevention section, and immediately implement those preventions, you will still be leaving your organisation open to other potentially unknown, or uncommon threats.

This attack showcases how security is an ever-evolving landscape – blue teams and red teams are constantly trying to one-up each other, and always will be. Security is a journey, not a destination.

To stay ahead of evolving threats, your organisation must implement prevention measures (and regularly review these), as well as having ongoing detection and response capabilities to detect any active threats or successful breaches.

Detect and Respond

Detect

Microsoft security products offer numerous advanced detection and response capabilities – this is one reason why we have built our Managed Detection & response (MDR) services on these technologies.

Microsoft recently announced that automatic attack disruption capability for AiTM attacks had become generally available. This automatic response will trigger based on a high-confidence identification of an AiTM attack, from multiple correlated Microsoft 365 Defender signals.

In addition to the above automatic disruption capability, additional alerting should be leveraged.

Microsoft Defender for Endpoint will raise an alert when it detects a user accessing a potential phishing website.

Microsoft 365 Defender will alert when a stolen cookie was used.

Microsoft Defender for Office 365 will alert upon the creation of a forwarding/redirection inbox rule. In addition, we recommend reviewing the age of a domain that’s used within an attack. Approximately 70% of newly registered domains are found to be malicious.

Microsoft Defender for Cloud Apps detects AiTM phishing and business email compromise (BEC) attacks by using the following alerts:

• Suspicious inbox manipulation rule. As part of an AiTM/BEC attack, attackers set inbox rules to hide their activities. This action is not normally performed by users, and is therefore suspicious behaviour. This alert will notify security teams when this happens for investigation.
• Impossible travel activity alert. If your users normally sign-in from the UK at 9AM, but then one of your users also signs-in from New York, an hour later – that’s impossible. It is not possible to travel to that location within that time and could indicate the user is compromised, and their account is being used elsewhere.
• Activity from infrequent country alert. Attackers may use VPNs or proxies to hide their true location however the egress location of these services might be uncommon based on the user’s previously monitored sign-in logs, raising an alert for investigation.

Entra ID Identity Protection automatically detects identity-based risks and suspicious sign-in attempts, and raises any of these alerts:

• Anomalous Token use. This alert will fire when a token is used with unusual characteristics, such as being used from an unfamiliar location.
• Unfamiliar sign-in properties. This alert will fire when a sign-in occurs with properties such as device and location that do not match previously observed sign-in properties for the user.
• Anonymous IP address. This alert will flag any sign-in attempts from anonymising services, such as an anonymous VPN service or the Tor browser.

Respond

Responses will vary depending on the severity of the attack, but as a general rule of thumb, you should perform the following actions to remediate the compromised identity:

• Revoke session cookies and reset password.
• Review and revoke MFA setting changes made by the attacker on the compromised user. For example, remove any unknown or unexpected MFA methods.

Your organisations CSOC should monitor and respond to these alerts as soon as possible.

Prevent

Detection and Response is a key component of responding to threats in real time, however once a threat and its prevention methods are identified, they should be implemented as soon as possible.

There are three main areas to look at when preventing this type of attack. The first is understanding MFA methods, and the protections that offer. The second area is phish-resistant MFA methods. The third is Entra ID Conditional Access controls, and the protections offered.

MFA Methods
No standard MFA method will protect against AiTM.

Phish-resistant MFA methods
Hardware-backed MFA methods will provide protection against AiTM.

Conditional Access Controls
Conditional Access controls which require device state information, or require specific network location, will provide protection for AiTM.

For many organisations, the simplest approach to mitigate AiTM is to immediately implement device compliance controls. By enforcing device compliance state in Intune as an access control method, you are ensuring that only devices that are enrolled in Intune and align to compliance policies are permitted access. This is the suggested approach for immediate mitigation for organisations that use Entra ID natively.

For organisations that utilise on-premises Active Directory and are not yet in a position to adopt compliance policy controls, we would recommend configuring Hybrid Entra ID Join, and leveraging that as the control.

Lastly, trusted locations can also be applied, however this is less dynamic than device compliance state.

Licensing Requirements

Throughout the “Detect” and “Prevent” areas of this article, various technologies were referred to. We’ve outlined a table below, that includes the minimum required license, as well as any notes.

Please note, Microsoft licensing can be quite complicated, and it is possible to extract further value for money using multiple add-on licenses. We have simplified the above table in the interests of brevity however if you would like to explore the alternate add-on licensing options, please get in touch.

Resources

For further reading and detail into AiTM, we recommend these resources:

• Stop attack progression with automatic disruption of ransomware and BEC attacks (microsoft.com)
• From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud | Microsoft Security Blog
• Detecting and mitigating a multi-stage AiTM phishing and BEC campaign | Microsoft Security Blog
• Microsoft 365 licensing datasheet
• Automatically disrupt adversary-in-the-middle attacks with XDR (microsoft.com)