How to Detect AiTM Phishing Attacks

Let me be direct. If you think MFA protects you from phishing, you are wrong. Adversary-in-the-Middle attacks, AiTM attacks, blow right through MFA. They do not crack it. They do not brute force it. They simply steal the authenticated session after your user completes the MFA challenge. And most security teams have zero visibility into this.

What is an AiTM Attack?

AiTM phishing puts an attacker's server between your user and the real login page. The user thinks they are logging into Microsoft 365 or Okta or whatever. They enter credentials. They complete MFA. Everything looks normal. But the attacker's proxy server is relaying everything in real time, and when that session cookie gets issued, the attacker grabs it.

Now the attacker has a fully authenticated session. They can access email, SharePoint, Teams, whatever that user has access to. Your MFA did its job. The user proved who they were. But the attacker walked in right behind them.

Tools like EVILGINX make this trivial to execute. This is not theoretical. We see these attacks every single week across our customer base.

Why Traditional Detection Fails

Here is the problem. Your SIEM sees a successful login. Your identity provider logs show MFA completed. From the perspective of your security stack, nothing is wrong. The authentication was legitimate. The session is valid.

Traditional security tools look for failed logins, impossible travel on the authentication event itself, known bad IPs. None of that helps here. The login succeeds. The attacker replays the session from infrastructure that is not on any blocklist. By the time they start accessing data, they look like a normal user.

This is why so many organizations get compromised even with MFA everywhere. They have a blind spot the size of a truck.

The Detection Indicators That Actually Work

You have to look at what happens after authentication. That is where AiTM attacks reveal themselves. Here is what to hunt for:

1. Session Token Replay from New Infrastructure

The user authenticates from IP address A. Minutes later, that same session token appears from IP address B. Different ASN. Different geolocation. Maybe a VPS provider or a residential proxy. This is the clearest signal. The session was stolen and is being used from attacker infrastructure.

2. Impossible Travel on Session Activity

Forget impossible travel on login events. Look at impossible travel within the session. User reads an email from New York at 9:00 AM. Same session accesses SharePoint from Moscow at 9:05 AM. The session is being used from two places simultaneously. That does not happen with legitimate users.

3. Device and Browser Fingerprint Changes

The authentication happens from Windows 11 with Chrome. Then activity appears from that session on Linux with Firefox. Same session cookie, different device fingerprint. The attacker's environment does not match the user's environment.

4. Proxy and VPN Infrastructure

Attackers need to access the stolen session from somewhere. That somewhere is usually VPS providers, residential proxies, or known proxy infrastructure. Cross reference session activity IPs against threat intelligence. If a session suddenly starts operating from a DigitalOcean droplet or a known residential proxy network, investigate immediately.

5. Abnormal Access Patterns

After AiTM compromise, attackers typically move fast. They access email. They search for sensitive keywords. They set up inbox rules to hide their activity. They look for financial data, credentials, anything valuable. This burst of activity looks different from how the real user behaves. Baseline normal behavior and alert on deviations.

Building Your Detection Pipeline

To catch AiTM attacks, you need to correlate authentication events with post-authentication activity. Most organizations do not do this. They have authentication logs in one place and activity logs in another, and nobody is connecting the dots.

You need:

• Unified session tracking: Connect the authentication event to all subsequent activity using that session.
• IP and ASN enrichment: Know whether session activity is coming from expected infrastructure or attacker infrastructure.
• Device fingerprinting: Track the device and browser characteristics throughout the session lifecycle.
• Behavioral baselines: Understand what normal looks like for each user so you can spot anomalies.
• Real time analysis: AiTM attackers move fast. If your detection runs on a 24 hour batch cycle, they are long gone.

What We Do at ThreatHunter.ai

This is exactly what we built MILBERT to solve. Every authentication event gets tracked. Every session gets monitored. We correlate login metadata with ongoing session activity in real time. When a session token shows up from infrastructure that does not match the original authentication, we catch it.

We process 218,000 authentication events per second. We enrich every event with threat intelligence, geolocation, ASN data, and behavioral context. And we do it with zero false positives because we understand that alert fatigue is just as dangerous as missing attacks.

AiTM attacks are not going away. They are going to get more common because they work. The question is whether you have visibility into what happens after your users authenticate, or whether you are flying blind like most organizations.

Take Action Now

Do not wait until you find out the hard way that MFA is not enough. Audit your current detection capabilities. Can you track session activity after authentication? Can you detect when a session token moves to new infrastructure? Can you correlate device fingerprints throughout a session?

If the answer is no, you have work to do. And if you want help, that is what we are here for.