Arctic Wolf says an active Microsoft 365 phishing campaign is stealing authenticated sessions from users in the United States, Canada, and Europe, then quietly mapping payroll, HR, finance, and administrative mailboxes for later fraud. The immediate operational concern is not a familiar inbox-rule takeover or a burst of outbound phishing: the campaign’s most distinctive behavior is automated session reuse every eight hours, often from rotating residential proxy IP addresses, after a victim completes a legitimate-looking Microsoft sign-in flow.
The report, published August 6, describes voicemail-themed lures that send recipients through a chain of Google Meet redirect links, Google advertising infrastructure, and Amazon S3 before reaching an adversary-in-the-middle, or AiTM, proxy. That proxy relays the real Microsoft authentication process in real time. A user can complete MFA successfully and still lose the session material that gives the attacker access afterward.
Arctic Wolf links the activity to the “Payroll Pirates” cluster Microsoft tracks as Storm-2755, while stopping short of declaring a conclusive attribution. That restraint is warranted. Microsoft’s April Storm-2755 report described Canadian victims lured through SEO poisoning and malvertising, while Security Risk Advisors reported related AiTM token-replay and Microsoft Graph reconnaissance in June across several client environments. Arctic Wolf is now documenting a different delivery channel—email phishing—with wider geography and a distinctive automation pattern. The common thread is the target: people who can reveal or influence salary, banking, invoice, and benefits workflows.
This is a business email compromise operation in its reconnaissance phase. Organizations that wait for a fraudulent payroll-change request, a malicious inbox rule, or a suspicious email sent from an employee account may be waiting for the attacker’s second move.
The phishing pages documented by Arctic Wolf are not static Microsoft lookalikes that simply collect a password and one-time code. They act as a reverse proxy between the victim and Microsoft’s genuine sign-in endpoints, rewriting URLs to keep the exchange flowing through attacker-controlled infrastructure. Once Microsoft returns authorization material to the proxy-controlled callback, the operator can capture the session artifacts needed to impersonate the user.
That mechanism explains why conventional MFA is insufficient here. SMS codes, push approvals, and authenticator codes can verify a real user during the proxied session; they do not prove that the session is being established directly with the intended relying party. Microsoft’s own identity-security guidance treats AiTM and token replay as a separate problem from password theft and recommends phishing-resistant authentication for sensitive or risky sign-ins.
Arctic Wolf’s phishing infrastructure also fingerprints the victim’s browser and queries a geolocation service before forwarding the user to Microsoft. The vendor’s controlled testing suggests a country value stored in a cookie may be used to choose a residential proxy exit in the victim’s country later. Arctic Wolf did not observe the server-side selection logic, so that remains an informed assessment rather than a confirmed capability. But the observed result—subsequent activity apparently coming from residential networks in the victim’s location—is exactly what makes simple country blocking or crude “impossible travel” rules unreliable.
The delivery chain should also change how mail-security teams interpret otherwise legitimate domains in click telemetry. Google Meet redirect handling, Google ad-tracking infrastructure, and Amazon S3 were used as intermediaries, not as the final phishing host. Blocking a final destination after a user has clicked remains useful, but reputation systems that judge each hop in isolation can miss the assembled chain.
According to Arctic Wolf, malicious activity commonly begins minutes after a visit to an AiTM proxy, sometimes with several residential-proxy sign-ins in rapid succession. Eleven to 24 hours later, the compromised session begins recurring at roughly eight-hour intervals. The sign-ins identify Microsoft Outlook as the client application but present Firefox 131.0, Firefox 151.0, or Python Requests user agents rather than the expected Edge pattern Arctic Wolf sees for this activity.
Security Risk Advisors reported a related but not identical cadence in June: repeat non-interactive Exchange Online sign-ins approximately every three hours using Firefox 131.0 and changing token identifiers. The disagreement should not be treated as a flaw in either report. It shows that a fixed detection for exactly eight hours—or exactly three—will age badly. The defensible detection is a sequence: a stable session or account relationship, recurring non-interactive access, rotating proxy-like addresses, and an Outlook-related client context that does not fit the normal device and browser history of that user.
Arctic Wolf also observed Microsoft Entra error 90014 associated with first-party OfficeHome authentication during early campaign activity, often alongside impossible browser-and-operating-system combinations such as Mobile Safari on Windows 10. The vendor calls that pairing highly unusual in its telemetry, but says it was absent from some confirmed intrusions. Treat error 90014 as a useful starting point for a hunt, not as a condition required to declare an account clean.
For Windows and Microsoft 365 administrators, the practical implication is straightforward: retain and ingest non-interactive Entra sign-in logs. Many SOC pipelines focus on interactive login events and email telemetry. That omission can erase the most persistent evidence of this campaign, leaving only a successful MFA event that appears to belong to the employee.
This activity is a warning that mailbox access has become the reconnaissance platform for payroll fraud. An attacker does not need to compromise an HR SaaS account immediately if an employee mailbox can reveal which provider is used, who approves changes, the wording of internal requests, payment dates, banking contacts, and exceptions to normal process.
Arctic Wolf’s most specific mailbox-access indicator is a combination of a Microsoft Outlook client application ID, an undocumented API ID, and a Firefox 131.0 REST user agent in
The report adds a more consequential detail:
That split is operationally important. The low-noise automation appears to retain access and identify worthwhile targets, while hands-on-keyboard operators intervene selectively when there is a reason to alter the mailbox or pursue a financial action. A detection program built around account modifications will see the later, noisier phase but can miss the earlier period when containment is cheapest.
Microsoft’s April report on Storm-2755 did document the end state: attackers diverted employee salary payments to accounts they controlled. Arctic Wolf’s new report does not say it observed payment diversion in most of these email-driven compromises. The absence of that behavior in the current cases should not lower priority. It means the evidence currently supports a campaign that is collecting the prerequisites for payroll fraud, not a claim that every compromised tenant has already suffered it.
Organizations should treat this as a payroll-system incident as soon as a linked Microsoft 365 compromise is confirmed. Review Workday, ADP, or equivalent HR platform activity for the full suspected dwell period; examine direct-deposit and payment-election changes; and independently verify any recent banking-detail changes through a channel that does not rely on the compromised mailbox.
Phishing-resistant MFA deserves priority, but deployment must be enforced through Conditional Access authentication-strength policies. Microsoft lists FIDO2 security keys, passkeys, Windows Hello for Business, and certificate-based authentication among the mechanisms designed to resist credential-and-session relay techniques. Simply making those methods available while leaving weaker options eligible gives an AiTM campaign an easier path through the remaining authentication choices.
Conditional Access should also require managed or compliant devices where business operations allow it, particularly for Exchange Online and other high-value Microsoft 365 resources. Microsoft’s token-protection guidance goes further for supported Windows native applications: device-bound refresh tokens can prevent bearer refresh tokens from being replayed elsewhere. Its current support scope matters, however; it should be deployed as a targeted control, not assumed to protect every browser, platform, and SaaS workflow.
Continuous Access Evaluation can reduce the lifetime of an attacker’s access after a risk event, password reset, session revocation, or relevant network-location change. It is not magic retroactive protection: Microsoft notes that coverage varies by client and resource provider, and policy or group changes are not always instantaneous. In a confirmed incident, administrators should still revoke sessions directly rather than relying on eventual policy reevaluation.
The central lesson from Arctic Wolf’s reporting is that the durable signal is no longer the phishing domain or even the MFA failure. It is the mismatch between a normal employee’s identity and the machine-like way their session behaves afterward: Outlook access from changing residential proxies, improbable client properties, repeated non-interactive refreshes, Graph searches for payroll staff, and coordinated mailbox reads. Those are the events Microsoft 365 defenders need to join together before the payroll-change request arrives.
Arctic Wolf links the activity to the “Payroll Pirates” cluster Microsoft tracks as Storm-2755, while stopping short of declaring a conclusive attribution. That restraint is warranted. Microsoft’s April Storm-2755 report described Canadian victims lured through SEO poisoning and malvertising, while Security Risk Advisors reported related AiTM token-replay and Microsoft Graph reconnaissance in June across several client environments. Arctic Wolf is now documenting a different delivery channel—email phishing—with wider geography and a distinctive automation pattern. The common thread is the target: people who can reveal or influence salary, banking, invoice, and benefits workflows.
This is a business email compromise operation in its reconnaissance phase. Organizations that wait for a fraudulent payroll-change request, a malicious inbox rule, or a suspicious email sent from an employee account may be waiting for the attacker’s second move.
The attack steals the session after MFA, not merely the password
The phishing pages documented by Arctic Wolf are not static Microsoft lookalikes that simply collect a password and one-time code. They act as a reverse proxy between the victim and Microsoft’s genuine sign-in endpoints, rewriting URLs to keep the exchange flowing through attacker-controlled infrastructure. Once Microsoft returns authorization material to the proxy-controlled callback, the operator can capture the session artifacts needed to impersonate the user.That mechanism explains why conventional MFA is insufficient here. SMS codes, push approvals, and authenticator codes can verify a real user during the proxied session; they do not prove that the session is being established directly with the intended relying party. Microsoft’s own identity-security guidance treats AiTM and token replay as a separate problem from password theft and recommends phishing-resistant authentication for sensitive or risky sign-ins.
Arctic Wolf’s phishing infrastructure also fingerprints the victim’s browser and queries a geolocation service before forwarding the user to Microsoft. The vendor’s controlled testing suggests a country value stored in a cookie may be used to choose a residential proxy exit in the victim’s country later. Arctic Wolf did not observe the server-side selection logic, so that remains an informed assessment rather than a confirmed capability. But the observed result—subsequent activity apparently coming from residential networks in the victim’s location—is exactly what makes simple country blocking or crude “impossible travel” rules unreliable.
The delivery chain should also change how mail-security teams interpret otherwise legitimate domains in click telemetry. Google Meet redirect handling, Google ad-tracking infrastructure, and Amazon S3 were used as intermediaries, not as the final phishing host. Blocking a final destination after a user has clicked remains useful, but reputation systems that judge each hop in isolation can miss the assembled chain.
Eight-hour token maintenance is the campaign’s most useful clue
The most valuable finding in Arctic Wolf’s report is behavioral rather than infrastructural. Domains are cheap, proxy exit nodes rotate, and lure documents can be rewritten in minutes. Repeated sign-ins sharing a session identifier while moving across ASNs, IP addresses, and geographic locations are much harder for an operator to disguise without changing the automation that makes the campaign scalable.According to Arctic Wolf, malicious activity commonly begins minutes after a visit to an AiTM proxy, sometimes with several residential-proxy sign-ins in rapid succession. Eleven to 24 hours later, the compromised session begins recurring at roughly eight-hour intervals. The sign-ins identify Microsoft Outlook as the client application but present Firefox 131.0, Firefox 151.0, or Python Requests user agents rather than the expected Edge pattern Arctic Wolf sees for this activity.
Security Risk Advisors reported a related but not identical cadence in June: repeat non-interactive Exchange Online sign-ins approximately every three hours using Firefox 131.0 and changing token identifiers. The disagreement should not be treated as a flaw in either report. It shows that a fixed detection for exactly eight hours—or exactly three—will age badly. The defensible detection is a sequence: a stable session or account relationship, recurring non-interactive access, rotating proxy-like addresses, and an Outlook-related client context that does not fit the normal device and browser history of that user.
Arctic Wolf also observed Microsoft Entra error 90014 associated with first-party OfficeHome authentication during early campaign activity, often alongside impossible browser-and-operating-system combinations such as Mobile Safari on Windows 10. The vendor calls that pairing highly unusual in its telemetry, but says it was absent from some confirmed intrusions. Treat error 90014 as a useful starting point for a hunt, not as a condition required to declare an account clean.
For Windows and Microsoft 365 administrators, the practical implication is straightforward: retain and ingest non-interactive Entra sign-in logs. Many SOC pipelines focus on interactive login events and email telemetry. That omission can erase the most persistent evidence of this campaign, leaving only a successful MFA event that appears to belong to the employee.
The objective is mailbox intelligence before payroll fraud
Arctic Wolf says the actors use Microsoft Graph to identify people whose user attributes suggest payroll, HR, finance, benefits, accounts, or administrative responsibilities. They then retrieve messages tied to invoices, banking, payments, benefits, and internal documents. Security Risk Advisors independently described the same general sequence: broad Graph user enumeration followed by keyword-based searches for payroll and HR personnel, using access tokens taken from legitimate sessions.This activity is a warning that mailbox access has become the reconnaissance platform for payroll fraud. An attacker does not need to compromise an HR SaaS account immediately if an employee mailbox can reveal which provider is used, who approves changes, the wording of internal requests, payment dates, banking contacts, and exceptions to normal process.
Arctic Wolf’s most specific mailbox-access indicator is a combination of a Microsoft Outlook client application ID, an undocumented API ID, and a Firefox 131.0 REST user agent in
MailItemsAccessed events. The vendor reports that it found no legitimate use of that application/API pairing in confirmed compromises across its managed detection telemetry. That makes it a strong hunt candidate, but it is still vendor-observed intelligence, not a documented Microsoft contract. Administrators should validate it against their own Exchange audit history before turning it into an automatic account-disable rule.The report adds a more consequential detail:
Bind operations confirmed that messages were actually opened or retrieved, rather than merely listed. It also found mailbox collection windows clustered across separate tenants within seconds. That pattern points to centralized tasking or collection infrastructure, not unrelated user activity. A tenant that finds one affected user should therefore investigate for contemporaneous access across other accounts, especially finance and payroll-adjacent mailboxes.
“No inbox rule” no longer means “no BEC”
Most investigated intrusions stayed narrowly focused on session maintenance, Graph reconnaissance, and email collection. Arctic Wolf generally did not see MFA changes, device registration, password changes, lateral phishing, or inbox rules. In a small subset, attackers later created rules that moved mail to Deleted Items and marked it read; those interactive sessions came from hosting-provider infrastructure rather than the residential proxies used for automated maintenance.That split is operationally important. The low-noise automation appears to retain access and identify worthwhile targets, while hands-on-keyboard operators intervene selectively when there is a reason to alter the mailbox or pursue a financial action. A detection program built around account modifications will see the later, noisier phase but can miss the earlier period when containment is cheapest.
Microsoft’s April report on Storm-2755 did document the end state: attackers diverted employee salary payments to accounts they controlled. Arctic Wolf’s new report does not say it observed payment diversion in most of these email-driven compromises. The absence of that behavior in the current cases should not lower priority. It means the evidence currently supports a campaign that is collecting the prerequisites for payroll fraud, not a claim that every compromised tenant has already suffered it.
Organizations should treat this as a payroll-system incident as soon as a linked Microsoft 365 compromise is confirmed. Review Workday, ADP, or equivalent HR platform activity for the full suspected dwell period; examine direct-deposit and payment-election changes; and independently verify any recent banking-detail changes through a channel that does not rely on the compromised mailbox.
The defensive fix is stronger than “enable MFA”
The immediate response remains broad because a stolen session can outlive a password reset if remediation is incomplete. Revoke active sessions and refresh tokens, reset credentials, require MFA method re-registration, inspect mailbox rules, review enterprise application consent, and scope what mail was accessed. Then hunt tenant-wide for the recurring non-interactive pattern rather than assuming the initial user was the only victim.Phishing-resistant MFA deserves priority, but deployment must be enforced through Conditional Access authentication-strength policies. Microsoft lists FIDO2 security keys, passkeys, Windows Hello for Business, and certificate-based authentication among the mechanisms designed to resist credential-and-session relay techniques. Simply making those methods available while leaving weaker options eligible gives an AiTM campaign an easier path through the remaining authentication choices.
Conditional Access should also require managed or compliant devices where business operations allow it, particularly for Exchange Online and other high-value Microsoft 365 resources. Microsoft’s token-protection guidance goes further for supported Windows native applications: device-bound refresh tokens can prevent bearer refresh tokens from being replayed elsewhere. Its current support scope matters, however; it should be deployed as a targeted control, not assumed to protect every browser, platform, and SaaS workflow.
Continuous Access Evaluation can reduce the lifetime of an attacker’s access after a risk event, password reset, session revocation, or relevant network-location change. It is not magic retroactive protection: Microsoft notes that coverage varies by client and resource provider, and policy or group changes are not always instantaneous. In a confirmed incident, administrators should still revoke sessions directly rather than relying on eventual policy reevaluation.
The central lesson from Arctic Wolf’s reporting is that the durable signal is no longer the phishing domain or even the MFA failure. It is the mismatch between a normal employee’s identity and the machine-like way their session behaves afterward: Outlook access from changing residential proxies, improbable client properties, repeated non-interactive refreshes, Graph searches for payroll staff, and coordinated mailbox reads. Those are the events Microsoft 365 defenders need to join together before the payroll-change request arrives.
References
- Primary source: Arctic Wolf
Published: 2026-08-06T23:15:55+00:00
Loading…
arcticwolf.com - Related coverage: microsoft.com
Loading…
www.microsoft.com - Related coverage: learn.microsoft.com
Phishing-resistant MFA | Microsoft Learn
Phishing-resistant multifactor authentication (MFA) is part of the protect identities and secrets pillar of the Secure Future Initiative (SFI), focusing on hardening authentication, eliminating unmanaged credentials, enforcing Zero Trust principles, and protecting cryptographic keys.learn.microsoft.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: sra.io
Loading…
sra.io - Related coverage: itpro.com
'Payroll Pirates' target US universities, Microsoft warns | IT Pro
Group uses simple but effective tactics to divert staff salaries to themselveswww.itpro.com