The headline says VoidProxy “uncloaks after you’ve already logged in.” True, and also a little beside the point. The uncomfortable part is that by the time anything uncloaks, it no longer matters — the session token is gone, replayed, and your user is still happily looking at a page that works.
So let’s pressure-test the claim that’s doing all the work here: that VoidProxy is a novel threat. Because the identity industry has now relearned the “MFA doesn’t stop proxies” lesson roughly once per phishing kit — Modlishka, Evilginx2, EvilProxy, Tycoon, and now this — and each time we act surprised.
Is any of this actually new?
The adversary-in-the-middle mechanics are not. Okta’s own research describes the familiar pattern: the victim lands on a lookalike domain, the kit reverse-proxies the real IdP login in real time, relays the password, relays the MFA prompt, and — the whole point — captures the authenticated session cookie the IdP hands back. The user completes MFA correctly. The attacker now holds a valid session. Nothing was “broken.” It was forwarded.
If you deployed phishing-resistant auth because someone told you MFA was dead, you deployed the right thing for a slightly wrong reason. More on that in a second.
What is sharper in VoidProxy is the cloaking. The phishing infrastructure fingerprints every request before deciding what to serve. Security scanners, URL-reputation crawlers, and threat-intel bots get benign filler. Only a request that looks like a real human on a real browser gets wired through to the live proxy. So the domain you submit to VirusTotal comes back clean, because to VirusTotal it was clean.
Why does your blocklist see nothing?
Because detection based on fetching a URL and inspecting what comes back assumes the server answers everyone the same way. It doesn’t. Conceptually:
The decision isn’t in the content. It’s in who’s asking. Your perimeter tooling is, almost by design, exactly the wrong profile to ever see the attack. That’s the real finding, and it’s not specific to VoidProxy — it’s the end of URL-reputation as a load-bearing control.
So what still works?
The honest answer: stop trying to detect the phishing page and start assuming the session cookie will get stolen. Defend the thing the attacker actually walks away with.
- Phishing-resistant auth (FIDO2 / passkeys). This is the one that actually kills the proxy, not just detects it. The WebAuthn assertion is cryptographically bound to the origin the browser sees —
sso-yourcompany.example-login[.]com— which does not match the real IdP’s origin, so the ceremony fails. The attacker can proxy your password and your OTP; they cannot proxy a passkey. If you take one action from this post, it’s enforcingauthenticationStrength/ phishing-resistant policy on privileged and high-value apps. - Token binding / sender-constrained sessions. Where the IdP supports it — Entra’s token protection (preview, needs Entra ID P2, Windows-only today) or DPoP — a stolen cookie replayed from the attacker’s device is worthless because it’s cryptographically tied to the original client. Check the preview and platform limits before you promise anyone coverage.
- Device compliance as a Conditional Access condition. The proxy runs on the attacker’s infrastructure, not your managed, compliant endpoint. Require a managed/compliant device for sensitive access and the replayed session hits a wall it can’t fake.
- Continuous evaluation + impossible-travel / risk signals. CAE revokes mid-session when the context shifts. Sign-in and session risk catch the datacenter IP and the geographic jump. Backstops, not front doors — but they shorten the attacker’s window from weeks to minutes.
The verdict, more precise than the headline: VoidProxy isn’t a new attack, it’s a new evasion wrapper on an old one — and its contribution is proving, again, that scanning for malicious infrastructure is a game you lose quietly. The kit is still rare. The lesson isn’t. Build like the session cookie is already stolen, because the next kit won’t bother to uncloak at all.