Adversary-in-the-Middle Kits: What They Are and What Makes Them So Dangerous

16:35 PM – almost the end of the workday at Northbridge Solutions LLC.
You quickly check your emails to make sure nothing urgent is left.
Deleting your way through the usual pile of automated messages, you suddenly stop.

Oh man… Tom, my manager. What is it this time? Another briefing about customer care?

You click the link, log in, enter the One-Time Code from your smartphone — and see only: Error 404 – this file does not exist.

Maybe it was a mistake and he already deleted it? Well, I’ll ask him tomorrow.

It’s 17:00, you shut down your PC and leave with your colleagues.

Next day, 10:00 AM at the office. You run into Tom and ask:

You: “Hey Tom, what about the file you uploaded for me in the company’s portal yesterday?”
Tom: “What file? I didn’t send you anything.”

Strange. You check your inbox again — and find another new email:

Shaken, you re-open the email “from Tom”.
Looking closely at the link, you finally notice it:

The "s" was swapped with a "-" — a phishing domain.
The site looked completely identical to the real company portal, and you even received a genuine MFA code.
How was that possible?

The attackers had used a technique called Adversary-in-the-Middle (AiTM), powered by a kit like Evilginx.

What an AiTM kit actually is#

Basically, an AiTM kit acts as a transparent proxy between the victim and the real website.
This means every request and response flows through the attacker’s infrastructure — allowing them to intercept, read, and modify data in real time.
The diagram below illustrates how this works in practice:

Step-by-Step Flow#

1. Victim enters credentials
   The victim navigates to the phishing domain — a proxy of the legitimate website that appears visually identical — and enters their username, password, and MFA code. Instead of reaching the genuine service, these credentials are first captured by the AiTM kit.

2. MFA code is requested
   The victim’s smartphone generates or receives a one-time code (OTP). The victim enters it into the phishing site.

3. Credentials forwarded
   The AiTM kit relays the captured credentials (username, password, OTP) to the legitimate website, so that the login looks authentic.

4. Legitimate site issues session cookies
   After successful authentication, the real website returns an authorization cookie (or token) to the AiTM kit.

5. Cookies passed back to the victim
   To keep the illusion alive, the AiTM kit forwards the valid cookies to the victim, who then successfully logs in on the fake website — believing everything worked normally.

6. Attacker harvests credentials and cookies
   At the same time, the AiTM kit saves a copy of the victim’s credentials and session cookies.

7. Legitimate session created
   With these cookies, the AiTM kit establishes a real, logged-in session on the legitimate website.

8. Victim sees a logged-in session on the fake domain
   The phishing site mirrors the real content, so the victim believes they are in the genuine company portal.

9. Authorized session available to attacker
   The attacker can now reuse the stolen cookies and access the victim’s account directly — without needing another password or MFA prompt.

10. Attacker fully impersonates the victim
    Using the stolen session, the adversary logs in to the real service as if they were the victim, with the same privileges and access level.

Why This Works#

• The victim sees the real login page content, delivered via the proxy.
• MFA codes are valid — the attacker just forwards them in real time.
• Once the authorized session cookie is captured, the attacker no longer needs the victim’s password or phone.

This is why AiTM phishing is so dangerous: it bypasses traditional defenses and turns MFA from a protection into a stepping stone.

Why Attackers Use It#

The real power of AiTM kits lies in their ability to bypass traditional Multi-Factor Authentication (MFA).
Normally, MFA requires the user to either enter a one-time code from a smartphone or approve a push notification on a second device.
With AiTM, the attacker doesn’t need to compromise that device at all — they simply proxy the login, forward the MFA code in real time, and then capture the authorized session cookie or bearer token issued after login.

Once the session cookie is stolen, the attacker can replay it to impersonate the victim without needing any additional credentials or MFA approvals. This makes AiTM one of the most efficient ways to defeat MFA in practice.

Why Attackers Favor AiTM Kits#

In short: AiTM attacks are attractive because they are cost-effective, highly convincing, and work against targets that would otherwise be “secure” with MFA enabled.

What Defenders Should Know#

Adversary-in-the-Middle phishing is a shift in threat model.
Traditional awareness trainings tell users to “check for the padlock” or “make sure MFA is enabled.”
With AiTM kits, both of those checks can succeed — and yet the attacker still walks away with a valid session.

That’s why defenders need to look beyond credentials and focus on detecting sessions that don’t belong.

Key Indicators of AiTM Activity#

• TLS and Domain Oddities
  The phishing site will have its own certificate and hostname. Both look valid on the surface but may not match corporate naming conventions. Automated checks can flag new domains that closely resemble your brand.

• Suspicious HTTP Headers
  AiTM proxies sometimes insert or strip headers. For example, X-Forwarded-For or altered Host headers can indicate the request did not originate directly from the client.

• User-Agent and IP Inconsistencies
  Victims usually log in from a predictable set of devices and geographies. AiTM attacks may show sudden mismatches: Chrome on Windows 11 yesterday, but suddenly Safari on macOS in another country — all with the same session cookie.

• Session Replay
  A token issued to an employee in Germany being replayed from a server in another continent seconds later is a strong sign of session hijacking.

Defensive Strategies#

1. Short-Lived Session Tokens
   Reduce the lifetime of session cookies and enforce regular revalidation. This limits the usefulness of stolen tokens.

2. Device Binding
   Tie authentication not just to “something you know” (password) and “something you have” (MFA code), but also to the device itself. FIDO2/WebAuthn achieve this elegantly.

3. Anomaly Detection
   Monitor for unusual access patterns, such as multiple IPs using the same cookie within minutes, or OTP codes being consumed unusually quickly.

4. User Education
   Train staff that MFA is not a silver bullet. They should be wary of lookalike domains and unsolicited login prompts, even if the login page “looks right.”

5. Threat Intelligence Integration
   Many AiTM campaigns reuse infrastructure. Subscribing to threat feeds and blocking known phishing domains or certificates can cut attacks off before they reach users.

6. Custom Security Controls
   Some companies add JavaScript integrity checks, CSP headers, or custom device fingerprints to make proxying more difficult. While not foolproof, these add friction for attackers.

Pentester’s Angle#

From a red-team perspective, AiTM phishing is one of the most realistic and high-impact techniques to evaluate an organization’s resilience against phishing and MFA bypass.
Where password spraying or brute-force only test password hygiene, AiTM simulation tests the entire identity pipeline — from login flows to MFA handling to session management.

During controlled engagements, this allows us to answer critical questions for the client:

• Would employees recognize a lookalike domain before entering credentials?
• Does the SOC detect suspicious token or cookie reuse?
• Are MFA policies truly phishing-resistant, or can sessions be hijacked once a code is entered?
• What compensating controls (device binding, anomaly detection, conditional access) actually trigger?

This has two advantages:

1. Accuracy – the attack is executed in a way real adversaries would attempt it, without false positives caused by commodity tooling.
2. Clarity – defenders can see exactly where their detection and response pipeline worked, and where it silently failed.

And of course:

Lessons From the Field#

Without revealing weaponized code, here are some insights we’ve encountered while building and testing AiTM kits during authorized engagements.
These lessons highlight just how varied and fragile real-world authentication systems can be.

• Cookie Handling Is Complex
  Applications often issue multiple Set-Cookie headers with different flags (HttpOnly, Secure, SameSite).
  Getting all of them handled correctly in a proxy setup is harder than most people think — and any mistake breaks the illusion of a “seamless” login.

• Not Every App Uses Cookies
  Some modern applications rely heavily on Authorization headers (Bearer tokens, JWTs, OAuth flows) instead of traditional cookies. For an attacker, this means a wider range of tokens to capture. For defenders, it means cookie-only protections won’t be enough.

• Lack of Anti-AiTM Defenses Is Common
  Surprisingly, many in-house and even some enterprise-grade web applications have no effective controls against being proxied.
  They don’t validate domain bindings, don’t tie sessions to devices, and don’t notice when traffic comes from an unexpected path.

• Demonstrations Speak Louder Than Reports
  Showing management a report with “session hijacking possible” is one thing.
  Opening a browser, importing the stolen cookie, and instantly being logged in as the CEO is far more impactful.
  It turns an abstract security issue into a visceral business risk.

• Defensive Bugs Are Revealing
  We’ve seen cases where developers attempted to protect against AiTM by checking document.location in JavaScript.
  A single overlooked rewrite rule on the proxy side completely bypassed it.
  It shows that partial defenses can provide a false sense of security.

These experiences underline why AiTM testing isn’t just about “capturing passwords.”
It’s about exposing how real applications behave under pressure — and showing organizations where their assumptions about MFA security may break down.

Defensive Takeaways#

So what can organizations do to stay ahead of AiTM attacks?
The answer is not a single tool, but a layered defense strategy.

1. Strengthen Authentication#

• Adopt phishing-resistant MFA such as FIDO2 / WebAuthn / hardware security keys.
• Bind sessions to devices so a stolen cookie cannot be reused from a different endpoint.
• Shorten session lifetimes and enforce reauthentication for sensitive actions.

2. Detect Suspicious Sessions#

• Monitor for cookie or token replay (same session used from two places at once).
• Flag impossible travel — logins from two distant geographies within minutes.
• Use behavioral analytics to detect anomalies in user-agent strings, IP addresses, or login velocity.

3. Harden Web Applications#

• Enforce strict domain checks (e.g. CSP, HSTS, referer validation).
• Implement integrity checks that break when traffic is proxied or altered.
• Evaluate support for conditional access policies (e.g. only allow logins from managed devices).

4. Educate and Test Users#

• Teach staff that MFA is not a silver bullet — phishing sites can still look perfect.
• Train users to spot lookalike domains and unexpected login prompts.
• Regularly run phishing simulations that include AiTM techniques, not just basic credential theft.

5. Integrate Threat Intelligence#

• Subscribe to phishing domain feeds and block lookalikes at DNS or proxy level.
• Watch for suspicious certificates issued against your brand.
• Share and consume IoCs from industry groups to stay ahead of active campaigns.

Turning Awareness Into Action#

Adversary-in-the-Middle kits change the rules of phishing defense. It’s no longer enough to say “we have MFA, we’re safe.”
Organizations need to assume attackers can intercept sessions — and prepare to detect and respond when they do.

Security teams that simulate AiTM attacks in a controlled way gain a realistic view of how their defenses hold up.
This is the only way to build true resilience before real criminals come knocking.

At 0xda7a, we simulate Adversary-in-the-Middle attacks in controlled penetration tests.
This allows organizations to see whether their MFA and identity security hold up — before criminals exploit the gap.

We use our own AiTM framework — built for testing, not abuse.
The goal: helping defenders stay ahead of attackers.