On January 21, 2026, Microsoft's Defender Security Research Team published a warning that should have made every CISO in the energy sector put down their coffee. A campaign had been running quietly against multiple energy companies — not through a software vulnerability, not through stolen credentials sold on a forum, but through a SharePoint link. An employee at a partner organization, whose account had already been compromised, sent what looked like a completely routine document-share email. The subject line read the way SharePoint subject lines always read. The link went to a real Microsoft domain. Nothing about it was wrong, except that it was.

That single campaign, documented across seven distinct stages by Microsoft's own researchers, is the cleanest public illustration we have of why adversary-in-the-middle phishing has quietly become the dominant way attackers break into Microsoft 365, Google Workspace, and Okta environments in 2026. Not the only way. The dominant way.

For most of the last decade, multi-factor authentication was the answer everyone gave when asked how to stop phishing. Turn it on, the thinking went, and a stolen password becomes worthless. For a long time that was true. It isn't anymore, and the reason isn't a flaw in MFA itself — it's that attackers stopped trying to guess or steal the password at all. They built infrastructure that sits in the middle of a real login, lets the real login happen, and steals the proof that it happened. Microsoft's own 2025 Digital Defense Report puts a number on how completely this has worked: 80% of MFA-bypass breaches now trace back to exactly this pattern.

This piece walks through what AiTM phishing actually is, how the kits running these campaigns are built and sold, what a real attack chain looks like stage by stage using Microsoft's own January 2026 case as the spine, why the controls most organizations are relying on don't touch this threat, and what detection architecture actually has to do differently to catch it.

What AiTM Phishing Actually Is

Strip away the acronym and the mechanism is almost embarrassingly simple. A reverse proxy server sits between the victim and the real login page — Microsoft, Google, Okta, whichever identity provider the organization actually uses. The victim visits what looks like a normal sign-in screen. They type their real password. The proxy quietly forwards that password to the real Microsoft server and gets back a real response. The victim is prompted for MFA, the same way they always are. They approve it — a push notification, a TOTP code, whatever method their organization uses. The proxy forwards that too.

At the end of this exchange, the real identity provider issues a session cookie — the small piece of data that tells every subsequent request "this person is already authenticated, don't ask again." The proxy captures that cookie as it passes through. From that point forward, the attacker doesn't need the password. They don't need to defeat MFA a second time. They have the actual, valid, fully-authenticated session, and they can load it into their own browser and walk straight into the account.

This is meaningfully different from classic phishing, where a fake page just collects a typed password and the attacker has to separately try to log in with it — an attempt that MFA would normally catch. AiTM doesn't try to defeat MFA. It lets MFA succeed, on the real service, and steals the result. That distinction is the entire reason this technique has been able to industrialize at the scale it has.

Why the Industry Settled on This One Term

The technique maps to MITRE ATT&CK technique T1557, combined in practice with T1539 for session cookie theft and T1556.006 for MFA process tampering. The name itself — adversary-in-the-middle rather than the older man-in-the-middle — reflects a deliberate shift in how security researchers describe this category, moving away from a term that implied passive network eavesdropping toward one that captures what's actually happening: an active participant inserting itself into a trusted exchange, at the application layer, not the network layer.

The Kits Doing This Work, and Who's Renting Them

What makes 2026 different from 2022, when Microsoft first documented AiTM attacks at scale against more than 10,000 organizations, isn't that the technique got cleverer. It's that it got packaged.

Threat intelligence firm Sekoia tracked eleven major AiTM phishing kits in active use through early 2025, and the rankings are not close. Tycoon 2FA carries the highest threat score of any kit they monitor — 4.8 out of 5 — based on infrastructure scale and detection telemetry. EvilProxy and NakedPages, two of the longest-running platforms, each maintained an average of 220 to 280 distinct active servers between January 2024 and April 2025, supporting an estimated 150 to 250 paying affiliates per platform. Evilginx, the open-source framework most of these commercial kits are built on top of, remains widely used on its own by threat actors who want to run a campaign without paying anyone.

The pricing is almost absurdly low for what it buys. Subscriptions run anywhere from $100 to $1,000 a month, and for that an affiliate gets a complete operational platform: email templates, anti-bot protection specifically designed to keep security researchers from studying the live infrastructure, a campaign management dashboard, and Telegram integration so stolen credentials and session cookies land in the operator's phone in real time. At the lower end, an attacker can run a kit-quality MFA-bypass campaign for less than the price of a mid-tier SaaS subscription.

80% of MFA-bypass breaches now trace back to AiTM session-token theft — Microsoft Digital Defense Report, 2025

Tycoon2FA: A Look Inside the Machine

Microsoft's own security team published a forensic breakdown of Tycoon2FA's internals in March 2026, and the detail is worth sitting with for a moment, because it explains exactly why signature-based detection keeps losing to this kit. The attack chain follows a consistent shape — phishing email, then a multilayer redirect chain, then a spoofed sign-in page running the AiTM relay, then authentication relay culminating in token theft — but the execution inside that shape is deliberately built to defeat anyone trying to fingerprint it.

Tycoon2FA's phishing pages don't just clone Microsoft's login screen. They mimic sign-in flows for OneDrive, Outlook, SharePoint, and Gmail individually, and the platform lets operators choose specific landing-page themes and branding to match whichever service makes the most sense for a given lure. Subdomains incorporate real SaaS brand names — Docker, Zendesk, Azure, SharePoint, OneDrive, even NordVPN — specifically to lower the entropy signals that automated detection models rely on to flag suspicious strings. The kit layers in anti-bot screening, browser fingerprinting, heavy code obfuscation, self-hosted CAPTCHAs, custom JavaScript, and dynamic decoy pages that show a security researcher something entirely different from what a real victim sees.

None of this requires the affiliate running the campaign to understand any of it. They log into a dashboard, pick a theme, configure how stolen data gets routed, and launch. The technical sophistication lives entirely on the kit operator's side. The barrier to running an MFA-defeating campaign against a Fortune 500 company is now, genuinely, lower than the barrier to running a basic credential-phishing campaign was five years ago.

Anatomy of a Real Campaign: The January 2026 Energy Sector Attack

Most explanations of AiTM phishing stay abstract. Microsoft's January 21, 2026 disclosure gives us something better — a documented, seven-stage attack chain against real organizations, broken down in enough detail that the mechanics stop being theoretical.

Stage 1 — Initial Access Through a Trusted Sender

The campaign didn't start with a stranger. It started with a phishing email sent from an account belonging to a genuinely trusted partner organization — one that had itself been compromised earlier, likely in an entirely separate incident. The message used a SharePoint URL and subject-line phrasing deliberately matched to how legitimate SharePoint document-sharing notifications actually read. Because the sending address was real and the recipient organization had an existing relationship with that partner, there was nothing here for a reputation-based filter to catch.

Stage 2 — The SharePoint Lure

Recipients clicked through to what appeared to be a standard document requiring authentication to view — exactly the kind of request employees in any organization respond to dozens of times a week without a second thought. SharePoint and OneDrive carry built-in legitimacy precisely because they're so ubiquitous in enterprise environments, and that familiarity is the entire point of using them as a delivery vehicle. Security researchers have taken to calling this pattern living-off-trusted-sites: instead of building suspicious-looking infrastructure from scratch, the attacker weaponizes infrastructure the target already trusts.

Stage 3 — AiTM Credential Theft

The link redirected to a spoofed sign-in page running a live AiTM relay. Victims entered real credentials, completed a real MFA challenge, and had no way to perceive that a proxy was sitting in the exchange — because from their perspective, login succeeded normally. Behind the scenes, the proxy captured both the credentials and the session token issued at the end of the flow.

Stage 4 — Inbox Rule Creation for Persistence

Once inside, the attackers didn't immediately act. They created inbox rules on the compromised account designed to delete specific incoming messages and mark others as read automatically — a quiet, low-visibility way to suppress any reply or warning that might tip off the real account owner that something was wrong.

Stage 5 — Phishing Spread at Scale

Using the now-compromised, fully trusted account, the attackers sent more than 600 phishing emails to internal colleagues and external contacts, drawing recipients from recent email threads and existing distribution lists. Every one of those 600-plus emails came from a real, authenticated, previously-trusted sender — which is precisely why this stage is so effective and so hard to catch with anything built around sender reputation.

Stage 6 — BEC Activity and Reply Suppression

This stage is classic business email compromise tradecraft layered on top of the AiTM foothold. The attacker monitored the mailbox for any reply questioning the legitimacy of the phishing message, read those replies, answered them in a way designed to reassure the sender that everything was genuine, and then deleted both the original concerned message and the attacker's own reassuring response — including pulling them from the Archive folder, where many users assume deleted items quietly persist.

Stage 7 — Account Compromise Expansion

Recipients inside the organization who clicked the malicious link were themselves subjected to a second AiTM attack, propagating the compromise to additional accounts. Microsoft's Defender Experts traced the full scope of the campaign by correlating landing IP addresses against sign-in IP patterns across affected accounts, which is how they were able to map exactly how far the compromise had spread.

Microsoft's own conclusion, stated directly in their disclosure, is the line that matters most for anyone building an incident response playbook around this threat: password resets alone are insufficient. Because the compromise lives in the session, not the credential, organizations affected by this exact pattern had to additionally revoke active session cookies and manually remove every attacker-created inbox rule — remediation steps that fall well outside what a standard identity-compromise response checklist typically covers.

The general remediation for identity compromise is resetting the password. In AiTM attacks, the sign-in session itself is what's compromised — and a password reset does nothing to a session that's already valid.

Why This Keeps Getting Bigger, Not Smaller

The energy sector campaign wasn't an isolated event. Three months later, between April 14 and 16, 2026, Microsoft's Defender Research team observed a separate, considerably larger AiTM campaign — more than 35,000 targeted users across over 13,000 organizations in 26 countries, with 92% of targets located in the United States. That campaign used a different lure entirely: PDF attachments disguised as HR disciplinary notices, with filenames like "Disciplinary Action — Employee Device Handling Case.pdf," routing victims through a Cloudflare CAPTCHA, then an intermediate "document encrypted, please authenticate" page, before finally landing on the real AiTM relay.

The lure changes. The underlying mechanism doesn't. And the delivery vehicle keeps evolving specifically to stay ahead of whatever defenders just learned to catch. Sekoia's research tracking this shift through 2024 and into 2025 shows a clear migration: QR codes embedded in PDF documents dominated early campaigns, then HTML attachments executing local JavaScript took over through 2024, and by April 2025 SVG file attachments — which render phishing content directly in the browser and slip past attachment filters tuned for more conventional formats — had become the preferred vector. Sekoia recorded a 67% quarter-over-quarter spike in live EvilProxy URLs alone during this period.

None of this evolution requires the underlying kit to change. Tycoon 2FA, EvilProxy, and the rest are infrastructure platforms. The lure sitting on top of that infrastructure is the only thing that needs to rotate to stay ahead of filters tuned to the last campaign's specific attachment type or subject line.

Why Startups and Mid-Market Companies Are Disproportionately Hit

There's a structural reason smaller organizations show up so often as victims in these campaigns, and it isn't bad luck. Most run entirely on Microsoft 365 or Google Workspace with software-based MFA — authenticator apps, SMS, or push notifications — which is exactly the category of MFA that AiTM kits are purpose-built to defeat. And most lack the conditional access controls that limit what a stolen session can actually do once an attacker has it: registered-device requirements, IP-based location restrictions, sign-in risk policies that flag an authenticated session suddenly appearing from an unfamiliar country.

There's also no targeting threshold built into the PhaaS business model that excludes smaller companies from the campaign list. At $100 to $350 a month, an affiliate can phish thousands of inboxes for less than the cost of a single enterprise software seat, and the economics work the same whether the target is a Fortune 100 company or a 40-person regional firm. A founder's or controller's compromised inbox becomes the launchpad for fraud against investors, customers, and payroll providers — often within hours of the initial compromise, because the attacker already has everything they need to act convincingly.

Why the Controls Most Organizations Already Have Don't Touch This

This is worth being precise about, because the gap here isn't a missing feature bolted onto an otherwise-complete security stack. It's a structural blind spot in how most identity and email security architecture was designed.

MFA Is Still Necessary — It's Just Not Sufficient Anymore

It's worth saying clearly: multi-factor authentication is not broken, and turning it off would make everything dramatically worse. Microsoft's own guidance on this point is direct — MFA remains a core pillar of identity security and is still highly effective at stopping a wide variety of threats. The honest way to frame AiTM's rise is that it reflects how much MFA has actually raised the bar for attackers, forcing them to build genuinely sophisticated proxy infrastructure instead of simply guessing or buying leaked passwords. The problem isn't that MFA failed. It's that software-based MFA methods — push notifications, TOTP codes, SMS — were never designed to resist a real-time relay attack, because nothing about completing them confirms that the browser the user is typing into is actually talking directly to Microsoft, rather than through a proxy in between.

Why Secure Email Gateways Miss This Almost Entirely

A traditional gateway is built to evaluate the technical attributes of an inbound message — sender reputation, known-bad links, attachment signatures. Stage one of the energy sector campaign came from a genuinely trusted, previously-legitimate sender. Stage five sent 600-plus emails from an account with real authentication history and real prior correspondence with every recipient. There was no spoofed domain to catch at any point in that chain, because nothing was spoofed. The sender was real. The link, on first click, went to a real Microsoft domain. The thing that was actually compromised — the session itself — exists entirely outside what a gateway built to inspect message content was ever designed to evaluate.

Why Sender Authentication Protocols Don't Help Either

SPF, DKIM, and DMARC verify that a message originated from a server authorized to send on behalf of a domain. Every email in this campaign passed that check cleanly, at every stage, because every sending account genuinely was authorized — it had simply been taken over. Authentication protocols answer the question "did this come from where it claims to come from." They have no mechanism for answering the much harder question this attack actually requires: "does the live session behind this account still belong to the person who's supposed to be using it."

What Actually Stops This

Phishing-resistant authentication — specifically FIDO2 security keys and passkeys — counters AiTM at the architectural level, because the cryptographic handshake these methods rely on is cryptographically bound to the legitimate domain itself. A reverse proxy serving a login page from a different domain simply cannot complete that handshake, which breaks the entire attack chain at the exact moment MFA would normally be exploited. This is the single most effective technical control against AiTM specifically, and it's worth treating as a near-term migration priority for any account with meaningful financial or administrative authority, rather than a someday upgrade.

Conditional access policies add a second layer that matters even when phishing-resistant MFA isn't yet fully rolled out — risk-based sign-in evaluation that factors in device status, IP location, and behavioral signals, configured so that a session suddenly appearing from an unfamiliar country or an unregistered device gets challenged again rather than waved through. And continuous access evaluation, where supported, shortens the window a stolen token remains useful by re-checking session validity against current risk signals rather than trusting a token for its full original lifetime.

Why Detection Has to Reason About Behavior, Not Just Check Signatures

Here's the uncomfortable conclusion that falls out of everything above: every individual technical artifact in an AiTM campaign can be, and usually is, completely legitimate. The sending domain is real. The session token is genuinely valid. The MFA approval genuinely happened. Pattern-matching tools built to flag known-bad signatures have nothing concrete to match against, because there isn't a known-bad signature here — there's a real authentication flow that happened to route through an extra hop nobody authorized.

This is exactly the category of threat that requires evaluating behavior in context rather than checking attributes against a blocklist. The question worth asking isn't whether this specific email or this specific login contains a recognizable malicious signature. It's whether the pattern of activity around it makes sense — does this account suddenly emailing 600 external contacts fit how this account has ever behaved before, does a sign-in from this location at this hour match this user's established pattern, do the inbox rules that just got created resemble anything a real user would ever configure for themselves.

How TRACE Approaches AiTM-Driven Compromise

StrongestLayer's TRACE engine evaluates exactly these behavioral dimensions as part of its core reasoning architecture, because AiTM-driven account takeover produces a specific, learnable signature even when every individual artifact looks clean. TRACE's behavioral baselining tracks how each account in an organization actually sends mail — typical recipient patterns, typical volume, typical timing — which means a sudden spike to 600-plus external and internal recipients from a single account generates a sharp, specific anomaly signal regardless of how authentic the sending credentials look.

The same baselining extends to mailbox configuration itself. An inbox rule that begins silently deleting incoming replies or auto-marking messages as read is not normal behavior for the overwhelming majority of real users, and TRACE's context engine is built to flag exactly this kind of configuration change as a high-priority signal, independent of whatever sender or content evaluation already happened upstream. Because the detection isn't anchored to message content or sender reputation, it remains effective at the exact stage where AiTM compromise actually does its damage — after the initial click, inside the account, where traditional email security has no visibility at all.

TRACE's pre-campaign threat hunting layer adds a further dimension specific to how AiTM infrastructure operates. Because kits like Tycoon2FA rotate subdomains daily and lean heavily on brand-name impersonation in their URL structure, continuous monitoring of domain registration patterns and certificate issuance tied to brand and platform-name variants can surface emerging proxy infrastructure before it's ever used in an active lure — closing part of the window these campaigns depend on.

Building a Defensible AiTM Response

Defending against this threat takes a layered approach, because no single control closes every stage of the chain documented above.

Migrate High-Risk Accounts to Phishing-Resistant MFA First

Not every account needs FIDO2 keys on day one, but executives, finance staff, IT administrators, and anyone with the authority to move money or grant access should be the first wave. This is the one control that breaks the AiTM chain at its architectural root rather than detecting the compromise after it's already happened.

Tighten Conditional Access Before You Need It

Risk-based sign-in policies — device status checks, IP-location evaluation, sign-in risk scoring — should already be configured before an incident, not assembled during one. Security defaults are a reasonable baseline; risk-based conditional access policies are what actually catch a session appearing somewhere it shouldn't.

Build Session Revocation Into Every Identity Incident Response Plan

Make it explicit, written down, and rehearsed: password reset is the first step, not the last one. Every AiTM-driven identity incident response needs to include active session revocation, a review of any MFA changes made during the suspected compromise window, and an audit of inbox rules created on the affected account — because all three of those, not just the password, are what the attacker actually controlled.

Deploy Detection That Watches Behavior Inside the Mailbox, Not Just Mail Entering It

The entire energy sector campaign succeeded specifically because nothing was watching what happened after the click — the inbox rule creation, the reply suppression, the 600-email spike. A detection layer that only evaluates incoming mail has no visibility into any of that. The detection that actually catches this operates continuously, evaluating account behavior against an established baseline, not just messages against a blocklist.

Final Thoughts: The Proof of Login Is Not the Same as the Person Logging In

For years, the entire model of identity security rested on a simple assumption: if someone provides the right password and completes the right MFA challenge, they are who they claim to be. AiTM phishing breaks that assumption cleanly, not by defeating either control, but by letting both succeed and stealing the proof that they did.

The energy sector campaign Microsoft documented in January 2026 didn't need a zero-day. It didn't need custom malware. It needed a SharePoint link, a previously compromised but genuinely trusted sender, and seven patient stages that each, individually, looked like nothing — right up until Defender Experts traced 600-plus phishing emails and a chain of session hijacks back to a single point of initial access. Three months later, a different operator ran the same fundamental playbook against 35,000 more people across 13,000 organizations, with a completely different lure wrapped around the same proven mechanism.

This is the threat landscape every organization running on Microsoft 365, Google Workspace, or Okta is actually operating in now. Not a hypothetical. A documented, repeating, industrialized pattern with a $100-a-month price of entry. Defending against it means accepting that MFA, while still necessary, was never built to survive a real-time relay, migrating the accounts that matter most to authentication methods that are, and building detection that watches what happens to an account after the click — not just what arrives in the inbox before it.

That last piece is what TRACE was built to provide: behavioral reasoning that doesn't depend on a message looking suspicious, because in an AiTM compromise, nothing does. It depends on noticing that this account, today, is not behaving like this account ever has before — and treating that, correctly, as the signal that matters most.

Frequently Asked Questions (FAQs)

Q1: What does AiTM stand for, and why does it matter?

AiTM stands for adversary-in-the-middle. It's a phishing technique where a proxy server sits between the victim and a real login page — Microsoft 365, Google Workspace, Okta, whatever the target organization actually uses. The victim logs in normally, completes MFA normally, and has no way of knowing anything is wrong, because from their end, everything worked. What they don't see is that the proxy captured their session cookie as it passed through. That cookie is what the attacker actually wanted. It's proof of a completed, authenticated login — and it lets them walk straight into the account without credentials or MFA.

Q2: If I have MFA enabled, shouldn't I be protected?

MFA still matters — a lot. It blocks the vast majority of credential-based attacks, and turning it off would make things dramatically worse. But software-based MFA methods — push notifications, TOTP codes, SMS — weren't designed to survive a real-time relay. AiTM doesn't defeat MFA. It lets MFA succeed and steals the result. The session cookie issued after a successful MFA login is what gets compromised, not the MFA step itself. Microsoft's own 2025 Digital Defense Report puts a hard number on this: 80% of MFA-bypass breaches now trace back to AiTM session-token theft.

Q3: What is Tycoon 2FA and why does it keep coming up?

Tycoon 2FA is currently the highest-threat-rated AiTM phishing kit tracked by threat intelligence firm Sekoia — 4.8 out of 5, based on infrastructure scale and active campaign telemetry. It's a phishing-as-a-service platform: affiliates pay a monthly subscription and get a complete operational setup including email templates, a campaign dashboard, anti-bot protection designed to keep security researchers away from the live infrastructure, and Telegram integration so stolen session cookies land on the attacker's phone in real time. Microsoft published a forensic breakdown of Tycoon2FA's internals in March 2026. The kit spoofs sign-in flows for Microsoft 365, OneDrive, SharePoint, Gmail, and others, and rotates subdomains daily to stay ahead of blocklists.

Q4: What actually happened in the January 2026 energy sector campaign?

Microsoft's Defender Security Research Team documented it on January 21, 2026. A campaign targeting energy companies used a SharePoint link sent from a genuinely compromised partner account — one the recipients already trusted — as its opening move. Clicking through led to an AiTM relay that captured session tokens after real MFA completions. The attacker then created inbox rules on compromised accounts to suppress incoming replies, used those accounts to send more than 600 additional phishing emails to internal and external contacts, suppressed any concerned responses, and expanded the compromise to additional accounts when those recipients clicked through. Microsoft's own conclusion: password resets alone were insufficient. The session itself had to be actively revoked.

Q5: Why can't secure email gateways catch this?

Because the attack's most damaging stages don't live in the inbound email. Stage one of the energy sector campaign came from a genuinely trusted, previously legitimate sender — nothing for a reputation filter to flag. Stage five sent 600-plus phishing emails from a real, authenticated account with real communication history with every recipient. There was no spoofed domain at any point. The thing that was actually compromised — the live session — exists entirely outside what a gateway built to evaluate message content was ever designed to see. A gateway stops bad things arriving in the inbox. AiTM's damage happens after the inbox, inside the account.

Q6: What's the difference between AiTM and a regular man-in-the-middle attack?

Classic man-in-the-middle attacks typically intercept network traffic — they sit on the wire between two parties and eavesdrop on what passes through, often requiring network access. AiTM operates at the application layer, not the network layer. The attacker runs a purpose-built reverse proxy that relays HTTP(S) traffic to and from the real identity provider, appearing as a legitimate login page to the victim and as a legitimate browser to the server. No network access required. No SSL stripping needed. Just a convincing phishing page pointing to proxy infrastructure that handles the relay transparently.

Q7: How affordable are these kits for attackers?

Genuinely cheap. Subscription pricing for kits like Tycoon 2FA, EvilProxy, and NakedPages runs anywhere from $100 to $1,000 a month. At the lower end, an affiliate can run a complete MFA-bypass campaign against thousands of inboxes for less than the price of a mid-tier SaaS subscription. Sekoia tracked 150 to 250 paying affiliates per platform on EvilProxy and NakedPages, and EvilProxy alone maintained an average of 220 to 280 active servers between January 2024 and April 2025. The economics make this technique viable against targets of any size — a 40-person regional firm gets the same campaign infrastructure as a Fortune 100.

Q8: What is phishing-resistant MFA and how does it actually stop AiTM?

Phishing-resistant MFA — specifically FIDO2 security keys and passkeys — counters AiTM at the architectural level. The cryptographic handshake these methods use is bound to the legitimate domain itself. A reverse proxy serving a spoofed login page from a different domain simply cannot complete that handshake, which breaks the attack chain at the exact moment it would otherwise capture the session. This is the single most technically effective control against AiTM specifically, and it should be treated as a near-term migration priority for any account with meaningful financial or administrative access, not a someday upgrade.

Q9: What's the living-off-trusted-sites tactic and why is it so effective?

Living-off-trusted-sites is exactly what it sounds like: instead of building suspicious-looking infrastructure, the attacker weaponizes platforms the target already trusts. SharePoint, OneDrive, DocuSign, Dropbox, Google Drive — services employees interact with dozens of times a week without scrutinizing them closely. The January 2026 campaign used a SharePoint link that went to a real Microsoft domain on first click. There was nothing technically wrong with the URL. The trust was real. The lure exploited that real trust to get the initial click, after which the AiTM relay took over. Filters built on domain reputation have no answer for an attack that routes through infrastructure with an impeccable reputation.

Q10: What should incident response look like after an AiTM compromise?

Three things, in order. First, revoke active sessions — not just reset the password. The session is what's compromised, and a password reset leaves a valid stolen session completely untouched. Second, audit inbox rules on the affected account — specifically looking for rules that auto-delete incoming messages, mark replies as read, or route mail to unusual folders. Third, check for MFA method changes made during the suspected compromise window, since attackers who gain access frequently add their own authentication method to maintain persistence after the initial session expires. All three steps need to be explicit in the runbook, not improvised during the incident.

Q11: Why does TRACE flag AiTM-driven compromise if the session looks legitimate?

Because the session looking legitimate is exactly what makes behavioral detection valuable here. TRACE's baselining tracks how each account in an organization actually sends mail — typical recipient patterns, typical volume, typical timing. A single account suddenly emailing 600-plus internal and external contacts in a short window generates a sharp anomaly signal regardless of how authentic the sending credentials look. The same baselining extends to mailbox configuration: an inbox rule that auto-deletes incoming replies is not normal user behavior for the overwhelming majority of real accounts, and TRACE flags exactly that configuration change as a high-priority signal, independent of anything upstream about the original email. That's where the real detection lives — inside the account, after the click, where traditional email security has no visibility.

Q12: Are mid-market companies a serious target for AiTM campaigns, or is this mostly an enterprise problem?

Mid-market companies are primary targets, not secondary ones. Most run entirely on Microsoft 365 or Google Workspace with software-based MFA — push notifications, TOTP, SMS — which is exactly the category these kits are built to defeat. Most lack the conditional access controls that limit what a stolen session can do. And PhaaS kits don't have a targeting floor: at $100 to $350 a month, an affiliate can run a campaign against thousands of inboxes regardless of whether the target is a Fortune 500 or a 40-person firm. A compromised controller's or founder's account becomes a launchpad for fraud against investors, vendors, and payroll processors within hours.

‍