Most phishing relies on alarm: a frozen account, a failed payment, a package held at customs. The campaign Microsoft detailed in early May 2026 relied on something quieter and more corrosive — professional dread. The lure was a fake internal "code of conduct" investigation, the kind of email an employee reads twice, tells no one about, and clicks through quickly to make the discomfort end. Subject lines like "Internal case log issued under conduct policy" do not trigger the skepticism that a fake invoice does. They trigger compliance.
Behind the HR-style packaging was a mature adversary-in-the-middle (AiTM) operation. Victims were walked through CAPTCHA gates, an email-collection step, and finally a "Sign in with Microsoft" prompt that was not Microsoft at all but a malicious reverse proxy. The proxy relayed the real Microsoft sign-in experience to the victim while sitting in the middle, harvesting not the password but the session token issued after a fully successful authentication, MFA included. With that token, the attacker held a live, MFA-satisfied session. No password to crack, no second factor to phish in real time as a separate step — the token is the completed login.
Microsoft observed the coordinated waves between April 14 and 16, 2026, and published its analysis around May 8, 2026. The scope was substantial: more than 35,000 users across over 13,000 organizations in 26 countries, with the United States accounting for roughly 92 percent of targets. This post breaks down the chain, the detection surface, and the controls that actually move the needle — because for this attack class, conventional MFA is not one of them.
TL;DR
- A phishing campaign using fake "code of conduct" investigation lures was detailed by Microsoft around May 8, 2026, with the main waves observed April 14-16, 2026.
- Scope: 35,000+ users, 13,000+ organizations, 26 countries; ~92% of targets in the US. Most-hit sectors: healthcare/life sciences (~19%), financial services (~18%), professional services (~11%), technology/software (~11%).
- The chain uses an adversary-in-the-middle (AiTM) proxy that relays the genuine Microsoft sign-in page and steals the post-authentication session token — bypassing MFA without the victim's password ever leaving the real flow.
- CAPTCHA gates and an email-collection step filter out automated analysis and pre-validate targets before the proxy stage.
- Microsoft did not publicly attribute the campaign to a named actor.
- The durable defense is phishing-resistant MFA (FIDO2 / passkeys / Windows Hello for Business) plus conditional-access controls that bind tokens to managed devices; image-CAPTCHA-gated AiTM kits defeat ordinary OTP and push MFA.
What happened
Microsoft's analysis describes a multi-stage social-engineering operation that prioritized credibility over volume tricks. The campaign opened with phishing emails impersonating an internal HR or compliance function. Reported subject lines and artifacts include phrasing such as "Internal case log issued under conduct policy" and PDF attachments named in the style of "Awareness Case Log File – Tuesday 14th, April 2026.pdf."
The PDF presented a fake case document and a "Review Case Materials" action. Following it led the victim through two image-based CAPTCHA gates. CAPTCHAs in a phishing flow are not there to stop humans; they are there to stop machines — automated crawlers, sandboxes, and security scanners that would otherwise detonate the link and flag the infrastructure. After the CAPTCHA gates, an intermediate page collected the victim's email address, pre-populating and validating the target before the expensive proxy stage.
The victim then encountered a "Sign in with Microsoft" prompt. This is the AiTM core: the prompt drove the session through an adversary-in-the-middle proxy that relayed the legitimate Microsoft sign-in experience. The victim saw a real Microsoft login, entered real credentials, and completed a real MFA challenge. The proxy, sitting in the middle, captured the resulting session token. With that token, the attacker had an authenticated session without ever needing to defeat MFA as a separate obstacle — the MFA had already been satisfied inside the relayed flow, and the token represents that satisfied state.
Microsoft reported the main observation window as April 14-16, 2026, with telemetry showing 35,000-plus targeted users across 13,000-plus organizations in 26 countries. Sample indicators published include lookalike domains such as acceptable-use-policy-calendly[.]de and compliance-protectionoutlook[.]de, and sender addresses including cocpostmaster@cocinternal.com and nationaladmin@gadellinet.com.
How the attack worked
[1] HR-style lure: "code of conduct" investigation email
| subject e.g. "Internal case log issued under conduct policy"
v
[2] PDF attachment with "Review Case Materials" link
v
[3] Two image CAPTCHA gates -> filters sandboxes / automated scanners
v
[4] Email-collection page -> pre-validates the target
v
[5] "Sign in with Microsoft" -> AiTM reverse proxy relays REAL login
| victim enters creds + completes MFA against genuine endpoint
v
[6] Proxy harvests the issued SESSION TOKEN (MFA already satisfied)
v
[7] Attacker replays token -> live, MFA-satisfied M365 session
The reason AiTM defeats most MFA is worth stating precisely, because the industry messaging that "MFA stops phishing" created a false sense of safety here. Time-based one-time passwords and push approvals authenticate the user at a moment in time. They do nothing to authenticate the channel. An AiTM proxy is a man-in-the-middle on a channel the user believes is direct. Whatever the user types, including a valid OTP or an approved push, is relayed faithfully to the real Microsoft endpoint. Microsoft issues a session token to what it believes is a legitimate client. The proxy keeps a copy. The OTP being single-use does not matter, because the proxy does not need to reuse the OTP — it needs the token that the successful OTP produced.
Phishing-resistant MFA breaks this because it authenticates the origin. FIDO2 / WebAuthn credentials are cryptographically bound to the legitimate site's origin (the relying-party ID). When the browser sees the phishing domain rather than login.microsoftonline.com, the authenticator simply will not produce a valid assertion for the wrong origin. The proxy has nothing to relay because the signed challenge is scoped to a domain the proxy does not control.
Below is an illustrative, non-functional sketch of the conceptual difference, to make the origin-binding point concrete — not runnable code:
# ILLUSTRATIVE — why phishing-resistant MFA defeats AiTM
# OTP / push (phishable): user proves identity, channel unverified
verify(user_secret) -> OK -> Microsoft issues session_token
# proxy sits in channel, copies session_token <-- theft succeeds
# FIDO2 / passkey (phishing-resistant): assertion bound to origin
sign(challenge, origin = "login.microsoftonline.com")
# but browser is on "compliance-protectionoutlook[.]de"
sign(challenge, origin = "compliance-protectionoutlook[.]de") -> NO valid credential
# authenticator refuses -> proxy has nothing to relay <-- theft fails
What detection looks like
AiTM token theft leaves a subtler trail than credential stuffing, but it is not invisible. Concentrate on the sign-in and post-sign-in telemetry in Entra ID and Microsoft 365.
- Sign-ins through anomalous infrastructure immediately followed by token replay. The legitimate user authenticates from their normal device/location; minutes later the same session token is exercised from the attacker's hosting (VPS / proxy ASN). Watch for a session whose origin shifts mid-life.
- Entra ID Protection "risky sign-in" and "anomalous token" alerts. These fire on unfamiliar sign-in properties and impossible-travel patterns that AiTM proxies frequently trigger.
- Inbox-rule creation post-sign-in. A hallmark of token-backed account takeover is the immediate creation of mail rules — often with special-character-only or single-letter names — to hide attacker correspondence and replies. Alert on new inbox rules created shortly after a flagged sign-in.
- Unusual Microsoft Graph / mailbox access. Token-holding attackers commonly enumerate mail and contacts via Graph for downstream BEC. Baseline Graph API usage per identity and alert on spikes.
- Lookalike-domain telemetry. Block and alert on the reported IOC domains and the broader pattern of
.delookalikes impersonating Microsoft, Outlook, and Calendly. Feed CAPTCHA-gated phishing domains into your proxy/DNS blocklists.
What to do Monday morning
Ordered by impact against this specific attack class.
- Roll out phishing-resistant MFA for all privileged and high-value accounts first. FIDO2 security keys, passkeys, or Windows Hello for Business. This is the single control that structurally defeats AiTM token theft. OTP and push MFA do not.
- Tighten conditional access to bind sessions to compliant/managed devices. Require device compliance or hybrid-join for access to sensitive apps so a stolen token from an unmanaged attacker host fails the policy even if it is otherwise valid.
- Shorten token and session lifetimes; enable continuous access evaluation (CAE). CAE lets Entra ID revoke access near-real-time on risk signals (e.g., a risky-sign-in detection), shrinking the window a stolen token stays useful.
- Hunt now for the post-compromise tell-tales. Query for inbox rules with anomalous names created in the campaign window (mid-April 2026 onward), and review sign-ins flagged risky that nonetheless succeeded.
- Block the published IOCs and the lure pattern. Add the reported domains and senders to your mail and web filtering; tune detection for "code of conduct" / "conduct policy" HR-impersonation lures with PDF attachments.
- Turn on Microsoft's recommended baseline: Zero-hour Auto Purge (ZAP), Safe Links, Safe Attachments, and Defender SmartScreen/network protection, to catch the delivery and detonation stages.
- Brief employees on the specific lure. Tell staff plainly that HR/compliance investigations are never initiated through an emailed PDF with a sign-in link, and that the right response is to report, not to click.
Why this keeps happening
The recurring failure is a mismatch between how MFA is marketed and how it actually works. For a decade the message was "enable MFA and you are safe from phishing." That message was always imprecise. Possession-and-knowledge factors authenticate the user; they do not authenticate the channel or the origin. AiTM phishing kits — now productized and sold as a service, with CAPTCHA evasion and real-time relaying built in — industrialized the gap between those two things. A control most organizations adopted specifically to stop phishing turns out not to stop the modern version of it.
The second force is social-engineering sophistication. The "code of conduct" lure is a study in psychological targeting: it exploits hierarchy, shame, and the instinct to handle a sensitive matter privately and quickly. CAPTCHA gates and email pre-validation show an operation optimizing for evasion and conversion, not spray-and-pray. As AI lowers the cost of producing fluent, context-aware lures, the volume and believability of these campaigns will keep climbing.
The structural fix
This campaign is fundamentally an identity and human-layer problem, and the durable fixes are phishing-resistant MFA and conditional access — controls that live in your identity provider, not in a supply-chain tool. We will not overstate Safeguard's role here.
Where Safeguard helps is the second-order blast radius. AiTM token theft is rarely the objective; it is a foothold the attacker uses to harvest secrets and pivot — exactly the pattern seen when token-holding intruders grep mailboxes, tickets, and repos for credentials. Secret detection across your code, CI/CD, and IaC reduces the payoff of a compromised mailbox or chat session by ensuring fewer live API keys, deployment tokens, and database credentials are sitting in places an authenticated session can reach. It would not have stopped the phish, but it shortens dwell time and shrinks what a stolen token can ultimately monetize. Pairing that with an incident-response workflow that treats any AiTM detection as a token-and-secret compromise — not just a password reset — is the honest improvement available.
What we know we don't know
- Microsoft did not publicly attribute the campaign to a named threat actor; do not assume a specific group.
- The reported figures (35,000+ users, 13,000+ orgs, 26 countries, sector percentages) are Microsoft's telemetry-derived estimates of targeting, not confirmed counts of successful compromises.
- The relationship between this "code of conduct" wave and the separate AI-enabled device-code phishing campaign Microsoft described in April 2026 is not fully clarified; they share AiTM/token-theft themes but are reported as distinct operations.
References
- Microsoft Security Blog (related April 2026 device-code phishing analysis): https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/
- MSFT News Now, "Microsoft warns of multi-stage 'code of conduct' phishing campaign for May 2026 abusing AiTM to steal tokens": https://msftnewsnow.com/microsoft-code-of-conduct-phishing-aitm-token-thef/
- SpyCloud, "Device Code Phishing: The New AiTM Attack Bypassing MFA": https://spycloud.com/blog/device-code-phishing-the-new-aitm-attack-bypassing-mfa/
- Cyber Security News, "Tycoon 2FA AiTM Kit Bypasses MFA on Entra ID and Google Workspace Accounts": https://cybersecuritynews.com/tycoon-2fa-aitm-kit-bypasses-mfa/
- IT Security Guru, "The AI Phishing Revolution: From Spray-and-Pray to Autonomous Operations": https://www.itsecurityguru.org/2026/05/27/the-ai-phishing-revolution-from-spray-and-pray-to-autonomous-operations/
Internal reading: