The campaign, described by Arctic Wolf as having targeted hundreds of organizations during July 2026, uses adversary-in-the-middle phishing: a victim follows a bogus Microsoft-branded voicemail notification, completes a real Microsoft sign-in through an attacker-controlled proxy, and hands the attacker the authenticated browser session along with the password. TechNadu separately reported the same Arctic Wolf findings, including the use of redirectors involving Google services and Amazon S3 infrastructure before victims reach the credential-relay page.
Arctic Wolf links the activity by technical overlap to “Payroll Pirates,” the broader direct-deposit fraud problem Microsoft has tied to financially motivated groups. But that is not the same as a settled attribution. Microsoft’s April 2026 report specifically identifies Storm-2755 as a payroll-pirate actor targeting Canadian users through search poisoning and malvertising, while Microsoft’s threat-actor naming material separately associates the “Payroll Pirates” alias with Storm-2657. The overlap is useful for defenders because the objective and methods resemble one another; it should not be read as proof that every campaign using a stolen Microsoft 365 session belongs to the same crew.
The attacker wants the mailbox before the paycheck
The central feature in Arctic Wolf’s reporting is restraint. The intruders reportedly do not begin with a blast of fraudulent messages, tenant-wide changes, ransomware, or bulk data theft. They use the stolen Microsoft 365 identity as an observation post, searching for the people and threads that govern payroll, banking, invoices, benefits, and finance approvals.
That approach changes the expected incident timeline. A conventional business-email-compromise case may announce itself through a suspicious supplier invoice or an external forwarding rule. A payroll-focused intruder can instead wait until it understands a company’s language, knows who processes changes, sees when the next payroll run occurs, and can impersonate an employee with a request that fits existing internal practice.
Microsoft’s own Storm-2755 investigation documented the same end goal: compromise a user’s Microsoft 365 account, locate payroll and HR processes, and divert salary payments to attacker-controlled accounts. Microsoft observed searches for terms including “payroll,” “HR,” “finance,” “account,” and “admin,” followed by direct-deposit requests sent from the employee’s genuine mailbox. In at least one Microsoft case, the actor went as far as signing in to Workday as the victim and changing banking details directly.
The important operational conclusion is that payroll fraud is no longer exclusively an HR-system security issue. The first successful compromise may be an ordinary Exchange Online mailbox, and the first evidence may be in Entra sign-in telemetry rather than in the payroll application’s audit trail.
A real Microsoft login can still be a phishing page
The misleading phrase in many user-awareness programs is “fake login page.” In an AiTM attack, the experience is more dangerous precisely because the victim is interacting with the genuine Microsoft authentication service through an intervening proxy.
The fraudulent voicemail message leads to a page operated by the attacker. That page relays the authentication conversation to Microsoft in real time. The employee enters a password, satisfies a push prompt or one-time code, and sees behavior that appears normal because Microsoft is, in fact, completing the authentication. The proxy records the credential material and, more importantly, captures the session cookies or tokens that Microsoft issues after sign-in.
At that point, changing the password alone may not immediately remove the intruder. The attacker is not simply retrying a known password; they may be replaying a previously authenticated session. Microsoft’s token-theft guidance explicitly tells responders to investigate anomalous tokens, unfamiliar sign-in properties, non-interactive sign-ins, suspicious URLs, unexpected device or location changes, and modified mailbox rules.
This is why “MFA enabled” is an inadequate closure note for an incident ticket. Push approvals, SMS codes, and time-based codes improve security against password-only phishing, but they do not inherently prove that the person or site receiving the authentication exchange is legitimate. The authentication was approved; the session was stolen afterward.
Arctic Wolf’s report says the campaign first fingerprints a visitor’s browser and country, then stores that information for later use. Its reported follow-up activity uses residential proxy infrastructure that can make an attacker’s subsequent access resemble a normal home or local connection. This weakens a common detection instinct: treating a familiar country, consumer ISP, or city-level location as affirmative evidence that the account owner is present.
Location is still useful evidence, but it must be weighed against the whole session: client application, user agent, sign-in type, authentication sequence, IP reputation, device state, and the user’s normal behavior.
Microsoft’s April report supplies the response pattern
Microsoft’s Storm-2755 report offers a useful comparison because it documents an earlier payroll-pirate campaign with a closely related account-takeover sequence. Microsoft saw sign-in interruption error 50199 immediately before a successful attacker-controlled session, followed by a change in user agent to Axios while the session identifier remained the same. That combination is consistent with a session being relayed and replayed rather than a separate, normal user sign-in.
Microsoft also observed non-interactive OfficeHome sign-ins at approximately 30-minute intervals in that campaign, continuing until defenders revoked active session tokens. Arctic Wolf reports a different maintenance rhythm—roughly every eight hours—but the defensive lesson is identical: persistence may appear as recurring non-interactive activity rather than a series of visible browser logins.
The precise indicators differ by toolkit. An environment should not hard-code one Axios version, one application ID, or one interval and call the job complete. The useful analytic is behavioral:
- A user signs in normally, then an unexpected client or automation library appears in the same session context.
- The account begins non-interactive access from unfamiliar or rotating residential IP addresses.
- Mailbox activity concentrates on finance, payroll, invoices, bank details, or benefits without a matching business explanation.
- Inbox rules move, delete, or suppress replies relating to direct deposit, banking, or payroll administration.
- An employee’s payroll record changes after an unusual Microsoft 365 session or unusual correspondence with HR.
Microsoft’s token-theft playbook also emphasizes that responders should treat unconfirmed anomalous activity as a breach until it can be validated. That is a sound posture here. In a campaign designed to remain quiet, waiting for a fraudulent transfer is waiting too long.
Phishing-resistant sign-in needs to move beyond a pilot
Microsoft says phishing-resistant authentication methods such as FIDO2/WebAuthn are designed to mitigate AiTM phishing because the authentication is bound to the legitimate site. Windows Hello for Business, FIDO2 security keys, and passkeys supported through Microsoft Entra provide a substantially stronger answer than a password plus an approval prompt or code.
For Windows estates, Windows Hello for Business deserves particular attention. It can provide a local, phishing-resistant credential tied to the user’s device, while administrators can retain a portable backup such as a FIDO2 key or approved passkey for recovery and cross-device use. Microsoft’s current Entra deployment guidance recommends that users have at least two authentication methods registered and identifies FIDO2 keys, synced passkeys, Microsoft Authenticator passkeys, and Windows Hello for Business as phishing-resistant options for different user populations.
Deployment, however, is not the same as enforcement. A tenant can have Windows Hello for Business broadly available while allowing the same users to fall back to passwords and weaker MFA methods for cloud access. Administrators should identify payroll, HR, finance, executive support, and help-desk personnel first, then use Conditional Access and authentication-strength policies to require phishing-resistant methods for the Microsoft 365 resources and administrative workflows that matter.
Microsoft also recommends considering Conditional Access token protection, which binds tokens to the device hardware where they were issued. It is not a substitute for phishing-resistant authentication or endpoint hygiene, but it addresses the next problem attackers will pursue when passwords and conventional MFA are less useful: extracting or replaying already-issued tokens.
Treat payroll verification as an out-of-band control
Technical controls reduce the chance of takeover; payroll controls limit the damage when an account is compromised. A request to redirect salary, update bank details, alter a vendor payment destination, or change a payroll portal profile should require verification through a communication channel that is independent of the requester’s Microsoft 365 mailbox.
A phone call to a known number, an in-person confirmation, or a workflow requiring a second authorized approver is far more reliable than replying to the email that made the request. An attacker with the employee’s authenticated Outlook session can read the reply, delete it, and continue the conversation as the employee.
The immediate task for Microsoft 365 security teams is to make token theft a first-class incident type. Revoke sessions, reset credentials, remove malicious authentication methods, inspect mailbox rules, review Entra sign-in and audit activity, and check payroll and HR systems for changes made after the suspected compromise. The successful attacker in this campaign does not need to break Microsoft 365 loudly; they need one employee to approve a believable sign-in and one payroll team to trust an email that came from the right mailbox.
