How legitimate cloud platforms enable phishers to bypass MFA

1. Executive summary

Threat actors are systematically abusing legitimate PaaS and decentralised hosting platforms — Cloudflare Workers/Pages, Vercel, Netlify, GitHub Pages, and IPFS gateways — to host adversary-in-the-middle (AitM) phishing infrastructure that bypasses MFA by intercepting session tokens. Kaspersky/Securelist reports 224,984 unique third-level domains blocked on these platforms across a 12-month period (Aug 2025–Jul 2026), with pages.dev (24.9%), vercel.app (13.8%), and github.io (13.7%) the most abused. The shared apex domains cannot be bulk-blocked without collateral damage to legitimate services. EMEA financial services face elevated risk because the attack chain defeats standard MFA and domain-reputation controls, producing valid session tokens that enable direct account takeover of banking, trading, and internal collaboration platforms.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item. The threat describes a general phishing/MFA-bypass technique using legitimate cloud platforms; while an organisation suffering a successful session-token theft would trigger incident-management obligations, the technique itself does not engage a distinctive regulatory article beyond what any credential-theft incident would.

3. Technical analysis & attack chain

The following attack chain is reconstructed from the Securelist report describing a real-world AitM campaign leveraging Cloudflare Workers. Attribution to a specific threat actor is not claimed in the source; no MITRE ATT&CK actor profile is available. The technical detail below is single-sourced (Securelist/Kaspersky telemetry); verify before enforcement.

Stage 1 — Contact harvesting via compromised relay site

1. Victim receives a phishing email with a plausible pretext (e.g., coworker requesting document review) containing a malicious link.
2. Clicking the link redirects to a fake CAPTCHA landing page hosted on a compromised legitimate website (source references hxxps://t[REDACTED]e.com as the specific campaign relay). The compromised site acts as a disposable relay — phishing links delivered directly via email are detected and blocked faster by security vendors.
3. The victim enters their email address and clicks "Continue." The pseudo-CAPTCHA marks them as human and initiates a redirect to a *.workers.dev subdomain (Cloudflare Workers, auto-provisioned free of charge).
4. The victim's email address is embedded in the URL hash (the # fragment), allowing the workers.dev page to extract it client-side without issuing a request to the attacker's server — the email never appears in HTTP request logs, evading network-based detection.

Stage 2 — Transparent proxy initialisation via service worker

5. The browser loads the [REDACTED].workers.dev page with #user@business.com appended. The page presents a genuine CAPTCHA challenge to filter out security sandboxes and automated analysis.
6. The page script extracts the email from the URL hash and stores it in sessionStorage to prevent overwrite when the CAPTCHA loads, and to pre-fill the username field later.
7. Upon CAPTCHA completion, a service worker is registered in the victim's browser. Service workers are standard PWA components; browsers execute them without user consent when the site uses HTTPS. The service worker intercepts all network requests generated by the current tab.
8. The attackers deploy Ultraviolet, a legitimate open-source web proxy library, via the service worker to dynamically rewrite all links and forms on the page. This forces every outgoing request — including Microsoft login credential submissions — to route through the attacker's reverse proxy rather than directly to the legitimate service.
9. The script constructs a redirect URL for Stage 3, appending the email from sessionStorage back into the URL hash. The email is passed via URL hash across all three stages, keeping it hidden from network detection systems throughout.

Stage 3 — AitM + Browser-in-the-Browser (BitB) credential and session theft

10. The final page combines AitM traffic interception with a Browser-in-the-Browser (BitB) UI spoofing technique. The script generates a pop-up visually identical to a native browser window — complete with window controls and a spoofed address bar displaying a trusted Microsoft URL.
11. Inside the simulated window, an iframe loads the authentic Microsoft login interface, routed dynamically through the service worker reverse proxy established in Stage 2.
12. When the victim enters credentials and MFA code into the BitB window, the proxy script intercepts both the credentials and the session tokens.
13. Upon successful login, the proxy closes the pop-up and redirects the victim to a generic error page (e.g., SessionExpired). The victim assumes a technical glitch and may attempt to log in again, unaware the attacker already holds the session token.

Platform abuse statistics (Aug 2025–Jul 2026, Securelist telemetry)

Total: 224,984 unique third-level domains blocked; 390,000+ phishing pages neutralised across cloud platforms and IPFS. IPFS-hosted content (dweb.link, ipfs.io) presents persistent availability — blocking one gateway does not remove the content, which remains accessible via alternative nodes.

4. Mitigation & containment

P1 — Within 24 hours

• Conditional Access policy enforcement: Configure identity provider (Entra ID / Okta) Conditional Access to require device compliance or hybrid-joined device state for authentication to financial services applications. Session tokens stolen via AitM cannot be replayed from non-compliant devices.
• Token binding / Continuous Access Evaluation (CAE): Where supported (Entra ID), enable CAE to shorten token lifetimes and enable real-time revocation on policy changes or risk events. AitM-captured tokens are then short-lived and revocable.
• Service worker blocking: Deploy browser policy (MDM/Group Policy) to restrict service worker registration to approved origins. In Chrome, enforce ServiceWorkersAllowedForUrls policy to an explicit allowlist. In Firefox, set dom.serviceWorkers.enabled to false via enterprise policy for high-risk workstations, or restrict via extension policy.
• URL hash inspection: Ensure secure web gateway (SWG) and CASB solutions inspect URL fragments (#) in addition to query parameters. The attack chain relies on passing the victim's email via the hash to evade network detection. Confirm your SWG performs client-side content inspection on HTTPS pages, not just URL reputation lookups.

P2 — Within 72 hours

• Cloud platform domain categorisation and selective blocking: In SWG/proxy, categorise pages.dev, workers.dev, vercel.app, netlify.app, wixstudio.com, webflow.io, dweb.link, and ipfs.io as "newly registered / unverified" for user-initiated browsing. Require just-in-time approval for access to these domains from managed devices. Do not block apex domains globally — collateral impact on legitimate development and business use is significant.
• Anti-phishing training update: Brief users that the presence of a browser lock icon, a legitimate CAPTCHA, or a workers.dev/pages.dev URL does not indicate authenticity. Specifically warn that pop-up login windows (BitB) embedded within a page are not genuine browser windows.
• Session token anomaly detection: Configure SIEM detection rules for impossible-travel and token-replay patterns — a session token used from an IP/ASN inconsistent with the user's typical authentication pattern, especially shortly after a successful MFA event from a different geography.
• Email security tuning: Ensure email gateways follow redirects on all embedded links and inspect the final destination URL, not just the initial hop. The attack chain uses a compromised legitimate site as a relay specifically to evade link-time scanning.

P3 — Within 7 days

• FIDO2 / phishing-resistant MFA migration: Accelerate migration from OTP/TOTP-based MFA (which AitM proxies can intercept in real time) to FIDO2 hardware security keys or platform authenticators with origin binding. FIDO2 authenticators cryptographically bind assertions to the legitimate origin, making AitM proxy interception ineffective.
• Content-based phishing detection: Evaluate and deploy browser-based anti-phishing extensions or SWG content-analysis capabilities that inspect page DOM for BitB patterns (spoofed address bars rendered as HTML elements, iframes loading authentication pages, service worker registration on non-PWA sites).
• Threat intel feed integration: Subscribe to feeds that provide indicators for cloud-platform-hosted phishing infrastructure with rapid subdomain enumeration. Standard domain-reputation feeds are insufficient because the apex domains maintain positive reputation scores.

5. Indicators of compromise

No atomic indicators of compromise are available in the source material. The specific compromised relay domain and workers.dev subdomain are redacted in the source.

Behavioural indicators

6. Detection

Insufficient indicators to author detection rules. The source material describes behaviours and techniques but does not provide specific file hashes, distinctive strings, command-line artefacts, or registry keys that constitute threat artefacts suitable for YARA or Sigma rules. The redacted URLs and subdomains in the source prevent the construction of actionable indicator-based detection.

7. Sources

• Securelist (Kaspersky), "How legitimate cloud platforms enable phishers to bypass MFA," https://securelist.com/cloud-platforms-in-phishing/120832/, published 2026-08-04.

8. Adverse Trace position

Severity: High. This is a mature, multi-stage AitM attack chain that reliably defeats OTP-based MFA — the dominant MFA modality across EMEA financial services — by combining service worker-based traffic interception, the Ultraviolet proxy library, and BitB UI spoofing on infrastructure that domain-reputation controls cannot block at scale. The abuse of legitimate cloud PaaS platforms (Cloudflare, Vercel, Netlify, GitHub Pages) and IPFS gateways is a confirmed, sustained trend (224,984 domains over 12 months, single-sourced to Securelist/Kaspersky telemetry — verify before enforcement). Attribution to a named threat actor is unconfirmed; no MITRE profile is available. The bottom-line risk for EMEA financial services clients is that existing MFA and URL-reputation controls are insufficient against this attack pattern. We recommend prioritising FIDO2 migration (P3, but architecturally the only durable defence), immediate Conditional Access / device-compliance enforcement (P1), and service worker restriction on managed workstations (P1). Adverse Trace will monitor for IOCs from follow-up reporting and client incident engagements and will issue a supplemental advisory if attribution or atomic indicators emerge.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.