A reverse-proxy kit that finishes workforce MFA for the attacker still walks away with a live session. According to JUMPSEC, UK industrial-sector AiTM phishing active through March 2025 relayed passwords and MFA responses on attacker-controlled login hosts and captured session tokens as the identity provider issued them. Phishing-proof, device-bound MFA stops that path: origin-bound signatures never complete on a fake host, so the kit never receives a usable workforce session. Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem. For the full attack chain and delivery path, read the companion on legacymfa.sucks.
FAQ
Would phishing-proof MFA have stopped the JUMPSEC industrial AiTM login?
Yes. The JUMPSEC UK industrial AiTM campaign depended on completing a live credential and MFA relay through an attacker reverse proxy. Phishing-proof MFA 2.0 uses device-bound, origin-bound public-key signatures with no transferable OTP, push, SMS, or email code. The private key never leaves the enrolled device, and the signature is bound to the real login origin, so the proxy path fails before the identity provider issues a session to the attacker. That is prevention, not detection: the kit never holds a workforce session from this path.
Why do stolen session cookies still need revocation after AiTM is closed at login?
Session cookies already captured after a completed login are residual post-authentication access. No login MFA undoes a token the attacker already holds. According to JUMPSEC, login events from the published malicious IPs indicate compromised accounts that need immediate credential resets and session revocation. Phishing-proof MFA's prevention claim is that the reverse-proxy kit never obtains that token in the first place. Revoke remains hygiene when a session is already out, including the harder case of malware on a machine that already held a legitimate login.
Are passkeys enough against this reverse-proxy kit?
Passkeys and other WebAuthn factors are phishing-resistant at the login ceremony because they refuse to sign for the wrong origin, which breaks this AiTM relay at authentication. MFA 2.0 is phishing-proof across the full identity lifecycle: registration, device onboarding, authorisation, authentication, and decommissioning, with no phishable enrollment factor left in the chain. Public reporting on this JUMPSEC campaign does not describe a helpdesk or recovery enrollment path, so the decisive control here is origin-bound login cryptography. Full-lifecycle coverage still matters for the next campaign that targets re-enrollment instead of the login form.
What should industrial CISOs change first on workforce login?
Industrial CISOs should remove transferable factors (password plus OTP, SMS, email code, or push) from workforce login and require device-bound, origin-bound authentication so reverse-proxy kits cannot finish the ceremony. Prefer an enterprise IdP that issues only hardware-bound signatures rather than bolting alerts onto phishable MFA. That is why legacy MFA fails against live relay: the real backend still accepts the proxied factor and mints a session the attacker keeps. Pair the login change with fast session revoke and credential reset playbooks for any account that already shows a login from JUMPSEC's malicious IP list.
What residual risk remains once origin-bound login stops the reverse proxy?
Once origin-bound login stops the JUMPSEC-style reverse proxy, residual risk is a session already issued or malware on a machine that already held a legitimate login. Public reporting does not establish a device-code OAuth path for this campaign, and it does not describe endpoint malware as the way session tokens were first obtained. The kit harvested credentials and session tokens during the live reverse-proxy relay at login. Fooling a user into a proxied login is easy. Planting malware is not. Prevention at the phishable login is the primary claim for this wave; revoke and endpoint controls cover residual cases after a session already exists.
