Your client has MFA on the VPN. EDR on every server. A green dashboard.

None of it fires.

That’s the pattern behind the latest wave of attacks on CVE-2026-0257, an authentication bypass in the GlobalProtect portal and gateway of Palo Alto Networks PAN-OS. According to the vendor’s advisory, it lets an attacker bypass security restrictions and establish an unauthorized VPN connection. Palo Alto Networks published fixes on May 13, and CISA lists the flaw in its Known Exploited Vulnerabilities catalog.

5 months later, ransomware crews are still getting in with it.

Who is using it, and what happens next

The vendor’s threat brief, updated October 19, names 2 ransomware operators exploiting the flaw: Qilin and Inc. Its investigations have run since early June across 11 sectors, including healthcare, financial services, manufacturing, education and government.

The brief describes the route. Attackers bypass MFA to establish a VPN session. Then they map the network with dual-use remote monitoring and management tools, move laterally over RDP and SMB, and stage tooling for credential theft, data theft and ransomware.

No MFA prompt. The VPN session looks like a user who connected.

The part EDR never sees

In one case in the brief, the attackers went from the VPN gateway straight to the vCenter management appliance. From there they disabled a security control on the ESXi hosts, a setting called execInstalledOnly. Then they used a custom tool to dump credentials offline, directly from a domain controller’s virtual disk.

Think about what that skips. The domain controller never runs the tool. The EDR agent inside it has nothing to see, because the attack happens to the disk file underneath the virtual machine, at the hypervisor layer. The brief says this bypasses in-guest EDR and security controls.

The prize is domain-wide credentials. With those, every Windows system in the client’s estate opens up.

If your detection strategy for a client is EDR plus MFA, this attack walks between the two.

Where to look instead

EDR has no view of the VPN gateway, the traffic between servers or the vCenter login page. Those are exactly the places this attack moves through. So watch them.

Odd VPN sessions. The brief lists device names and hardware addresses tied to the exploit code, including generic names such as DESKTOP-GP01 and GP-CLIENT and placeholder MAC addresses such as aa:bb:cc:dd:ee:ff. It also flags sessions reporting Windows 10 Pro with an empty user domain. A successful connection matching any of those needs escalating today.

RDP and SMB hops. A VPN user who starts opening RDP and SMB sessions to server after server is not behaving like a remote worker. That movement shows up in network and identity data, whether or not an agent sits on the target.

vCenter admin logins from the VPN pool. Most remote staff have no reason to touch vCenter. An administrator login that originates from a VPN address, followed by a change to execInstalledOnly on an ESXi host, is about as clear a signal as you get.

What to do this week

1. Check exposure. The advisory says the flaw affects GlobalProtect portals or gateways with authentication override cookies enabled and a specific certificate configuration. Check that setting on every client firewall.

2. Patch or mitigate. Upgrade to a fixed PAN-OS version, or apply the vendor’s workarounds: a dedicated certificate for authentication override cookies, or turning authentication override off. Users will need to sign in again once after the upgrade.

3. Hunt back to June. Search GlobalProtect logs for successful connections from the device names, MAC addresses and IP addresses listed in the brief. Patching closes the door. It doesn’t tell you who already came through it.

4. Fence off vCenter. Block the VPN address pool from the vCenter management interface, apart from named admin accounts on named jump hosts.

5. Alert on the crossings. Feed firewall and VPN logs into your monitoring alongside identity events, and alert on RDP and SMB sweeps, vCenter admin logins from the VPN pool and ESXi configuration changes.

Steps 1 and 2 are firewall admin work, per client. Step 3 takes longer, because the activity goes back to early June. Steps 4 and 5 are the ones that keep paying off after this CVE is old news.

The outcome: caught on the network and identity side

Do this and the attack stops being invisible. The VPN session gets flagged on the way in. The RDP and SMB sweep shows up in the network data. The vCenter login from the VPN pool raises an alert before anyone touches a virtual disk.

None of that needs an agent on the hypervisor or the gateway. It needs someone watching the network and identity data around them, and patching edge devices on time.

My advice would be to start with clients who run GlobalProtect with authentication override switched on. Check their logs before you check anything else.

This is the work the enhanced.io SOC does across MSP client estates: correlating VPN, network and identity events, then detecting and escalating what doesn’t fit to your team.

Key takeaways

• Qilin and Inc are exploiting CVE-2026-0257, a PAN-OS GlobalProtect authentication bypass, to open VPN sessions past MFA.

• In one case, attackers reached vCenter and dumped domain credentials from a domain controller’s virtual disk, bypassing in-guest EDR.

• The flaw needs authentication override cookies and a specific certificate configuration. Check that setting, then patch or apply the workarounds.

• Hunt GlobalProtect logs back to early June for the indicators in the vendor’s threat brief.

• Watch the places EDR has no view: odd VPN sessions, RDP and SMB hops, and vCenter admin logins from the VPN pool.

About enhanced.io

enhanced.io is a channel-only Open XDR SOCaaS built exclusively for MSPs, with 400+ integrations across endpoint, network, cloud, identity and IoT/OT. We work only through MSP partners and never sell direct to end clients. To talk about how enhanced.io fits your stack, book a partnership conversation with Hannah Lloyd.