Payroll pirates: an eight-year-old fraud that MFA did not stop

On payday, the money goes somewhere else.

That is the entire objective. No ransomware note, no data leak site, no encryption. Someone signs into a payroll portal as you, changes the bank account on your profile, and waits for the next payment run. The first person to notice is usually the employee who was not paid, and by then the money has moved.

The uncomfortable part is not that this works. It is that the FBI described this exact scheme in a public service announcement dated September 18, 2018: phish the credentials, add mail rules to suppress the alerts, change the direct deposit, cash out through a prepaid card [3]. Eight years later it is still working, and now it clears multi-factor authentication on the way through.

What happened

Microsoft has published on two clusters of this activity.

In October 2025 it described Storm-2657, which targeted US higher education. Phishing reached nearly 6,000 email addresses across 25 universities, and Microsoft observed 11 successfully compromised accounts across three institutions [2]. Activity was traced back to March 2025. In one organisation, a single compromised account was used to target 500 people [2].

In April 2026 it described Storm-2755, targeting Canadian users [1]. Microsoft characterises this one as geographically rather than sectorally targeted. The selection criterion was that the victims were in Canada, not that they worked in a particular industry [1].

Both end the same way: manual edits to an HR software-as-a-service platform, Workday in the documented cases, redirecting salary to an account the attacker controls [1][2].

Neither cluster has public attribution. “Storm-” designations are Microsoft’s temporary labels for activity it has not yet attributed to a known group.

Why this matters

For an employee, this is a direct hit on personal finances. Not a corporate data breach where the loss is abstract and the remedy is credit monitoring. An actual missing paycheque, at the end of an actual month.

For the organisation, the exposure is not one salary. Once an attacker holds a compromised session in an HR system, the reachable population is every employee profile that account can edit. Microsoft’s figure of 500 people targeted through a single organisation is the shape of the problem [2].

For leaders, the number that matters is not the individual loss but the category. The RCMP puts worldwide BEC losses above 26 billion dollars, and records that Canada’s Anti-Fraud Centre documented close to 30 million dollars in a single year, 2020 [4]. Payroll diversion is one branch of that tree, and it is a branch where the victim is your own staff.

There is also a quieter organisational cost. When someone’s salary vanishes because an attacker edited their HR profile, the employer generally makes them whole. That is right, and it means the financial loss lands on the business regardless of whose account was compromised.

Technical breakdown

The chain in the Canadian activity is worth walking through, because each step is a place to break it. Two of them are marked below. Those are the points where a control you can actually buy or write stops the sequence dead, rather than merely making it harder.

The two marked steps are where phishing-resistant MFA and out-of-band verification of banking changes each end the sequence on their own. Everything else on the chain is an attacker convenience.

Getting the credentials. Storm-2755 did not start with an email. Microsoft describes search engine optimisation poisoning and malvertising that pushed an actor-controlled domain to the top of results for generic queries, things like “Office 365” and common misspellings [1]. The victim searches for the login page they use every day and clicks a sponsored result.

Defeating MFA. The fake sign-in page relays the authentication in real time. This is adversary-in-the-middle, or AiTM: the attacker sits between the user and the real service, passes the credentials and the MFA response through, and captures the session cookie and OAuth token that come back. Microsoft’s phrasing is that this lets the actor “bypass legacy MFA protections not designed to be phishing-resistant” [1]. The MFA prompt is answered legitimately, by the real user. It just is not protecting the session any more.

A useful artefact for defenders: Microsoft observed a 50199 sign-in interrupt error immediately before successful compromise [1].

Persistence. With the token replayed, non-interactive sign-ins continued roughly every 30 minutes until the session was revoked [1]. Microsoft observed sessions being renewed around 5:00 AM in the user’s local time zone, outside the window where anyone is watching [1]. Left alone, stolen tokens stayed usable for about 30 days before going inactive [1].

The user-agent on those replayed sessions changes to axios, typically version 1.7.9, while the session ID stays the same. Microsoft names that combination as the indication that a token has been replayed [1]. Axios is an ordinary open-source HTTP client, not malware. Microsoft notes the attack path “seems to take advantage of” CVE-2025-27152, an axios server-side request forgery issue [1]; that is hedged vendor language about a possible path, not a claim of confirmed exploitation, and it should not be repeated as one.

Finding the target. The compromised session was used to search the intranet for terms like payroll, HR, human, resources, finance and admin [1]. Emails went out with the subject line “Question about direct deposit” [1].

Hiding the evidence. This is the step that makes the fraud durable. Inbox rules were created to move messages containing “direct deposit” or “bank” out of the inbox [1]. The 2025 campaign did the same thing with rules that deleted Workday notification emails outright, sometimes named with junk strings like .... to look unremarkable in a rules list [2].

That suppression step is not new tradecraft. The FBI’s 2018 alert already described criminals adding “rules preventing the employee from receiving alerts regarding direct deposit changes” [3]. The technique has not changed in eight years because it still works.

Persistence in the identity layer. In the 2025 campaign, attackers enrolled their own phone numbers as MFA devices on compromised accounts, so they could return without needing the victim to approve anything [2].

Detection ideas

Ordered by how cheap they are to implement:

• Alert on inbox rule creation that filters or deletes on terms like direct deposit, bank, payroll, or that targets your HR platform’s notification sender. Microsoft calls alerting on suspicious inbox-rule creation “essential” for triaging this class of compromise [1].
• Alert on payment election or bank account changes in your HR platform, especially in bulk or outside business hours. The FBI recommended monitoring logins outside normal hours in 2018 [3].
• Hunt for sessions where the user-agent changes to axios while the session ID is unchanged [1].
• Watch for new MFA methods registered on accounts, particularly phone numbers [2].
• Treat a 50199 sign-in interrupt followed by a successful sign-in as worth a look [1].

What defenders should do Monday morning

Immediate: today. Find out who can change bank details in your HR system and whether any confirmation email is sent when they do. Then check whether that confirmation can be filtered away by a mailbox rule. If the answer is yes, you have the same gap both campaigns exploited.

Near term: this week. Turn on alerting for inbox rule creation and for banking changes in the HR platform. Review existing inbox rules across payroll, HR and finance accounts, the ones already in place are the ones nobody is watching. If you find a compromise, revoke the tokens and sessions rather than only resetting the password; Microsoft is explicit that revoking sessions, removing the malicious rules and resetting credentials are all required [1], and a password reset alone leaves a live stolen token in play for up to about 30 days [1].

Structural: this quarter. Two things, in this order.

First, out-of-band verification for banking changes. Any change to payroll bank details gets confirmed by a phone call to a number already on record, not a number supplied in the request. The RCMP recommends verification “through another means of communication” [4] and the FBI recommended heightened review of employee-initiated banking changes in 2018 [3]. This control does not care whether the account was compromised, which is exactly why it works.

Second, phishing-resistant MFA for anyone who can touch payroll. FIDO2 security keys or passkeys are not phishable by relay in the way codes and push approvals are. Microsoft’s guidance names SMS codes, email one-time passwords and push notifications as the methods that fail here [1].

Checklist

• Known list of who can edit payroll banking details
• Confirmation emails sent on every banking change, to an address the employee cannot filter
• Alerting on inbox rule creation, especially rules mentioning bank or direct deposit
• Alerting on bulk or out-of-hours payment election changes
• Out-of-band phone verification for bank detail changes, using a number on file
• Phishing-resistant MFA for payroll, HR and finance roles
• Incident runbook says revoke sessions, not just reset the password
• Existing inbox rules on HR and finance mailboxes reviewed at least once

What eight years should have taught us

The novel parts of this attack are real. Search poisoning as the delivery mechanism is a smarter opening move than a mass phishing email. Relaying MFA in real time is a genuine advance on stealing a static password. Timing session renewals for five in the morning shows someone paying attention to when defenders are not.

But strip those away and the 2026 fraud is the 2018 fraud [1][3]. Compromise an account, silence the notifications, change the bank details, wait for payday. The delivery got better and the authentication bypass got better, and the underlying business process is exactly as exploitable as it was.

That is the part worth sitting with. Every control that got upgraded in those eight years was a technical one, and the fraud routed around all of them. The control that would actually stop it, someone picking up a phone to confirm a bank change against a number already on file, is not technical, costs nothing, and still is not in place in most organisations.

MFA was treated as the finish line. It was a hurdle, and this is what clearing it looks like.