A password alone was enough to sit on a European bank network for months. According to Palo Alto Networks Unit 42, compromised credentials authenticated through a third-party-managed external VPN gateway that did not enforce multi-factor authentication, and that edge failure funded noisy internal reconnaissance until endpoint defenses stopped a remote code execution attempt against a central WSUS server. The bank is not named in the public write-up. How the credentials were first obtained is also not established. What is established is simpler and uglier: workforce VPN access without a second factor turned a single set of secrets into sustained internal presence.
How the third-party VPN accepted compromised credentials
According to Unit 42, 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. Unit 42 authors Antonio Diaz and Ruben Castillo put the failure in plain language: opportunistic actors will take advantage of simple oversights such as missing multi-factor authentication on a VPN or an unpatched edge device.
That is the whole initial-access story the public record supports. There is no reported adversary-in-the-middle kit, no helpdesk Temporary Access Pass handoff, and no named phishing page in this case. The appliance sat at the boundary between the open internet and the bank’s internal network. When it accepted a password (or password-equivalent secret) without a second factor, the session that followed was a legitimate VPN login from the network’s point of view.
Third-party management made the gap harder to notice, not softer in impact. The gateway was part of the bank’s remote-access surface even though another party operated the box. Workforce identity still had to protect that path. It did not. Once the tunnel was up, the attacker did not need a fresh login ceremony for every internal hop that trusted the VPN-connected host.
Unit 42 frames the lesson around configuration, not exotic malware. Missing MFA on the VPN is listed beside unpatched edge devices as the kind of boring miss that still opens real environments. For a financial-services network, boring is expensive. Remote access is where contractors, admins, and employees meet the crown jewels. Leaving that door on single-factor trust is an identity decision, whether or not the appliance badge says “managed by someone else.”
Months of scans, admin password guessing, and share scraping
With VPN access in hand, the actor stayed for several months. According to Unit 42, the activity was noisy: extensive host and network scanning, multiple password-guessing campaigns aimed at administrator accounts, and automated scraping of internal documentation and shares for reconnaissance.
Password guessing against admin accounts is not subtle tradecraft. It is volume against accounts that should never answer to a password alone. If those privileged logins still accepted guessed or reused secrets without a phishing-resistant or stronger second factor, each successful guess would have expanded the attacker’s reach inside the same trusted network path. Unit 42 does not publish a count of cracked admin passwords. It does establish that admin-focused guessing ran repeatedly while the VPN session remained available.
The documentation and share scraping mattered for a different reason. Internal runbooks, architecture notes, and shared drives map where the valuable systems live. Automated collection of that material turns a foothold into a guided tour. Unit 42 does not confirm bulk customer-data exfiltration or publish an affected-record count. The public case stops at reconnaissance access to internal documentation and shares. That limit still leaves a serious exposure: months of reading the bank’s own operational paper trail from an unauthorized VPN seat.
Bank security eventually noticed unusual VPN activity spanning those months and brought in Unit 42. Detection arrived after the long dwell, not before the first login. Credential rotation came after forensics, not as a real-time kill switch on the original gateway authentication.
The bank’s chain held two identity failures, one at the VPN edge and one on administrator accounts. At the edge, any compromised workforce secret could open the VPN because MFA was missing. Deeper inside, administrator accounts remained exposed to prolonged guessing. Closing only one of those gaps would still leave the other. Password-only VPN access gives the attacker time. Password-only admin paths give the attacker elevation. This case had both problems in sequence.
| Control surface | What Unit 42 reported | Why it failed here |
|---|---|---|
| Third-party VPN / gateway | Compromised credentials accepted | No strict auth / missing MFA |
| Administrator accounts | Repeated password-guessing campaigns | Password-only guessing stayed viable |
| Internal docs and shares | Automated scraping for recon | Readable after VPN login |
| WSUS distribution server | RCE attempt | Stopped by endpoint detection |
The WSUS attempt Cortex XDR stopped
The attacker did not stop at reading. According to Unit 42, they attempted remote code execution on a central WSUS software-distribution and configuration-management server. That class of target is attractive because a compromised distribution point can push attacker-controlled packages across a fleet. Cortex XDR detected and contained the unauthorized code execution. Forensics afterward found no persistent foothold.
Unit 42’s hunt covered endpoint telemetry across approximately thousands of systems and logs from dozens of Windows and Linux servers. Investigators reported no additional attacker presence after containment. Leadership rotated compromised credentials and reviewed exposed documentation. The public narrative ends on cleanup and hardening recommendations centered on identity controls for VPNs and third-party gateways, not on a confirmed ransomware detonation or a published extortion demand. No ransom figure appears in the case. No threat group is named.
That endpoint save matters, and it should not rewrite the identity failure that came first. Blocking WSUS RCE prevented a software-supply path inside the bank. It did not un-issue the months of VPN time, the scans, the admin guessing, or the documentation scrape. Those stages were already complete under a session that began with single-factor gateway authentication.
Reading shares after a successful VPN login is post-authentication access. MFA does not reach into an already-open tunnel and redact file shares. Refusing the password-only gateway login, and refusing password-only admin authentication, is what keeps the recon seat from existing. Malware or live-off-the-land abuse on a machine that already holds a legitimate session is a harder, different problem. This case’s documented start was not that harder problem. It was a gateway that treated a compromised secret as enough.
Unit 42’s own line lands cleanly: sometimes the most damaging intrusions begin with the simplest oversights. A third-party edge appliance without strict authentication is exactly that class of oversight. Financial institutions run complex fraud stacks and heavy compliance programs. None of that compensates for a remote-access path that still bows to a lone password.
If you want to skip the attack details and go straight to what can stop this, read the related article on mfa2point0.com: how phishing-proof MFA on bank VPNs and admin paths blocks password-only reuse.
FAQ
How did attackers get into the European bank network in the Unit 42 case?
Attackers got into the European bank network by authenticating with compromised credentials through a third-party-managed external VPN gateway appliance that did not enforce strict authentication, including multi-factor authentication. According to Unit 42, that gateway origin produced unauthorized VPN access to internal systems. Public reporting does not establish how the credentials were first stolen or guessed.
Did the Unit 42 European bank intrusion involve confirmed customer data theft?
Unit 42 does not confirm bulk customer-data exfiltration or publish an affected-record count for the European bank case. The documented data access is automated scraping of internal documentation and shares used for reconnaissance during several months of VPN access. Credential rotation and review of exposed documentation followed the investigation.
Why did missing MFA on the VPN matter more than the later WSUS block?
Missing MFA on the VPN mattered because it allowed the initial unauthorized session that funded months of scanning, administrator password guessing, and documentation scraping before any WSUS activity. Cortex XDR later blocked remote code execution on the central WSUS server and forensics found no persistent backdoor, but those controls acted after the identity failure at the gateway had already granted a long internal seat.
Were administrator accounts part of the European bank attack chain?
Yes. According to Unit 42, while holding VPN access the attacker ran multiple password-guessing campaigns focused on administrator accounts over several months. Those campaigns sat on top of the same unauthorized remote-access path and targeted privileged workforce logins that still answered to guessed passwords.
What did Unit 42 recommend after the European bank investigation?
Unit 42’s public case stresses enforcing strong authentication and identity controls on VPNs and third-party-managed gateways so missing MFA and similar edge oversights stop being easy entry points. The bank rotated compromised credentials after forensics across roughly thousands of endpoints and dozens of servers showed no remaining attacker foothold beyond the contained WSUS attempt.
