Identity and access management provider Okta has discovered what it says is a novel phishing-as-a-service (PhaaS) operation that, if victims fall for an infected email, may get around the 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 awareness training that alerts users to beware of suspicious emails will help blunt the efforts of threat actors who subscribe to the service. Experts also told us phishing-resistant authentication is vital to swat aside phishing attacks aimed at stealing credentials.

However, the discovery is of significance to CSOs who use third party single-sign on providers like Okta, OneLogin, AuthO, Microsoft Azure AD, and Google for login protection.

The criminal phishing service, called VoidProxy, “represents a mature, scalable, and evasive threat to traditional email security and authentication controls,” Okta said in a report Thursday. 

“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 multi-factor authentication (MFA) methods, such as SMS codes and one-time passwords (OTP) from authenticator apps,” the researchers wrote.

“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.”

Service has anti-analysis features

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, Okta said. 

An attack works like this: Phishing lures are sent from compromised accounts of legitimate email service providers (ESPs) such as Constant Contact, Active Campaign (Postmarkapp), NotifyVisitors, and others. The hope is that these message sources will fool spam filters.

If a victim falls for the message, they click on a link that makes use of URL shortening services (such as TinyURL), which would each be redirected a number of times before the user ends up at a first-stage landing site. The goal in the redirects is to evade automated analysis.

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.

The 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. The report says this minimizes operational costs to VoidProxy 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.

The victim user’s browser then communicates with a Cloudflare Worker (*.workers.dev). Okta believes that this worker likely acts as a gatekeeper and lure loader to filter incoming traffic and to load the appropriate phishing page for any given 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 is unwise enough to enter 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, says Okta.

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.

A core proxy server hosted on ephemeral infrastructure executes an AitM attack. This 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.

Shows the risks of SMS and OTP

“The report highlights the risks of old multi-factor authentication types like SMS and one-time password (OTP) codes combined with the theft of session tokens,” commented David Shipley of Canadian security awareness training provider Beauceron Security. “The trick here is ensuring organizational users have fallbacks when more sophisticated approaches like app-based 2FA are unavailable.”

The other trick, he added, is to make the transition to MFA easier and more convenient. “Everyone needs to take a hard look at session token lifespans / re-authentication and revisit notions that it wasn’t needed if people were on premises,” he said.

“The report highlights an interesting role that Cloudflare has been caught in, with criminals using it to hide from security tools,” he noted. “If this trend continues, we may see more pressure on these kinds of providers for the kinds of know-your-customer (KYC) rules we see in the financial services industry.”

Would security awareness training blunt this attack from the beginning? Johannes Ullrich, deal of research at the SANS Institute was doubtful. “Security awareness training has repeatedly been proven to be ineffective,” he said.

Shipley was more optimistic. “An effective security awareness program can reduce the top of the risk funnel, but can’t eliminate it. Our research shows that immediately after training, the chance someone will click on a phish is still 3.5%. After 90 days, the probability is 15%, after 360, it’s a whopping 95%. So [only] annual awareness training isn’t going to cut it.”

Both agreed on the importance of also having phishing-resistant defenses.

“Phishing resistance should be a baseline requirement for authentication,” said Ullrich.

“There are two things that CSOs must know about modern phishing attacks and defenses,” he added. “First of all, authentication methods must be phishing safe. Any method that allows the user to select credentials to enter for a particular site is not phishing-safe. Methods like Passkeys, that automatically match credentials to websites, are phishing safe and should be implemented. Password managers selecting credentials provide some protection, but users are usually able to override that safeguard.

“Second, there is no safe authentication for an actual ‘machine in the middle’ attack, or ‘machine in the browser’ attacks like browser plugins. In this case, attackers are able to obtain post-authentication session credentials, and the actual authentication method is irrelevant.”

Google has been proposing Device Bound Session Credentials, Ullrich noted, but they have not been widely adopted yet. DBSC adds a layer of hardware-backed security (such as a motherboard’s Trusted Platform Module) to ensure sessions are bound to specific devices. Sessions use short-lived cookies. When one of these cookies expires, the browser proves possession of a private key before refreshing them. This process links session continuity to the original device.

Shipley also said it’s time to retire what he called “the misleading term ‘phishing resistant.’ It’s not. Lazy criminals doing bare bones phishing may be deterred, but advanced platforms like this and others include live capture of MFA codes with operators standing by in real time (and with AI agents coming onto the scene, even faster ways to be in the process).” 

“Vendors over-promised on phishing resistant authentication and owe folks an apology,” he added. “More accurate branding would be ‘Lazy phishing resistant’ but that doesn’t sound as good for marketing.”

Recommendations

In its report, Okta recommends CSOs:

• enroll users in strong authenticators such as passkeys, security keys or 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 show indicators of basic cybersecurity 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, using behavior or risk monitoring solutions. Policies can be configured to step-up or deny requests;
• train users to identify indicators of suspicious emails, phishing sites, and common social engineering techniques used by attackers;
• respond in real time to user interactions with suspicious infrastructure by automating remediation flows;
• 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.