Identity and access management company Okta has discovered a new phishing-as-a-service (PhaaS), dubbed VoidProxy, that can bypass user account protections from third-party single sign-on providers to steal Microsoft and Google login credentials. However, that's a big "if."
Effective security training , which helps users be on the lookout for suspicious emails , can reduce the efforts of threat actors to sign up for the service. Phishing-resistant authentication is also crucial to deter attacks aimed at stealing credentials.
However, the discovery is significant for CSOs that use providers single sign-on such as Okta, OneLogin, AuthO, Microsoft Azure AD and Google for login protection. The criminal phishing service VoidProxy, “represents a mature, scalable and discrete threat to traditional email and authentication security controls,” Okta said in a report on Thursday.
See also: FBI: Reveals IOCs for hackers targeting Salesforce environments
" The service uses Adversary-in-the-Middle (AitM) techniques to interfere with authentication flows in real time, capturing credentials, MFA codes , and any session tokens generated during the sign-in event. This capability can bypass the protection of several common multi-factor authentication (MFA) methods, such as SMS codes and one-time passwords (OTP) from authentication applications ," the researchers wrote
«By offering this advanced PhaaS, VoidProxy lowers the technical barrier for a wide range of threat actors and enables them to execute AitM phishing attacks. Accounts compromised using PhaaS platforms facilitate a variety of malicious activities such as business email compromise (BEC), financial fraud, data exfiltration , and lateral movement within victims’ networks.».
VoidProxy: How the attack works – Analysis evasion
The VoidProxy platform has managed to evade analysis to this point by using multi-layered anti-analysis features, including compromised email accounts, multiple redirects, Captcha challenges from Cloudflare, Cloudflare Workers, and dynamic DNS services.
An attack works like this: Phishing baits are sent from compromised accounts of legitimate email service providers (ESPs) such as Constant Contact, Active Campaign (Postmarkapp), NotifyVisitors, and others.
If a victim falls for the trap, they click on a link that uses URL shortening (such as TinyURL). Multiple redirects occur before the user reaches the first website. The goal of the redirects is to avoid automated analysis. Before the first website loads, the user sees a Captcha challenge from Cloudflare to determine whether the request is coming from an interactive user or a bot.
See also: Cybersecurity in the Age of Artificial Intelligence
The first phishing pages are hosted on domains registered with a variety of low-cost, well-known TLDs, such as .icu, .sbs, .cfd, .xyz, .top, and .home. The Okta report says this reduces operational costs for VoidProxy and allows attackers to treat the domains as expendable assets, quickly abandoning them once they are detected and blocked. The phishing sites are hosted behind Cloudflare, effectively hiding the actual IP address of the phishing site’s server and making it much harder for security teams to track down and take down the malicious host.
The victim's browser then communicates with a Cloudflare Worker (*.workers.dev). Okta believes this worker likely acts as a gatekeeper and lure loader to filter incoming traffic and load the appropriate phishing page for any target.
Once the Captcha challenge is passed, the user sees a perfect replica of a legitimate Microsoft or Google login portal. 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.
Credentials go to adversary-in-the-middle server
If a victim enters their primary Microsoft or Google credentials on the phishing page, the data is sent to VoidProxy’s primary AitM proxy server. This is where the sophisticated, layered nature of VoidProxy comes into play, Okta says. Federated users are redirected to additional pages after they provide their primary Microsoft or Google account credentials. Non-federated users are redirected directly to Microsoft and Google servers through the proxy infrastructure. A primary proxy server hosted on ephemeral infrastructure executes an AitM attack. This server acts as a reverse proxy to capture and transmit information, including usernames, passwords, and MFA responses, to legitimate services like Microsoft, Google, and Okta.
🔑 Secure your passwords with Proton Pass
Password manager from Proton — end-to-end encryption, passkeys, built-in 2FA, and monitoring for leaks of your credentials.
- ✔ Encrypted storage of passwords & passkeys
- ✔ Notification if any of your passwords are leaked (Dark Web Monitoring)
- ✔ Free version — on all devices
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
When the legitimate service validates the authentication and issues a session cookie, the VoidProxy proxy server steps in. A copy of the cookie is extracted and made available to the attacker via their admin panel. The attacker now has a valid session cookie and can access the victim's account.
See also: Clickfix attack promises “Free WiFi” but distributes malware
The dangers of SMS and OTP
“The report highlights the risks of legacy multi-factor authentication such as SMS codes and one-time passwords (OTPs) combined with session token theft,” commented David Shipley of Canadian security training provider Beauceron Security. “The trick here is to ensure that organizational users have alternatives when more sophisticated approaches such as app-based 2FA are not available.” The other trick, he added, is to make the transition to MFA easier and more convenient.
Could security training have reduced this attack from the start? Johannes Ullrich, head of research at the SANS Institute, is skeptical. “Security training has repeatedly been shown to be ineffective,” he said. Shipley was more optimistic. “An effective security awareness program can reduce the peak risk, but it can’t eliminate it. Our research shows that right after training, the chance of someone clicking on a phishing is still 3.5%. After 90 days, the chance is 15%; after 360, it’s a whopping 95%. So [just] annual training won’t reduce that.”
Both agreed on the importance of having phishing-resistant defenses. “Phishing resistance should be a core requirement for authentication,” Ullrich said. “There are two things CSOs need to know about modern phishing attacks and defenses,” he added. “First of all, authentication methods need to be phishing-resistant. Any method that allows a user to choose credentials to enter on a specific website is not phishing-resistant. Methods like Passkeys, which automatically map credentials to websites, are secure and should be implemented. Password managers provide some protection, but users can usually bypass this security. Second, there is no secure authentication for a true ‘machine in the middle’ or machine in the browser’ attack. In this case, attackers can obtain post-authentication session credentials, and the actual authentication method is irrelevant.”
See also: Apple warns of spyware attacks
Google has proposed Device Bound Session Credentials (DBSC), but they have not yet been widely adopted. DBSCs add a layer of security with hardware support (such as the Trusted Platform Module) to ensure that sessions are associated with specific devices. Sessions use short-lived cookies. When one of these cookies expires, the browser proves possession of a private key before renewing them. This process links the continuation of the session to the originating device.
Recommendations – Protection
In its report, Okta recommends that CSOs:
- require users to use passkeys, security keys or smart card passkeys
- enforce phishing-resistance in policies
- Restrict access to sensitive applications to devices managed by endpoint management tools. For access to less sensitive applications, require registered devices that demonstrate basic cybersecurity health indicators
- deny or require higher security for requests from infrequently used networks
- detect requests for access to applications that deviate from previously established patterns of user activity, using behavioral or risk monitoring. Policies can be configured to enhance or deny requests
- train users to recognize indicators of suspicious emails, phishing websites, and common social engineering techniques used by attackers
- respond in real-time to user interactions with suspicious infrastructure by automating remediation flows
- implement IP Session Binding in all administrative applications to prevent the reproduction of stolen administrative sessions
- force re-authentication every time an administrative user tries to perform sensitive actions
