Breaking into thousands of cloud-based VPNs with one bug

Breaking into thousands of cloud-based VPNs with one bug

Speakers: David Cash, Rich Warren

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=1mTg32BTZlA

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/David%20Cash%20Rich%20Warren%20-%20Zero%20Trust%20Total%20Bust%20-%20Breaking%20into%20thousands%20of%20cloud-based%20VPNs%20with%20one%20bug.pdf

Overview

Zero Trust Network Access (ZTNA) products — marketed as the successor to legacy VPNs — are increasingly deployed across enterprise environments following high-profile Ivanti, Pulse Secure, and Fortinet VPN compromises. The pitch is compelling: no user, device, or request is inherently trusted; everything is continuously evaluated. Dave Cash and Rich Warren from Amberwoolf, a UK-based red team and vulnerability research consultancy, spent months auditing the most widely deployed ZTNA products and found that the zero trust promise was almost universally broken.

Their research covers five products — Zscaler, Netscope, Checkpoint Harmony, and two others with disclosures still in progress — and documents a complete kill chain for each: authentication bypass, configuration theft, privilege escalation to SYSTEM, hardware ID spoofing to defeat posture checks, and ultimately seamless access to the target's internal network from an unmonitored attacker machine. The talk is structured around a wish list of "best possible findings" and methodically checks off each item as the presentation progresses.

The most broadly impactful finding is a SAML authentication bypass for Zscaler (CVE-2025-54982) that affects every Zscaler tenant using SAML authentication — a default configuration for enterprise deployments. The SAML assertion signature was checked only for presence, not validated against the IDP's public key, meaning any attacker could forge a SAML assertion for any user in any Zscaler-protected organization and receive a valid JWT. The bug was fixed, then reintroduced via a regression, then fixed again. A Netscope cross-tenant authentication bypass — allowing enrollment into any Netscope tenant by supplying a valid secure enrollment token from any other Netscope tenant — rounds out the pair of cloud-wide authentication failures.

Background

▶ Watch: MFA by coming from those ranges. (3:03)

The context for this research is the wave of Ivanti Connect Secure and Fortinet SSL-VPN critical vulnerabilities from 2023–2025, which drove enterprise interest in ZTNA products as a modernization path. However, as Cash and Warren note, many organizations effectively replaced their VPN with a ZTNA product but then configured it identically to the VPN — no granular access controls, just routing connections into the internal network.

Worse, a common misconfiguration was observed: conditional access policies with MFA bypass exceptions for traffic originating from the ZTNA provider's public IP ranges (to reduce authentication friction for enrolled devices). In the context of a shared-cloud ZTNA product, every customer shares IP ranges with every other customer. A successful authentication bypass on any customer can thus result in MFA-bypassed internal network access even at organizations that believe they have MFA enforced.

The products assessed: Zscaler Internet Access / Zscaler Private Access (ZIA/ZPA), Netscope Private Access, Checkpoint Harmony ZTNA, and two others in disclosure. All are among the most widely deployed ZTNA products globally.

Key Findings

▶ Watch: bypass and net scope uh to set the scene for kind of what comes afterwards. (17:23)

Checkpoint Harmony — hardcoded AES key and 30-day JWT exposure:

The Windows client for Checkpoint Harmony contains a hardcoded AES key and IV in the binary, used to decrypt an embedded OpenSSH private key. This private key is used to upload log files to an SFTP server when a customer chooses to "share logs with Checkpoint support." The log files themselves are encrypted with a predictable, brute-forceable key and contain 30-day JWTs. Any customer who has ever uploaded logs to Checkpoint support has their ZTNA session token exposed — extractable by anyone who reverses the client binary and contacts the SFTP server. Read access to the SFTP filesystem was removed immediately upon disclosure; additional Checkpoint bugs remain in active disclosure.

Zscaler SAML authentication bypass (CVE-2025-54982) — affects all SAML-enabled tenants:

The SAML authentication flow for Zscaler validates that a SAML assertion signature is present but does not validate it against the identity provider's configured public key. An attacker can send a SAML response signed with any arbitrary key (or even with an invalid signature) and receive a valid JWT back from Zscaler's service provider endpoint. This JWT can then be used to register a device in the target organization's Zscaler tenant — gaining full ZTNA network access under any chosen username.

The bug was fixed on July 22, 2025. The researchers tested the fix and confirmed it worked. Zscaler then rolled back the fix due to a more critical regression introduced in the patch. The bug re-existed until a second fix was deployed. A CVE was assigned: CVE-2025-54982.

Zscaler device token authentication — credential extraction and username impersonation:

An alternative Zscaler authentication mode (device token authentication, documented in Zscaler's public docs) allows distributing a token to machines or mobile devices to authenticate without a full IDP flow. The token is stored in plaintext in the Windows registry. Any attacker with registry read access can extract the token. Critically, the token is not bound to a specific username — only to the tenant. By importing the token on an attacker machine and changing the username in the registry, the attacker can register as any user in the tenant, potentially bypassing steering policies tied to specific usernames.

Netscope original authentication bypass (CVE-2024-7401) — still exploitable a year after disclosure:

A previously disclosed Netscope authentication vulnerability (CVE-2024-7401, disclosed August 2024) allows bypassing the SAML/IDP enrollment flow by directly supplying an OR key (leaked from the SAML request before any password is entered) and an email address to exchange for a user key, which can then be exchanged for a certificate establishing a VPN tunnel. No authentication required. The researchers discovered this vulnerability independently during a red team engagement in February 2025 — six months after the CVE advisory was published and a supposed fix was released. In August 2025, organizations were still running the vulnerable configuration.

Netscope cross-tenant bypass via "secure enrollment" — new research:

Netscope introduced "secure enrollment" as the fix for CVE-2024-7401. Secure enrollment tokens are distributed via MDM to employee devices and must be included in enrollment requests as a signed JWT. However, the enrollment endpoint accepts an OR key both in the JWT (which is validated for signature) and in a URL parameter. The server validates the JWT signature against the OR key inside the JWT, but uses the OR key from the URL parameter when actually performing the enrollment — a parameter confusion vulnerability. An attacker with a valid enrollment JWT from any Netscope tenant can tamper with the OR key URL parameter to enroll into any other Netscope tenant as any user specified in the JWT. No knowledge of the target organization's secure enrollment token is required. This has no CVE (Netscope's policy is not to issue CVEs for server-side fixes) and was fixed server-side in May 2025.

Universal privilege escalation across all ZTNA products — IPC authentication failure:

All ZTNA products share an architecture of a low-privilege system tray component communicating with a high-privilege service/broker over IPC (TCP socket, named pipe, or RPC). None of the products properly authenticated the calling process — signature-based checks could be bypassed via DLL injection into a signed process, and path-based checks were similarly bypassed. Vulnerable IPC methods allowed code execution as SYSTEM: via direct process spawning, via file write operations that could be exploited, or via injecting malicious update packages delivered as MSIs that execute as SYSTEM. Demonstrated for both Zscaler (version 4.7, latest at time of research) and Netscope.

Posture check bypass via Windows API hooking:

ZTNA posture checks (antivirus status, disk encryption status, OS version, certificate presence, etc.) are evaluated locally by the ZTNA client and reported to the server over HTTP. Intercepting proxy-based tampering is impractical (DTLS/mutual TLS), but DLL injection with Windows API hooking (MinHook library) allows spoofing every check at the API level. For Zscaler, a stolen device configuration is imported, a custom GUI application ("RedScaler") applies the correct posture profile spoofing settings, and ZTNA proceeds as if the compliance checks passed.

Hardware ID spoofing:

The hardware ID (a hash of CPU ID, motherboard serial, drive serial, and other OS components) is the primary per-device identity signal. All component values are spoofable via Windows API hooks — except CPUID, which is a processor instruction rather than an API call. This is handled via a page guard hook: scanning memory for CPUID instruction bytes, setting the memory page as PAGE_GUARD, and catching the resulting exception to modify register values (which contain the CPUID output) immediately after execution.

Technical Deep Dive

▶ Watch: Uh and what you end up with is the the decrypted um enrollment key. (25:06)

Zscaler SAML Bypass (CVE-2025-54982) — Full Technical Flow

The normal Zscaler SAML authentication flow:

1. Client submits email address → client receives pre-auth configuration (cloud endpoint, authentication method).
2. For SAML tenants: client requests a SAML request from Zscaler's SP endpoint (/ssl/auth), including the domain parameter and a PKCE code challenge.
3. Zscaler returns a SAML request with a relay state parameter.
4. Client browser submits the SAML request to the tenant's identity provider (IDP).
5. IDP authenticates the user and returns a SAML response signed with the IDP's private key.
6. Client browser POSTs the SAML response + relay state to Zscaler's SSO endpoint (/sfc/sso).
7. Zscaler validates the SAML response and redirects to a mobile API endpoint with a JWT in the ck parameter.
8. The client uses the JWT + code challenge to register a device.

The vulnerability: At step 7, Zscaler's server verified that the SAML assertion contained a signature element but did not validate the signature against the IDP's configured public key (typically an X.509 certificate uploaded by the customer admin). An attacker could:

• Intercept the relay state from step 3 (which is not secret — it's passed through the browser).
• Construct a SAML response with forged user attributes, signed with any arbitrary RSA key.
• POST this forged response to /sfc/sso.
• Receive a valid JWT for the forged user identity.

The attack scales to every Zscaler tenant worldwide using SAML authentication: one exploit script works universally because there is no per-tenant knowledge required (the OR key/relay state is obtained from the pre-auth flow, which requires only the target's email address domain).

Netscope Cross-Tenant Secure Enrollment Bypass

The secure enrollment token is an HS256-signed JWT containing: the UPN (user principal name), the user key, and the OR key (tenant identifier). The server should verify: (a) the JWT signature is valid, and (b) the OR key in the URL matches the OR key in the JWT.

The vulnerability: The server verified condition (a) — the JWT is signed correctly for the OR key inside the JWT. But for the enrollment action, the server used the OR key from the URL parameter, not from the JWT. These two checks were independent. An attacker could:

1. Obtain a valid secure enrollment JWT for any Netscope tenant they control (or a leaked enrollment token found online).
2. Sign a JWT for the target user in the target tenant.
3. Submit the enrollment request with the legitimate source JWT in the Authorization header and the target tenant's OR key in the URL parameter.
4. The server validates the JWT signature using the source OR key (check passes), then enrolls the device into the target tenant (using the URL parameter OR key).

The result: private access (VPN-equivalent) to the target organization's internal network as the specified user, using only an enrollment token from any other Netscope tenant.

Leaked enrollment tokens found online by the researchers meant that a non-Netscope customer could exploit this — no prior customer relationship required.

IPC Privilege Escalation Chain

The ZTNA IPC exploitation chain:

1. Identify IPC channel: Use process monitor to capture IPC calls made by the low-privilege system tray component to the high-privilege broker service. Record method names, parameters, and data formats.

1. Identify validation mechanism: Reverse engineer the IPC server's authentication check. Typically: check that the calling process is at a specific path, or check that the calling process binary is signed by the vendor.

1. Bypass validation via process injection: DLL injection into a process that already passes the path/signature check (e.g., inject into the system tray component itself, which is a trusted caller). The high-privilege broker trusts calls from processes that pass the check, regardless of whether injected DLLs are present.

1. Identify vulnerable method: With an authenticated IPC client (running inside the injected process), enumerate available methods and test for dangerous operations: process spawning, file write to privileged locations, loading of signed but untrusted DLLs, or — in the case of Netscope — enrollment into a malicious update server followed by malicious MSI delivery.

For Netscope: The IPC client enrolls nachevpn-style into an attacker-controlled update server. The update server delivers a malicious MSI package. The high-privilege Netscope service executes the MSI as SYSTEM. Ping — SYSTEM shell.

For Zscaler (version 4.7): Process injection bypasses the signer check, a vulnerable RPC method is called to load malicious code, a SYSTEM shell is obtained, and the Zscaler config file (XOR'd with a fixed key) is decrypted to extract posture profile information for the hardware ID spoofing step.

Posture Check Bypass and Hardware ID Spoofing

ZTNA posture checks include a combination of registry reads, WMI queries, and Windows API calls that the ZTNA client makes locally and reports to the server. The RedScaler tool:

1. API hooking: Uses MinHook to intercept Windows API functions called during posture evaluation (GetVolumeInformation for drive encryption, WSCEnumProtocols for VPN detection, RegQueryValueEx for registry-based checks, etc.).
2. Return value spoofing: Hook functions return attacker-chosen values regardless of the actual system state.
3. CPUID instruction spoofing: Memory is scanned for the 2-byte CPUID opcode. The containing memory page is set to PAGE_GUARD. When the CPUID instruction executes, the processor triggers a STATUS_GUARD_PAGE_VIOLATION exception; the custom exception handler reads the faulting address, determines CPUID was executing, and modifies EAX/ECX/EDX to the desired values before resuming execution.
4. Config import automation: The stolen ZTNA config is imported, posture profiles are read, and the spoofing settings are configured to match exactly what the original device would report.

The result: an attacker machine with no compliant software, different hardware, and different OS state passes all posture checks and receives ZTNA network access.

Demo / Proof of Concept

▶ Watch: So, we cover the orth bypasses. (26:03)

Four demonstrations were shown:

1. Zscaler SAML bypass (CVE-2025-54982): A script forged a SAML assertion, obtained a JWT, used the pic-scaler tool to register a fake machine, visible in the Zscaler admin portal with the attacker-chosen hardware ID.

1. Zscaler device token extraction and replay: On a victim VM, the device token was extracted from the Windows registry. On the attacker VM, the token was imported, Zscaler restarted, and after changing the registry username from user1 (no internet access) to admin1, the attacker obtained internet access under the network admin policy.

1. Netscope cross-tenant bypass: A script was provided with the target tenant details and source (attacker-controlled) OR key + enrollment token. A branding file and JWT were returned, imported into the attacker VM, Netscope restarted, and VPN-equivalent access to the target network was established.

1. RedScaler posture bypass: The stolen config was imported into the RedScaler GUI, posture spoofing applied automatically, Bitlocker status spoofed to enabled, Zscaler restarted — internet access confirmed through the ZTNA tunnel.

Defensive Implications

▶ Watch: So for most checks a simple Windows API hook was all that was needed. (33:51)

For Netscope customers:

• Enable secure enrollment immediately if still on IDP-only mode. The original CVE-2024-7401 authentication bypass remains exploitable without it.
• Verify that the server-side fix for the cross-tenant secure enrollment bypass (released May 2025) is applied — this requires no client action.
• If your secure enrollment token has ever been exposed (e.g., via Intune configuration leak), rotate it.

For Zscaler customers:

• CVE-2025-54982 is fully patched server-side; no customer action required for the SAML bypass.
• Audit for device token authentication mode usage; tokens stored in the Windows registry in cleartext should be rotated if the device may have been compromised.
• Enable cryptographically verified posture checks (available since Zscaler client version 4.4) for hardware-ID and posture attestation.

For all ZTNA deployments:

• ZTNA does not eliminate the need for internal network segmentation. Even with full ZTNA authentication bypass, granular access controls reduce the blast radius.
• Never configure MFA exclusions for ZTNA provider IP ranges — in a shared-cloud ZTNA product, the entire customer base shares those IP ranges.
• Regularly update ZTNA clients; unpatched privilege escalation vulnerabilities are vendor-independent and affect all products assessed.
• Cryptographically verified device compliance checks (server-side attestation) are the correct direction; client-side-only posture checks with locally-evaluated results reported over HTTP will always be bypassable by a motivated attacker with local access.

Privacy consideration:

All assessed products install a root CA certificate to perform TLS inspection. This means encrypted traffic passes through the ZTNA provider's infrastructure decrypted and re-encrypted. A compromised ZTNA provider cloud (not demonstrated in this research but architecturally possible) would have access to all inspected traffic from all customers simultaneously.

Key Takeaways

• CVE-2025-54982 (Zscaler SAML assertion signature not validated against IDP public key) is a single bug affecting every Zscaler tenant using SAML authentication — thousands of organizations — and was found in a product specifically marketed as replacing insecure legacy infrastructure.
• All five ZTNA products assessed shared the same IPC authentication failure pattern: low-privilege system tray communicating with high-privilege broker without proper process validation, universally bypassable via DLL injection into a trusted process.
• ZTNA posture checks evaluated locally by the client are fundamentally bypassable via Windows API hooking — including CPUID hardware fingerprinting, which is spoofable via page guard exception handler manipulation; only cryptographic server-side attestation provides meaningful assurance.
• Netscope's cross-tenant enrollment bypass required only a valid enrollment token from any other Netscope tenant — not the target's token — meaning leaked tokens posted online were sufficient for exploitation across the entire Netscope customer base.
• "Zero trust" is a marketing term that means different things to different vendors; the products assessed represent a significant improvement over cleartext VPN but have their own class of critical vulnerabilities that defenders must actively manage rather than treating as inherently secure.

About the Speaker(s)

▶ Watch: To detect malicious behavior, you can look at vendor provided logs for newly (39:54)

David Cash and Rich Warren are vulnerability researchers and red team operators at Amberwoolf, a UK-based cybersecurity consultancy specializing in red teaming and original vulnerability research. Both have extensive experience finding vulnerabilities in enterprise security products through red team engagements — the Netscope CVE-2024-7401 regression, for example, was discovered during an active client engagement. Their work on ZTNA products was motivated by the frequency with which these products appear in real-world red team targets and the lack of published independent security research into their internals. They have committed to publishing full technical details of all findings on their blog, with some details already published as of the DEF CON talk date.