New AiTM Phishing Campaign Targets Microsoft 365 Accounts, Evades Detection with Residential Proxies
A sophisticated, email-driven phishing campaign is actively targeting **Microsoft 365** accounts, utilizing adversary-in-the-middle (AiTM) techniques to bypass multi-factor authentication (MFA). Researchers at **Arctic Wolf Labs** warn that the attackers are employing residential proxies and a multi-stage redirection chain to identify key financial personnel and exfiltrate sensitive email data across various sectors.
Cybersecurity researchers are sounding the alarm on a widespread phishing campaign that leverages advanced adversary-in-the-middle (AiTM) tactics to compromise **Microsoft 365** accounts. The primary objective is to pinpoint personnel involved in financial operations and harvest relevant email communications.
### Sophisticated Evasion Techniques
**Arctic Wolf Labs** reports that the campaign employs residential proxies to mask malicious sign-ins, making them appear as legitimate consumer traffic. This automated activity maintains compromised sessions at approximately eight-hour intervals, significantly hindering detection efforts.
### Impacted Sectors and Tactical Overlaps
Organizations in healthcare, education, manufacturing, government, and professional services across the U.S., Canada, and Europe are being impacted. This campaign exhibits tactical similarities with **Payroll Pirate** attacks, which **Microsoft** tracks under the moniker **Storm-2755**.
**Payroll Pirates** is a broader, financially motivated threat cluster documented since early 2025, with **Microsoft** also tracking a related threat as **Storm-2657**. These campaigns typically involve hijacking employee accounts to redirect salary payments to attacker-controlled accounts.
Last month, **Arctic Wolf** observed hundreds of organizations targeted by email in this latest phishing wave, leading to successful intrusions across a diverse range of victim environments.
### The Anatomy of the Attack Chain
The attack begins with voicemail-themed phishing emails. These emails direct victims to AiTM decoy pages that act as a proxy for the legitimate **Microsoft** account authentication flow, stealthily capturing both credentials and multi-factor authentication (MFA) codes.

This is achieved through a six-stage redirection chain that abuses legitimate and trusted services such as **Google**, **Google Meet**, **Google Ads**, and **Amazon S3** to bypass reputation-based filters.
**Arctic Wolf** explains: "The chain begins with a **Google Meet** linkredirect URL, and continues through **Google's** outbound-link infrastructure before reaching a **Campaign Manager /ddm/clk** dynamic click tracker. In the activity we observed, the destination embedded in the tracker URL pointed to an HTML object hosted in an **Amazon AWS S3** bucket. The **S3**-hosted page then redirected the victim to the campaign's AiTM phishing infrastructure."
### Fingerprinting and Geolocation Evasion
The phishing pages also incorporate JavaScript to fingerprint the visiting host, collecting extensive information including web browser, operating system, screen dimensions, browser language, time zone offset, cookie capabilities, **WebDriver** status, **WebGL** vendor, and browser API availability. This data is then sent to a PHP endpoint via an HTTP POST request, followed by a redirection to the proxied **Microsoft OAuth** authorization endpoint.

The attackers also query a geolocation API (`api.country[.]is`) for the requester's country code, storing the result in a `rcfh_country` cookie. This geolocation data is then leveraged to select geographically matched residential proxy infrastructure for subsequent logins. This tactic helps evade security controls that typically flag access from unusual IP addresses.
### Post-Compromise Actions and Stealth
Controlled testing revealed that malicious sign-in activity often originates within minutes from a residential proxy exit node in the victim's country. Some sign-in events have reported "implausible browser and operating-system combinations," such as mobile versions of **Apple Safari** or **Google Chrome** on **Windows 10**.
**Arctic Wolf** further noted: "Typically, 11 to 24 hours after the initial anomalous activity, malicious sign-ins began recurring at eight-hour intervals from rotating residential proxy addresses. These events reported **Microsoft Outlook** as the client application but used **Firefox 131.0**, **Firefox 151.0**, or occasionally **Python Requests** user agents rather than the expected **Edge** user agent."
The recurring sign-ins maintained the same **SessionID** despite changes in source IP address, ASN, and geographic location, indicating centralized automation refreshing each compromised session independently.
Similar to **Storm-2755**, the threat actors utilize the **Microsoft Graph API** to enumerate tenant users associated with payroll, HR, finance, and administrative functions. They then access messages related to payroll, invoices, payments, banking, benefits, and internal documents.
In most intrusions investigated, post-compromise actions were limited to session maintenance, reconnaissance, and mailbox collection. The attackers deliberately avoided common BEC behaviors like MFA-method changes, device registration, credential modification, lateral phishing, or inbox rule creation. This restraint significantly limits opportunities for early detection based on account modification or outbound email abuse.
However, in a few instances, the attackers engaged in hands-on keyboard activity to create inbox rules that automatically moved certain messages to the Deleted Items folder and marked them as read. This suggests selective intervention for account manipulation, while a centralized automation infrastructure handles other attack aspects.
"Using rotating residential proxies, the threat actor quietly maintained stolen sessions, identified personnel involved in financial workflows, and collected relevant mailbox data through automated activity," **Arctic Wolf** concluded. "The delay between initial access and subsequent automation, combined with restrained post-compromise activity, makes the campaign harder to connect to the original phishing event and less likely to trigger existing detections."