They read your email for weeks and changed nothing. That was the plan.
Arctic Wolf Labs spent July 2026 watching an operation take Microsoft 365 accounts at hundreds of organisations and then behave, deliberately, like nothing had happened. No password change, no new inbox rule, no forwarded mail. Just quiet reading, until somebody's salary went to a different bank account.
The Brief
A voicemail notification email leads to a page that proxies the real Microsoft sign-in. You type your password, you approve the multi-factor prompt, and both are relayed to Microsoft while the attacker keeps the resulting session. From there they query the Microsoft Graph API for colleagues whose job titles contain payroll, hr, finance or human resources, read the mail about payments and banking, and eventually change a direct deposit record in a system like Workday or ADP. The part worth internalising is what they do not do: Arctic Wolf found no MFA changes, no device registrations, no password resets, no inbox rules in most compromised accounts, because those are precisely the events that raise an alert. If you only remember one thing, make it this: approving the prompt does not keep them out, and nothing about your account will look wrong afterwards. The one checkable moment is the link itself, so catch the page before you sign in, not after.
Add to Chrome, free
Get the free Android app
or scan a URL now →
Who is doing this, and how big is it
Arctic Wolf Labs published the research on 6 August 2026, under the title Payroll Pirates. In July 2026 alone they observed hundreds of organisations targeted by email, with successful intrusions across a broad range of environments: healthcare, education, manufacturing, government and professional services, in the United States, Canada and Europe.
Microsoft tracks an overlapping cluster as Storm-2755. The shared objective in that cluster is blunt: hijack an employee's account in order to reroute their salary to an account the attacker controls. Parts of this activity have been documented since early 2025, so this is a maturing operation rather than a novelty.
The lure is a voicemail, and the page is a mirror
The opening email says you have a voicemail. It is a good choice of pretext because it is mundane, it is plausible in almost any organisation, and it carries no threat, so it does not trigger the suspicion an urgent warning would.
The link opens an adversary-in-the-middle page. That is not a copied login screen, it is a relay: the page passes your keystrokes to the genuine Microsoft authentication flow and passes Microsoft's responses back to you. Everything behaves correctly because everything is real, including the multi-factor prompt on your phone. You approve it, Microsoft issues a session, and the relay keeps a copy.
This is why the usual advice stops working here. The mechanics of that relay, and the one form of authentication it cannot defeat, are covered in how AiTM attacks steal your 2FA. Two other named kits doing the same job on Microsoft 365 are Kali365, which the FBI issued an advisory about, and Bluekit, which streams a real login page instead of proxying it.
The first thing they do is search for the word "payroll"
What makes this campaign worth its own write-up is not the entry, it is the next step.
Rather than rifling through the mailbox they landed in, the operators query the Microsoft Graph API, the interface applications use to read tenant data, looking for user accounts whose attributes contain terms such as payroll, hr, finance and human resources. Arctic Wolf recorded the queries hitting the standard users endpoint.
Then they read: messages about payroll, invoices, payments, banking, benefits and internal documents.
Read that as an org chart being built from the inside. The compromised mailbox may belong to nobody important. Its value is the directory it can see and the finance conversations it can reach, which together answer the only question that matters to the attacker: who can change a payment, and what does a normal request to change one look like here.
The restraint is the tradecraft
This is the finding worth carrying into any other investigation, and it inverts what most people expect a hacked account to look like.
In most affected accounts Arctic Wolf observed none of the following: multi-factor method changes, device registrations, credential modification, lateral phishing, or evasive inbox rules. Their conclusion is stated plainly, that by avoiding these common business email compromise behaviours the actors limited opportunities for early detection based on account modification or outbound email abuse.
Every item on that list is an event a security team alerts on, or that a user eventually notices. A new inbox rule quietly filing replies away. Colleagues asking why you sent a strange link. A password that stopped working. Skip all of it and the account looks completely normal for as long as the operation needs.
So the instinct that your account is fine because nothing seems different is not just unreliable here. It is the specific outcome that was engineered.
The eight-hour heartbeat
The operators cannot avoid leaving every trace, and the one they do leave comes from their own automation.
Sessions are kept alive by tooling that refreshes them at roughly eight-hour intervals, routed through residential proxies so the sign-ins look like ordinary consumer traffic rather than a datacentre. Arctic Wolf notes the giveaway in the logs: the same session persisting while the source address, network operator and country all change underneath it, which is what centralised automation refreshing many sessions independently looks like from the inside.
Other reported oddities in the sign-in records are of the same kind: a mobile browser version reported on desktop Windows, or a session claiming Microsoft Outlook as its client application while carrying a Firefox or Python scripting user agent.
None of that is visible to the person whose account it is. It is a tenant-log signal, which is worth being honest about, and it is the reason this campaign is usually found by a security team rather than by the employee.
Where the money actually leaves
Not from the mailbox. Arctic Wolf's own remediation guidance points at the place that matters: audit payroll and HR platform activity, naming Workday and ADP, across the full suspected period, and it flags that direct deposit changes are of particular interest to this actor.
So the shape of the whole thing is: email access is reconnaissance, and the payout is a bank account field edited in a payroll system, timed so the next salary run does the work. The victim often finds out on payday.
That is the same destination as the older executive-impersonation fraud in the whaling and wire transfer scam, reached by a quieter road. There is no urgent message from a fake CEO here, and nobody is asked to approve anything unusual.
What an employee can actually notice
Most of the detection in this campaign is not available to you, so here is only the part that is.
- A voicemail notification that arrives by email and wants a sign-in. Check how your organisation genuinely delivers voicemail. For most, it is not a link to a Microsoft login.
- An MFA prompt you did not personally start. Approving one is how a session gets issued. If a prompt appears while you were not signing in, decline it and report it, and do not assume it was a glitch.
- A sign-in page reached from a message. This is the only moment in the whole chain where the attack is a URL you can examine, and it is the moment before anything is lost.
- Any request about payment details that arrived by email, even a normal-sounding one, even internally. Confirm it on a channel you started yourself.
- Your own payroll record. If your platform lets you view your direct deposit details, look at them occasionally. It costs nothing and it is the field this entire operation exists to change.
If you signed in on one of those pages
- Tell IT or security now, and say it was a sign-in page. That framing matters, because it tells them to look for a live session rather than a stolen password.
- Ask for active sessions to be revoked. Changing your password does not end a session that already exists. Revocation does. Arctic Wolf lists this first for the same reason.
- Rotate the credential and re-register MFA after the revoke, in that order.
- Ask for the payroll platform to be checked, Workday or ADP or whatever is in use, for any direct deposit change across the whole period, not just today.
- Ask them to hunt the eight-hour pattern on other accounts. This campaign targeted hundreds of organisations, so one confirmed session is a reason to look wider, and there is more general guidance in what to do after a scam.
Catch the relay page, because it is the only checkable moment
Being precise about scope matters more than usual on this one, because most of this campaign happens somewhere a browser extension cannot see.
We do not read your mailbox, we cannot see Graph API queries against your tenant, and we cannot tell you whether a direct deposit record changed. Those are tenant-side questions and they belong to your security team and your payroll platform. Anyone claiming a browser tool solves business email compromise is describing something else.
What is checkable is the single link in the voicemail email, which happens to be the one point in the chain where nothing has been lost yet. Layer 1 reads the shape of the URL locally before the page renders. Layer 2 checks the destination server-side against reputation sources, our blocklist, and a brand database of more than 550 names, which is the layer that treats a Microsoft sign-in living on a domain that is not Microsoft as impersonation rather than a match. Layer 3 is the AI deep scan, a Premium feature with one free scan a day for everyone else, which reads what the page actually serves rather than the logo it is wearing.
The honest division: your security team owns everything after the sign-in, and the sign-in page itself is the part that can be judged before you type.
Get the free Android app
Is that Microsoft sign-in page really Microsoft?
Paste the address here before you enter a password. Our 3-layer engine (Local + APIs + AI) returns a verdict in about 3 seconds. Free, no signup.
Frequently asked questions
How does a payroll diversion scam actually start?
With a voicemail notification email, in the campaign Arctic Wolf Labs documented on 6 August 2026. The link opens a page that proxies the real Microsoft sign-in, so what you see is the genuine flow and what you type passes through to Microsoft while a copy is kept. Because the page relays your multi-factor prompt too, approving it does not stop the attack. What the attacker ends up holding is not your password but a live session, which is why nothing about your account appears to change afterwards.
If they are in the mailbox, why did nothing look wrong?
Because looking wrong is the part they deliberately skipped. Arctic Wolf reported that in most affected accounts there were no multi-factor changes, no new device registrations, no password changes, no inbox rules and no phishing sent onward. Those are exactly the events that trigger a security alert or that a user would notice. By doing none of them, the operation stays quiet while it reads mail. The restraint is not politeness, it is the tradecraft.
What are they searching for once they are inside?
Colleagues, by job function. Arctic Wolf saw the Microsoft Graph API queried for user accounts whose attributes contain terms like payroll, hr, finance and human resources, and then messages about payroll, invoices, payments, banking, benefits and internal documents being read. The mailbox is not the target so much as the directory it can reach. The goal is to learn who moves money and how a change to a payment is normally requested.
Where does the money actually leave?
Usually not from the mailbox at all. Arctic Wolf's remediation guidance tells organisations to audit payroll and HR platform activity such as Workday and ADP for the whole suspected period, and notes that direct deposit changes are of particular interest to this actor. The email access is reconnaissance; the payout is a bank detail changed in the payroll system so that the next salary run pays the attacker.
I clicked a voicemail link and signed in. What do I do?
Treat it as a live session, not a stolen password, because changing your password alone does not end a session that already exists. Tell your IT or security team immediately and ask them to revoke active sessions for your account, rotate the credential and re-register MFA. Then ask them to check the payroll platform for any direct deposit change, and to look for sign-ins refreshing on a roughly eight-hour cycle. Speed matters more here than certainty.