Adversary-in-the-Middle

AiTM rarely opens the intrusion on its own. On the network side it is a credential-harvesting step that follows initial network access, whether that is a compromised guest port, a rogue device on the LAN, or a foothold already gained through phishing; the NTLMv2 hashes or relayed sessions it produces feed straight into privilege escalation and lateral movement, which is why forced-authentication relay sits directly upstream of admin-level access on a second host. On the cloud side, AiTM phishing is usually the initial access step itself: the attacker sends the reverse-proxy link instead of a plain credential-harvesting page precisely because it defeats the MFA that would otherwise stop a stolen password cold.

MITRE's own procedure examples show how broadly the technique is used. ArcaneDoor intercepted HTTP traffic on compromised network devices to support espionage; Kimsuky ran a modified PHProxy instance to examine victims' web traffic and steal session data; Sea Turtle modified DNS records at the registrar level to redirect traffic toward attacker infrastructure for large-scale credential capture; and evilginx2 itself is the reference implementation behind most commodity AiTM phishing kits sold as phishing-as-a-service. Once an AiTM foothold lands in a cloud tenant, the next moves are predictable: register a new MFA method or OAuth app for persistence, then move to mailbox rules, data collection, or further lateral movement inside the tenant.

LLMNR and NBT-NS chatter is loud in a normal Windows network even without an attacker. Misconfigured DNS suffixes, printers and IoT devices that only speak NetBIOS, and users who fat-finger a share name all generate the same broadcast-and-fallback pattern Responder feeds on, so a rule that alerts on any LLMNR response will bury an analyst. Legitimate NTLM authentication also produces the same event codes (4624/4625) the relay detection watches; VPN concentrators, jump hosts, and load balancers that terminate connections on behalf of a computer account can make the source IP legitimately not match the host, which is why the Elastic rule narrows to a username-to-hostname mismatch rather than IP mismatch alone.

On the cloud side, a genuinely traveling user, a corporate VPN that changes egress IP mid-session, or a mobile client that hops between cellular and Wi-Fi can produce the same same-SessionId-different-IP pattern as a stolen cookie. Tune by correlating the IP change against travel-time feasibility (a session ID from Warsaw and then Kansas City ninety seconds later cannot belong to one legitimate person) and by checking whether the second IP maps to a known corporate egress range or VPN exit node before treating it as attacker infrastructure. Conditional Access token protection and continuous access evaluation reduce the false-positive rate further by invalidating stolen cookies that move networks, so alert volume should already be sparse once those controls are enabled.

When an NTLM relay or WPAD alert fires, the first question is whether the source is infrastructure you control: a VPN concentrator, a proxy, a known backup job account, or something unexplained. If unexplained, pull the target host's recent authentication history, since a relay that lands on a domain controller or file server is materially worse than one that dead-ends on a workstation with no useful access. For a concurrent-session or impossible-travel alert, check whether the second IP correlates with a Conditional Access failure, a new MFA method registration, or a mailbox rule created immediately after, since those are the tells that the session was actually used and not just observed in passing.

Contain fast on either flavor. For network AiTM, isolate the source host from the segment, since Responder and its relatives need to sit on the same broadcast domain to work, and rotate the credentials for any account whose hash plausibly reached the rogue server. For cloud AiTM, revoke the user's refresh tokens and active sessions immediately, which invalidates the stolen cookie even though the attacker never had the password, force a password reset, and re-register MFA. Then check the tenant's OAuth app consents and mailbox rules for anything created during the compromise window before closing out the incident.