Enterprise-targeted phishing has migrated from dodgy domains and cheap VPSes to the same cloud platforms that companies trust to run their businesses—Microsoft Azure, Google Firebase, AWS and Cloudflare—and that shift is changing how SOCs detect, investigate, and stop credential theft and MFA bypass attacks. ny.run/malware-trends/tycoon/)
Background
The last 18 months have seen a rapid rise in adversary-in-the-middle (AiTM) phishing kits—reverse proxies that sit between a victim and the real login page, relay credentials and MFA tokens, and capture session cookies. These kits are now commonly hosted on established cloud providers or CDN edges instead of malicious-looking domains, which lets attackers “hide in plain sight” behind legitimate HTTPS, valid certificates, and trusted Autonomous System Numbers (ASNs). Industry reporting and interactive sandbox analyses from vendors such as ANY.RUN, incident write-ups from vendors and researchers, and open reporting on kits like EvilProxy, Tycoon2FA and Sneaky2FA show this is not a niche trick but a repeatable, commercialized tactic.
This article pulls together technical details, operational impacts, and practical detection and response guidance for defenders. It summarizes the current kits and tactics, explains why traditional IOCs are failing, and prescribes an operational playbook SOCs can adopt to fight cloud-hosted AiTM phishing effectively.
Overview of AiTM Kits and How They Abuse Cloud Services
What AiTM phishing kits do, in plain terms
AiTM phishing kits operate as a transparent reverse proxy between the victim and the legitimate service. When a user lands on the phishing page and enters credentials or an MFA code, the kit forwards those requests to the real provider and relays the legitimate responses back to the user—while silently harvesting session cookies, authentication tokens, and one-time codes. With valid session cookies, attackers can often access accounts without repeating the entire authentication flow. This capability has made AiTM the preferred method for stealing corporate accounts protected by typical MFA methods.
Key technical traits:
- Reverse-proxying of live authentication sessions to capture session cookies and tokens.
- Multi-stage redirections and CAPTCHA gates to filter out scanners and automated sandboxes.
- Domain and hosting abuse: infrastructure is placed on cloud platforms (blob storage, Firebase storage, Cloudflare Workers, Google Sites) so network telemetry looks benign.
- Filters to exclude consumer email providers (Gmail, Outlook.com), focusing the attack on business accounts that are more valuable.
The most prominent kits defenders should know now
- Tycoon2FA — A PhaaS (phishing-as-a-service) toolkit focused on bypassing MFA for Microsoft 365 and Google accounts; frequently observed using Azure Blob Storage and other cloud hosting to serve phishing landing pages and CAPTCHA-protected entry points. ANY.RUN and multiple sandbox analyses have documented Tycoon’s proxy logic and its rapid use in enterprise-targeted campaigns.
- Sneaky2FA — First described publicly by Sekoia and subsequently analyzed in sandboxes; distributed as a Telegram-based PhaaS. Sneaky2FA uses blurred interface screenshots, CAPTCHA gating, and modern evasion like Browser-in-the-Browser (BitB) overlays to make pop-ups look native and to keep automated tools out. It has been observed hosted on Firebase and CloudFront in enterprise campaigns.
- EvilProxy (and variants such as VoidProxy/VoidProxy-like kits) — A very active reverse-proxy phishkit marketed to criminals, known for running millions of attacks and for documentation that instructs operators to route reconnaissance and gating through Cloudflare and its Workers/Turnstile protections to avoid detection and resist takedowns. Vendors including Proofpoint and independent reporting have chronicled EvilProxy’s scale and abuse of CDN platforms.
These kits are not hobbyist one-offs; they are commercial services with documentation, support channels (Telegram), and subscription tiers that enable rapid, targeted campaigns.
How Cloud Platforms Make Detection Harder
Trusted hosts, trusted TLS, and disappearing network signals
When phishing landing pages and proxy endpoints are served from legitimate cloud subdomains—blob.core.windows.net, firebasestorage.googleapis.com, or sites.google.com—network logs record a known good provider and a valid TLS certificate. That means:
- IP-based blocks or ASN blocks are ineffective and risk collateral damage.
- TLS-based fingerprints (JA3/JA3S) are less reliable when TLS terminates at CDN edges; the observable TLS handshake reflects the edge node rather than the origin server or the client’s true characteristics. Cloudflare’s edge TLS termination and programmable Workers make the server-side TLS profile generic and shared across customers.
This removes two classic hunting levers—suspicious IPs and odd TLS fingerprints—from everyday detection. What’s left as a reliable starting lead is often the domain and the historical reputation of that domain, but attackers rapidly rotate domains, use legitimate subdomains, or piggyback on genuinely-owned cloud accounts, meaning reputation feeds lag or fail to flag abuse in time.
Anti-analysis gating: CAPTCHAs, Turnstile, geo-blocks, and User-Agent filters
Cloud providers and CDNs offer easy-to-enable gatekeeping features—CAPTCHA widgets, geo-blocking, User-Agent filtering, and rate-limiting—that attackers can programmatically enable on Worker scripts or via simple console settings. These stop automated crawlers and sandboxes, allowing the phishing chain to serve only to human victims. Reports and sandbox captures repeatedly show attackers chaining CAPTCHA steps and anti-bot checks before the final phishing page, ensuring static AV and automated analysis tools rarely reach the malicious stage.
UX-level deception: Browser-in-the-Browser (BitB)
Popular kits now embed Browser-in-the-Browser overlays—an iframe or UI that mimics a genuine browser pop-up window (complete with fake address bars) so users believe they’re interacting with a trusted sign-in prompt. BitB, combined with reverse proxying, makes the victim see a convincing user experience while the attacker relays real authentication flows. BleepingComputer and other analysis write-ups have documented this addition in recent kit updates.
Operational Impacts for Enterprises
Why business accounts are being targeted
Attackers filter out consumer domains and focus on corporate emails because the upside is far larger: business accounts unlock corporate email, calendars, internal files, cloud assets, and admin consoles. Executive accounts are particularly lucrative—EvilProxy and other kits have been used in targeted campaigns against C-suite and finance teams to enable BEC and follow-on extortion.
SOC visibility gaps and false confidence
Organizations that rely heavily on static IOCs—malicious IPs, certificate hashes, known bad domains—are blind to these campaigns until post-compromise signals appear (unusual mailbox rules, unexpected OAuth grants, anomalous file downloads). The use of legitimate cloud domains gives defenders a false sense of safety based on TLS and ASN heuristics. Sandboxes and interactive analysis tools report faster exposure of the full attack chain because they actively simulate human interactions and traverse CAPTCHA gates; vendor-supplied metrics claim dramatic SOC performance improvements when interactive analysis and TI correlation are applied, although such vendor metrics should be treated as vendor-reported outcomes pending independent verification.
Dissecting a Typical Multi-Stage Attack
- Initial lure — The phishing email arrives as a plausible business message (payment receipt, invoice, DocuSign/SharePoint link) or as an embedded PDF/QR code that points the victim to a trusted cloud domain.
- Anti-automation gating — The victim is redirected through CAPTCHA (e.g., Cloudflare Turnstile) or custom image-based checks that block bots and AV sandboxes.
- Target filtering — The kit verifies the provided email. If it’s a consumer address (Gmail, Outlook.com) it redirects to a benign page; corporate addresses are allowed to proceed.
- Browser-in-the-Browser / fake popup — The user sees a realistic-looking sign-in UI that resembles the target service (Microsoft 365, Google Workspace).
- AiTM reverse proxy — The kit relays the real authentication flow, captures credentials, OTPs, and session cookies.
- Post-capture manipulation — The proxy returns “wrong password” prompts, triggers loops, or performs on-the-fly behavior changes to keep the victim engaged while attackers harvest tokens and session cookies for account takeover.
ANY.RUN sandbox runs have repeatedly demonstrated these steps and document sample flows where Azure Blob-hosted pages mimic Microsoft 365 portals, posting harvested data back to the operator’s infrastructure. Defender teams should consider those sandbox-based chains as practical exemplars of what to expect.
Detection and Hunting Playbook for SOCs
Below are practical, prioritized actions SOCs can implement immediately and next steprovements.
Immediate (hours to days)
- Enforce and monitor Conditional Access policies aggressively:
- Block legacy auth where possible.
- Require step-up authentication or device compliance for access to high-value apps.
- Force re-authentication on sensitive actions (password resets, grant of admin roles).
- Hunt for credential-stuffing and session reuse:
- Look for multiple sign-ins from geographically disparate locations using the same session cookie or OAuth token.
- Flag sign-ins with short-lived, rapid retries that mimic proxy-driven loops.
- Scan mail flows for QR-coded PDFs or email attachments containing base64-encoded redirects and suspicious short-lived redirectors.
- Add detection rules to flag the use of cloud storage subdomains in inbound mail links (for example, links pointing to .blob.core.windows.net, .firebasestorage.googleapis.com, .s3.amazonaws.com, .sites.google.com). These are legitimate services—prioritize monitoring and context rather than automatic blocking.
Tactical hunting queries and indicators
- Domain pivoting:
- Search TLS SNI or HTTP host headers for known cloud-hosting patterns combined with suspicious paths (e.g., /signin, /microsoft, /login).
- Behavioral IoCs:
- Repeated identical user interactions that complete CAPTCHAs but produce no downstream data (possible filter gating).
- Session token reuse:
- Monitor for OAuth tokens or session cookies that appear on multiple distinct client IPs or user agents within short windows.
- Email-to-link correlation:
- Cross-check inbound emails that include cloud-hosted links with subsequent anomalous sign-in attempts for linked accounts.
- Cloud worker patterns:
- Look for Worker/Function subdomain traffic that has no prior legitimate baseline (e.g., new *.workers.dev subdomains suddenly receiving inbound clicks from your org).
Medium-term (weeks to months)
- Deploy interactive sandboxing that simulates human interaction (mouse movement, CAPTCHA solving through responsible means) to observe full attack chains rather than relying on static detonation.
- Integrate Threat Intelligence (TI) feeds that focus on extracted phishing indicators (landing-page paths, page screenshots, obfuscated JS signatures) rather than simply domain reputation.
- Implement browser isolation / link protection for email links: open email links inside an isolated remote browser or enforced corporate browser profile to limit potential token capture and reduce risk of credential submission from unmanaged endpoints.
- Enforce hardware keys or passkeys for high-value users. AiTM kits are designed to capture codes and session cookies issued by traditional OTP and authenticator apps; phish-resistant methods such as hardware-bound FIDO2 keys dramatically reduce the attack surface.
Practical Incident Response Steps When a Phish Is Detected
- Assume compromise—contain first:
- Immediately revoke sessions and tokens for any impacted accounts; rotate client secrets and invalidate refresh tokens.
- Search for lateral movement:
- Look for any changes to mailbox rules, forwarding addresses, or OAuth app grants.
- Forensic capture:
- Collect landing page artifacts (HTML, JS) and capture the redirected chain; analyze in a controlled sandbox to extract the real target endpoints and any operator-reported callback destinations.
- Notify cloud provider abuse teams:
- Use the cloud provider’s abuse/reporting channels to request takedown of phishing content hosted under their services; attackers will often move quickly, so this is time-sensitive.
- Post-incident hardening:
- Apply tighter Conditional Access policies, require device compliance, and run targeted phishing simulations for affected teams.
Strategic Recommendations for Leadership and Security Architects
- Move from static IOCs to behavioral detection: invest in analytics that correlate email click patterns, session creation, and OAuth grant activity across time.
- Consider security for SaaS tooling: restrict inbound external content in corporate workflows (e.g., limit auto-accept of third-party app links in mail/calendar invites).
- Require passkeys / FIDO2 for privileged users: policy changes at the identity layer are the most cost-effective way to reduce the value of stolen OTPs and session cookies.
- Establish rapid takedown and legal escalation workflows with major cloud providers and CDNs. While providers make takedown easier than in the past, the speed of rotation demands automated or semi-automated abuse handling.
- Budget for interactive analysis capability in the SOC: vendor case studies show reduced triage time and faster detection when interactive sandboxes and TI correlation are in place—but treat vendor performance claims as one input and validate through pilot deployments.
Strengths and Risks of the New Attack Surface
Notable strengths (for defenders who adapt)
- The shift to cloud platforms is visible: though network signals are blurred, the pattern of abuse—short-lived cloud-hosted landing pages, CAPTCHA gating, and targeted filtering—creates detectable sequences that behavioral analytics can identify.
- Tools exist to close the gap: interactive sandboxes, identity-based conditional controls, and passkeys materially reduce attacker success when properly deployed.
- Centralized cloud governance at scale means providers can remove abuse quickly once detected—if detection is fast enough.
Persistent risks and blind spots
- Speed and scale: PhaaS models and easy-to-provision cloud resources let attackers spin up convincing campaigns in hours, outpacing typical TI updates.
- Human factor: UX-level deception (BitB) and plausible business lures still reliably trick users; notrol will eliminate this.
- TLS & ASN camouflage: TLS termination at the edge and shared provider ASNs reduce the efficacy of network-based fingerprinting and IP-based mitigations. Defenders must not over-rely on those signals.
What We Don’t Yet Know — Claims Needing Caution
Several quantitative outcomes (for example, “+62.7% more threats detected,” “94% faster triage,” “30% fewer escalations”) originate from vendor-published case studies and republished marketing material. These figures describe measured improvements in environments that deployed specific sandboxing + TI stacks; they are useful benchmarks but should be treated as vendor-reported and validated locally before assuming the same results. Use pilot programs and measurement against your own baselines before extrapolating these numbers to your organization.
Similarly, claims like “Tycoon cases on Azure doubled in a week” have been seen in analyst chatter and vendor telemetry snapshots; such trends should be tracked in your own TI and log pipelines rather than adopted as absolute fact without corroboration. Vendor and open-source reporting provides timely signals, but defenders must cross-validate across at least two independent telemetry sources where possible.
Final Verdict: Treat Cloud as a Vector, Not a Safe Harbor
The era when cloud-hosted content implied “safe by default” is over. Attackers have adapted quickly: they use CAPTCHAs, reverse proxies, Browser-in-the-Browser tricks, and legitimate cloud domains to focus on high-value enterprise accounts and bypass the protections defenders leaned on for years. The good news is that defenders have effective countermeasures: harden identity, add behavioral detection, deploy interactive analysis tools, and train users to recognize the new UX-level deceptions. Those measures together restore the asymmetry back toward defenders.
If your organization has not reviewed identity policies, conditional access rules, and phishing simulation programs in the last six months, treat this as an urgent board-level item. The cloud platforms that accelerate your business can also accelerate compromises—unless you invest in the identity-first, behavior-focused defenses that these attacks require.
Source: Cyber Press
https://cyberpress.org/cloud-platforms-target-enterprises/