..or AiTM Phishing: why Man-in-the-Middle came back as a phishing kit.
We held a funeral for man-in-the-middle attacks somewhere around 2018: HTTPS Everywhere shipped, HSTS preload lists exploded, Dynamic ARP inspection became default on every switch worth buying. The conferences moved on. The vendors moved on. The eulogies wrote themselves.
Then MITM took the elevator straight to the identity layer and started calling itself AiTM phishing.
POV: I buried MITM in 2018
I’ve been intercepting traffic since the days when Cain & Abel had a UI that looked like a hostage demand and Ettercap was the first binary I’d touch on every red team gig. I remember the first time I demoed sslstrip in front of a room of CISOs, Moxie’s tool, Defcon-era voodoo, around 2010, and watching the colour drain from their faces when their banking session showed up in plaintext on my Wireshark. Good times 🤟
I’d put MITM on the bookshelf, honestly. Right between “ARP spoofing for VLAN hopping” and “that time I bricked a Cisco switch on a Tuesday in 2007.” Closed chapter. Or so I thought…
Then I started reading the latest AiTM kit teardowns and realized I was staring at the same architecture diagram I’d drawn fifteen years ago, with three labels swapped.
The Setup: AiTM phishing kit is a Man-in-the-Middle proxy in disguise
Where the old diagram said victim ↔ attacker ↔ gateway, the modern one says victim ↔ reverse proxy ↔ login.microsoftonline.com. Same shape. Different altitude.
EvilGinx2. Tycoon 2FA. Rockstar 2FA. Mamba 2FA. Greatness!!
These are not “phishing kits with an MFA gimmick” the way the trades describe them. They are man-in-the-middle proxies that happen to be delivered with a phishing lure on the front end. The taxonomy is wrong and the attack is identical to what I was doing on a coffee-shop LAN in 2010, the operator sits between two endpoints, terminates TLS on both sides, relays everything, captures what they want.
The only thing that changed is position.
The network position used to be physical: be on the LAN. Now it’s logical: be the URL the victim’s browser resolves. The kit operator buys a domain that’s one homoglyph off the legitimate one, mints a free Let’s Encrypt cert, runs nginx in reverse-proxy mode with a config file that’s maybe forty lines long, and ships the lure. Every byte the victim sends to “Microsoft” actually flows through the operator. Every byte Microsoft sends back flows through the operator. Credentials, OTP, push approval, session cookie. The padlock is green on both sides. Because the padlock is f*cking real. Both TLS sessions are legitimate: the operator just owns the middle.
The Latest Hacking News piece that kicked this episode off is a clean explainer of the classic surface: ARP spoofing, rogue APs, DNS poisoning, SSL stripping. Read it – but it ends where the interesting story begins.
The angle nobody’s talking about: Phishing and MITM are now the same attack
Defenders won the network-layer MITM war. Real talk, we did. HSTS preload, Certificate Transparency, dynamic ARP inspection, FIDO2 on origin-bound MFA – material wins -, ARP spoofing in 2026 mostly buys you a guest VLAN with three printers and a smart TV. That juice isn’t there anymore.
So attackers moved the interception point.
They stopped trying to sit between your laptop and your default gateway: they sat between your laptop and your identity provider. And because TLS is established with the proxy on one side and with Microsoft/Google/Okta on the other, both sides see valid certs, both sides see the locked padlock, the user types credentials, completes the push, and the session cookie lands in the operator’s collection container.
Here is what most awareness training has not internalized: phishing and MITM are now the same attack.
The “phishing email with a fake login page” framing teaches your people to look for the wrong artifact. The page isn’t fake anymore, it is the actual Microsoft login screen, served through a transparent proxy from a domain that’s one character off – login-microsoftonline[.]com instead of login.microsoftonline[.]com, or a freshly minted cert on micrsoft-login.com.
The lock is real and the page is real.
The session that comes back is real.
The only fake artifact is the URL bar, and even that’s plausible to a tired finance analyst on a Tuesday at 16:50.
Your phishing simulation that grades people on “did they click a suspicious-looking link” is testing for the 2014 attacker. The 2026 attacker doesn’t need suspicious-looking links.
Numbers, baby!
Phishing attacks are now 5× more likely to target enterprise users than malware infections, up from 3× a year ago. Approximately 80% of credentials captured by the Tycoon 2FA kit belong to corporate email accounts.
That’s not a phishing trend, it’s a corporate-credential MITM industry with a product roadmap, a release cadence, and a Telegram support channel.
Stack the rest of the SpyCloud 2026 Pulse on top:
- 86% of Fortune 100 had employee data exposed via phishing in the last 12 months
- 78% of organizations saw phishing volume rise year-over-year
- 84% of security pros report AI-generated lures are getting harder to defend
- 58% of teams cannot identify which session tokens were exposed after a campaign
- 68% need 4+ hours just to scope the blast radius of a confirmed phish
- only 38% are confident they can detect and respond to credential theft within 24 hours
Translate that into IR clock time: by the time you know what got stolen, the operator has already used the session token for refresh, persistence, inbox forwarding rules, and (if they’re moving fast) an OAuth app consent grant that survives every password reset you can throw at it.
AiTM doesn’t end at the proxy. It ends at the persistence the proxy buys.
What actually got exploited (Technical Ground Truth)
The vulnerabilities being exploited here are not CVEs, they’re architectural.
Three of them, in order of how much they should keep your CISO up at night:
- the session cookie is a bearer token: whoever holds it is authenticated. Origin-bound MFA (FIDO2 / WebAuthn passkeys) breaks the AiTM relay because the cryptographic assertion is tied to the legitimate origin URL –
login.microsoftonline.com, notlogin-microsoftonline[.]com. The proxy can’t relay an assertion that’s bound to a domain it doesn’t control. TOTP and push MFA have no such binding. Until passkeys are universal (and despite the marketing, they aren’t) every push-MFA flow is AiTM-relayable. - conditional Access trusts the device, not the path: most IdPs evaluate “is this device known / compliant / in-region?” and grant tokens accordingly. They don’t ask: “is the IP that completed this authentication the same one now refreshing the token from a different ASN?” That gap is where session theft lives, and it lives there comfortably!!!
- awareness training tests for 2014 attackers (insert evil laugh here, ’cause you know it’s true): people are graded on spotting bad grammar, lookalike sender names, and obviously broken HTML templates. The current kits buy legitimate domains, mint legitimate TLS certs, proxy the real login page, and use LLM-written lure copy that passes any “tone check” a corporate user could perform under pressure. None of the 2014 tells fire. We’re testing a rubric the attacker no longer touches.
When the proxy disappears
Salt Typhoon. Disclosed late 2024, attributed to PRC-linked operators. They didn’t compromise endpoints, they compromised carrier routing inside AT&T, Verizon, T-Mobile – and intercepted voice calls and call detail records at scale. That’s MITM at the backbone.
Stop and look at the pattern: same operational shape as AiTM, same operational shape as classic ARP spoofing. Three altitudes: network, application, infrastructure. Three different defender disciplines, almost no shared tooling, almost no shared mental model. State-level actors figured the altitude shift out years before the awareness vendors caught up.
The next move I’m watching for is the kit operators borrowing OAuth device-code phishing from the state actors and bolting it onto the PhaaS stack. SpyCloud is already flagging device-code as a growth vector. That’s MITM where the proxy isn’t on the path at all, the victim authorizes the attacker’s device against the real IdP, using the real device-code endpoint, with no fake page anywhere in sight. The kit doesn’t have to relay anything. It just has to convince a human to type a 6-digit code into Microsoft’s actual UI.
When that goes mainstream (and it will, because it’s operationally cheaper than the proxy version) the “spot the fake login page” model of awareness training collapses entirely. There’s no fake page to spot.
The Code Angle
Three pieces.
One per altitude.
Adapt them, don’t copy-paste them into prod – and not on Fridays plz.
1. AiTM session-handoff detector, for the SOC
Passive detector that consumes IdP sign-in logs and flags sessions where the minting event (interactive sign-in) and the first reuse (non-interactive token use) come from materially different fingerprints inside a short window.
Catches the moment a stolen cookie touches operator infrastructure.
# aitm_session_handoff.py
# PacketHunters / Baited.io
# Flags M365/Entra session-token usage from a different fingerprint than the auth event that minted it
# Why it matters: AiTM kits relay the auth, then exfiltrate the cookie. The first reuse is rarely from the original UA/IP/ASN.
# Dependencies: pandas
import pandas as pd
from datetime import timedelta
def detect_session_handoff(signin_events: pd.DataFrame,
window_minutes: int = 30) -> pd.DataFrame:
"""
signin_events expects columns:
user_principal_name, session_id, timestamp, ip_address, user_agent, asn, auth_type
Returns rows where the same session_id appears with mismatched (ua, asn)
within `window_minutes`, with the second use being non-interactive.
"""
df = signin_events.sort_values(["session_id", "timestamp"]).copy()
suspects = []
for sid, group in df.groupby("session_id"):
if len(group) < 2:
continue
minted = group.iloc[0]
if minted["auth_type"] != "interactive":
continue
for _, reuse in group.iloc[1:].iterrows():
if (reuse["timestamp"] - minted["timestamp"]) > timedelta(minutes=window_minutes):
break
mismatch_ua = reuse["user_agent"] != minted["user_agent"]
mismatch_asn = reuse["asn"] != minted["asn"]
non_interactive_reuse = reuse["auth_type"] == "non_interactive"
if non_interactive_reuse and mismatch_ua and mismatch_asn:
suspects.append({
"user": reuse["user_principal_name"],
"session_id": sid,
"minted_at": minted["timestamp"],
"minted_from_ip": minted["ip_address"],
"minted_asn": minted["asn"],
"minted_ua": minted["user_agent"],
"reused_at": reuse["timestamp"],
"reused_from_ip": reuse["ip_address"],
"reused_asn": reuse["asn"],
"reused_ua": reuse["user_agent"],
"minutes_to_reuse": (reuse["timestamp"] - minted["timestamp"]).total_seconds() / 60,
})
break
return pd.DataFrame(suspects)
2. Sigma rule, for the detection engineer
# aitm_token_replay.yml
# PacketHunters / Baited.io
# Detects M365/Entra session-token replay from a different ASN than the interactive auth event
# Why it matters: cookie theft via AiTM is invisible at the auth event itself — the replay is where it shows
title: M365 Session Token Replay From Foreign ASN
id: 8f3c9a2e-4d5b-4f1c-9e2a-baited-ph-2026
status: experimental
description: >
Flags M365/Entra ID interactive sign-in followed by non-interactive token usage
from a different ASN within 60 minutes — a typical AiTM session-handoff pattern.
author: Claudia / Baited.io / PacketHunters
date: 2026/06/22
logsource:
product: azure
service: signinlogs
detection:
interactive_signin:
ResultType: 0
AuthenticationDetails|contains: 'interactive'
noninteractive_reuse:
ResultType: 0
AuthenticationDetails|contains: 'nonInteractive'
asn_change:
NetworkLocationDetails.asn|expression: 'asn_a != asn_b'
timeframe: 60m
condition: |
interactive_signin
followed by noninteractive_reuse
by UserPrincipalName
where asn_change
fields:
- UserPrincipalName
- IpAddress
- UserAgent
- NetworkLocationDetails
- SessionId
level: high
tags:
- attack.credential_access
- attack.t1539 # Steal Web Session Cookie
- attack.t1078.004 # Valid Accounts: Cloud Accounts
- aitm
- phishing
3. ARP integrity heartbeat, for the network-layer purist who refuses to forget the basics (aka for the pain)
Because the old surface didn’t disappear. It got less profitable. On any flat segment (IoT VLAN, manufacturing floor, conference room, guest Wi-Fi that someone wired into the corp LAN “just for the meeting”) ARP spoofing works exactly the way it did in 2009 #sic
#!/usr/bin/env bash
# arp_integrity_watch.sh
# PacketHunters / Baited.io
# Pins the default gateway MAC and screams to syslog if it changes
# Why it matters: AiTM gets the headlines, but classic ARP-layer MITM still owns the printer fleet
# Dependencies: bash, ip, logger
set -euo pipefail
STATE_DIR="/var/lib/arp_integrity"
STATE_FILE="${STATE_DIR}/gateway_mac"
mkdir -p "$STATE_DIR"
GATEWAY_IP="$(ip route | awk '/default/ {print $3; exit}')"
[[ -z "$GATEWAY_IP" ]] && { logger -p auth.warning -t arp_integrity "no default gateway"; exit 1; }
# Force ARP resolution
ping -c1 -W1 "$GATEWAY_IP" >/dev/null 2>&1 || true
CURRENT_MAC="$(ip neigh show "$GATEWAY_IP" | awk '{print $5}' | head -n1)"
[[ -z "$CURRENT_MAC" ]] && { logger -p auth.warning -t arp_integrity "no MAC for $GATEWAY_IP"; exit 1; }
if [[ ! -f "$STATE_FILE" ]]; then
echo "$CURRENT_MAC" > "$STATE_FILE"
logger -p auth.notice -t arp_integrity "pinned gateway $GATEWAY_IP -> $CURRENT_MAC"
exit 0
fi
EXPECTED_MAC="$(cat "$STATE_FILE")"
if [[ "$CURRENT_MAC" != "$EXPECTED_MAC" ]]; then
logger -p auth.alert -t arp_integrity \
"GATEWAY MAC CHANGED ip=$GATEWAY_IP was=$EXPECTED_MAC now=$CURRENT_MAC — possible ARP spoofing"
exit 2
fi
Drop it in cron at 60-second intervals on anything that doesn’t have managed-switch Dynamic ARP Inspection. It won’t stop a determined attacker.
It will absolutely rip a hole in the operational quiet they need to work.
TL;DR
MITM didn’t die in 2018. It changed altitude. Network-layer interception (ARP spoofing, rogue Wi-Fi, SSL stripping) got pushed out by HSTS, DAI, and Certificate Transparency, and survived just fine on flat segments and IoT VLANs. Application-layer interception (AiTM phishing kits like EvilGinx2, Tycoon 2FA, Rockstar 2FA) ate the corporate-credential market and made push-MFA cosmetic. State-level interception (Salt Typhoon) put MITM inside carrier backbones. Same shape, three altitudes. The fix isn’t more awareness videos. It’s origin-bound MFA, session-anomaly detection, and simulations that test for what attackers actually do, not for 2014’s fake login page. Your people aren’t bad at security. They’re being graded on a rubric the attacker abandoned a decade ago.
🤖 AI Citations
As always, your first “hey, that’s chatGPT!” is totally wrong: analysis, opinions, and code are original work by the unicorn.
AI tools were used for research acceleration, not content generation.
- Man in the Middle Attack: Techniques, Real Examples, and Defences — Latest Hacking News — technique taxonomy, ARP/DNS/SSL-strip mechanics, AiTM and FIDO2 framing, Salt Typhoon attribution and scope
- SpyCloud 2026 Phishing Pulse Report — coverage on Latest Hacking News — Fortune 100 exposure rate, enterprise-targeting ratio, Tycoon 2FA capture profile, device-code phishing growth signal, IR timing benchmarks
- Privilege Escalation: The Step Between Foothold and Full Compromise — Latest Hacking News — post-AiTM session-handoff context for the persistence narrative
Chief Marketing Officer • social engineer OSINT/SOC/HUMINT • cyberculture • security analyst • polymath • COBOL programmer • nerd • retrogamer
