Payroll Pirates Hijack M365 Inboxes for 8 Hour Shifts

The lure carried Microsoft branding, a caller ID, a date, a call duration and a reference number. Every one of those details was invented. What made the message land was the route, not the design work: the link travelled through a Google Meet redirect, Google's outbound link infrastructure, a Campaign Manager click tracker and an object in an Amazon S3 bucket before it ever touched attacker owned infrastructure. By the time a reputation filter saw the destination, four trusted brands had vouched for the path.

Key Takeaways

• Arctic Wolf Labs published this campaign on 6 August 2026 and matched it to the Payroll Pirates cluster Microsoft tracks as Storm-2755, which overlaps with Storm-2657.
• Hundreds of organisations across healthcare, education, manufacturing, government and professional services in the United States, Canada and Europe received the voicemail themed lures during July 2026.
• The phishing page proxied Microsoft's genuine authentication flow in real time, so the multifactor prompt completed normally and the attacker walked away with the resulting session.
• Between 11 and 24 hours after the first sign in, automated activity resumed and refreshed each hijacked session at roughly eight hour intervals from rotating residential proxy addresses.
• Microsoft Graph queries against graph.microsoft.com/v1.0/users filtered tenant users for payroll, hr, finance and human resources attributes, then pulled mail covering invoices, payments, banking and benefits.

Who Are the Payroll Pirates?

Payroll Pirates is a financially motivated cluster whose whole business model is redirecting somebody else's salary into an account they control. Microsoft documented the pattern in its October 2025 investigation into attacks on US universities, where Storm-2657 compromised 11 accounts at three institutions and sent close to 6,000 phishing emails into 25 more. No product vulnerability was involved. The weak point was multifactor authentication a proxy could relay.

The Storm prefix is worth reading literally. Microsoft's threat actor naming taxonomy assigns a Storm number to a cluster still under development, tracked until analysts reach high confidence about who is behind it. Storm-2755 has now carried that temporary label through at least three distinct delivery methods, which is the point most coverage skipped. We wrote about this same actor in April 2026, when it was poisoning search results for Office 365 login pages to catch employees who typed their portal name into a search box. The objective has not moved an inch since 2025. The front door has been rebuilt twice.

How Does the Six Stage Redirect Chain Work?

Each stage borrows the reputation of a service your security stack already trusts, so no single hop looks worth blocking. Arctic Wolf Labs traced the sequence from the link in the email body to a Google Meet redirect URL, Google's outbound link infrastructure, a Campaign Manager /ddm/clk dynamic click tracker, an HTML object in an Amazon S3 bucket, and only at the sixth hop the actor's own phishing infrastructure.

The S3 stage does something the earlier hops cannot. Before forwarding the visitor, JavaScript on that page collects browser and operating system properties, screen and window dimensions, language and timezone offset, hardware concurrency, WebDriver status, WebGL vendor and renderer, and which browser APIs are present. Results go out by HTTP POST to a PHP endpoint, and a geolocation lookup stores a country code in a cookie named rcfh_country for seven days.

None of that is needed to phish anybody. It decides who gets shown the real page. A headless browser with WebDriver enabled, no WebGL renderer and a data centre address is an automated scanner, and it gets sent somewhere harmless. Analysts detonating the link in a sandbox often see nothing, which is why the campaign ran a month before it was written up.

Why Does MFA Not Stop This?

Because nothing about the authentication was fake. The page did not render a static copy of the Microsoft login screen and harvest what you typed. It sat between your browser and Microsoft and relayed the genuine flow both ways, so your password reached the real endpoint, the real multifactor prompt appeared on your real phone, and you approved it correctly. Microsoft then issued a valid session to the browser it was talking to, which was the proxy.

Once the attacker holds that session, the second factor is already spent. It is the same structural weakness we covered in the Outlook session hijacking campaign in July, and in the Greatness kit spoofing RingCentral to reach Microsoft 365. Different actors, different lures, one shared assumption: a token issued after a successful challenge is trustworthy on any device presenting it. Push notification and one time code MFA both fall to it, a different failure mode from the password spraying that skips the MFA prompt entirely through legacy authentication, though both end with a working session.

What Did the Attackers Do Once Inside the Mailbox?

They read mail, quietly, and looked for the people who move money. Arctic Wolf observed the actor calling Microsoft Graph at graph.microsoft.com/v1.0/users with filters for attributes containing payroll, hr, finance and human resources, building a target list from the tenant's own directory. Access then moved to messages about invoices, payments, banking, benefits and internal documents.

Most intrusions went no further than session maintenance, reconnaissance and mailbox collection. In a smaller number of cases a human intervened and created inbox rules that moved certain messages into Deleted Items and marked them as read. That is the classic tell for a direct deposit change in progress: the payroll platform's confirmation notice has to vanish before the employee sees it.

The persistence pattern is the detail worth memorising. Suspicious sign ins appeared within minutes of the proxy visit, went quiet, then automated activity resumed 11 to 24 hours later and settled into refreshes at roughly eight hour intervals. Three a day, twenty one a week, each from a different residential ISP or mobile carrier address flagged by IP intelligence as proxy infrastructure, most commonly anyIP. The session identifier stayed constant while the geography moved.

Why Email Users Should Care

This is not a story about a stolen password. It is a story about somebody else reading your inbox for days while every dashboard reports a healthy, authenticated user. Nothing in your mail client changes. No alert fires. The mailbox holding your salary history, bank details, approved invoices and benefits paperwork is simply open in a second browser behind a residential proxy, and Microsoft has no reason to think that browser is not you. Related coverage on how AitM session hijacking plays out in Outlook walks through the same mechanics from the victim's side.

Gmail users should not read this as somebody else's problem. Nothing about a reverse proxy relaying a login flow is Microsoft specific, and the technique works against any identity provider issuing a bearer session token after a challenge. Google Workspace tenants are the obvious next stop, and between them the two platforms cover most business mailboxes worldwide. The lure needs one change: a different logo.

One correction to the usual advice while we are here. Hovering over a link to check where it goes would not have saved anybody in this campaign. The first hop was a genuine Google Meet URL. The visible destination was true, and it was also stage one of six. A parallel campaign went further and removed the link entirely, using SVG voicemail attachments that build the credential page inside your browser so there is no URL to inspect at all.

How Should Defenders and Individuals Respond?

Session theft breaks the assumption that a completed challenge equals a trusted user, so the fixes split in two: stop the token reaching a proxy, and catch the ones that did.

• Deploy phishing resistant MFA. FIDO2 keys and passkeys bind the credential to the origin, so a proxy on a lookalike domain cannot complete the ceremony. CISA's guidance on implementing phishing resistant MFA is the reference to hand leadership. Start with payroll, HR and finance staff.
• Turn on token protection in Conditional Access. Microsoft's token protection documentation covers binding a refresh token to the device it was issued to, making a replayed token useless elsewhere. Pair it with policies requiring a compliant or managed device for mail access.
• Hunt for implausible client fingerprints. Mobile Safari reporting Windows 10, or an Outlook client presenting a Firefox user agent where Edge is expected, are both signals Arctic Wolf called out, as is one SessionID appearing across multiple autonomous systems and countries in a day.
• Alert on new inbox rules that delete or mark as read. Rules targeting payroll or HR keywords, or silently moving mail to Deleted Items, deserve a page rather than a weekly report. It is one of the few steps here a human actually performs.
• Revoke sessions, do not just reset passwords. A password change leaves an existing refresh token working. Revoke sign in sessions, then audit Graph API activity in the unified log for enumeration against the users endpoint.
• Verify voicemail notices out of band. If your organisation does not route voicemail into email, every such message is fake by definition. If it does, open the voicemail from the phone system directly instead of following the link. The same rule covers document requests: NovaCookies rides genuine Docusign notifications into the same kind of session theft.

For compliance teams, the exposure is not only fraud loss. HR and payroll mailboxes hold bank details, national identifiers and benefits records for the whole workforce, so an intrusion of this shape is a personal data breach with notification clocks attached, whether or not a payment was ever redirected.

Sources: Arctic Wolf: Payroll Pirates, Strange New Tides in Business Email Compromise; The Hacker News: Microsoft 365 AitM Phishing Hijacks Accounts to Collect Payroll and Finance Emails; Microsoft Security Blog: Investigating targeted payroll pirate attacks affecting US universities; Microsoft Security Blog: Investigating Storm-2755, payroll pirate attacks targeting Canadian employees; Microsoft Learn: How Microsoft names threat actors; Microsoft Learn: Token protection in Conditional Access; CISA: Implementing Phishing Resistant MFA.