Microsoft 365 AitM Phishing Campaign Targets Payroll and Finance Emails

A widespread Microsoft 365 AitM phishing campaign has targeted hundreds of organizations across North America and Europe, seeking to hijack user accounts and exfiltrate sensitive payroll and financial communications. Detailed by researchers at Arctic Wolf Labs, the campaign shares significant operational tactics with the threat group known as Payroll Pirates, tracked by Microsoft under the monikers Storm-2755 and Storm-2657. Rather than deploying noisier Business Email Compromise (BEC) tactics like widespread lateral phishing or modifying account credentials, these threat actors employ disciplined post-compromise reconnaissance focused strictly on stealing salary, invoice, and banking data from key personnel in financial workflows.

The activity has impacted organizations across healthcare, education, manufacturing, government, and professional services sectors located in the United States, Canada, and Europe.

Multi-Stage Redirection and AitM Session Token Theft

At the core of the attack chain is a highly evasive delivery mechanism designed to bypass reputation-based email filters and secure email gateways. The attack originates with voicemail-themed phishing emails containing links that trigger a six-stage redirection sequence across trusted enterprise platforms:

1. The initial click routes through a Google Meet link redirect URL.
2. The request passes through Google’s outbound-link infrastructure.
3. It hits a Google Campaign Manager (/ddm/clk) dynamic click tracker.
4. The tracker directs the victim’s browser to an HTML file hosted in an Amazon AWS S3 bucket.
5. The S3-hosted page executes a final redirection to the campaign’s Adversary-in-the-Middle (AitM) phishing proxy infrastructure.
6. The victim interacts with an AitM decoy page proxying the legitimate Microsoft account authentication flow.

Because AitM phishing sites act as a live reverse proxy between the victim and genuine Microsoft Entra ID authentication endpoints, traditional multi-factor authentication (MFA)—such as SMS, time-based one-time passwords (TOTP), and mobile push notifications—is completely bypassed. The proxy captures both the victim’s plain-text credentials and the resulting session tokens (including MFA authentication cookies) in real time.

Geolocation Fingerprinting and Residential Proxy Automation

Before initiating the OAuth authentication flow, the phishing landing page executes client-side JavaScript to fingerprint the visiting host environment. The script collects telemetry including browser user-agent, operating system details, screen and window dimensions, browser language, time zone offset, cookie capabilities, WebGL vendor, and WebDriver status. This payload is packaged and transmitted via an HTTP POST request to a remote PHP endpoint.

Simultaneously, the script queries a geolocation API (api.country[.]is) to extract the requester’s country code, writing the value into a cookie named rcfh_country with a seven-day expiration. Controlled testing indicates that within minutes of initial access, the threat actor leverages this geolocation data to select geographically matched residential proxy exit nodes in the victim’s country. By routing sign-in traffic through domestic residential IP addresses, the attackers successfully bypass security controls and Conditional Access policies designed to flag logins from unusual countries or commercial datacenters.

Initial sign-in events frequently display implausible browser and operating system combinations, such as mobile versions of Apple Safari or Google Chrome running on Windows 10. Approximately 11 to 24 hours after initial compromise, automated infrastructure assumes control of the hijacked session:

• Centralized automation scripts refresh compromised Microsoft 365 sessions at strict eight-hour intervals.
• The recurring sign-ins retain the exact same SessionID while the source IP address, ASN, and geographic location continuously rotate across residential proxies.
• Sign-in logs report Microsoft Outlook as the client application, but user-agent strings reveal Firefox 131.0, Firefox 151.0, or Python Requests signatures rather than expected Microsoft Edge or official desktop client headers.

Stealthy Graph API Exploitation and Post-Compromise Reconnaissance

Once authenticated access is established, the threat actors execute targeted reconnaissance while deliberately avoiding common triggers for security alerts. In the vast majority of investigated intrusions, post-compromise actions were strictly confined to session maintenance, directory enumeration, and mailbox collection.

The threat actors leverage the Microsoft Graph API to enumerate tenant users associated with payroll, human resources, finance, and administrative functions. Using automated requests, they extract messages, attachments, invoices, wire payments, banking details, and employee benefit documentation.

To maintain low visibility, the attackers routinely avoid common BEC behaviors: they do not register new MFA authentication methods, modify user passwords, enroll rogue devices, send internal phishing messages, or create global forwarding rules. However, in a limited number of cases, operators intervened manually to create inbox rules that silently moved incoming financial emails to the “Deleted Items” folder and marked them as read, preventing targets from noticing intercepted communications.

Defending Against Microsoft 365 AitM Phishing Attacks

Mitigating adversary-in-the-middle phishing campaigns requires moving beyond standard multi-factor authentication toward phishing-resistant credentials and strict session-context controls.

• Enforce Phishing-Resistant MFA: Transition accounts handling payroll, finance, and administrative functions to FIDO2 WebAuthn security keys, Certificate-Based Authentication (CBA), or Windows Hello for Business. FIDO2 tokens cryptographically bind the authentication response to the origin domain in the browser URL bar, causing authentication to fail automatically on AitM proxy pages.
• Require Compliant or Managed Devices: Configure Microsoft Entra Conditional Access policies to enforce Compliant Device or Entra ID Hybrid Joined Device requirements for accessing Exchange Online and Microsoft Graph API. Requiring a verified device state prevents attackers from reusing stolen session tokens on unmanaged residential proxy nodes.
• Audit Sign-Ins and Session Telemetry: Set up automated SIEM alerts for Entra ID sign-in events where the client application is reported as Microsoft Outlook but accompanied by non-standard User-Agents (Firefox/131.0, Firefox/151.0, Python-requests). Monitor for persistent SessionID values that execute successful logins across rotating ASNs and residential proxy networks within short timeframes.
• Restrict and Monitor Graph API Access: Enforce Continuous Access Evaluation (CAE) to immediately revoke active sessions upon detection of risk signals, and audit Graph API query volumes for anomalous mailbox data export patterns across administrative and finance accounts.