Uncloaking VoidProxy: a novel and evasive Phishing-as-a- Service framework

Executive Summary

Okta Threat Intelligence has uncovered a novel, sophisticated, and actively deployed Phishing-as-a-Service (PhaaS) platform targeting Microsoft 365 and Google Workspace accounts, which we are tracking as VoidProxy or O-TA-083.

Activity from the VoidProxy PhaaS has been observed since at least January 2025 and new domains and account takeover attempts are being observed daily. The platform is being used to target organizations in multiple industry sectors.

VoidProxy leverages Adversary-in-the-Middle (AitM) techniques to intercept authentication flows in real-time, to capture credentials and multi-factor authentication (MFA) codes, and to steal session cookies, thereby bypassing MFA protections.

This capability renders common MFA methods, such as SMS codes and one-time passwords (OTP) from authenticator apps ineffective. However, Okta offers a choice of authenticators for phishing resistance, including Okta FastPass, which prevented all account takeover attempts from VoidProxy in the attacks we have observed.

The primary objective of VoidProxy is the compromise of corporate accounts to facilitate subsequent malicious activities, such as Business Email Compromise (BEC), financial fraud, data exfiltration and lateral movement within victim networks.

Given its PhaaS model, VoidProxy lowers the technical barrier for a wide range of threat actors to execute AitM phishing attacks, significantly amplifying its potential impact. The platform represents a mature, scalable and evasive threat that challenges conventional email security and authentication controls.

The information in this advisory is provided to enable organizations to understand and mitigate the risks posed by this threat.

Threat Analysis

Anatomy of an attack: The VoidProxy kill chain

The VoidProxy attack methodology follows a multi-stage kill chain designed to systematically bypass security controls and deceive end-users. Each stage is carefully orchestrated, leveraging a distributed infrastructure to achieve its objective of account takeover.

Stage 1: Delivery

The initial vector for a VoidProxy attack is a phishing email targeting users of major cloud services like Microsoft 365 and Google Workspace.

To bypass standard security controls, the operators use legitimate, high-reputation Email Service Providers (ESPs). We observed the use of Constant Contact, Active Campaign (Postmarkapp), NotifyVisitors and others to send their malicious lures. This is a deliberate choice, as emails originating from the trusted IP ranges of such services are less likely to be flagged as spam or malicious by email gateways.

Embedded within these emails is a link that often uses legitimate URL shortener services like TinyURL to conceal the real address of the phishing page. This serves to mask the true destination from both the user and automated scanners, increasing the likelihood that the user will click the link and reach the final destination.

VoidProxy Infrastructure

VoidProxy employs a multilayered approach composed of distinct stages, each with its own specific characteristics.

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

Domain and subdomain patterns

VoidProxy's operators adhere to a consistent set of patterns for infrastructure deployment:

• Phishing domains: The primary landing 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 harder for security teams to trace and take down the malicious host.
• Subdomain prefixes: Analysis of multiple VoidProxy URLs reveals the recurring use of specific subdomain prefixes, notably: accounts, login, portal, securedauthxx and newnewdom. We assess that it is likely these prefixes are generated automatically by the kit's deployment script in order to target patterns used by specific identity providers.

Security filtering using Cloudflare Workers

As described above, the PhaaS platform uses a distributed architecture. Cloudflare Workers (*.workers.dev) acts as an initial gatekeeper, serving the phishing content and performing preliminary checks, such as presenting a Cloudflare CAPTCHA challenge.

An interesting insight into the operational model of the VoidProxy PhaaS comes from the naming convention of its Cloudflare Worker endpoints. After analyzing multiple cases, a consistent pattern emerged: all the Cloudflare Worker endpoints were crafted using the same naming construct. The threat actor has been using plausible-sounding English names like aidenveliz, kelvingomez, and sammybruce in the subdomain:

<alphanumeric>.<firstnamelastname>.workers.dev.

This pattern strongly suggests an automated or semi-automated provisioning system for the PhaaS customers (threat actors who rent the kit). Manually creating and managing unique Cloudflare accounts for each threat actor who bought the kit would be inefficient and difficult to scale. Instead, it is likely that the VoidProxy operators use a master account or API key to programmatically generate this infrastructure. The randomly-generated <firstnamelastname> component likely serves as a unique namespace for a specific customer or a large-scale campaign. The <alphanumeric> prefix then acts as a unique identifier for a specific phishing page instance deployed by that threat actor. This architecture provides a layer of isolation between buyers of the kit and makes it more challenging for researchers to link all VoidProxy activity to a single controlling entity.

Core proxy and C2 infrastructure

The core of VoidProxy's operation - both the AiTM reverse proxy and the attacker's administrative panel - are 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, a feature intended for development that has now been weaponized for malicious purposes.

This infrastructure serves as:

1. AitM proxy engine: This is the server that performs the actual adversary-in-the-middle attack, relaying traffic between the victim and the legitimate service to steal session cookies.
2. Attacker admin panel: These URLs also host the web panel that PhaaS customers use to configure campaigns, monitor victims in real-time and access stolen data.

The use of the "voidproxy" prefix is a self-identifying marker for this C2 infrastructure. This architecture, which separates the initial lure loading on the phishing URL domains from the core logic (*.sslip.io), demonstrates a sophisticated, multi-layered approach designed for operational efficiency and resilience.

Infrastructure used in account takeover activity

Okta Threat Intelligence observed several account takeover attempts following successful VoidProxy phishing campaigns.

Account takeover attempts were successful against users relying on non-phishing-resistant MFA methods (such as OTPs and push requests). The AitM capabilities of VoidProxy allow the attackers to intercept and relay these one-time codes and push notifications in real-time, effectively bypassing the MFA challenge.

By contrast, Okta FastPass successfully prevented all account takeover attempts. FastPass binds the authentication to the legitimate domain and device, making it impossible for AitM proxies to intercept and replay valid session information.

This demonstrates the critical importance of deploying phishing-resistant MFA to effectively mitigate threats from sophisticated PhaaS platforms like VoidProxy.

Following a successful compromise of user credentials, the threat actor(s) were observed attempting to authenticate from IPs that were predominantly hosted on the following ASNs:

• AS36352 - HostPapa
• AS149440 - Evoxt Enterprise
• AS210558 - 1337 Services GmbH
• AS401120 - cheapy.host LLC
• AS23470 - ReliableSite.Net LLC

The VoidProxy admin panel

Analysis of the phishing kit reveals a full-featured administrative panel that allows PhaaS customers to manage and monitor their campaigns. This panel provides a comprehensive interface for orchestrating attacks and collecting stolen data.

Linking VoidProxy to underground identities

After analyzing the campaign, Okta Threat Intelligence researched the underground ecosystem for activity that could link this novel PhaaS platform to a specific threat actor.

The research uncovered a Telegram message dated August 2024 posted on the "BIGFATCHAT™" channel - a channel known for harboring scammers where a user under the moniker VOID was offering a service to "bypass all 2FA".

Threat Response

What we're doing:
We're actively engaged in the following activities to mitigate this threat:

• Continuously monitoring for newly registered phishing domains and infrastructure associated with this campaign.
• Proactively filing abuse reports with relevant registrars and hosting providers to initiate takedown requests for identified malicious sites.
• Feeding a continuous stream of relevant threat indicators into Okta Identity Threat Protection with Okta Al.
• Providing guidance and assistance to organizations to enhance the security of their Okta environments and investigate any suspicious activity related to potentially compromised accounts.

Protective Controls

Recommendations for customers

• Enroll users in strong authenticators such as Okta FastPass, FIDO2 WebAuthn and smart cards and enforce phishing resistance in policy. If any exceptions are made for Okta Verify Push notifications, we recommend enforcing number challenges for all sign-in attempts or for high-risk sign-in attempts.
• Okta authentication policies can also be used to restrict access to user accounts based on a range of customer-configurable prerequisites. We recommend administrators 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 (using Okta FastPass) that exhibit indicators of basic hygiene.
• Deny or require higher assurance for requests from rarely-used networks. With Okta Network Zones, access can be controlled by location, ASN (Autonomous System Number), IP, and IP-Type (which can identify known anonymizing proxies).
• Okta Behavior and Risk evaluations can be used to identify requests for access to applications that deviate from previously established patterns of user activity. 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.
• Document, evangelize and adhere to a standardized process for validating the identity of remote users that contact IT support personnel, and vice versa.
• Take a "Zero Standing Privileges" approach to administrative access. Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles.
• Apply IP Session Binding to all administrative apps to prevent the replay of stolen administrative sessions.
• Enable Protected Actions to force re-authentication whenever an administrative user attempts to perform sensitive actions.

Observing and responding to phishing infrastructure:

• Review application logs (Okta logs, web proxies, email systems, DNS servers, firewalls) for any evidence of communication with any such suspicious domains.
• Monitor the domains regularly to see if the contents change.
• If content hosted on the domain violates copyright or legal marks, consider providing evidence and issuing a takedown request with the domain registrar and/or web hosting provider.