11 minhigh
How legitimate cloud platforms enable phishers to bypass MFA
Threat actors are systematically abusing legitimate cloud PaaS platforms and IPFS gateways to host multi-stage adversary-in-the-middle (AitM) phishing infrastructure that bypasses MFA. The attack chain uses compromised websites as disposable relays, Cloudflare Workers for core phishing content, browser service workers with the Ultraviolet proxy library to intercept all tab network traffic, and Browser-in-the-Browser (BitB) spoofing to display trusted URLs while silently capturing credentials and session tokens. Over 390,000 phishing pages on legitimate cloud platforms were identified in 12 months, with reputation-based blocklists proving ineffective against programmatically generated subdomains on trusted apex domains.
Sens:▲ 24h
Detection / Hunteropenrouter
What Happened
Cybercriminals are using popular cloud platforms like Cloudflare, Vercel, and GitHub Pages to host phishing websites that steal passwords and bypass multi-factor authentication (MFA). Because these platforms are trusted and offer free accounts, attackers can create hundreds of phishing pages that security tools won't block without also blocking legitimate users. The attack works in stages: a phishing email leads to a fake CAPTCHA page that collects the victim's email, then redirects to a cloud-hosted page that silently installs a proxy in the browser. This proxy intercepts all traffic, including Microsoft login pages, and captures both passwords and MFA codes. A fake browser window (a technique called Browser-in-the-Browser) displays a legitimate-looking Microsoft URL to trick the victim. Anyone using cloud platforms or Microsoft 365 could be affected. This matters because it defeats MFA, which many organizations rely on as their primary defense. Users should manually type website addresses instead of clicking links, be suspicious of CAPTCHA pages that ask for personal information, and always check the real address bar at the top of the browser rather than trusting pop-up windows.
Key Takeaways
- Threat actors are mass-abusing legitimate PaaS platforms (Cloudflare Workers, Vercel, Netlify, GitHub Pages) and IPFS gateways to host phishing infrastructure, exploiting domain reputation to evade blocklists.
- A multi-stage AitM attack uses compromised sites as disposable relays, Cloudflare Workers for core phishing content, and browser service workers to deploy the Ultraviolet reverse-proxy library for traffic interception.
- The attack combines Browser-in-the-Browser (BitB) UI spoofing with AitM proxying to display a legitimate-looking Microsoft login URL while silently intercepting credentials and MFA session tokens.
- Over 390,000 phishing pages on legitimate cloud platforms were identified in a 12-month period, with pages.dev (24.9%), vercel.app (13.8%), and github.io (13.7%) being the most abused domains.
- Traditional reputation-based domain denylists and HTTPS trust indicators are ineffective; defenders must adopt content-based analysis and inspect the true browser address bar rather than rendered pop-up UI elements.
Affected Systems
- Web browsers (all major browsers supporting Service Workers and HTTPS)
- Microsoft 365 / Azure AD users targeted for credential and MFA token theft
- Cloud platforms: Cloudflare Workers/Pages, Vercel, Netlify, GitHub Pages, IPFS gateways, Wix, Webflow, Microsoft Azure
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Phishing email with plausible pretext (e.g., coworker document review request) directs target to a compromised legitimate website hosting a fake CAPTCHA page
- Credential Harvesting: Fake CAPTCHA collects victim email address, filters bots, and redirects to a Cloudflare Workers subdomain with email embedded in URL hash to evade network detection
- Proxy Establishment: Legitimate CAPTCHA challenge verifies human user, then a service worker is registered in the browser deploying the Ultraviolet proxy library to intercept all tab network traffic
- Session Hijacking: Browser-in-the-Browser (BitB) pop-up displays spoofed Microsoft login URL while AitM proxy intercepts credentials and MFA session tokens routed through the service worker
- Cover-up: Victim redirected to generic SessionExpired error page to minimize suspicion while attacker retains stolen session access
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules or queries are provided in the article. The article includes JavaScript code snippets and URL path patterns from the phishing kit that could be used to develop custom detections.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | The attack is entirely browser-based using standard web technologies (service workers, JavaScript, iframes). EDR agents have limited visibility into in-browser service worker registration and sessionStorage manipulation. No process injection or filesystem artifacts are created on the endpoint. |
| Network Visibility | Medium | Network proxies and gateways can observe traffic to workers.dev and other cloud platform subdomains, and URL path patterns like /q/s8s28 or /sw.js?tab= are detectable. However, SSL/TLS encryption prevents content inspection, and the use of legitimate CDN domains generates high false positive volume. |
| Detection Difficulty | Hard | The attack leverages legitimate cloud platforms with high domain reputation, standard browser APIs (service workers, sessionStorage), and URL hash fragments to avoid server-side detection. Blocking apex domains causes collateral damage to legitimate users. Content-based analysis is required but computationally expensive at scale. |
Required Log Sources
- Web proxy logs (forward and reverse proxy)
- DNS resolution logs
- CASB (Cloud Access Security Broker) logs for cloud platform access
- Browser telemetry or web isolation proxy logs
- Email security gateway logs for initial phishing link detection
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for service worker registration requests containing the path pattern /sw.js with a tab query parameter, as this is characteristic of the Ultraviolet proxy-based phishing kit. If you have web proxy or CASB logs with URL visibility, look for this pattern on cloud platform domains. | Web proxy logs, CASB logs, DNS logs | Execution | Low to Medium — legitimate service worker registrations exist but the specific path and parameter combination is uncommon outside this phishing kit. |
| Consider hunting for URL hash fragments containing email addresses (#[email protected]) in HTTP requests to cloud platform subdomains, as the phishing kit passes victim emails via URL hash to avoid server-side detection. If your proxy logs capture full URLs including fragments, this is a strong indicator. | Web proxy logs with full URL capture, CASB logs | Credential Access | Low — email addresses in URL hash fragments are unusual in normal web traffic to cloud platform subdomains. |
| Consider hunting for JavaScript file requests matching the /z/ONocN/c/ path pattern on any cloud platform domain, as these are Ultraviolet proxy scripts specific to this phishing infrastructure. | Web proxy logs, CASB logs | Execution | Low — this path pattern is specific to the observed phishing kit and unlikely in legitimate applications. |
| Consider hunting for users accessing Microsoft login pages (login.microsoftonline.com) through cloud platform domains (workers.dev, pages.dev, vercel.app) rather than directly, as this indicates traffic is being proxied through an AitM infrastructure. | CASB logs, web proxy logs, SSO/IdP authentication logs with referrer data | Credential Access | Medium — some legitimate applications embed Microsoft login in iframes, but direct navigation from cloud platform subdomains to login.microsoftonline.com via proxy is suspicious. |
| Consider hunting for the session storage key 'uv_tab_id' in browser telemetry or web isolation platform logs, as its presence indicates the Ultraviolet proxy framework is active in the user's browser session. | Browser telemetry, web isolation/isolation proxy logs, EDR with browser extension/script monitoring | Execution | Low — this key is specific to the Ultraviolet proxy library and would not appear in normal browsing sessions unless the user is legitimately using Ultraviolet. |
Control Gaps
- Reputation-based domain denylists cannot block cloud platform apex domains without collateral damage to legitimate users
- SSL/TLS inspection is required to see URL paths and hash fragments but may not be deployed for all cloud platform traffic
- Standard email security gateways may not detect phishing links routed through compromised legitimate websites as disposable relays
- MFA alone does not prevent session token theft via AitM proxy interception
- Browser security models do not prompt users before registering service workers over HTTPS, enabling silent proxy installation
Key Behavioral Indicators
- Service worker registration at path /sw.js with a 'tab' query parameter on cloud platform domains
- URL hash fragments containing email addresses (#[email protected]) in requests to cloud platform subdomains
- JavaScript requests to paths matching /z/ONocN/c/ pattern on cloud platform domains
- Session storage key 'uv_tab_id' indicating active Ultraviolet proxy framework
- Navigation to login.microsoftonline.com originating from workers.dev or pages.dev subdomains rather than direct user navigation
- Post-login redirect to generic error pages named 'SessionExpired' after Microsoft authentication
False Positive Assessment
Medium — The URL path patterns and service worker registration paths are specific enough to have low false positive rates, but the cloud platform domains themselves (workers.dev, pages.dev, etc.) host millions of legitimate projects. Blocking at the domain level would generate high false positives; path-based detection is required for acceptable accuracy.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider blocking the specific URL path patterns (/q/s8s28, /sw.js?tab=, /z/ONocN/c/) at your web proxy or CASB for cloud platform domains if your tooling supports path-based URL filtering.
- Consider evaluating whether your email security gateway can inspect and block links that redirect through compromised legitimate websites to cloud platform subdomains, as this disposable relay pattern is designed to evade direct link blocking.
- If your organization uses conditional access policies, consider evaluating whether restricting Microsoft 365 authentication to expected IP ranges or device compliance states would limit the value of stolen session tokens.
Infrastructure Hardening
- Consider deploying or enhancing web content analysis capabilities that inspect page behavior (service worker registration, proxy script loading) rather than relying solely on domain reputation scores.
- Evaluate whether your CASB or secure web gateway can apply content-based inspection to traffic destined for cloud platform domains (workers.dev, pages.dev, vercel.app, github.io, netlify.app).
- If applicable to your environment, consider implementing FIDO2 hardware security keys for MFA, which are resistant to AitM session token theft unlike OTP-based MFA methods.
User Protection
- Consider rolling out browser security extensions that detect and warn users about service worker registrations from untrusted origins, if compatible with your endpoint management strategy.
- Evaluate whether web isolation or remote browser isolation technology could be deployed for users accessing cloud platform domains, which would contain any service worker-based proxy execution in an isolated environment.
- Consider advising users to always verify the true browser address bar (top of the window, alongside native navigation controls) rather than trusting URLs displayed within pop-up windows or rendered page elements.
Security Awareness
- Consider incorporating guidance into existing awareness programs that legitimate CAPTCHA challenges do not request personally identifiable information such as email addresses; any CAPTCHA requesting an email should be treated as suspicious.
- Consider adding training content about Browser-in-the-Browser (BitB) attacks, emphasizing that attackers can render fake browser windows with spoofed address bars and that only the topmost address bar reflects the true destination.
- Consider reinforcing the practice of manually navigating to authentication portals by typing the URL directly, rather than clicking links in emails, especially for document review or collaboration requests.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping5 techniques
Tactic
Initial Access
Tactic
Execution
Tactic
Stealth
Tactic
Lateral Movement
Tactic
Collection
Additional IOCs
- File Paths:
/sw.js- Service worker script file deployed by the phishing kit on Cloudflare Workers to intercept browser network requests
- Other:
uv_tab_id- Session storage key used by the Ultraviolet proxy framework to track the victim's tab; presence in browser sessionStorage indicates active reverse-proxy phishingSessionExpired- Generic error page name used as post-hijack redirect destination to minimize victim suspicion after successful credential and session token theft