惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园 - 聂微东
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
L
LangChain Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 司徒正美
WordPress大学
WordPress大学
T
The Blog of Author Tim Ferriss
Blog — PlanetScale
Blog — PlanetScale
J
Java Code Geeks
Y
Y Combinator Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
GbyAI
GbyAI
Vercel News
Vercel News
大猫的无限游戏
大猫的无限游戏
T
Tailwind CSS Blog
Jina AI
Jina AI
B
Blog
Recorded Future
Recorded Future
MyScale Blog
MyScale Blog
I
InfoQ
aimingoo的专栏
aimingoo的专栏
博客园_首页
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
The Cloudflare Blog
雷峰网
雷峰网
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
腾讯CDC
爱范儿
爱范儿
Last Week in AI
Last Week in AI
博客园 - 三生石上(FineUI控件)
博客园 - Franky
Schneier on Security
Schneier on Security
V
V2EX
TaoSecurity Blog
TaoSecurity Blog
H
Hacker News: Front Page
Cloudbric
Cloudbric
D
DataBreaches.Net
B
Blog RSS Feed
P
Palo Alto Networks Blog
云风的 BLOG
云风的 BLOG
NISL@THU
NISL@THU
I
Intezer
Recent Commits to openclaw:main
Recent Commits to openclaw:main
Cyberwarzone
Cyberwarzone
F
Fortinet All Blogs
D
Darknet – Hacking Tools, Hacker News & Cyber Security
C
Cybersecurity and Infrastructure Security Agency CISA
C
Cisco Blogs
K
Kaspersky official blog
Forbes - Security
Forbes - Security

Okta Security RSS Feed

OpenSSL HollowByte: A DoS Hiding in 11 Bytes Datadog and Okta Combine for New Customer Detections Detecting OpenClaw at Sign-In Okta Hardening Guide Updated to Secure Non-Human Identities Okta Pooled Security Audits: a One-Year Retrospective Account Recovery, without Password Resets Okta’s Response to React2Shell Attackers Target Hotelier Accounts in Malvertising and Phishing Campaign Using Auth0 Logs for Proactive Threat Detection Controlling Cross-App Data Sprawl in Google Workspace How this ClickFix campaign leads to Redline Stealer Paving the Path: Pooled Audits with Okta Security Building Confidence in Support Comms with Caller Verify at Okta Enabling ISO/IEC 27001:2022 Compliance with Okta Okta’s Secure by Design Pledge - One Year On Leveraging Okta System Logs for Proactive Threat Detection Enhancing Customer Trust Through a Comprehensive Audit Program Okta's new Security Technical Implementation Guide (STIG) A Guide to DORA Compliance with Okta How AI services power the DPRK’s IT contracting scams Detect and Prevent Cross Device Authentication How Responsible Disclosures are Shaping a Safer Cyberspace Cybersecurity’s Next Gen Next.js CVE-2025-29927 CSO Conversations: Matthew Hansen, Regional CSO of Americas West Empowering Security with Customer Trust Solutions Putting Security First with Secure Development One trick finds the root of any Okta troubles CSO Conversations: Stephen McDermid, Regional CSO of EMEA Content-Security-Policy in a Complex Environment CSO Conversations: Keiko Itakura, Regional CSO of Japan How Okta Embraces Identity Verification Using Persona CSO Conversations: Matt Immler, Regional CSO of Americas East Raising the Bar for our Industry with IPSIE Cyber-Safety over the Holidays Okta Social Engineering Impersonation Report - Response and Recommendation Five Reasons to Upgrade your Org to Okta Identity Engine Okta’s Ongoing Commitment to Secure By Design Unveiling the Essence of the Security Customer Trust Function Security Education Through the Art of Storytelling Seven Ways to Reduce Super Admins in Okta The Case for Zero Standing Privileges FastPass: The battle-hardened authenticator Detecting Cross-Origin Authentication Credential Stuffing Attacks How to Block Anonymizing Services using Okta Why Cyber-heroes need a Zero Trust CAEP! Okta Verify Vulnerability Disclosure Report - Response and Remediation Defensive Domain Registration is a Mug’s Game Protecting Administrative Sessions in Okta How to Secure the SaaS Apps of the Future Okta October 2023 Security Incident Investigation Closure October Customer Support Security Incident - Update and Recommended Actions Unauthorized Access to Okta's Support Case Management System: Root Cause and Remediation Tracking Unauthorized Access to Okta's Support System Go “Secure by Default” With Custom Admin Roles for IT support staff Cross-Tenant Impersonation: Prevention and Detection BYO Telephony and the future of SMS at Okta Saying “No Thanks” to nOAuth Telling More Okta Detection Stories with Google Chronicle An Unexpected Endorsement for WebAuthn Social Engineering is Getting More Extreme, but the Fixes Can Be Simple Study up on Okta Logs for Splunk’s Boss of the SOC! Keeping Phishing Adversaries Out of the Middle Using Workflows to Respond to Anomalous Push Requests Okta and Splunk Combine to Detect Common Attacks Setting the Right Levels of Assurance for Zero Trust Catch-All's and Canary Rules User Sign-in and Recovery Events in the Okta System Log Okta Code Repositories Detecting Real-Time Phishing Attacks Detecting Real-Time Phishing Attacks Okta’s Response to OpenSSL Security Update Monitoring for Abuse of Administrative Privileges System Log: a Window into Supporting the Okta Cloud The Human Factor in Phishing Resistance Auth0 Code Repository Archives From 2020 and Earlier Phishing Resistance and Why it Matters Detecting Scatter Swine: Insights into a Relentless Phishing Campaign Defending against Session Hijacking Unlocking the Mystery of 700+ Okta System Log Events Official Okta Statement on LAPSUS$ Claims Protection, without perimeters We (still) need to talk about RDP Just How Risky is Legacy Authentication?
Uncloaking VoidProxy: a Novel and Evasive Phishing-as-a-Service Framework
Houssem Eddine Bordjiba · 2025-09-11 · via Okta Security RSS Feed

Okta Threat Intelligence has published a detailed analysis on a previously unreported Phishing-as-a-Service (PhaaS) operation, which its authors name VoidProxy.

VoidProxy is a novel and highly evasive service used by attackers to target Microsoft and Google accounts. The service is also capable of redirecting accounts protected by third-party single sign-on (SSO) providers like Okta to second-stage phishing pages. 

VoidProxy represents a mature, scalable and evasive threat to traditional email security and authentication controls. 

The service uses Adversary-in-the-Middle (AitM) techniques to intercept authentication flows in real-time, capturing credentials, MFA codes and any session tokens established during the sign-in event. This capability can bypass the protection of several common MFA methods, such as SMS codes and one-time passwords (OTP) from authenticator apps.

By offering this sophisticated PhaaS, VoidProxy lowers the technical barrier for a wide range of threat actors to execute AitM phishing attacks. Accounts compromised using PhaaS platforms facilitate numerous malicious activities such as Business Email Compromise (BEC), financial fraud, data exfiltration and lateral movement within victim networks.

In all attacks we observed, users enrolled in phishing-resistant authenticators (in this case, Okta FastPass) were unable to share credentials or sign-in via VoidProxy infrastructure, and were warned that their account was under attack.

The VoidProxy platform has been able to evade analysis until this point by using multiple layers of anti-analysis features, including compromised email accounts, multiple redirects, Cloudflare CAPTCHA challenges, Cloudflare Workers and dynamic DNS services. Our understanding of VoidProxy arose from Okta’s unique ability to detect and alert on phishing attacks in customer environments where FastPass is used, as well as the dedicated work of our threat analysis and research team. 

Below, we summarize each anti-analysis technique, analyze the attacker’s infrastructure, and offer recommendations to defend against this threat. A complete threat advisory, available to Okta customers at security.okta.com, also includes:

  • An in-depth, 20-page analysis of VoidProxy PhaaS infrastructure

  • A peek inside the attacker’s admin panel

  • Indicators of Compromise that identify threat actors known to be using the service. These indicators have been uploaded to Identity Threat Protection, a service that enables Okta customers to take in-line responses to user interactions with this infrastructure. 

A VoidProxy attack, step-by-step

Stage 1: Delivery and lure

In the first phase of attacks we observed, phishing lures were sent from compromised accounts of legitimate Email Service Providers (ESPs) such as Constant Contact, Active Campaign (Postmarkapp), NotifyVisitors, and others, leveraging the reputation of these accounts to bypass spam filters.

Embedded in each phishing email were links to URL shortening services (such as TinyURL), which would each be redirected a number of times before the user is directed to first-stage landing sites in order to evade automated analysis.

Figure 1. URLscan data showing the redirects from a tinyurl link to the phishing domain

These first-stage phishing pages are hosted on domains registered with a variety of low-cost, low-reputation TLDs, such as .icu, .sbs, .cfd, .xyz, .top, and .home. This strategy minimizes operational costs and allows the attackers to treat the domains as disposable assets, quickly abandoning them once they are identified and blocklisted. The phishing sites are placed behind Cloudflare, effectively hiding the real IP address of the phishing site's server and making it much harder for security teams to trace and take down the malicious host.

Stage 2: Evasion and lure loading

Before any first-stage landing sites load, the user is presented with a Cloudflare CAPTCHA challenge to determine if the request is from an interactive user or a bot.

Figure 2. Cloudflare CAPTCHA challenges presented on a phishing domain

The targeted user’s browser then communicates with a Cloudflare Worker (*.workers.dev). We assess that this worker is likely to act as a gatekeeper and lure loader. Its primary functions are to filter incoming traffic and to load the appropriate phishing page for any given target. This architecture separates initial filtering from the core phishing operations of the campaign. Once a challenge is passed, the user is presented with a phishing page, which is a perfect replica of a legitimate login portal.  First-stage phishing sites follow a consistent domain registration pattern, as described in the captions below:

Figure 3. Domain pattern for Microsoft phishing pages: login.<phishing_domain>.<tld>

Figure 4. Domain pattern for Google phishing pages: accounts.<phishing_domain>.<tld>

Any attempt to access the site using automated scanners or other security tools redirects the user to a generic “welcome” page with no further functionality.

Figure 5. Phishing domain showing “Welcome!” page

Stage 3: Second stage landing pages

After a targeted user enters their primary Microsoft or Google credentials on the phishing page, the data is sent to VoidProxy’s core AitM proxy server. It’s here that the sophisticated, multi-layered nature of VoidProxy comes into play.

Federated users are redirected to additional second-stage landing pages after providing primary  credentials for their Microsoft or Google account. Non-federated users are redirected to Microsoft and Google servers directly via the proxy infrastructure.

Targeted User Account

First-Stage Phishing Page

Second-Stage Phishing Page

Requests Proxied To:

Local Microsoft account

Landing page impersonates Microsoft at: login.<phishing_domain>.<tld>

None

Microsoft servers

Local Google account

Landing page impersonates Google at: accounts.<phishing_domain>.<tld>

None

Google servers

Microsoft account federated to Okta for SSO

Landing page impersonates Microsoft at: login.<phishing_domain>.<tld>

Landing page impersonates an Office 365 SP-initiated flow with Okta at: newnewdom<randomstring>.<phishing_domain>.<tld>

Okta servers

Google account federated to Okta for SSO

Landing page impersonates Google at: accounts.<phishing_domain>.<tld>

Landing page impersonates a Google SP-initiated flow with Okta at: securedauthxx<randomstring>.<phishing_domain>.<tld>

Okta servers

Figure 6. VoidProxy redirects to a mix of first and second stage landing pages depending on account configuration.

Figure 7. Domain pattern for second-stage Microsoft phishing pages: newnewdom<randomstring>.<phishing_domain>.<tld>

Figure 8. Domain pattern for second-stage Google phishing pages: securedauthxx<randomstring>.<phishing_domain>.<tld>

Stage 4: AitM relay and session hijacking

In the next stage of the phishing attack, a core proxy server hosted on ephemeral infrastructure executes an AitM attack. 

The server acts as a reverse proxy to capture and relay information — including usernames, passwords, and MFA responses — to legitimate services like Microsoft, Google, and Okta. When the legitimate service validates the authentication and issues a session cookie, the VoidProxy proxy server intercepts it. A copy of the cookie is exfiltrated and made available to the attacker via their admin panel. The attacker is now in possession of a valid session cookie and can access the victim's account.

VoidProxy infrastructure

The operational infrastructure of VoidProxy is a combination of disposable, high-turnover frontends and a more persistent, resilient backend hosted on serverless architecture.

Our threat advisory contains a detailed analysis of the naming patterns of both page domains and Cloudflare Worker endpoints, all of which strongly suggest an automated or semi-automated provisioning system for customers of the Phishing-as-a-Service platform (threat actors who rent access to it) that provides both a layer of isolation between these customers and another form of obfuscation that (until now) made it difficult for researchers to link all activity to a single controlling entity. 

The core of VoidProxy's operation is hosted on servers accessed via dynamic DNS wildcard services sslip[.]io and nip[.]io. These services are designed to resolve hostnames with embedded IP addresses directly to those IPs. 

This ephemeral infrastructure is used to host:

  • The VoidProxy AitM proxy engine: the server that performs the actual adversary-in-the-middle attack, relaying traffic between the victim and the legitimate service to steal session cookies.

  • The attackers’ admin panel: the hosting of a web panel that PhaaS customers use to configure campaigns, monitor victims in real-time and access stolen data.

VoidProxy offers a full-featured administrative panel that allows PhaaS customers to manage and monitor their campaigns.

Figure 9. VoidProxy admin login page

Once a user logs in, they have access to numerous pages for campaign management including:

  • An account-level dashboard (see image below)

  • An account-level settings page (see image below)

  • A campaign management page

  • A dashboard for each campaign

Figure 10. VoidProxy admin panel dashboard

Figure 11. VoidProxy admin panel settings

These pages provide a view of what target services can be impersonated using the kit, how stolen secrets are extracted (via manual downloads or real-time notifications via Telegram Bot Tokens or Webhook URLs), and what other third party tools can be integrated into phishing operations.

Recommendations

  • Enroll users in strong authenticators such as Okta FastPass, FIDO2 WebAuthn (passkeys and security keys), and smart cards and enforce phishing-resistance in policy. 

  • Restrict access to sensitive applications to devices that are managed by Endpoint Management tools and protected by endpoint security tools. For access to less sensitive applications, require registered devices that exhibit indicators of basic hygiene

  • Deny or require higher assurance for requests from rarely-used networks. 

  • Identify requests for access to applications that deviate from previously established patterns of user activity (for example, using Okta Behavior and Risk evaluations). Policies can be configured to step-up or deny requests using this context.

  • Train users to identify indicators of suspicious emails, phishing sites and common social engineering techniques used by attackers. Make it easy for users to report potential issues by configuring End User Notifications and Suspicious Activity Reporting.

  • Respond in real-time to user interactions with suspicious infrastructure by automating remediation flows (using Okta Identity Threat Protection, for instance). 

  • Apply IP Session Binding to all administrative apps to prevent the replay of stolen administrative sessions.

  • Force re-authentication whenever an administrative user attempts to perform sensitive actions (for Okta customers, make sure to enable Protected Actions).

Marga del Val contributed to this research.