Uncloaking VoidProxy: a Novel and Evasive Phishing-as-a-Service Framework

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.

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

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 7. 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 8. VoidProxy admin panel dashboard

Figure 9. 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.