In-Depth

Adversary in The Middle (AiTM) Trends

We're going to be seeing more of these attacks, says our one-man SOC from Down Under, who explains how Zero Trust and phishing-resistant MFA can help.

Is your business enforcing Multi-Factor Authentication (MFA) when you login to your computer or cloud services? Perhaps you're using an app on your phone to do this? If they're not, they absolutely should but the type of MFA they enforce it is crucial.

There are three types of businesses: those who haven't started enforcing MFA yet, those who have but picked the "wrong" MFA, and those who are using phishing resistant MFA.

In this article I'll look at trends of Adversary in The Middle (AiTM) attacks over the last couple of years and cover how Microsoft and a business called Lab539 tackles AiTM, each with their own angle. It's a follow-on from my in-depth article from October last year where I described how AiTM attacks work, options for Authentication strength in Entra ID, and variants such as Browser in The Middle -- which uses Remote Desktop Protocol connections instead -- and how a user at one of my clients was successfully phished and entered her credentials on a AiTM site.

Here, I'm going to go deeper on two approaches to identifying these sites and block them before they even get in front of your users. However, even in businesses that have gone through the huge project of moving everyone to MFA with all the user training, technical enablement and so on that this entails, if you're not using phishing-resistant MFA, your users are still at risk. But, while you go back to leadership to convince them to add more budget for your "next MFA project": moving everyone to Passkeys or FIDO keys, the solutions outlined here provide good protection until that project is completed. And while you're at it, complete a thorough threat model for your organization, something that certain people have yet to learn apparently.

One note -- the obvious question is -- can phishing resistant MFA be bypassed? The answer is of course yes, but doing it at scale seems to be impossible, at least for now. This article shows a real-world bypass of Passkeys (the flaw has since been patched) and there are various approaches for defeating Windows Hello for Business; it'll be interesting to see if cyber security researchers come up with other methods.

Lab 539
As I was researching what options I could use to protect my SMB clients against AiTM I came across Lab539 and tried out a subscription. Turns out it's easy to set up and configure, and these are traits I value (as a one-man SOC) in a security product. Based in the UK, they provide a service called AiTM Feed, which feeds into Entra ID's Conditional Access policies in real time, automatically blocking AiTM backend infrastructure that the attackers have stood up.

Full disclosure -- I have no financial relationship with Lab539, apart from being a customer.

Lab 539 AiTM Feed Portal
[Click on image for larger view.] Lab 539 AiTM Feed Portal

Initially there was only an AiTM feed that I could incorporate into the CA policies of each client, but recently they added Tor exit nodes, Stark Industries Solutions and XHOST Internet Solutions LP. That last one is the front company for ZSERVERS, which was a key component of the Russian cybercrime supply chain as a BulletProof Hosting provider (BPH), which was recently sanctioned. Stark Industries is also a BPH, which occasionally also hosts legitimate content.

Here's what the portal looks like with my clients connected, with their feeds being enabled:

Lab 539 AiTM Portal CA Policy Feeds
[Click on image for larger view.] Lab 539 AiTM Portal CA Policy Feeds

There are two ways to connect these named feeds into your CA policies, one is through the self-hosted method where you don't want to grant permissions to Lab539 in your Entra tenant, and instead have to create a Logic App in Azure (or you can use Azure Functions) and grant that app permissions. This app then uses the API key that's provided as part of your subscription to update the Named Location objects with the IP address ranges as they're added.

The simpler approach that I used is having the right permissions, either the Application Administrator or Conditional Access Administrator role will work, or a custom role with the specific permissions Policy.ReadWrite.ConditionalAccess and Policy.Read.All, along with scope=offline_access. Login to the Lab539 portal, click on the box and enter the username you want to use in each tenant, approve the permissions and this will create the Named Locations in the Entra ID tenant.

Named Locations in Conditional Access Policies
[Click on image for larger view.] Named Locations in Conditional Access Policies

Now all that is left to do is create a CA policy with these locations and a Grant with the setting of Block. This policy covers all resources (used to be called All cloud apps), but as is standard practice I have two break-glass accounts excluded from the policy.

CA Policy that Blocks Access to Any of the Four Named Locations
[Click on image for larger view.] CA Policy that Blocks Access to Any of the Four Named Locations

In short -- Lab539 tracks down attacker backend infrastructure and adds their IP addresses to the AiTM feed, which is delivered to each Entra ID CA policy in real time. If an attacker (that Lab539 has identified) sends a phishing email to a user at any of my clients, and they click on the link they'll be blocked from accessing the site as its IP address is blocked by the CA policy. I'm using Microsoft Sentinel as the SIEM for my clients and I have an analytics rule in place to flag if a user is blocked by this, but so far, I haven't had a hit.

This is probably a combination of good email hygiene (Defender for Office 365) filtering out most of the phishing emails before they even reach the users mailboxes, and well-trained users. I use phishing simulations for my clients to train them to be careful when clicking links in emails. But cybersecurity is all about layers, so I trust that when an email slips through the filters, and a user isn't cautious enough, this solution will be there to protect them.

At the time of writing there were 1,324 IP address ranges in the AiTM feed:

IP Address Ranges in the AiTM Feed
[Click on image for larger view.] IP Address Ranges in the AiTM Feed

It's worth noting that the IP addresses that feed into the Named Location feed are backend attacker infrastructure. In some cases, the front end phishing page is cohosted with it, but in other cases the web pages are hosted on Cloudflare, for example. Front-end infrastructure isn't fed into the Named Location feed but is available from the API that's part of the subscription. My next project is seeing how I can take hostnames (both domain names and IP addresses might also catch legitimate resources) and feed them into custom network indicators in Defender for Endpoint to block them that way.

The Rise of Attacker in the Middle Assaults
Lab539 held a great webinar early in 2025 where they shared statistics and insights from 2024 for AiTM, here are some interesting findings.

AiTM attacks are on the rise -- no surprise there, as businesses move to deploy MFA broadly, attackers simply use AiTM kits as a standard tool to ensure they can trick both MFA and password only users.

AiTM Distribution Per Month 2024 (courtesy of Lab539)
[Click on image for larger view.] AiTM Distribution Per Month 2024 (courtesy of Lab539)

My guess would have been that the attackers would have automated the process of "purchase domain, deploy infrastructure, send out phishing emails," as most phishing kits assist with several of the steps, but it turns out that the time between purchase and use can be quite lengthy.

Time Between Domain Purchase and Domain Use for AiTM (courtesy of Lab539)
[Click on image for larger view.] Time Between Domain Purchase and Domain Use for AiTM (courtesy of Lab539)

DigitalOcean is the preferred hosting provider (21%) with AWS in second place, and Cloudflare third. Nearly half (49.3%) of all AiTM infrastructure is hosted in the U.S., with Netherlands in second place, and Germany in third. Namecheap is the most preferred domain registrar at 30.4%, with Hostinger in second place.

The Other End of Town - TITAN
The approach of identifying and blocking attacker infrastructure isn't just the domain of Lab539, of course, as all the large cloud providers are doing it as well. Microsoft, the world's largest cybersecurity company, had a great breakout session at Ignite 2024 where they (amongst other things) talked about TITAN. The latest figure is that Microsoft gathers 78 trillion risk signals every day -- TITAN is one way they use this huge pool of data to thwart attackers.

Attackers' infrastructure consists of C2 servers, phishing kits and so on, and traditionally analysts would have to identify these artifacts and then make sure they're blocked in the relevant security services (block email from this mail server, block malicious files with this hash, block connections to this IP address as it's an AiTM page). The problem here is that there's a time lag in this process, making attacker's infrastructure very effective early on.

With Threat Intelligence Tracking via Adaptive Networks (TITAN -- yes I know it sounds like a backronym), the very first time an attacker gains a foothold in an organization, the identifying information from the attack is fed into the TITAN database, effectively blocking the next attack in any other business (where Microsoft XDR / Sentinel) is used. Furthermore, the TITAN database is graph based and maps the relationship between different indicators and artifacts, and through using "guilt by association" can block new infrastructure before it's even been used. This machine learning-based approach means that Threat Intelligence (TI) Indicators of Compromise (IoCs) aren't limited by human analyst speed but are instead identified automatically. If you read the paper, they've seen some very impressive numbers from this approach. TITAN is generally available and in use by the different security services Microsoft offers.

Conclusion
Because of the incredible amount of money that can be earned, along with a low bar of entry and near-zero risk from law enforcement in the countries where most of the cyber attacks come from, we're going to see more attacks and adaptations of these attacks on our businesses for the foreseeable future. Therefore, adopting a sensible, Zero Trust-based approach to protecting our digital infrastructure is prudent, and including strong protections against AiTM tricks, at least until every sign-in is performed using phishing-resistant MFA, is a must.

Featured

Subscribe on YouTube