AiTM Detection
Adversary in The Middle Introduction
In recent years AiTM attacks have surged. They are currently the primary way we see organisations compromised and they are often extremely difficult to detect because they directly mirror typical authentication flows, even circumventing most Multi Factor Authentication (MFA) controls.
A typical AiTM flow looks something like this:
Firstly there is a victim who is lured to an AiTM frontend (e.g. a phishing page). This is hosted on infrastructure controlled by an adversary and is where a user will be tricked into entering their credentials. These credentials are proxied via the attackers infrastructure to the entity being impersonated (in this case Microsoft). Essentially the adversary captures those credentials and then uses them to log into Microsoft themselves (hence the term Adversary in The Middle).
If MFA is in use then an MFA challenge will be initiated. In the case of Microsoft Authenticator, this will typically be an out of band push notification will be sent to the user phone for them to respond to. And in addition to this the numerical code will be sent to the adversary which will then be proxied to the user and displayed in their web browser as the code to enter in their Microsoft Authenticator app.
From the users perspective, this almost exactly mirrors the authentication flow that they expect from Microsoft and, seeing as they have been lured into entering their credentials in what they believe to be a legitimate Microsoft website, they will be expecting this push notification so will likely enter the code they have been displayed and approve the MFA challenge.
The moment the MFA challenge is approved the adversaries session becomes authenticated. This session ID is the valuable asset that the adversary is after.
The AiTM Evolution
Before MFA was widely adopted there was no need to immediately proxy credentials, they could simply be captured for later use. However, where MFA is in use the credentials alone are not sufficient, an adversary needs that additional factor. As a result they need to immediately perform authentication in order to trigger this MFA challenge.
Whilst most AiTM toolkits will still capture credentials, MFA should mean that these alone are of no use to an adversary. When MFA is in use, it is the authenticated session ID that the adversary requires.
This is why, if you ever suspect that you or one of your users has been the victim of an AiTM attack terminating active sessions is always a worthwhile, although not always sufficient.
APIs And Automation
One thing that has allowed AiTM attacks to surge is the exposure of identity providers to the public internet. When businesses operated on premise Active Directory (AD) there was no single place that authentication for millions of organisations could be performed. Now that many businesses have migrated to the likes of Microsoft Entra and other similar identity providers there is not just a single location that can be targeted to hit lots of businesses, but there are also really useful APIs meaning that an adversary, compromising an account, can automate activities the moment they gain access to a validated session. Common automations we see are the addition of MFA devices and the creation of email rules to help maintain persistence.
Legitimate Services
Another common technique used in AiTM campaigns is the use of legitimate infrastructure. We've blogged about Azure Front Door being used for exactly this. But that is just one of many other examples. Essentially, any legitimate website that can be used to host content or redirect users is a potential source for this - think things like code repositories, storage buckets, and online development platforms. We also see anything that allows for an open redirect being used too, including cyber security URL rewrite tooling being used as part of these chains. The goal of adversaries is really to utilise things that security tooling is not going to block (because it is predominantly legitimate) as part of their redirect chain or hosting infrastructure.
This approach to evasion is interesting. Partly it is about evading detection by hiding within things that security tooling is going to consider safe so that the user receives no warnings. But there are also another couple of components to this too. The first being: providing the adversaries an opportunity to "vet" visitors - it's often relatively straightforward to detect bot activity or security crawling activity, so a gate to control this is a great way to make things look safe to security tooling whilst redirecting real victims to the malicious content. The other angle is around simply making it difficult to block even if a detection is made. You can't block that legitimate service which is being used without causing unnecessary disruption, so the challenge then becomes "how specific can you make the detection in order to avoid over blocking?" which itself comes with the challenge - a very specific block might block that specific instance, but it probably won't block all other instances including those that you have not yet detected.
Legitimate services is a great masking technique, and one that definitely makes the defenders job hard. It's not exclusive to frontend infrastructure, but is definitely far more prevalent there than in the backend space.
Frontend and Backend Infrastructure
At Lab539 we track both frontend and backend infrastructure used in AiTM attacks. Our goal is to identify infrastructure before it is used in attacks so that we can block attacks before there are victims. This is fundamentally different to how most of the industry operates where there is either a focus on detecting attacks as they are occurring, or after they have occurred, and predominantly on the frontend infrastructure.
When we talk about frontend infrastructure, typically we are referring to phishing websites that mimic the impersonated entity in order to trick a victim into providing what is required in order to gain access to a validated session. Phishing sites have existed for years and techniques for detecting them constantly evolve, as do techniques for evading detection. This does not mean that it's not a fight that defenders shouldn't fight, it's just it's a tough battle, essentially a constant game of whack-a-mole, but with an awful lot more moles.
Whilst we do detect and share frontend infrastructure in our feed, our focus at Lab539 is actually on identifying the backend infrastructure. The reason we do this is that, whilst it is trivial to create thousands of "frontends" to lure unsuspecting victims in, it is far more difficult and expensive to create thousands of sets of backend infrastructure. We definitely see this being done, but not to the same rate or with the same ease as we see with frontend infrastructure. In fact we typically see multiple frontends, potentially thousands, using the same backend infrastructure, often over a time-period of multiple months, and we also see re-use across campaigns. Essentially, the frontend infrastructure is far more expendable than backend. So, right now, disrupting the backend has a far greater impact; identify one set of backend infrastructure and prevent it from authenticating to your IDP and you likely kill multiple AiTM campaigns in their tracks. - As an added bonus, when you find the backend infrastructure you often get the frontend infrastructure for free!
It's not harder or easier to identify backend infrastructure vs frontend infrastructure, but it does take different techniques. At the moment we are finding identifying and disrupting backend infrastructure to be far more effective than frontend, but as other cybersecurity companies move into the proactive defence space and start sharing IOCs we do expect the way backend infrastructure is handled to evolve too.
