Arctic Wolf researchers are tracking a widespread, email-driven phishing campaign that shares clear tactical overlap with Storm-2755, the cluster Microsoft first named “Payroll Pirate” in April after it drained direct-deposit paychecks from Canadian employees. The new activity has spread across the United States, Canada, and Europe, hitting healthcare, education, manufacturing, government, and professional services organizations. What makes this wave worth a second look is not that it steals credentials. It is what the phishing link does on its way to stealing them, and how long the resulting access survives once it succeeds.
A Voicemail That Routes Through Four Trusted Domains
The lure email looks like an automated voicemail notification, a format familiar enough to get clicked without much scrutiny. The link behind it does not go straight to a fake login page. It routes through Google Meet’s own link-redirect service, then Google’s outbound-link infrastructure, then a Google Campaign Manager dynamic click tracker, before finally landing on an HTML file hosted in an Amazon S3 bucket, which is where the adversary-in-the-middle proxy actually lives. Every hop in that chain sits on a domain security tooling has learned to trust: google.com, googleadservices.com, amazonaws.com. Reputation-based URL filtering, the kind that flags a link the moment it points somewhere unfamiliar, has nothing to flag until the very last redirect, and by then the victim is already looking at a convincing Microsoft 365 sign-in page.
Once a victim signs in, the AiTM proxy captures the session cookie and OAuth access token issued after authentication succeeds, the same mechanism Microsoft documented in the original Storm-2755 cases. Non-phishing-resistant MFA does not stop this. The victim completes their multi-factor challenge for real, against the real identity provider, and the proxy simply copies the resulting session rather than trying to guess a code.
A Session That Moves Faster Than Your Alerting Does
The detail that separates this from a routine credential-phishing writeup is what happens after access is established. Arctic Wolf found that, typically eleven to twenty-four hours after the initial compromise, automated activity refreshes each hijacked session at roughly eight-hour intervals, and the SessionID stays constant across every refresh even as the source IP address, the ASN, and the geographic location all change. The operators are also routing sign-ins through residential proxies, so the traffic pattern that shows up in your logs looks like an ordinary consumer internet connection rather than a spike from unfamiliar hosting infrastructure. A security team watching for the textbook signal of account takeover, a login from a new country on a new ASN, will see exactly that signal fire repeatedly, attached to a session that was never forced to reauthenticate.
From inside that session, the actor uses Microsoft Graph to enumerate which employees handle payroll, HR, finance, and administration, then reads mail specifically about invoices, banking details, and benefits. That reconnaissance feeds the same endgame Microsoft documented in the April cases: inbox rules that hide the words “direct deposit” and “bank” from the real employee, a spoofed request to change banking details, and a paycheck that lands in an account the victim never chose.
Why None of This Touches What DMARC Checks
DMARC, SPF, and DKIM answer exactly one question, whether the domain in a message’s From header is authorized to send that message. That question is fully answered and fully passed the moment the lure email lands, because nothing about the voicemail notification needs a forged domain to work. The redirect chain that follows is a web-reputation problem, not an authentication problem, since Google Meet and Amazon S3 are legitimate services being used exactly as designed by anyone who has an account, which the attacker does. And the session hijacking that comes after the click sits a full layer above anything DMARC evaluates. DMARC checks the envelope a message arrives in. It has no mechanism for revoking a session token, no visibility into whether a SessionID that has now touched six different ASNs in three countries over two days is still the same trusted user who typed the password.
This is not a criticism of DMARC. It is a description of the boundary DMARC was built to sit at, and this campaign is engineered specifically to operate past that boundary from the first click onward.
What This Means for Your Program
Push toward phishing-resistant MFA where your identity provider supports it. Passkeys and FIDO2 hardware keys are bound to the origin they were registered against, which defeats a proxy sitting between the victim and the real sign-in page in a way that a one-time code never can.
Monitor for SessionID continuity across IP and ASN changes, not just for logins from new locations. The signal this campaign is exploiting is one where your alerting fires correctly but your response treats each alert as a fresh, unrelated event instead of recognizing a single session that has been quietly persisting for days.
Audit inbox rules that hide keywords like “bank,” “payroll,” or “direct deposit” as a standing detection, not a post-incident forensic step. That rule is the mechanism the entire financial-harm stage of this campaign depends on, and it is visible before any money moves if anyone is looking.
Keep DMARC enforced at reject regardless. It still closes the door on anyone trying to spoof your domain outright, and that is a door worth keeping shut even while this particular campaign walks in through a different one entirely.
The Takeaway
A domain can run DMARC at full enforcement, with clean aggregate reports and every legitimate sender aligned, and still watch an employee’s payroll get redirected by an attacker who never once needed to forge that domain. The Payroll Pirate campaign succeeds by laundering its phishing link through infrastructure your filters already trust and by keeping the resulting session alive long after the login that created it. Closing that gap takes session-aware monitoring and phishing-resistant authentication sitting next to DMARC, not a stronger version of DMARC itself.
Excello Mail gives you continuous visibility into your DMARC enforcement and every source authorized to send under your domain, so you always know what your own authentication is actually protecting, and where its edges are. Sign up for free to Excello Mail and see exactly who is sending as you, all the time.