A single workforce secret was enough to sit on a European bank network for months because the third-party VPN gateway never demanded a second factor. According to Palo Alto Networks Unit 42, compromised credentials authenticated through that external appliance, then funded noisy scanning, administrator password guessing, and automated scraping of internal documentation before endpoint defenses blocked a WSUS remote code execution attempt. Enforcing phishing-proof device-bound MFA on the corporate VPN, third-party gateway, and admin logins would have stopped password-only reuse at the edge and blocked pure password guessing from producing privileged access.
What Unit 42 reported at the bank edge
According to Unit 42 authors Antonio Diaz and Ruben Castillo, the intrusion originated through a third-party-managed external gateway appliance that was not properly configured to enforce strict authentication. The attacker signed in with compromised credentials and reached internal systems over that VPN path. Public reporting does not name the bank, does not establish how those credentials were first obtained, and does not confirm bulk customer-data exfiltration or an affected-record count.
What the case does establish is simpler. Over several months the actor ran extensive host and network scans, multiple password-guessing campaigns aimed at administrator accounts, and automated scraping of internal documentation and shares for reconnaissance. They then attempted remote code execution on a central WSUS software-distribution server. Cortex XDR contained that attempt. Forensics across roughly thousands of endpoints and dozens of Windows and Linux servers found no persistent foothold. Leadership rotated compromised credentials and reviewed exposed documentation.
Unit 42 frames the miss bluntly: opportunistic actors take advantage of simple oversights such as missing multi-factor authentication on a VPN or an unpatched edge device. The bank is not publicly named, and no threat group is attributed. The identity failure still is.
If you want more detailed information about this attack, read the related post on legacymfa.sucks: third-party VPN without MFA and months of bank network recon.
Why password-only VPN and admin paths failed
The first failure sat at remote access. The third-party gateway treated a compromised password (or password-equivalent secret) as sufficient proof of workforce identity. From the network’s point of view the tunnel that followed was a legitimate VPN session. No reported adversary-in-the-middle kit, helpdesk recovery handoff, or spoofed login page appears in Unit 42’s write-up. The public record supports a greyer, more common story: edge authentication that never required a second factor at all.
Third-party operation of the appliance did not shrink the blast radius. The box still sat on the bank’s remote-access surface. Contractors, admins, and employees meet crown-jewel systems through that path. When the gateway accepts a lone secret, every later hop that trusts the VPN-connected host inherits that trust. Detection of unusual VPN activity arrived after months, not before the first successful sign-in. Credential rotation followed forensics, not the original gateway authentication.
The second failure sat on privileged accounts inside the same seat. While holding VPN access, the attacker ran repeated password-guessing campaigns focused on administrator logins. Guessing is not subtle. It is volume against accounts that should never answer to a password alone. Unit 42 does not publish how many admin secrets fell. It does establish that admin-focused guessing ran for months while the unauthorized tunnel remained available. Password-only VPN access bought time. Password-only admin paths offered elevation. Closing only one gap would still leave the other.
After a successful VPN login, automated reading of internal documentation and shares is post-authentication access. No login factor reaches into an already-open tunnel and redacts file shares. The WSUS remote code execution attempt is likewise outside interactive authentication. Cortex XDR stopped unauthorized code execution on the distribution server; that is endpoint and patch territory, not a second factor on a sign-in form. The identity lesson is upstream: refuse the password-only gateway session and refuse password-only admin authentication so the recon seat never exists.
| Control surface | Unit 42 finding | Identity gap |
|---|---|---|
| Third-party VPN gateway | Compromised credentials accepted | Missing MFA / weak strict auth |
| Administrator accounts | Months of password guessing | Privileged logins still password-viable |
| Internal docs and shares | Automated recon scraping | Readable after VPN login |
| Central WSUS server | RCE attempt blocked by XDR | Endpoint control, not login MFA |
How phishing-proof MFA closes the gateway path
Device-bound, origin-bound authentication changes the edge math. On a phishing-proof identity path there is no transferable password for an attacker to reuse on the third-party VPN, and no OTP, SMS code, or push approval for anyone to relay, fatigue, or read out. The private key stays on the enrolled device. The server holds only public material. A stolen or guessed password string is not enough to complete workforce sign-in on that gateway.
The same hardware-bound requirement closes the administrator password-guessing path. Pure password guessing fails when privileged logins demand a fresh hardware-bound signature from an already-enrolled device. Weak or reused admin passwords stop being a usable second path once the login ceremony has nothing transferable to spray. That is prevention, not detection: the unauthorized VPN seat and the admin foothold never form, so months of scanning and share scraping never start from that identity failure.
Once a legitimate VPN session already exists, reading internal documentation is session-stage work. MFA does not revoke file-share access mid-tunnel. Stopping a WSUS remote code execution attempt is endpoint containment. Malware or live abuse on a machine that already holds a good session is a harder, different problem. Unit 42’s documented start was not that harder problem. It was a gateway that treated a compromised secret as enough, then admin paths that still answered to guessing.
For banks, third-party-managed appliances are still workforce identity. Configuration ownership can sit with a vendor; authentication policy cannot. Require phishing-proof factors on every external VPN and gateway that reaches internal systems, including boxes another party operates. Require the same class of factor on administrator and other privileged workforce logins so prolonged guessing cannot mint admin access from inside a stolen seat. Shortening session lifetime after the fact only forces the attacker to re-authenticate sooner. It does not fix a gateway that never asked for a second factor in the first place.
| Attack stage | Password-only path | Device-bound phishing-proof path |
|---|---|---|
| Third-party VPN sign-in | Compromised secret opens tunnel | No transferable factor to reuse |
| Admin password guessing | Guessed secret can elevate | Hardware signature required |
| Doc and share scraping | Possible after VPN login | Seat never granted by password |
| WSUS RCE attempt | Endpoint/EDR problem | Still endpoint/EDR problem |
A generic enterprise IdP that issues only hardware-bound signatures illustrates the login act cleanly: the user approves on the enrolled device, the private key never leaves hardware, and the gateway receives a signature bound to that authentication request. There is nothing useful to spray from a password list and nothing useful to paste into a remote VPN form.
Passkeys and FIDO2 for remote access
Passkeys and FIDO2 put a key pair on the device and keep the private key inside hardware. Signatures are origin-bound, so a lookalike host cannot complete the ceremony the real gateway expects. Industry language calls that phishing-resistant at the login act. For a bank VPN, that means a password spray or a reused secret alone cannot finish remote access when the gateway demands a device-bound assertion. Illustrate it on a generic enterprise IdP that only accepts hardware-bound signatures, not on a consumer login brand. The private key never transits the network, and the server stores public keys only.
Where enrollment still reopens the door
This Unit 42 case is not a documented enrollment or helpdesk recovery failure. The public gap is missing MFA on the VPN and password-viable admin paths. Still, FIDO2 and passkeys harden authentication only. If device onboarding or recovery falls back to email codes, SMS, or other transferable secrets, an attacker who controls that channel can enroll their own authenticator and later sign requests that look legitimate. Phishing-proof coverage means no phishable factor at registration, device onboarding, authorisation, authentication, or decommissioning. On third-party gateways, that full lifecycle matters as much as the login checkbox: a hardened VPN sign-in with a soft enrollment path recreates a transferable factor under another name. The enrolment model has to match the login strength or the edge win erodes at the next device add.
Key takeaways for defenders
- Require phishing-proof, device-bound MFA on every corporate VPN and third-party-managed external gateway that reaches internal systems.
- Put the same hardware-bound requirement on administrator and other privileged workforce accounts so password guessing cannot elevate.
- Treat vendor-operated edge appliances as in-scope workforce identity, not as someone else’s authentication problem.
- Plan share-access monitoring and WSUS/EDR controls for post-login abuse; login MFA will not redact an already-open tunnel.
- Rotate credentials after investigation, but do not confuse rotation with prevention of the next password-only gateway sign-in.
Unit 42’s line still holds: sometimes the most damaging intrusions begin with the simplest oversights. A bank can run heavy fraud stacks and still lose months to a remote-access path that bows to a lone secret. Close the transferable factor on the gateway and on admin logins before the noisy recon ever starts.
FAQ
Would MFA on the third-party VPN have stopped the Unit 42 European bank intrusion?
Yes for the initial unauthorized seat. According to Unit 42, compromised credentials authenticated through a third-party-managed external gateway that did not enforce strict authentication, including MFA. Phishing-proof device-bound MFA on that bank VPN path would have refused password-only reuse, so the months of internal scanning and documentation scraping funded by that tunnel would not have started from a single compromised secret. How the credentials were first obtained is not publicly established.
Can phishing-proof MFA stop administrator password guessing like the European bank case?
Yes when administrator logins demand a device-bound signature instead of a guessed password. Unit 42 reported multiple password-guessing campaigns against administrator accounts during the unauthorized VPN access. If privileged workforce authentication has no transferable secret to spray, pure guessing cannot mint admin access even when passwords are weak or reused.
Would passkeys alone have been enough on the bank VPN gateway?
Passkeys are phishing-resistant at the login act and would block password-only completion on a correctly enforced gateway. They do not automatically protect enrollment or recovery if those steps still use email codes, SMS, or other transferable factors. MFA 2.0 is phishing-proof across the full identity lifecycle, which closes that enrollment gap passkeys alone leave open.
Does login MFA stop internal documentation scraping after a bank VPN session exists?
No. Unit 42 documented automated scraping of internal documentation and shares after the attacker already held VPN access. Reading shares inside an established session is post-authentication access. Login MFA prevents the password-only seat; it does not redact files mid-tunnel. Data-access monitoring and least privilege still matter after sign-in.
Why did blocking WSUS RCE not fix the European bank identity failure?
Cortex XDR contained remote code execution on the central WSUS software-distribution server and forensics found no persistent foothold, but that save came after months of VPN-based reconnaissance. Endpoint containment stops a distribution-server attack path. It does not un-issue the earlier gateway authentication that accepted compromised credentials without MFA. Identity controls on the VPN and admin paths address the failure that created the seat.
