Observed Campaign Pattern
Between April 14 and 16, 2026, the Microsoft Defender research team observed a coordinated phishing campaign that reached more than 35,000 users across over 13,000 organizations in 26 countries. The bulk of the targeting landed in the United States, and the affected organizations spanned healthcare, financial services, professional services, and technology rather than a single vertical.
The campaign is worth studying not because it was novel in any single component, but because it assembled familiar components cleanly. It used a disciplinary pretext to create urgency, a PDF attachment to defer the malicious link past the mail gateway, a CAPTCHA to screen out automated analysis, and an adversary-in-the-middle proxy to steal authenticated sessions in real time. Each stage handed off to the next with a clear job.
For an APT tradecraft tracker, that staged structure is the record to keep. The pretext, the redirect carrier, the analysis gate, and the proxy are reusable parts. An actor can swap the theme, the file type, or the proxy framework and still run the same shape of campaign.
The Disciplinary Pretext
The emails carried PDF attachments with filenames built around workplace discipline, with examples such as an awareness case log and an employee device-handling disciplinary action. The pretext is the engine of the campaign. A message that implies the recipient is personally the subject of an HR case creates a specific kind of urgency that a generic invoice or shipping lure does not.
Fear about one's own standing at work narrows attention. The recipient wants to know what they are accused of, and they want to know now. That motivation pushes them past the small hesitations that might otherwise stop them: an unfamiliar sender, a slightly wrong domain, an attachment they did not expect.
The red-team lesson is that pretext quality matters more than payload sophistication. The blue-team lesson is that awareness content should name this category directly. Users handle "you have an unpaid invoice" with more skepticism than "you are the subject of a conduct review," and training should close that gap.
A PDF as the First Redirect
The malicious link did not appear in the email body. It was inside the PDF, behind a "Review Case Materials" prompt. This is a deliberate placement. Many secure email gateways inspect and rewrite URLs in message bodies more aggressively than they parse links embedded in attachments. Putting the link one layer down buys the campaign a better chance of reaching the inbox intact.
The PDF also does useful work on the human side. It looks like a document, and documents feel like the natural place for case materials to live. Opening it and then clicking inside it feels like two ordinary steps rather than one suspicious one. The attachment is both an evasion layer and a credibility layer at the same time.
Defenders should treat attachment-borne links as a first-class detection surface. A PDF whose only meaningful content is a single outbound link to a freshly registered domain is a strong signal, and that signal is lost if inspection stops at the message body.
The CAPTCHA as an Anti-Analysis Gate
After the click, victims were sent to attacker-controlled domains that displayed a Cloudflare-style CAPTCHA, presented as a check to confirm the visitor was arriving from a valid session. To a user, this looks reassuring. CAPTCHAs are associated with security, so the page feels more legitimate, not less.
The real purpose is anti-analysis. A CAPTCHA blocks the automated crawlers, sandboxes, and URL-detonation systems that defenders rely on. Those systems often cannot solve the challenge, so they never see the credential-harvesting page behind it. The CAPTCHA splits the audience: a human proceeds, an automated analyzer stops at the gate and may record the site as benign.
This is the most important reframing in the whole campaign. A CAPTCHA inside a suspicious redirect chain is not a security control protecting the user. It is a filter protecting the attacker. Detection logic and analyst playbooks should treat an unexpected CAPTCHA on a redirect path as a reason for more suspicion, not less.
Adversary-in-the-Middle Token Theft
The chain ended at a sign-in experience that proxied the real Microsoft login through an adversary-in-the-middle server. The victim sees a genuine-looking sign-in page, enters their credentials, and completes multi-factor authentication. Every step is real, because the proxy is relaying it to the legitimate service and relaying the responses back.
What the attacker captures is not just the password. It is the session token issued after authentication succeeds. That token represents a login that has already cleared MFA. Replaying it gives the attacker an authenticated session without needing the password or the second factor again. This is why "we have MFA" is no longer a complete answer to phishing. AiTM does not break MFA; it steps around it by stealing the result.
The durable defense is to make the stolen token less useful. Phishing-resistant methods such as passkeys and certificate-based authentication resist the proxying step itself. Binding tokens to a managed, compliant device means a token replayed from attacker infrastructure fails a device check. Conditional access that evaluates device and location at the time of token use, not only at sign-in, narrows the replay window.
DetectionDetection Opportunities
Detection should follow the handoffs. At the mail layer, surface PDFs whose primary content is an outbound link, especially to recently registered domains. At the identity layer, the strongest signals appear after the token is stolen: a session token first seen on attacker infrastructure, then reused from a new device, a new ASN, or an improbable location relative to the original sign-in.
A useful hunt is to compare the network context of token issuance against the context of subsequent token use:
SigninLogs
| where ResultType == 0
| where AuthenticationRequirement == "multiFactorAuthentication"
| project UserPrincipalName, SessionId, IssueTime = TimeGenerated, IssueIP = IPAddress, IssueASN = AutonomousSystemNumber
| join kind=inner (
SigninLogs
| project UserPrincipalName, SessionId, UseTime = TimeGenerated, UseIP = IPAddress, UseASN = AutonomousSystemNumber
) on UserPrincipalName, SessionId
| where IssueASN != UseASN and UseTime > IssueTime
| where datetime_diff('minute', UseTime, IssueTime) < 60The intent is not the exact query but the idea behind it: a single session reused across two unrelated networks within a short window is consistent with token theft and replay. Treat post-authentication context as evidence, rather than treating a successful MFA sign-in as the end of the question.
Red and Blue Application
Red teams can use this campaign as a template to test controls end to end: a personally urgent pretext, an attachment-borne link, an anti-analysis CAPTCHA gate, and an AiTM proxy. The objective of the exercise is to find which stage the organization can actually see. Many programs can catch a crude lure but cannot detect a stolen token being replayed, and that is the gap the exercise should expose.
Blue teams should use the same staged model to decide where to invest. If the answer to AiTM is still "we have MFA," the campaign has already shown why that is incomplete. The work is to move toward phishing-resistant authentication, bind sessions to compliant devices, and build identity detections that question a token after it is issued. The shared goal across both teams is the same: stop treating a successful sign-in as proof that the right person is on the other end.