JUMPSEC documented an adversary-in-the-middle phishing campaign active through March 2025 against UK industrial workforce logins in engineering, construction, manufacturing, oil and gas, and energy. An adversary-in-the-middle attack sits between the user and the real login host, relaying what the victim types and what the identity provider returns. According to JUMPSEC, BEC emails with malicious PDFs from compromised Adobe and Gamma services pushed targets through CAPTCHA, VPN, bot, and sandbox checks into attacker-controlled reverse-proxy login pages. Those kits harvested credentials and session tokens live, so legacy MFA completed on the proxy path still left the attacker holding a usable session. Public reporting does not name victim organisations, threat-actor groups, or affected account counts.
If you want the prevention angle, read the related article on mfa2point0.com.
FAQ
How did the JUMPSEC UK industrial AiTM campaign defeat workforce MFA at login?
The JUMPSEC UK industrial AiTM campaign defeated workforce MFA by completing the full login through an attacker reverse proxy rather than on a trusted origin. According to JUMPSEC, the kits impersonated legitimate login sites, intercepted and relayed credentials in real time, and captured both the victim login material and the session token as the identity provider issued it. OTP, push, SMS, or other transferable MFA still satisfied the real backend because the proxy finished the ceremony for the attacker. The session cookie that followed is what kept access alive after the login page closed.
What delivery path put UK industrial staff on the fake login?
UK industrial staff reached the fake login through business email compromise messages that carried malicious PDFs. JUMPSEC reported that threat actors used compromised legitimate services, including Gamma App and Adobe, to send those emails. Victims who cleared Cloudflare CAPTCHA, VPN, bot, and sandbox checks were redirected to the attacker-controlled AiTM proxy. Public reporting does not establish a device-code OAuth path for this campaign.
If we see logins from JUMPSEC's malicious IPs, what is compromised?
Login events from the malicious IPs JUMPSEC published indicate a compromised account, not a clean false positive to ignore. According to JUMPSEC, those events require immediate investigation, credential resets, and session revocation. The kit already held a live session token from the proxied login, so password changes alone leave residual authenticated access until sessions are killed. Treat every hit on that IP list as an identity incident until both credentials and sessions are cleaned.
Did this campaign need malware on employee PCs to steal sessions?
No. Public reporting on the JUMPSEC UK industrial AiTM campaign describes remote reverse-proxy harvest at the login path, not endpoint malware as the way session tokens were first obtained. The kit captured cookies or tokens during the live relay while the user authenticated. Malware on an already-logged-in PC is a harder, separate problem. Closing the phishable login stops this path; revoke remains hygiene after any token is already out.
Were named companies or victim counts published for this wave?
Public reporting does not establish named victim organisations or affected account or record counts for the JUMPSEC UK industrial AiTM wave. JUMPSEC described numerous industrial-sector targets, predominantly in the UK and also in the US, across engineering, construction, manufacturing, oil and gas, and energy. No ransom or extortion figures appear in the advisory. Defenders still get concrete response value from the published TTPs and the malicious-IP login guidance on JUMPSEC Labs' GitHub.
