10 minmedium
The Infrastructure Relay: Inside Multi-Stage Phishing Redirection Chains
The article describes two phishing campaigns discovered via VirusTotal monitoring that use multi-stage URL redirection across legitimate cloud platforms and newly registered domains to evade detection. The first campaign abuses the Framer no-code website builder and Cloudflare Workers, using a custom CAPTCHA, Web Crypto API decryption, and HTML5 Blob-based smuggling to assemble a fake Google sign-in page in browser memory. The second campaign chains randomized alphanumeric domains, a .shop domain, and a final newly registered domain to deliver a device code phishing page impersonating OneDrive, with both pages employing anti-debugging JavaScript to hinder analysis.
Sens:▲ 24h
Showing defanged values
- domain2934523t5234535323973294afhdsfga[.]comNewly registered randomized alphanumeric domain (registered 2026-07-01) used as the initial redirect page in the device code phishing chain
- domainalasilla[.]comNewly registered domain (registered 2026-06-10) used to host the final device code phishing page impersonating OneDrive
- domaindase7[.]shopNewly registered domain (registered 2026-02-16) used to host the second-stage secure document portal phishing page
- ip162[.]243[.]24[.]246Hosting IP address observed for the final alasilla.com device code phishing URL
- urlhxxp://2934523t5234535323973294afhdsfga[.]comInitial phishing URL using randomized alphanumeric domain, displays fake 'Preparing Your Documents' loading page
- urlhxxps://alasilla[.]com/frontdeskformationdocusignpaywet/zTlHo9aEUKYakbJYawRlffu6C2imV2To1eOpFinal landing page hosting device code phishing impersonating OneDrive, prompts victim to enter attacker-supplied code at microsoft.com/deviceLogin
- urlhxxps://bl[.]dase7[.]shop/7tr22673862r7436r20348r6243078r627784608263652874635743209043652603485264350263478023352026/3933453326jkjdsbvfvvkzfadfxv[.]html[.]htmlSecond-stage phishing page impersonating a 'Microsoft Private Cloud' secure document portal, redirects to final device code phishing page
- urlhxxps://logangrowthadvisors-rfp-centre[.]framer[.]website/Initial phishing lure page posing as a shared proposal document, redirects victim to next stage
- urlhxxps://stored-plans-hlei[.]w-y9a826[.]workers[.]dev/Cloudflare Workers-hosted second stage presenting a fake CAPTCHA and assembling the final Google sign-in phishing page via Blob API
Detection / HunterAnthropic
What Happened
Security researchers found two email/link-based scams designed to steal login credentials. The first tricks victims into thinking they are viewing a shared business document, then routes them through several fake verification screens before showing a fake Google login page. The second impersonates a Microsoft OneDrive file share and tries to get victims to enter a real Microsoft sign-in code on the attacker's behalf, which would let the attacker access the victim's account without needing a password. Anyone who receives unexpected 'shared document' or 'sign in to view this file' links could be targeted, particularly employees who handle proposals, RFPs, or shared business files. This matters because these scams use trusted-looking hosting services and multiple redirect steps, so most antivirus and security scanners did not initially flag them as dangerous. Users should be cautious with unsolicited document-sharing links and verify device sign-in codes before entering them anywhere, and organizations should consider deploying phishing detection tools that inspect page behavior rather than relying only on known bad domain lists.
Key Takeaways
- Attackers chain multiple hosting layers, including no-code website builders, Cloudflare Workers, and newly registered domains, to add redirection hops between the initial lure and the final credential harvesting page.
- One campaign uses HTML5 Blob API smuggling combined with Web Crypto API decryption to assemble the final phishing page content in browser memory, which can bypass network content inspection that only scans transmitted data.
- A second campaign uses device code phishing impersonating OneDrive/Microsoft, tricking victims into entering a real device code at microsoft.com/deviceLogin to authorize an attacker session.
- Both campaigns implement anti-debugging JavaScript that blocks developer tools shortcuts, disables text selection, and monitors for network inspection tools to hinder analyst review.
- VirusTotal scans at time of discovery showed only a single vendor (the reporting vendor) flagging these URLs as phishing out of dozens of engines, indicating low detection coverage for these techniques at initial delivery.
Affected Systems
- End users receiving phishing emails or links
- Web browsers (Chrome, Edge, Firefox) rendering the phishing pages
- Microsoft 365/OneDrive account holders (device code phishing target)
- Google account holders (credential harvesting target)
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Victim receives or clicks a link to a phishing page hosted on a trusted no-code platform (Framer) or a newly registered randomized domain, disguised as a shared proposal or document notification.
- Redirection Stage 1: Clicking the lure button or continue prompt triggers a JavaScript-driven redirect to a secondary hosting platform (Cloudflare Workers) or a newly registered secondary domain.
- Evasion and Challenge: The secondary page presents a custom or managed CAPTCHA-style challenge and loads anti-debugging JavaScript that blocks developer tools shortcuts, disables text selection, and monitors for network inspection.
- Payload Assembly: In the Framer/Workers chain, encrypted data is decrypted client-side via the Web Crypto API and assembled into the final phishing page content using the HTML5 Blob API and createObjectURL, avoiding direct delivery of the phishing HTML over the network.
- Final Redirect: In the device code chain, a third-stage domain presents a fake 'Secure Document Portal' impersonating Microsoft, which redirects to a final newly registered domain.
- Credential/Session Theft: The final page displays either a fake Google account sign-in form to harvest credentials, or a fake OneDrive share prompting the victim to enter a legitimate Microsoft device code at microsoft.com/deviceLogin, granting the attacker an authorized session without a password.
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
The article does not include YARA, Sigma, Snort/Suricata, KQL, SPL, or EQL detection rules. It describes the vendor's proprietary machine-learning-based URL scanner and heuristic content/behavior analysis as the detection mechanism, without publishing reusable rule logic.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | This activity occurs primarily in the browser via JavaScript and does not involve endpoint file drops, process injection, or binary execution that typical EDR agents would flag, though browser process network connections to unusual domains could still be logged. |
| Network Visibility | Medium | Network proxies and DNS logs can capture connections to the newly registered and cloud-hosted domains, but the use of trusted platforms (Framer, Cloudflare Workers) and Blob-based in-memory content assembly can defeat static content inspection and URL reputation checks that rely on known-bad lists. |
| Detection Difficulty | Hard | The campaigns use trusted third-party hosting, newly registered domains that rotate, multi-hop redirection, and client-side content assembly (Blob API, Web Crypto decryption) that evades static URL and content-based detection, requiring behavioral or heuristic analysis instead. |
Required Log Sources
- Web proxy / secure web gateway logs
- DNS query logs
- Email gateway logs (for initial link delivery)
- Browser history / URL access logs
- TLS/SNI logs for outbound connections
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for outbound web requests to domains registered within the last 30-90 days, especially where the domain resolves to generic-purpose hosting or uses randomized alphanumeric naming. | DNS logs, proxy logs, domain registration age enrichment | Initial Access / Redirection | Medium, as many legitimate new business domains also fall into this window |
| Consider hunting for browser sessions that load pages using blob: URI schemes shortly after visiting an unfamiliar or newly seen domain, which may indicate client-side assembly of phishing content. | Browser history, proxy logs with URL scheme visibility, endpoint browser telemetry | Credential Harvesting / Defense Evasion | Medium, as blob: URIs are used by many legitimate web applications |
| Consider hunting for users being directed to microsoft.com/deviceLogin or similar device code entry pages from an external referring domain not owned by the organization, which may indicate device code phishing. | Proxy/browser referrer logs, Azure AD/Entra sign-in logs showing device code authentication flows | Credential Access / Initial Access | Low to Medium, since legitimate device code flows exist for CLI tools and some enterprise apps |
| Consider hunting for JavaScript that overrides console.log, blocks common developer tool keyboard shortcuts, or disables text selection on pages visited by employees, as these are common anti-analysis patterns on phishing pages. | Web proxy content inspection, browser extension telemetry, threat intel feeds tagging such scripts | Defense Evasion | Low, since legitimate business sites rarely implement these specific combinations |
| Consider hunting for successful Azure AD/Entra ID device code sign-ins that occur shortly after a user visits an external, non-corporate URL, which may indicate a completed device code phishing attack. | Azure AD sign-in logs, conditional access logs, correlated proxy logs | Credential Access / Impact | Low, correlating timing across two log sources reduces false positives |
Control Gaps
- Static domain and URL reputation blocklists alone are insufficient since the campaigns use newly registered domains and trusted cloud platforms not yet flagged as malicious.
- Traditional network content scanning may miss phishing content assembled client-side via Blob API and decrypted via Web Crypto API, since the malicious HTML is never transmitted in plaintext over the wire.
- Standard antivirus/URL scanning engines showed extremely low detection rates (1 of 92 vendors) at time of discovery, indicating a coverage gap across most commercial security vendors.
Key Behavioral Indicators
- Browser navigation to blob: URI schemes immediately following a redirect from a newly registered or unfamiliar domain
- Presence of JavaScript event listeners blocking F12, Ctrl+Shift+I/J/C, and Ctrl+U keyboard combinations on a visited page
- Multiple sequential redirects across different top-level domains and hosting providers within a single browsing session before reaching a credential entry form
- Device code entry prompts referencing microsoft.com/deviceLogin sourced from an external, non-Microsoft-owned domain
False Positive Assessment
Low, the described indicators (specific URLs and newly registered domains) are unlikely to appear in legitimate business traffic, though generic behavioral indicators like blob: URI usage or device code flows have moderate false positive risk since they are also used by legitimate applications.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting; consider blocking or sinkholing the specific URLs identified in this report at the web proxy/firewall level if observed in your environment.
- Consider searching email gateway and proxy logs for any user access to the specific domains and URLs listed in this report to determine if any employees interacted with them.
- If any user is found to have entered credentials or a device code on these pages, consider forcing a password reset and revoking active sessions/tokens for the affected account.
Infrastructure Hardening
- Consider enabling or tuning web proxy/secure web gateway policies to inspect and flag pages that use blob: URI content assembly combined with newly registered domain referrers.
- Evaluate whether your email security and URL scanning tooling incorporates heuristic/behavioral analysis of page content rather than relying solely on static domain reputation.
- Consider implementing DNS or proxy-based alerting for connections to domains registered within a short lookback window (e.g., under 90 days), where feasible for your environment.
User Protection
- Consider deploying browser isolation or link-rewriting technology for external links received via email, if supported by your existing email security stack.
- Evaluate whether your organization can restrict or monitor use of device code authentication flows, since these can be abused to bypass standard credential and MFA prompts.
- Consider enabling conditional access policies in identity providers that flag or block device code sign-ins originating from unusual or unmanaged network locations, if your identity platform supports this.
Security Awareness
- Consider updating phishing awareness training to include examples of 'shared document' and 'secure proposal' lures hosted on legitimate-looking platforms like no-code website builders and cloud worker services.
- Consider training staff to never enter a device code or sign-in code shown on an external website into microsoft.com/deviceLogin or any similar prompt unless they initiated that specific login request themselves.
- Consider reinforcing guidance that a low or single-vendor detection result on a URL scanning site does not guarantee a link is safe.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping8 techniques
Tactic
Resource Development
Tactic
Initial Access
Tactic
Execution
Tactic
Credential Access
Tactic
Command and Control
Additional IOCs
- Ips:
162[.]243[.]24[.]246- Hosting IP address observed for the final alasilla.com device code phishing URL
- Domains:
dase7[.]shop- Newly registered domain (registered 2026-02-16) used to host the second-stage secure document portal phishing pagealasilla[.]com- Newly registered domain (registered 2026-06-10) used to host the final device code phishing page impersonating OneDrive2934523t5234535323973294afhdsfga[.]com- Newly registered randomized alphanumeric domain (registered 2026-07-01) used as the initial redirect page in the device code phishing chain