Key Takeaways
- Attackers are conducting a widespread email‑driven phishing campaign that uses adversary‑in‑the‑middle (AitM) techniques to hijack Microsoft 365 accounts.
- The campaign leverages residential proxies and a multi‑stage redirection chain involving trusted services (Google Meet, Google Ads, Amazon S3) to bypass reputation‑based filters.
- Victims span healthcare, education, manufacturing, government, and professional services in the U.S., Canada, and Europe, with overlaps to the Payroll Pirate threat cluster (Storm‑2755/Storm‑2657).
- After credential theft, threat actors maintain compromised sessions via rotating residential proxies at roughly eight‑hour intervals, using automated scripts to collect email from payroll, HR, and finance personnel.
- Post‑compromise activity is largely limited to session maintenance, reconnaissance, and mailbox collection; only a few cases showed hands‑on‑keyboard manipulation such as creating inbox rules to hide stolen data.
- The use of geolocation APIs and browser fingerprinting helps attackers select geographically matched proxies and evade detections that flag anomalous IPs or user‑agent strings.
- Detection is challenging because the attackers avoid typical BEC behaviors (MFA changes, device registration, lateral phishing) and delay malicious sign‑ins, making the campaign harder to link to the initial phishing lure.
Overview of the Campaign
Arctic Wolf Labs has identified an active, email‑based phishing operation that specifically targets Microsoft 365 accounts using adversary‑in‑the‑middle (AitM) tactics. The goal is to gain persistent access to corporate mailboxes in order to locate employees who handle payroll, HR, finance, and other financial workflows, then exfiltrate relevant email content. The campaign has been observed hitting hundreds of organizations across multiple sectors and regions, indicating a broad, opportunistic scope rather than a narrowly focused attack.
Initial Infection Vector
The attack begins with voicemail‑themed phishing emails that lure recipients to click a seemingly innocuous link. These emails are crafted to appear as legitimate notifications, increasing the likelihood of user interaction. Once the recipient clicks, they are funneled into a sophisticated redirection chain designed to conceal the malicious endpoint while appearing to traverse trusted internet services.
Multi‑Stage Redirection Chain
The phishing flow employs a six‑step redirection sequence that leverages legitimate platforms such as Google Meet, Google’s outbound‑link infrastructure, Google Ads, and Amazon S3. The chain starts with a Google Meet link‑redirect URL, passes through Google’s click‑tracking system (Campaign Manager /ddm/clk), and ultimately lands on an HTML object hosted in an Amazon AWS S3 bucket. This S3‑hosted page then forwards the victim to the attackers’ AitM phishing infrastructure. By routing traffic through well‑known domains, the attackers evade many reputation‑based security controls that would otherwise flag direct connections to malicious sites.
Credential and MFA Harvesting via AitM
At the core of the operation is an AitM proxy that sits between the user and the genuine Microsoft OAuth authorization endpoint. The proxy presents a convincing Microsoft login page, capturing the user’s username, password, and the multi‑factor authentication (MFA) code entered during the authentication flow. JavaScript embedded in the phishing page performs extensive browser fingerprinting—collecting data on the browser version, operating system, screen resolution, language, time zone, cookie support, WebDriver status, WebGL vendor, and available APIs. This information is sent to a PHP endpoint via an HTTP POST request, enabling the threat actors to tailor subsequent attacks and evade detection mechanisms that rely on behavioral baselines.
Geolocation and Proxy Utilization
After harvesting credentials, the script queries a public geolocation API (api.country[.]is) to obtain the victim’s country code, storing the result in a cookie named “rcfh_country” with a seven‑day expiration. This data allows the attackers to select residential proxy exit nodes that appear to originate from the same geographic location as the victim. Consequently, malicious sign‑ins originate within minutes from a residential IP address matching the victim’s country, reducing the likelihood of triggering geo‑based anomaly alerts. The use of residential proxies also helps the traffic blend in with normal consumer internet traffic, further obscuring the attack.
Session Maintenance and Automated Activity
Arctic Wolf observed that compromised Microsoft 365 sessions are kept alive through automated activity that refreshes the session approximately every eight hours. These recurring sign‑ins originate from rotating residential proxy addresses, yet they retain the same SessionID while the source IP, autonomous system number (ASN), and geographic location change. This pattern indicates a centralized automation system that independently renews each stolen session, allowing the attackers to maintain persistent access without manual intervention.
Post‑Compromise Behavior
In the majority of investigated intrusions, the threat actors limited their actions to session maintenance, reconnaissance, and mailbox collection. They used the Microsoft Graph API to enumerate tenant users associated with payroll, HR, finance, and administrative functions, then accessed messages related to payroll, invoices, payments, banking, benefits, and internal documents. Notably, the attackers avoided typical business email compromise (BEC) tactics such as altering MFA methods, registering new devices, changing credentials, launching lateral phishing attempts, or creating inbox rules for data exfiltration. This restraint reduces the chances of triggering alerts that focus on account modification or abnormal outbound email patterns.
Limited Hands‑On‑Keyboard Interventions
A small subset of cases revealed deliberate, hands‑on‑keyboard activity where attackers created inbox rules that automatically moved specific messages to the Deleted Items folder and marked them as read. These actions suggest selective intervention to conceal particular emails—likely those containing sensitive financial information—while the bulk of the operation remained automated. The hybrid approach indicates that a centralized automation framework handles routine tasks, whereas human operators step in for precise manipulations when needed.
Detection Challenges
The combination of delayed malicious sign‑ins (typically 11 to 24 hours after initial credential theft), the use of geographically matched residential proxies, and the avoidance of overt BEC behaviors makes this campaign difficult to detect with conventional security controls. Security products that rely on sudden spikes in authentication failures, impossible travel alerts, or known malicious IP ranges may miss the subtle, low‑and‑slow nature of the attack. Moreover, the extensive use of trusted services in the redirection chain helps the phishing links bypass URL‑reputation and sandboxing defenses.
Implications for Organizations
Organizations should prioritize multi‑layered defenses that go beyond credential protection. Recommendations include: implementing conditional access policies that block sign‑ins from residential IP ranges unless absolutely necessary; enforcing phishing‑resistant MFA (e.g., FIDO2 security keys); deploying advanced threat protection that inspects JavaScript behavior and detects anomalous redirection chains; monitoring for unusual session persistence patterns (e.g., same SessionID with changing IPs); and conducting regular user awareness training focused on voicemail‑themed lures and suspicious link structures. Additionally, logging and alerting on Microsoft Graph API queries related to payroll, HR, and finance can help identify reconnaissance activity early. By combining technical controls with vigilant monitoring, organizations can reduce the likelihood of successful session hijacking and subsequent data exfiltration in campaigns like the one described.