Identity The AiTM problem nobody’s architecture actually solves May 20, 2026 Share By Alan LeFort (Adobe Stock) COMMENTARY: We’ve all heard of card skimmers on ATMs. Adversary-in-The-Middle (AiTM) phishing is the same idea, but for a login. The attacker authenticates successfully. Multi-factor authentication (MFA) fires. Everything looks normal. The theft already happened. Most security teams haven't fully absorbed that. AiTM attacks went from nation-state-grade capability to a Phishing-as-a-Service (PhaaS) subscription under $1,000 a month. Evilginx2 is open source. Commercial kits ship with customer support. The attack isn't exclusive anymore. It's wholesale. And the architecture most organizations rely on to stop it was never designed to see it. [ SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here . ] AiTM phishing isn't a convincing fake login page. It's a real-time proxy sitting between the victim and a legitimate identity provider — Microsoft, Google, Okta. The attacker's infrastructure forwards requests to the real identity provider (IdP) and relays responses back. It’s a genuine authentication session, and a real MFA challenge. The victim completes it. The attacker captures the session cookie issued after authentication completes. It’s a valid cookie, MFA-satisfied credential. The attacker never needed the password. They never needed to defeat MFA. They waited for the user to prove their identity, then stole the proof. The victim sees a valid transport layer security (TLS) certificate, real IdP content, and every visual marker that normally signals safety. Nothing looks wrong because it’s not fake. The "just use MFA" conversation misses this entirely. MFA worked. The attack didn't need it to fail. Why our current stacks can't see it The lure emails route through compromised M365 tenants. DMARC passes. DKIM passes. SPF passes. The links point to legitimate cloud services. Volume per sender remains low. From our email gateway's perspective, there's nothing to flag. This isn't a tuning problem. The gateway evaluates the invitation to the crime scene. The crime happens afterward, in an authenticated session the gateway has no window into. ML-based detection doesn't close it either. Most models trained on datasets where AiTM samples were sparse in the threat class, while the emails that now carry AiTM attacks — SharePoint links, DocuSign requests — were heavily represented in the benign class. The model learned that document-sharing emails from low-volume senders are safe. That was accurate in 2021. It's a liability in 2026. Behavioral anomaly models get closer but hit the same boundary. They can flag that a user clicked an unusual link from an unfamiliar sender. They can't see that the click routed through a proxy, or that the session was intercepted. They're reasoning about email content without access to the information that actually reveals the attack. The architectural problem Most organizations responding to AiTM wire together SIEM correlation rules across their email gateway, IdP, and endpoint tools: stream Entra sign-in logs into Splunk, flag IP/ASN mismatches, correlate email delivery timestamps with login events. That approach has merit as a safety net. But it's post-compromise detection. By the time our SIEM flags that a session token fired from an unexpected IP, the attacker already has the cookie. The lure was delivered. The user clicked. The session was stolen. Our rule fires minutes later. In that window, the attacker has already created inbox rules, exfiltrated data, or launched internal phishing from the compromised account. Accountability represents the bigger risk. When we build detection from three or four vendor components, each vendor owns a fragment. The email vendor says the email passed authentication standards. The IdP vendor says MFA worked as designed. The SIEM vendor says the correlation rule wasn't tuned for this scenario. Three correct statements, zero accountability. The architecturally correct answer: detection pre-engagement within seconds: stopping the lure before it’s seen in the inbox, in a platform that can reason across infrastructure fingerprints, follow multi-stage click chains, and model sender behavior over time. That's where detection happens before the session gets compromised, and where there’s clear accountability when something gets through. What to do next Ask the email security vendor to demonstrate, in our company’s environment, a detection for an AiTM lure delivered through a compromised M365 tenant where DMARC, DKIM, and SPF all pass. If the answer involves our SIEM or IdP doing part of the work, we’re looking at a detection architecture that depends on components outside their platform — which may be fine, but we need to know who owns the failure when the correlation breaks. Then ask how their platform handles multi-stage click chains where the final destination sits behind CAPTCHA gates and obfuscated redirects. AiTM campaigns are specifically designed to defeat static link analysis. The answer tells us whether our vendor's detection was built for the current attack structure or for phishing from five years ago. Finally, ask the accountability question directly: "If an AiTM attack gets through, what does the evidence chain look like and who owns the miss?" Both detection platforms and detection components are valid architectures. But the accountability model differs, and we need to know which one we're operating before the incident. For the team: enable authentication event streaming from IdP. Entra, Okta, and Google Workspace all expose sign-in logs via API. If those events aren't flowing into our SIEM today, we have no visibility into whether an AiTM has already happened. Build one detection rule: flag any authentication where the session token fires from a different IP or ASN than the one that initiated authentication, within a short window. This is the proxy signature. It won't prevent AiTM, but it tells us when our pre-delivery detection missed one. In completing the process, document this gap for the next audit cycle. If the compliance framework requires evidence of controls against credential theft, AiTM proxy attacks likely fall outside what our email security and MFA controls actually cover. Naming the gap explicitly is better than finding it in an incident review. The vendor questions cost us one meeting. The team actions cost engineering hours. Discovering this gap during an actual incident in a regulated environment runs $2M to $5M when we add forensics, regulatory notification, and compliance remediation. Today, the commercial kits keep getting cheaper. We won’t see sophisticated threat actors as the next wave of AiTM operators — we’ll see mid-tier criminals using commodity tooling, noisier and less careful, but far more numerous. By the time this attack shows up consistently in industry surveys, it’s because it already worked at scale before the architecture caught up. The card skimmer isn't being installed at the ATM. It's on the wire between the customer and the bank. Detecting it requires instrumentation of the part of the infrastructure almost nobody has built yet. The detection architecture exists today, at both the email layer and the identity layer. Teams now need to know if the organization has the right primary defense and the right backstop — and who owns the failure for each. Alan LeFort, founder and CEO, StrongestLayer SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial. Alan LeFort Related Identity Microsoft to phase out SMS authentication for account recovery SC Staff May 20, 2026 Microsoft has announced it will begin phasing out SMS-based authentication and account recovery, citing it as a leading source of fraud. Identity Stolen UK data, including bank cards and IDs, is cheap on the dark web, NordVPN reports SC Staff May 18, 2026 Stolen UK payment card details are commonly available on dark web marketplaces for approximately $12, with comprehensive digital identity packs fetching around $40. Privacy Trump administration’s voter data collection efforts face legal challenges SC Staff May 14, 2026 The Department of Justice's Office of Legal Counsel issued a memo arguing that a provision in the 1960 Civil Rights Act, requiring election officials to retain voter records for 22 months, grants the Attorney General the authority to obtain copies of these records. Related Events Cybercast IAM for MSSPs: Real-World Deployments On-Demand Event Cybercast Privilege risk is in the lifecycle: A CISO discussion on modernizing identity control On-Demand Event Cybercast The industrialization of identity compromise On-Demand Event Get daily email updates SC Media's daily must-read of the most current and pressing daily news Business Email By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy . Subscribe Related Terms Basic Authentication Biometrics Certificate-Based Authentication Challenge-Handshake Authentication Protocol (CHAP) Digest Authentication Digital Certificate Discretionary Access Control (DAC) You can skip this ad in 5 seconds