The enterprise email security stack most organizations have spent years building has a structural blind spot: it trusts Google and Amazon. A financially motivated threat campaign disclosed Thursday by Arctic Wolf Labs is exploiting that trust directly — threading a six-stage redirect chain through Google Meet, Google Ads infrastructure, and Amazon S3 to deliver adversary-in-the-middle phishing links that pass every reputation-based filter on the way to a victim's inbox.

Arctic Wolf Labs reported that in July 2026 alone it observed hundreds of organizations targeted, with confirmed intrusions spanning healthcare, education, manufacturing, government, and professional services across the United States, Canada, and Europe. Once inside, the attackers do not announce themselves. They quietly harvest email from finance, payroll, and HR personnel — reconnaissance for the payroll diversion that defines the "Payroll Pirates" threat cluster Microsoft tracks as Storm-2755 threat cluster.

Every compromised account in this campaign was running MFA at the time of breach.

Why Google and AWS Are the Attack Surface

The campaign begins with an email that looks exactly like an automated voicemail notification from a business service: a Microsoft logo, a fabricated caller ID and reference number, and a button labeled "OPEN [Organization] VOICEMAIL PORTAL." When a recipient clicks that button, the URL that fires is a real Google Meet link.

That is the first of six hops. The full chain routes through Google Meet's link redirect service, then through google.com's outbound-link infrastructure, then through a Google Campaign Manager dynamic click tracker (a legitimate digital advertising measurement service run at adservice.google[.]com), before landing on an HTML file in Amazon S3. Only at that point does the chain route onward to the attackers' own AiTM proxy domain.

Every link in that chain before the final hop belongs to Google or Amazon. Enterprise email gateways — Secure Email Gateways, Microsoft Defender for Office 365, Proofpoint, Mimecast — analyze URLs before delivery using domain reputation scores. Google and Amazon score at the highest possible trust tier. An email carrying a google.com/url link pointing at a Campaign Manager tracker passes every reputation check, even though each hop is being used to obscure a malicious destination. This is not a bug in the email security products; it is an intentional exploitation of a trust relationship those products were designed to honor, as security researchers have documented.

Arctic Wolf's DNS telemetry confirmed the chain's operation: during observed phishing activity, resolution of Google Ads-related domains was followed within the same second by resolution of a newly registered phishing domain. The timing is that precise.

What Happens When a Victim Clicks

Before routing the victim to a fake Microsoft login page, the phishing infrastructure runs a profiling step. A JavaScript fingerprinting script at the redirect endpoint silently collects browser type, operating system, screen and window dimensions, time zone offset, browser language, hardware concurrency, WebGL vendor, WebDriver status, and cookie capabilities — and sends the full profile to a PHP backend via HTTP POST. A separate API call queries api.country.is, a free geolocation service, to determine the victim's country. That country code is stored in a cookie with a seven-day expiration.

Arctic Wolf assessed that the geolocation data is likely used to match the victim to a residential proxy exit node in their own country for subsequent malicious sign-in activity. This matters for detection: a sign-in to a US employee's account from a residential IP looks like consumer traffic to anomaly-detection systems that flag international logins. Standard geographic anomaly alerts do not fire.

Once fingerprinting completes, the victim's browser is redirected to the AiTM proxy. Unlike a static credential-harvesting page, this is a live reverse proxy: it connects to Microsoft's actual authentication endpoint in real time and relays every step of the real login flow, including MFA. The victim completes authentication normally, against the real Microsoft servers. What the proxy intercepts is the session token Microsoft issues after authentication succeeds — the proof-of-authentication credential that grants ongoing access to Outlook, Teams, and SharePoint without requiring credentials again. The victim's account is now compromised, the MFA requirement has already been satisfied, and the victim has no indication anything went wrong.

How Stolen Sessions Hide for Days

Within minutes of a victim completing authentication, the campaign's infrastructure initiates a sign-in from a residential proxy IP matching the victim's country. The session ID from the original authentication is reused; only the source IP and geographic location change.

Eleven to twenty-four hours later, a persistent automation cycle begins: every eight hours, the same session is refreshed from a different residential proxy address, maintaining access as long as the token remains valid. Each refresh retains the same hijacked session ID but reports a different autonomous system number and geographic origin. The pattern produces a durable behavioral signal but one that only surfaces when session-level telemetry is correlated across time rather than evaluated per sign-in.

A further detection signal comes from an anomalous user-agent combination: these automated sessions report Microsoft Outlook as the client application but present Firefox 131.0 or Python Requests as the browser, rather than the Edge browser that real Outlook clients use. Legitimate Microsoft Outlook and Edge pairings are the overwhelming norm in corporate environments; the mismatch is functionally impossible in real traffic and highly specific to this campaign.

Arctic Wolf identified a unique combination in Microsoft 365 audit logs that its global telemetry associates exclusively with confirmed intrusions from this campaign: MailItemsAccessed events carrying Microsoft Outlook's Client App ID (5d661950-3475-41cd-a2c3-d671a3162bc1) paired with a specific API ID (c999ed3e-27ae-4cb3-b3a2-46b056af63d3) that does not appear in any documented legitimate Outlook mail access. Organizations with Microsoft 365 E3/E5 licenses can hunt for this combination directly in their audit logs.

Staying Below the BEC Detection Radar

Standard business email compromise detection tools alert on specific account behaviors: changes to MFA methods, new device registrations, outbound phishing emails, inbox rule creation. This campaign avoids all of them.

In the majority of observed intrusions, the attackers performed no account modifications and sent no external emails. They used Microsoft Graph API queries — the same programmatic interface that legitimate enterprise tools use to read directory and mailbox data — to enumerate users with payroll, HR, finance, and administrative roles across the tenant. Then they silently read email related to payroll, invoices, banking, payments, and benefits. A shared SessionID links all of this activity to the original phishing event, but only investigators correlating identity, session, and mailbox logs will see the connection.

Cross-tenant coordination adds another dimension: Arctic Wolf observed MailItemsAccessed events from multiple separate tenant environments clustering into the same brief windows — 18 events across three organizations within 26 seconds in one documented case, 11 events across two organizations within 43 seconds in another. This confirms centralized automation operating simultaneously against multiple compromised organizations.

In a smaller subset of intrusions, operators did intervene manually — creating inbox rules that automatically moved messages to Deleted Items and marked them as read, the kind of silent surveillance setup that can go undetected indefinitely. Those manual sign-ins originated from hosting provider IP addresses rather than residential proxies, suggesting operators step in selectively for hands-on account manipulation while automation handles everything else.

Why Standard MFA Does Not Stop This

Multi-factor authentication was designed to prevent an attacker who has stolen a password from using it. This attack never steals a password in the traditional sense. The victim logs in normally, completes the MFA challenge, and receives a valid authenticated session. The AiTM proxy intercepts the session token before it reaches the victim's browser.

This is a structural limitation of every MFA method that produces a reusable code or approval: TOTP authenticator apps, push notifications, and SMS codes all generate one-time values that a live proxy can relay to Microsoft's servers in the milliseconds they remain valid. The reverse proxy does not crack MFA — it uses it correctly and captures what MFA produces.

The only widely deployed authentication technology that defeats this at the protocol level is FIDO2 — physical security keys such as YubiKey, platform authenticators like Windows Hello for Business, or device-bound passkeys. FIDO2 binds the authentication assertion cryptographically to the specific domain the user is accessing. When the attacker's proxy domain differs from the real Microsoft login domain — even by a single character — the device refuses the assertion. There is nothing for the proxy to capture.

CISA and NIST both classify only FIDO2, WebAuthn/passkeys, and certificate-based authentication as phishing-resistant MFA. Standard authenticator apps, push notifications, and SMS are explicitly excluded from that classification because they can all be relayed through a reverse proxy.

What Security Teams Should Do Now

Arctic Wolf's guidance, corroborated by Microsoft's Entra documentation, points to four specific defensive controls that address distinct stages of this attack chain:

Deploy phishing-resistant MFA. FIDO2 security keys, Windows Hello for Business, and certificate-based authentication are the only methods that structurally prevent session token theft in a reverse-proxy attack. Organizations already using Microsoft Entra ID can enforce FIDO2 via Authentication Methods policy.

Enforce Conditional Access policies requiring compliant or hybrid-joined devices. A Conditional Access policy that only permits sign-ins from managed, policy-compliant devices prevents an attacker from using stolen session tokens on an unmanaged device — even if the token is valid. The compromised session material is rendered unusable on attacker-controlled infrastructure.

Enable Continuous Access Evaluation (CAE). Standard Microsoft 365 access tokens are valid for up to 60–90 minutes after issuance. CAE establishes a real-time channel between Entra ID and services including Exchange Online, SharePoint, and Teams so that token revocation takes effect in near-real-time rather than waiting for expiry. When a compromised session is identified and an admin revokes tokens, CAE can cut the attacker's access window from over an hour to under 15 minutes.

Ensure non-interactive sign-in log ingestion is enabled. The eight-hour session-maintenance pattern that provides the most durable detection signal appears in non-interactive sign-in logs — the log category that some organizations have disabled to manage data volume. Without this telemetry, the periodic token-refresh activity is invisible to both SOC teams and SIEM tools.

For organizations investigating suspected compromise, Arctic Wolf recommends immediately revoking all active sessions for affected accounts, rotating credentials and re-registering MFA, and auditing payroll and HR platforms (specifically Workday and ADP) for direct deposit changes across the full suspected dwell period. The MailItemsAccessed audit log combination noted above provides a high-fidelity scope indicator for what data the attacker accessed.

Arctic Wolf has published a full set of indicators of compromise — including phishing domains, email subject-line patterns, DNS indicators, and Advanced Hunting queries for Microsoft Defender XDR — in its public GitHub repository.

---

Frequently Asked Questions

Does enabling MFA protect a Microsoft 365 account from this type of attack?

Standard MFA methods — TOTP codes from authenticator apps, push notifications, and SMS codes — do not protect against adversary-in-the-middle attacks because they produce reusable values a live proxy can relay in real time. The only methods classified by NIST and CISA as phishing-resistant are FIDO2 security keys, device-bound passkeys, Windows Hello for Business, and certificate-based authentication. These bind authentication cryptographically to the specific destination domain, making token relay structurally impossible. An organization that has deployed push-notification MFA has substantially reduced password-based account takeover risk but has not closed the AiTM attack path.

How can attackers use a Google Meet link to steal my work account credentials?

The Google Meet link is a redirect that points to Google's own outbound-link infrastructure, which in turn points to a Google Campaign Manager click tracker, which points to a file hosted on Amazon S3, which finally routes to the attackers' fake Microsoft login page. Each step in that chain belongs to a legitimate platform with a strong reputation score. Enterprise email security tools check URLs against domain reputation databases before allowing delivery; because every link in the chain points to google.com or amazonaws.com until the final hop, the chain passes every reputation check. The malicious destination is only revealed after multiple redirects through platforms that email filters trust by design.

What is the most reliable way to detect this attack in Microsoft 365 logs?

Arctic Wolf identified a combination in Microsoft 365 Unified Audit Logs that appears exclusively in confirmed intrusions and never in legitimate Outlook activity: MailItemsAccessed events with Client App ID 5d661950-3475-41cd-a2c3-d671a3162bc1 paired with API ID c999ed3e-27ae-4cb3-b3a2-46b056af63d3. Organizations with Office 365 E3/E5 or Microsoft 365 E3/E5 licenses can search for this combination in their audit logs. A second durable signal is the Outlook client application reporting Firefox 131.0 as the browser user agent — legitimate Outlook uses Edge. Both signals appear in non-interactive sign-in logs, which must be ingested for detection tools to surface them.

What is the connection between this campaign and the Storm-2755 "Payroll Pirates" cluster?

Microsoft has been tracking Storm-2755 since at least early 2026, when it documented the group conducting AiTM attacks against Canadian employees to redirect salary payments into attacker-controlled bank accounts. The current campaign overlaps with Storm-2755 in its use of the Microsoft Graph API to enumerate payroll and HR personnel, the axios/1.18.1 user-agent signature in reconnaissance activity, and the focus on financial workflow email. Arctic Wolf assessed the campaign shares significant technical and behavioral overlap with the broader Payroll Pirates cluster, though it noted the current activity covers a wider geographic scope than prior reporting. Business email compromise caused approximately $3.046 billion in US reported losses in 2025 alone, according to the FBI's IC3 2025 Internet Crime Report.