Ransomware Gangs Are Using a Palo Alto VPN Flaw to Skip MFA and Move Straight to Virtualisation. Would Your Logs Show a Legitimate-Looking Session?

Qilin and INC ransomware operators are exploiting CVE-2026-0257, an authentication bypass in Palo Alto Networks' GlobalProtect VPN, to start VPN sessions without valid credentials and get around MFA. According to Cybersecurity Dive, Palo Alto's Unit 42 tracks the two groups as Spikey Scorpius (Qilin) and Tarnished Scorpius (INC). ReliaQuest also links the flaw to Settra ransomware, and reported activity from several groups on 9 October.

What the flaw does

CVE-2026-0257 sits in the GlobalProtect portal and gateway of PAN-OS. Attackers can establish a VPN connection without a valid login, so the MFA step that normally follows a password is never reached. The flaw is rated 7.8 out of 10 under CVSS v4.0. Palo Alto Networks published fixed builds in May 2026, and CISA added the flaw to its Known Exploited Vulnerabilities catalogue. Public proof-of-concept code followed in late May.

Sources disagree on the exact technical mechanism, including whether attackers forge or replay cookies, so treat any single description of the bypass as provisional until Palo Alto's advisory is checked directly.

What happens after the VPN

The VPN is the entry point, not the goal. Unit 42 describes a sequence that looks like a normal ransomware playbook once inside:

• Pivot to virtualisation. Attackers moved from the compromised VPN to a VMware vCenter management appliance.
• Disable hypervisor protections. They turned off security controls on an ESXi host.
• Steal credentials offline. A custom tool dumped credentials from a domain controller's virtual disk. Because the work happens against a copied disk rather than a live host, it can avoid endpoint detection and response.
• Use common tooling. Cobalt Strike, BloodHound and SharpHound were observed.

Targets include education, financial services, healthcare, IT, manufacturing and government organisations. Arctic Wolf has also tied Qilin affiliates to attacks ranging from rapid encryption to double extortion.

ReliaQuest's warning is the part that matters most for defenders. Because the activity arrives through the VPN, it can look like a legitimate remote session. Credential theft, lateral movement and data theft can all happen before anyone notices. In ReliaQuest's words, the flaw "has become a reliable way into networks for ransomware groups."

What to do now

• Confirm your PAN-OS and GlobalProtect versions against Palo Alto's fixed builds, and treat the exposed portal as a priority asset.
• End existing VPN sessions after patching. Closing the vulnerable entry point does not show whether an earlier session already reached internal systems.
• Hunt backwards from the VPN. Look for new or unusual VPN sessions, especially from unfamiliar addresses, and for logins to vCenter, ESXi and domain controllers from VPN address ranges.
• Alert on hypervisor and directory access. Changes to ESXi security settings, and bulk reads of domain controller disks or NTDS data, are high-signal events.
• Rotate privileged credentials that could have been exposed through a domain controller or hypervisor compromise.

The same pattern of a remote access appliance as the first step is covered in our report on the BeyondTrust remote support zero-day, and on the SafePay ransomware campaign.

Where Obiguard SOC fits

Most of the activity described here happens after the initial login succeeds, which is where a flaw like this is hard to spot. Obiguard SOC correlates VPN authentication events with what follows, including hypervisor configuration changes, privileged account use and bulk credential access on domain controllers. That lets a team see a legitimate-looking remote session that is behaving like an intrusion, and respond before encryption starts.

The question to take away

If a VPN session opened from an unfamiliar address today, would anyone know whether it went on to touch your hypervisor or domain controller?

See how SOC connects VPN activity to what comes next, or talk to us about your remote access logging.