← Back to the cybersecurity blog

Payroll Pirates: the Microsoft 365 intrusion that ends on payday

By Thilina Manana · COO, Director Técnico de Seguridad hard2bit y socio fundador · Published: 14 August 2026 · Updated: 14 August 2026
Payroll Pirates: the Microsoft 365 intrusion that ends on payday
AI-generated video
Playing loads the video from YouTube.

In July 2026 Arctic Wolf counted hundreds of organisations receiving the same fake voicemail notification aimed at their Microsoft 365 accounts. The payoff sat several steps downstream: change the bank account an employee is paid into, and collect their next salary.

The activity cluster goes by the name Payroll Pirates. Microsoft attributes much of it to a group it tracks as Storm-2755, alongside a related cluster, Storm-2657, documented against US universities in 2025. Confirmed intrusions this summer span healthcare, education, manufacturing, the public sector and professional services across the United States, Canada and Europe, according to Arctic Wolf.

One fact runs through the whole case: everything happens in the identity cloud, without touching a single device. The stolen sessions appear in the logs as authenticated with MFA, and for most of the intrusion there is no malware for an EDR to flag. This analysis reconstructs the campaign from the public research available and sets out the signals it leaves in Entra ID and Microsoft Graph telemetry.

The way in: a voicemail that never existed

The email mimics an automated missed-call notification, complete with a Microsoft logo and fabricated caller, date, duration and reference details. A button invites the recipient to open the organisation's "voicemail portal". Arctic Wolf notes the subject line follows a recognisable format: [Organisation] :ATTN: Review messages. Ref id: [string].

The link does not go straight to the fake page. The chain runs through redirects on legitimate services: Google's outbound-link infrastructure, a Campaign Manager click tracker and an HTML object hosted in an Amazon S3 bucket. Every hop shows a clean reputation to email filters, and the final phishing domain is typically under ten days old, on subdomains such as mslogin, msonline or msauth.

Before the fake sign-in appears, a fingerprinting script inspects the browser to weed out sandboxes and researchers, and stores a cookie named rcfh_country holding the victim's country for seven days. Arctic Wolf suggests that value may later be used to pick residential proxies matching the victim's location, while acknowledging it could not observe the server-side logic that consumes the cookie.

One attribution caveat matters here: Arctic Wolf found closely similar delivery URLs in public sandbox submissions that ultimately served other AiTM kits, including EvilTokens. Delivery infrastructure may be shared or reused between groups, and that alone does not establish a common operator.

Why having MFA switched on is not enough

The final page is not a static imitation: it is an adversary-in-the-middle (AiTM) proxy that relays Microsoft's genuine authentication flow in real time. The victim types their real password, approves their real MFA prompt and lands in their real mailbox. What they do not see is that the session cookie and OAuth tokens also end up in the attacker's hands. Any second factor that is not phishing-resistant, such as push approval or an SMS code, is defeated by this scheme.

The proxy leaves a telling trace: it sometimes starts the OAuth flow without the nonce parameter that binds an identity token to a specific session, producing failed authentications with error code 90014 against the OfficeHome application. Arctic Wolf describes the error as exceedingly rare in its global telemetry and strongly associated with this campaign, while cautioning that it was not present in every confirmed intrusion.

Once the capture is complete, automation takes over: non-interactive sign-ins refresh each stolen session roughly every eight hours from rotating residential proxies. The SessionID stays constant while the IP address, carrier and even country change, and the client claims to be Microsoft Outlook while presenting Firefox 131.0, Firefox 151.0 or Python Requests user agents.

Inside the tenant: hunting whoever runs payroll

With a Microsoft Graph token in hand, reconnaissance starts with a bulk directory pull (/v1.0/users with $top=999) and continues with chained searches across names, job titles and addresses for keywords such as payroll, hr, finance, account and admin, paginated with $skiptoken. Security Risk Advisors reconstructed nearly identical queries across several client environments during incident response work. Arctic Wolf adds that in Defender XDR environments these requests triggered the "Suspicious Exchange Online Graph Reconnaissance Activity" alert, usually under the axios/1.18.1 user agent, a version released in June 2026.

The tokens SRA observed carried broad delegated permissions: Directory.Read.All, Files.ReadWrite.All, Group.ReadWrite.All, Chat.ReadWrite and User.ReadWrite. That is ample room to read the compromised account's directory, files and conversations, and it leaves open a persistence route through consented OAuth applications, which survives a password reset and MFA re-registration.

Nor is the mailbox harvesting done by hand. Arctic Wolf observed MailItemsAccessed events from different tenants clustering into windows of seconds: 18 events across three organisations in 26 seconds, 11 across two in 43. The pattern points to a single central infrastructure harvesting finance and banking email from multiple victims at once.

The endgame is known from the cases Microsoft documented: persuading HR staff through social engineering to change an employee's salary bank details, or making the change directly as the victim in an HR platform such as Workday.

Three research teams, one playbook

Storm-2657: US universities (October 2025)

The persistence trick was the distinctive finding here: attacker-controlled MFA devices enrolled on the victim's account, with plain phishing for initial access, as Microsoft documented. It is the same family of authenticator-enrolment abuse we analysed in the passkey enrolment hijack in Microsoft 365.

Storm-2755: Canada and SEO poisoning (April 2026)

Search results, not inboxes, delivered the victims that time: Microsoft described SEO poisoning and malvertising that pushed a fraudulent domain to the top of search results for generic terms such as "Office 365". Victims walked into an AiTM proxy on their own, and it captured the full session. The entry vector rotates; the playbook does not.

Security Risk Advisors: the same choreography across clients (June 2026)

What SRA's incident responders kept finding was the same choreography, client after client: account takeovers with a recognisable sequence of error codes, Graph tokens replayed from unmanaged, device-less sessions and, in accounts not yet remediated, non-interactive Exchange Online sign-ins recurring roughly every three hours. SRA makes no independent attribution; it points to the overlap with what Microsoft tracks as Storm-2755 and Storm-2657.

Arctic Wolf: the campaign is still running (August 2026)

The August report confirms the operation remains live: hundreds of organisations targeted by email in July alone, intrusions across several sectors and regions, and a residential proxy network, with the provider anyIP the most recurrent, dressing every sign-in up as ordinary consumer traffic. The Hacker News coverage records the sector and geographic reach of the campaign.

Why the usual controls miss it

The entire intrusion lives in valid web sessions and legitimate calls to Microsoft APIs, which leaves the endpoint out of the picture. The classic tell-tales of business email compromise take their time as well: unlike traditional BEC operators, this crew avoids creating inbox rules early on, and when rules do appear it is late, from interactive sessions at hosting providers, with the fraud already in motion.

And the reconnaissance stage is simply invisible to most organisations: Microsoft Graph activity logs are not enabled by default, so the directory searches for payroll staff are recorded nowhere unless someone switched the logs on beforehand. SRA puts it plainly: without those logs, this stage cannot be seen.

Behavioural detection: signals that outlive domain rotation

Phishing domains expire within days; these behavioural signals last months. All of them surfaced consistently across the telemetry published by the three teams:

  • Failed authentications with error code 90014 against OfficeHome from mobile carrier IP space: the fingerprint of the AiTM proxy's missing nonce.
  • Implausible browser and operating system combinations, such as Mobile Safari or Chrome Mobile reported on Windows 10.
  • Non-interactive sign-ins on a regular cadence of roughly eight hours, with a constant SessionID while IP, carrier and country change.
  • Requests to /v1.0/users combining $search with payroll and finance keywords, $top=999 and $skiptoken pagination.
  • Bursts of MailItemsAccessed events synchronised within seconds across accounts or tenants, incompatible with a human reading email.
  • New inbox rules that hide or delete messages containing terms such as direct deposit, bank or payroll.

None of these signals depends on fresh indicators of compromise: they are patterns of behaviour. A managed SOC with access to Entra ID sign-in logs, Exchange Online auditing and Graph activity logs can turn them into durable detections; without that telemetry centralised in a SIEM, most of the campaign runs below the alerting threshold.

The same signals work in reverse: a retrospective sweep of recent months of logs, in the style of a threat hunting exercise, can surface stolen sessions that are still being refreshed without a single alert attached to them.

Defence and governance: treat payroll as a critical process

The measure that cuts the vector at the root is phishing-resistant MFA (FIDO2, passkeys) enforced through authentication strength policies in Conditional Access. Enabling passkeys without enforcing them is not enough: the attacker can downgrade the victim to the weaker method during the phishing flow itself.

On the session side: continuous access evaluation, sign-in frequency limits and compliant-device requirements all shorten the useful life of a stolen token. And remediation has to be complete: revoke sessions and refresh tokens, re-register MFA methods, remove malicious inbox rules and audit OAuth application consents granted during the compromise window. The steps match those we set out when analysing Microsoft 365 account takeover through AiTM.

Enabling Microsoft Graph activity logs and shipping them to the SIEM covers the stage almost nobody sees today: directory reconnaissance. The logs have improved considerably since their early versions and now capture the full URI of every call, which is exactly where this actor's tradecraft lives.

One control has nothing to do with technology: the HR platform itself. It should alert on every payment account change, every new MFA device enrolment and any unusual access, and no change to salary bank details should go through without out-of-band confirmation with the real employee. At Hard2bit our view is simple: the process that moves salaries deserves the same controls as an international transfer.

For corporate email and identity, the starting point is reviewing the tenant's actual configuration: Conditional Access, authentication methods, which logs are enabled and which applications hold consent. That is the scope of a Microsoft 365 security audit.

What this case lays bare

Business email compromise no longer needs the email for much more than the key to the door. The target is identity and, behind it, the payment processes that hang off a web session. The voice cloning behind deepfake CEO fraud aims at the same spot by a different route: money in transit between a company and its people.

At Hard2bit we work to make that account change, at the very least, a conversation between two people. The open question no source resolves is how much money has already been diverted: neither Microsoft nor Arctic Wolf nor SRA publishes figures, and we will not guess at one here. What is harder to dispute is where the incentives point: as long as an employee's payment account can be changed with a stolen session and no further verification, someone will keep funding proxy infrastructure with other people's wages.

This article describes detection signals and defensive measures in general terms, based on public research by Microsoft, Arctic Wolf and Security Risk Advisors available in August 2026. Validate any detection or configuration change in a controlled environment and adapt it to your organisation before rolling it out to production.

Frequently asked questions

What is the Payroll Pirates campaign?

A set of fraud operations against Microsoft 365 accounts whose ultimate goal is diverting salaries: the attacker steals an authenticated session through AiTM phishing, locates payroll and HR staff via Microsoft Graph and seeks to change employees' salary bank details, either through social engineering or directly in the HR platform. Microsoft attributes part of the activity to the Storm-2755 and Storm-2657 clusters, and Arctic Wolf documented an active campaign in August 2026 with hundreds of organisations targeted in July.

Why does MFA not stop this attack?

Because what the attacker takes is the already-authenticated session, not the password. The AiTM proxy relays Microsoft's genuine flow in real time, the victim completes their MFA as normal, and the session cookies and OAuth tokens end up with the attacker. Only phishing-resistant methods, such as FIDO2 or passkeys enforced through authentication strength policies, cut off this vector.

Who is behind it: Storm-2755 or Storm-2657?

Microsoft tracks both clusters as "payroll pirate" operations: Storm-2657 against US universities in 2025 and Storm-2755 against employees in Canada in 2026. Security Risk Advisors observed the same choreography across several clients but makes no attribution of its own, and Arctic Wolf links the 2026 campaign to this same ecosystem. As with any attribution, the boundaries between clusters may evolve.

Which signals expose the intrusion in Entra ID logs?

The most consistent ones: failed authentications with error code 90014 against OfficeHome, implausible browser and operating system combinations, non-interactive sign-ins recurring every eight hours with the same SessionID from changing IPs and countries, and anomalous user agents (Firefox 131.0 or 151.0, Python Requests, axios) on sessions claiming to be Microsoft Outlook.

What are Microsoft Graph activity logs and why enable them?

They are the telemetry that records every call to the Graph API, including the full request URI. They are not enabled by default, and without them the reconnaissance stage of this campaign, the directory search for payroll staff, is invisible. Without them, that stage is recorded nowhere; enabling them and shipping them to the SIEM is what makes it visible and allows retrospective hunting.

How do you protect salary bank account changes?

With process controls on top of the technical ones. The HR platform needs to raise an alert whenever someone modifies a payment account, registers a new MFA device or signs in from unusual locations, and every change to salary details should require confirmation over a second channel with the affected employee before it takes effect. The payroll workflow deserves to be treated as a critical business process.

What does remediation of an AiTM-compromised account involve?

Revoking all sessions and refresh tokens from the Entra admin centre, resetting credentials, re-registering MFA methods, removing malicious inbox rules, reverting payroll or banking changes and auditing OAuth application consents granted during the compromise window: a consented application survives both a password reset and token revocation.

Does this attack leave any trace on the EDR?

Practically none. There is no executable or malicious attachment: the intrusion runs through valid web sessions and legitimate calls to Microsoft APIs. Detection depends on identity telemetry (Entra ID), Exchange Online auditing (MailItemsAccessed events, inbox rules) and Microsoft Graph activity logs, not on the endpoint.

Want to know what's actually exposed, and what to fix first?

Thirty minutes with a technical consultant — not a salesperson — is enough to get the problem in order: what's exposed right now, what gets fixed this week, what can wait, and what each stage costs. Penetration testing, security audits, vulnerability management, Microsoft 365, SOC/MDR and incident response.

If your situation is different, tell us anyway — we also take one-off questions on cybersecurity and regulatory compliance.

Based in Spain · Working across the EU and LATAM · ENS High · ISO 27001 · We usually reply in under 24 business hours