Users typed passwords, approved MFA, and still lost their Microsoft 365 sessions. In the Payroll Pirates campaign disclosed by Arctic Wolf Labs, voicemail-themed emails funneled victims through trusted Google and Amazon infrastructure into an adversary-in-the-middle proxy of the real Microsoft login. Victims completed multi-factor authentication on that proxied flow; attackers harvested the resulting session cookies and used compromised workforce accounts to identify finance and payroll staff and collect related mail across hundreds of organizations in the US, Canada, and Europe.
An adversary-in-the-middle attack is a reverse-proxy phishing setup that sits between the victim and the real identity provider, captures credentials and live MFA completion, and obtains a usable authenticated session for the attacker.
How voicemail lures and a six-stage redirect chain reached Microsoft 365
According to Arctic Wolf Labs, the operation used voicemail-themed phishing emails to push recipients toward pages that proxied the genuine Microsoft authentication flow, even when MFA was enabled. The delivery path was not a crude lookalike domain sitting in plain sight. Arctic Wolf describes a multi-stage redirect chain that abused trusted Google and Amazon infrastructure, including paths associated with Google Meet, Google Ads infrastructure, and Amazon S3, so filters and human skepticism both had less to grab onto.
That design matters. Security teams train people to distrust random domains. They do not train people as hard to distrust a chain that starts on infrastructure their browsers already treat as ordinary business web traffic. By the time the victim landed on the proxied Microsoft 365 login, the page looked like the real thing because, from the victim's perspective, it was driving the real authentication ceremony.
Arctic Wolf Labs reported that hundreds of organizations across healthcare, education, manufacturing, government, and professional services were targeted in July 2026, with successful intrusions observed. Public disclosure landed on 6 August 2026 while the campaign was still described as active and widespread. Arctic Wolf also noted significant technical and behavioral overlap with the Payroll Pirates activity cluster Microsoft tracks as Storm-2755, and with related activity documented earlier by Security Risk Advisors. Exact victim counts, named organizations, and record volumes were not published in the material available, so the honest scale statement is the one Arctic Wolf gave: hundreds of organizations targeted, with confirmed account compromises used for finance-oriented mailbox work.
Why finishing MFA still produced a session the attacker could keep
The failure was not that MFA never ran. According to the campaign facts Arctic Wolf laid out, MFA was completed by the legitimate user. The attacker intercepted the resulting token.
That is how AiTM reverse proxies beat push approvals, TOTP codes, and SMS codes. Those factors are transferable proofs. The victim proves identity to the proxied login. The proxy forwards a completed authentication to Microsoft. Microsoft issues a normal cloud session. The attacker copies the session cookie or equivalent token and continues as the user without another prompt.
| Control in play | What happened in this campaign | Why it failed |
|---|---|---|
| Password | Entered on proxied Microsoft login | Visible to the reverse proxy |
| Push / TOTP / SMS MFA | Completed by the real user | Approval is phishable through the proxy |
| Microsoft 365 session cookie | Harvested after auth succeeded | Reusable without a fresh MFA challenge |
| SSO blast radius | One cloud session, many apps | Mail and related workloads open from one token |
Once that cookie existed, persistence no longer depended on tricking MFA again. Arctic Wolf reported automated activity that maintained compromised sessions at roughly eight-hour intervals, plus residential proxies so follow-on sign-ins looked more like ordinary consumer or local traffic. At that point defenders were dealing with a live cloud session, not a login prompt. Shortening session lifetime only forces the attacker to refresh or re-steal sooner. It does not undo the fact that a reusable token was issued through a phishable ceremony.
This is also where classic workforce SSO collides with zero-trust slogans. One Microsoft 365 authentication is supposed to open mail, files, chat, and whatever else is federated behind the same identity plane. When the session is stolen, that convenience becomes a skeleton key. No second app login is required for the attacker to start reading the mailbox that matters.
From stolen sessions to payroll and finance mailbox hunting
Post-compromise behavior was not random data vacuuming for its own sake. According to Arctic Wolf Labs, compromised Microsoft 365 accounts were used to identify personnel involved in financial workflows and to collect related email, with MailItemsAccessed-style activity supporting business-email-compromise style payroll and finance targeting. That is the pirate part of Payroll Pirates: get a real workforce session, map who touches money movement, and live inside those threads.
Nothing in the disclosed chain required OAuth consent phishing or a malicious app grant. The attackers did not need the user to authorize a third-party application. They needed the user to finish a login that looked legitimate. After that, mailbox search and mail-item access were ordinary authenticated actions performed with a stolen session.
For security teams cleaning this up, the ugly operational reality is familiar. You revoke sessions, force re-authentication, hunt anomalous MailItemsAccessed patterns, check forwarding rules and inbox rules, and watch for residential-proxy sign-in noise that does not match the user's normal path. All of that is containment after the token already left the building. It is necessary. It is also slower and noisier than never issuing the token to a proxied client in the first place.
Device-bound, origin-bound authentication closes the login path this kit needs. Transferable OTP and push factors do not. Passkeys and other phishing-resistant login factors refuse a proxied origin at the authentication ceremony; full phishing-proof coverage across enrollment and recovery is a broader lifecycle question. This campaign's documented failure sat squarely on the phishable login surface, not on helpdesk re-enrollment.
The prevention-focused companion walks through how that login path is closed before a Microsoft 365 session cookie is ever issued: stop AiTM Microsoft 365 phishing with device-bound MFA.
FAQ
Did users actually complete MFA in the Payroll Pirates Microsoft 365 campaign?
Yes. In the Payroll Pirates Microsoft 365 AiTM campaign reported by Arctic Wolf Labs, MFA was completed by the legitimate user on a proxied Microsoft authentication flow, and the attacker intercepted the resulting session token. The problem was not a missing second factor. The problem was a phishable factor completed through an adversary-in-the-middle reverse proxy.
How did Payroll Pirates attackers keep Microsoft 365 access after the initial login?
Payroll Pirates operators kept Microsoft 365 access by harvesting authenticated session cookies or tokens after the victim finished login and MFA, then maintaining those sessions with automated refresh activity at roughly eight-hour intervals and residential proxies. Because the session was already issued, later mailbox access did not require another MFA prompt until defenders revoked or expired the token.
Was this campaign OAuth consent phishing against Microsoft 365?
No. Public reporting on the Payroll Pirates Microsoft 365 campaign describes AiTM proxying of the genuine Microsoft login and theft of the resulting session, not pure authorization abuse such as malicious OAuth consent grants. The user authenticated; the attacker stole the session that authentication produced.
Why didn't ordinary Microsoft 365 MFA stop the Payroll Pirates AiTM emails?
Ordinary Microsoft 365 MFA based on push, TOTP, or SMS did not stop Payroll Pirates because those factors are designed to be completed by a human and can be completed on a proxied login page. The reverse proxy captures a fully approved authentication and obtains a normal cloud session. Only authentication that binds the ceremony to the legitimate origin and a device-held private key refuses that remote proxy completion path.
How is this Payroll Pirates wave connected to Storm-2755?
According to Arctic Wolf Labs, this campaign shares significant technical and behavioral overlap with the Payroll Pirates activity cluster Microsoft tracks as Storm-2755, and with related activity documented by Security Risk Advisors earlier in the year. That is an overlap statement from the researchers, not a court attribution with separate public victim tallies for every related writeup.
Updates
2026-08-18: Related disclosure
Microsoft Incident Response (DART) documented this activity family earlier as Storm-2755: financially motivated "payroll pirate" attacks against Canadian employees, using adversary-in-the-middle session theft and then diverting salary payments.
