A large amount of the incidents we are called in to respond to are Business Email Compromise (BEC) attacks. From that BEC, we quickly establish that the initial attack vector is an AiTM attack.
So what is it? – Good question, but first, let’s look at the attack surface.
Business Email Compromise incidents are typically tied to a successful phishing attack. Phishing remains one of the most common techniques attackers use in their attempts to gain initial access to organisations.
Traditional Multi-Factor Authentication, along with various other security controls, has been the “go-to” however, the attackers have evolved their attack methodologies to a far more effective method.
Enter AiTM.
In AiTM phishing, attackers deploy a proxy server between a target user and the website the user wishes to visit (that is, the site the attacker wishes to impersonate). Such a setup allows the attacker to steal and intercept the target’s password and the session cookie that proves their ongoing and authenticated session with the website.
It is important to note that this is not a vulnerability in MFA; since AiTM phishing steals the session cookie, the attacker gets authenticated to a session on the user’s behalf, regardless of the sign-in method the latter uses.
But How?
Every modern web service implements a session with a user after successful authentication so that the user doesn’t have to be authenticated at every new page they visit. This session functionality is implemented through a session cookie provided by an authentication service after initial authentication. If you really want to go deep, have a look here: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html.
The session cookie is proof for the web server that the user has been authenticated and has an ongoing session on the website. In AiTM phishing, an attacker attempts to obtain a target user’s session cookie so they can skip the whole authentication process and act on the latter’s behalf.
Looking back at that cheat sheet and OWASP Top 10, yes, there are session timeouts and the like, but remember, the attackers will be watching – I will cover this later.
The attacker deploys a webserver that proxies HTTP packets from the user who visits the phishing site to the target server the attacker wishes to impersonate and the other way around.
This way, the phishing site is visually identical to the original website (as every HTTP is proxied to and from the original website). The attacker also doesn’t need to craft their own phishing site like how it’s done in conventional phishing campaigns. The URL is the only visible difference between the phishing site and the actual one.
The Attacking Platform
There are a couple of excellent projects that are under ongoing development to help the attackers run these types of attacks. The two below are favourites. Remember, these are mostly all automated once they are set up correctly.
Evilginx is a man-in-the-middle attack framework used for phishing login credentials along with session cookies, which in turn allows for bypassing 2-factor authentication protection. Very hacker screen, but it’s an excellent platform.
Muraena – An almost-transparent reverse proxy aimed at automating phishing and post-phishing activities. A module that is scary with Muraena is the ability to notify the attacker hosting the platform via Telegram and the like. So they don’t need to be hands-on watching.
The Attack Workflow
The phishing page has two different Transport Layer Security (TLS) sessions—one with the target and another with the actual website the target wants to access. They are signed; the screenshot above shows the use of LetsEncrypt. Apologies – what they teach in the CISSP, “SSL/TLS and you are safe”… is wrong, sorry.
These sessions mean that the phishing page practically functions as an AiTM agent, intercepting the whole authentication process and extracting valuable data from the HTTP requests, such as passwords and, more importantly, session cookies. Once the attacker obtains the session cookie, they can inject it into their browser to skip the authentication process, even if the target’s MFA is enabled.
Once access is achieved, we tend to see the attackers move very fast, enumerating the environment through Global Address Lists and the like; they will then proceed to set up Outlook rules to conceal their access.
How to Detect and Defend
Detecting an AiTM attack requires a mix of detection engineering rules, some with P1 assignment and Near Real Time (NRT) rules, as the attack does move quite quickly once the attacker tricks a user into authenticating.
We put a lot of effort into staying on the bleeding edge with our detection engineering, various incident responses, and the like. It also gives us cutting-edge insights into how the attackers are hosting their proxy sites and the like.
Defending against an AiTM attack comes back to basics but requires special effort.
Similar to our MFA article recommendations:
- Move to Phishing-resistant authentication (FIDO2 Standard) hardware-based authenticator methods such as YubiKeys or Windows Hello for Business
- Configure Conditional Access Policies to require devices to be marked as compliant through Intune
- Configure Conditional Access Policies to reduce the lifetime of a session
- Configure Conditional Access Policies to only allow certain geographic zones to complete authentication (bypassable – keep reading)
- Heavy user awareness training
In more recent times (the last week), Microsoft has started to play with conditional access: Token protection.
Token protection attempts to reduce attacks using token theft by ensuring a token is usable only from the intended device. When an attacker is able to steal a token, they can impersonate their victim until the token expires or is revoked.
Token protection creates a cryptographically secure tie between the token and the device (client secret) to which it’s issued. Without the client secret, the bound token is useless. When a user registers a Windows 10 or newer device in Microsoft Entra ID, their primary identity is bound to the device.
What this means: A policy can ensure that only bound sign-in session (or refresh) tokens, otherwise known as Primary Refresh Tokens (PRTs), are used by applications when requesting access to a resource.
We are watching this space closely, as it is currently in public preview by Microsoft.
Jon Robertson
Managing Director & Founder
Tarian Cyber
