Breaking into thousands of cloud based VPNs with 1 bug -David Cash, Rich Warren

Breaking into Thousands of Cloud-Based VPNs with 1 Bug

Speakers: Dave (Amberwolf), Rich (Amberwolf)

Conference: DEF CON

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

Overview

In their DEF CON talk, "Zero Trust, Total Bust," Dave and Rich from Amberwolf unveiled a disturbing reality: the much-touted Zero Trust Network Access (ZTNA) solutions, often marketed as the secure successor to legacy VPNs, are frequently riddled with critical vulnerabilities. Through extensive research into popular ZTNA products like Checkpoint Harmony, Zscaler, and NetScope, the presenters demonstrated how fundamental security flaws, ranging from authentication bypasses to privilege escalation and posture check circumvention, undermine the core principles of zero trust.

The talk highlighted that many organizations, in their haste to adopt ZTNA, merely replace their VPNs without implementing granular access controls, effectively recreating the same security pitfalls in a new cloud-based environment. The speakers methodically detailed how these products, despite their advanced claims, suffer from "same old bug classes reimagined for a new technology stack," exposing thousands of cloud-based networks to compromise. This presentation serves as a crucial wake-up call for enterprises and security professionals, urging a re-evaluation of ZTNA implementations and a more critical approach to vendor claims.

The significance of this research cannot be overstated. As organizations increasingly migrate their infrastructure to the cloud and embrace remote work, ZTNA products become central to their security posture. The findings presented by Amberwolf reveal that this critical layer of defense often fails to live up to its "never trust, always verify" promise, instead operating as "always trust, never verify." This exposes sensitive internal networks to attackers who can exploit these vulnerabilities to gain unauthorized access, steal data, and maintain persistence, fundamentally challenging the perceived security benefits of ZTNA.

Background

▶ Watch: Talk introduction and zero trust overview (0:00)

The concept of Zero Trust is foundational to modern cybersecurity, positing that no user, device, or request should be inherently trusted, regardless of its location. Instead, every access attempt must be continuously evaluated against a set of access controls, ensuring that only authenticated and authorized entities can access specific resources. Key terminology in this context includes SAS (Security as a Service), acting as a gatekeeper for access requests; Steering, which intelligently routes traffic based on conditions like ACLs; and Identity Providers (IDP), which manage user authentication.

However, the speakers observed a significant disconnect between this theoretical ideal and practical implementation. Many organizations, driven by vendor marketing that declares "legacy VPNs are dead," have transitioned to ZTNA products primarily to replace their traditional VPN infrastructure. This often results in ZTNA being used simply as a modern VPN, brokering connections into the internal network without implementing the granular access controls and continuous verification that define true zero trust.

A particularly concerning trend identified was the persistence of the "trusted corporate LAN" concept within ZTNA environments. While traditional VPNs might have provided a false sense of security within a private IP space, ZTNA products often place multiple customers within a shared public IP range. This misconfiguration can lead to critical bypasses, such as excluding Multi-Factor Authentication (MFA) for connections originating from these ZTNA public IP ranges to reduce authentication friction. Attackers exploiting this shared IP space can effectively bypass MFA, gaining unauthorized access. This highlighted the speakers' "wish list" for their research: achieving authentication bypass, configuration theft, privilege escalation, and posture bypass across these ZTNA products.

Key Findings

▶ Watch: Checkpoint Harmony: Encrypted private key disclosure (2:40)

The research uncovered a series of critical vulnerabilities across leading ZTNA platforms, demonstrating how the "never trust, always verify" mantra often devolves into "always trust, never verify."

1. Checkpoint Harmony Private Key Exposure: The Windows client was found to contain an encrypted OpenSSH private key, discoverable via DN Spy. This key, used for SFTP log uploads, was decryptable using a hard-coded AES key and IV within the binary. Furthermore, the log files themselves, containing 30-day valid JWTs for ZTNA service access, were encrypted with a predictable and brute-forceable key. This allowed for potential compromise of any customer who had uploaded logs.

1. Zscaler SAML Authentication Bypass (CVE-2025-54982): A severe flaw in Zscaler's SAML authentication flow allowed attackers to bypass authentication for any tenant using SAML. The server only checked for the presence of a signature on the SAML assertion, not its validity against the Identity Provider's public key. This enabled attackers to forge SAML assertions with arbitrary keys, register devices, and gain unauthorized access. Although quickly patched, a regression occurred, emphasizing the fragility of such fixes.

1. Zscaler Device Token Authentication Bypass: For tenants using device token authentication, the token only validated for the tenant, not a specific user. Crucially, on Windows, this token was stored in cleartext within the registry. This allowed an attacker to extract the token, register a machine with any chosen username, and effectively bypass steering policies or gain access intended for other users.

1. NetScope User Key Authentication Bypass (CVE-2024-7401 re-emergence): The researchers rediscovered and exploited a previously reported and patched authentication bypass in NetScope. This vulnerability allowed an attacker, knowing only a target organization's org key (which was easily leaked pre-authentication) and a valid email address, to obtain a user-specific user key without any authentication. This granted full VPN-equivalent access to the target network via NetScope's private access solution. Despite a CVE and advisory, many organizations had not enabled the recommended "secure enrollment."

1. NetScope Cross-Tenant Secure Enrollment Bypass: Even with NetScope's "secure enrollment" enabled, a critical flaw persisted. The server, during enrollment, prioritized the org key specified in the URL over the one embedded within the cryptographically signed JWT in the authorization header. This meant an attacker with a valid secure enrollment token from any NetScope tenant could tamper with the URL's org key to enroll into any other target tenant, provided the target org key was known (which, as established, was often leaked). Leaked enrollment tokens were even found online, exacerbating the risk.

1. General Privilege Escalation in ZTNA Clients: Across all assessed ZTNA products, a common architectural pattern involved a low-privilege system tray application communicating with a high-privilege service or broker via Inter-Process Communication (IPC) mechanisms (TCP sockets, named pipes, RPC). These IPC channels consistently failed to properly validate the calling process, making them vulnerable to injection attacks that bypassed signing or path-based checks. Exploiting vulnerable IPC methods (e.g., process starting, file writing) allowed attackers to achieve system-level code execution.

1. ZTNA Config Theft and Posture Bypass: ZTNA client configurations, often containing sensitive details, were stored as DPAPI-encrypted blobs on endpoints (Zscaler by default). While theoretically protected, the researchers demonstrated that with system-level access, these configurations could be exfiltrated. Furthermore, all vendor-specific posture checks (e.g., BitLocker status, antivirus presence) and hardware ID validations could be completely bypassed. Posture checks, retrieved over HTTP and processed locally, could be spoofed at the Windows API level using DLL injection and API hooking (e.g., Minhook). Even hardware ID components, including CPU ID instructions, were spoofable using advanced techniques like page guard hooks. The custom-developed "Red Scaler" tool showcased the ease with which these checks could be circumvented, especially since cryptographically verified or server-side checks were rarely enabled by default.

Technical Deep Dive

▶ Watch: Zscaler: Unauthenticated pre-auth configuration disclosure (4:40)

The technical underpinnings of these vulnerabilities reveal a pattern of flawed design and implementation choices across the ZTNA ecosystem.

Checkpoint Harmony: Private Key and JWT Exposure

The initial discovery involved analyzing the Checkpoint Harmony Windows client using DN Spy. Within the client's binary, a function responsible for uploading log files to Checkpoint support via SFTP was identified. This function referenced an encrypted private key. Further investigation revealed a decode resource function that decrypted this resource using a hard-coded AES key and IV embedded directly within the binary. The result was a standard OpenSSH private key. Additionally, the log files themselves were encrypted before upload, but the encryption key was found to be predictable and brute-forceable. Crucially, these log files contained JSON Web Tokens (JWTs) valid for up to 30 days, which could be used directly to authenticate to the ZTNA service. The immediate impact was that any customer who had ever uploaded logs could have their ZTNA access compromised.

Zscaler: Pre-Authentication Information Leakage and SAML Bypass

The Zscaler client's initial interaction, after an email address is entered, involves requests to the mobile API. These requests are encrypted using a complex scheme: a random AES key is generated, combined with a hard-coded key, encrypted with RSA, and then added to a token header. The actual POST request body is AES-encrypted. Upon decryption, it was found that the client sends the device type and user email to fetch the cloud endpoint hostname. Subsequently, a GET /api/v1/mobile/config/preauth request retrieves a pre-authentication configuration for the tenant before any password is supplied. This configuration could include authentication settings (e.g., IDP usage), enabled cloud features (ZPA, ZIA), and ZCC client features. Historically, this pre-auth config also contained the URL for the PAC (Proxy Auto-Configuration) file, which could expose misconfigured wildcards or abusable services for C2 bypass.

The most critical Zscaler finding was the SAML authentication bypass (CVE-2025-54982). The SAML login flow involves the client making a request to a CL endpoint with a domain parameter and a PKCE (Proof Key for Code Exchange) code_challenge. The server responds with a SAML form containing a SAML request and a relay_state. After the user authenticates with their IDP, the SAML response and relay_state are posted back to the Zscaler SFC/SSO endpoint. This endpoint then redirects the client to test.html, including a JWT in the CK parameter of the redirected URL. The vulnerability lay in Zscaler's validation of the SAML assertion: the server only checked for the presence of a signature, completely neglecting to validate it against the IDP's public key. This allowed an attacker to forge a SAML assertion signed with any key, effectively bypassing authentication for any SAML-enabled Zscaler tenant. The demo illustrated this by forging a SAML assertion and using a custom tool, PIC Scaler, to register a fake machine in Zscaler, visible in the admin portal.

Zscaler: Device Token Authentication Flaws

Zscaler also supports device token authentication, where an admin distributes a token to machines for use as an IDP. On Windows, this token is specified as an MSI argument during installation. The critical flaw here is that the token only validates for the tenant, not a specific user. If an attacker extracts this token, they can register a machine with any username, potentially bypassing steering policies. The token, along with a username parameter, is stored in cleartext in the registry under HKLM\SOFTWARE\Zscaler\Zscaler Client Connector\DeviceToken. The demo clearly showed extracting this token from a victim machine, replaying it on an attacker VM, and then changing the associated username in the registry to bypass internet access restrictions and gain higher-privilege access.

NetScope: Org Key Leaks and Authentication Bypass Resurgence

NetScope's architecture uses an org key (immutable, assigned to tenant) and a user key (immutable, assigned to user). Reconnaissance showed that the org key was consistently leaked during the initial unauthenticated flow when the tenant name was sent, or via the customer admin portal. This org key could then be used to pull parts of the tenant configuration or PAC file, often leaking more information than Zscaler pre-authentication.

The original NetScope authentication bypass (CVE-2024-7401), discovered by Sander de Wit, was still exploitable. The flow involved exchanging the leaked org key and an email address directly for a user key without any authentication. This meant an attacker could skip the entire SAML IDP stage and obtain a user key for any known email address, granting access equivalent to a VPN.

NetScope: Cross-Tenant Secure Enrollment Bypass

NetScope's fix for CVE-2024-7401 introduced secure enrollment, requiring a secure enrollment token deployed via MDM. This token was used to sign a JWT (using HS256) containing the UPN, user key, and org key, which was then sent in an authorization header. However, a critical flaw remained: the server prioritized the org key specified in the URL over the org key within the signed JWT. This allowed an attacker with any valid secure enrollment token (from any NetScope tenant) to tamper with the org key in the URL and initiate a secure enrollment process for any other target tenant, as long as the target org key was known. Leaked secure enrollment tokens were even found online, making this a widely exploitable cross-tenant vulnerability. The fix, released in server-side version 126, now correctly checks that the URL org key matches the JWT org key, but no CVE was issued for this server-side fix. The demo visually confirmed the cross-tenant exploit, showing an attacker gaining MPA access using a source token and a target org key.

General ZTNA Privilege Escalation (PrivEsc)

A common architectural flaw across ZTNA products was the interaction between a low-privilege system tray application and a high-privilege service or broker. These components communicate via IPC (TCP sockets, named pipes, RPC). The key vulnerability was the failure to properly validate the calling process, making them susceptible to injection attacks that bypass signing or path-based checks. Specific vulnerable IPC methods, whether for process starting or file writing, allowed attackers to achieve system-level code execution.

• NetScope LP PrivEsc Demo: An attacker used a custom IPC client, injected a TCP proxy into a legitimate process (to bypass path/signature checks), enrolled "Nachevpn style" into a malicious server, and received an MSI update that executed as SYSTEM, granting a system shell.
• Zscaler PrivEsc Demo (v4.7): Process injection was used to bypass the signature check, triggering a vulnerable RPC method to load malicious code. This led to a system shell, enabling the dumping of user configurations and hardware ID spoofing values.

ZTNA Configuration Theft and Posture Bypass

ZTNA client configurations are often stored as DPAPI-encrypted blobs. While this offers some protection, system privileges (achieved via PrivEsc) allow for decryption and theft. Zscaler's config, for example, is XORed with a fixed key after a convoluted XOR shuffle, but still requires system access to dump.

Posture checks and hardware ID validations, designed to verify device health and uniqueness, were universally bypassable. Posture checks are retrieved over HTTP, processed locally by the client, and results are returned to the server.

• NetScope Posture Bypass: Initially, a simple intercepting proxy could change status=false to status=true in HTTP responses. However, due to DTLS and mutual TLS, this is impractical.
• Advanced Posture Bypass: A more robust approach involved DLL injection and API hooking (primarily using Minhook) at the Windows API level to spoof the results of these checks.
• Hardware ID Spoofing: The hardware ID, a hash of various OS and hardware components, is sent during registration and keep-alives. Mismatches can trigger re-registration or connection refusal. All underlying values making up the hardware ID were found to be spoofable.
• CPU ID Spoofing: The CPUID instruction, used for unique hardware fingerprinting, is an instruction, not a hookable method. To bypass this, the researchers employed a page guard hook. They searched memory for CPUID instructions, set the containing page as PAGE_GUARD, caught the resulting exception, and then swapped register values after the CPUID instruction executed, effectively spoofing the output.
• The custom-built Red Scaler GUI application was developed to control these hook settings dynamically. It could import a ZTNA config and automatically adjust spoofing settings to match the required posture profile. The fact that cryptographically verified compliance checks or server-side checks are often not enabled by default, or not supported at all by some vendors, means these client-side bypasses remain highly effective. The Red Scaler demo showed importing a Zscaler config, applying posture checks, logging in, and then dynamically spoofing BitLocker status to gain internet access.

Demo / Proof of Concept

▶ Watch: Zscaler: Stealing gateway cookies for authentication bypass (6:20)

The talk was rich with live demonstrations, visually confirming the severity and practicality of the discovered vulnerabilities.

1. Zscaler SAML Authentication Bypass: The first demo showcased the SAML bypass. A script was run that forged a SAML assertion, leveraging the lack of signature validation. This forged assertion, combined with a code_challenge, yielded a valid JWT. The custom PIC Scaler tool then took this JWT and registered a "fake machine" in Zscaler. The presenters then navigated to the Zscaler admin portal, where the newly registered, unauthorized machine, with its attacker-chosen hardware ID, was clearly visible, proving the complete authentication bypass.

1. Zscaler Device Token Replay: This demo illustrated the cleartext device token vulnerability. On a "victim's machine," the device token was extracted from the Windows registry. Then, on an "attacker VM," this stolen token was imported. The Zscaler client was paused, the token and a default username were imported into the registry, and Zscaler was restarted. The client logged in as "user one," but initially had no internet access due to policy. The attacker then suspended Zscaler, changed the username in the registry to "admin one," restarted Zscaler, and immediately gained internet access, demonstrating the ability to bypass steering policies and impersonate users by simply altering a cleartext registry entry.

1. NetScope Cross-Tenant Secure Enrollment Bypass: This advanced demo highlighted the cross-tenant secure enrollment flaw. An attacker ran a script providing target tenant details (UPN, org key) and source tenant details (org key, secure enrollment token). The script leveraged the server's preference for the URL's org key to obtain a valid certificate and branding file for the target tenant. The attacker then imported these files onto their VM, restarted NetScope, and successfully gained MPA (NetScope Private Access) access to the target organization's network, proving the ability to enroll into an arbitrary tenant using a token from a different organization.

1. NetScope DPAPI Extraction (Enrollment Key): A quick demonstration showed how even NetScope's "encrypted" secure enrollment token, stored in the registry, could be decrypted. While encrypted with DPAPI, it used flag 4 (local machine context) and a hard-coded global entropy string. This meant any user on the machine could decrypt it, revealing the plaintext enrollment key, further weakening the secure enrollment mechanism if an endpoint was compromised.

1. NetScope Privilege Escalation: This demo illustrated a general ZTNA client privilege escalation. An attacker used a custom IPC client to inject a TCP proxy into a legitimate NetScope process, bypassing path and signature checks. This manipulated the IPC communication, allowing the client to enroll "Nachevpn style" (referencing a known VPN exploit pattern) into a malicious server. This server then delivered an MSI update, which, due to the escalated privileges, executed as SYSTEM, providing the attacker with a high-privilege shell.

1. Zscaler Privilege Escalation and Config Dump: The demo for Zscaler version 4.7 showed a similar privilege escalation path. Process injection was again used to bypass signature checks. This enabled the attacker to trigger a vulnerable RPC method, loading malicious code and achieving a SYSTEM shell. Once system access was gained, the demo proceeded to dump the user's Zscaler configuration and extract various source values needed for hardware ID spoofing, setting the stage for subsequent posture bypasses.

1. Red Scaler (ZTNA Posture Bypass): The final, comprehensive demo showcased the Red Scaler tool. The tool imported a stolen Zscaler configuration (containing posture check details in plaintext). Red Scaler then re-encrypted the config and placed it in the correct location. It identified the required posture checks from the config and asked if it should apply them automatically. After restarting Zscaler with the spoofing enabled, the client successfully logged in. Initially, internet access was denied because one posture check (BitLocker) was not yet spoofed. The attacker then dynamically enabled BitLocker spoofing in Red Scaler's GUI, and upon re-evaluation, internet access was immediately granted, demonstrating the complete and dynamic bypass of ZTNA posture checks.

These demos collectively painted a stark picture of how attackers could chain these vulnerabilities, moving from unauthenticated access to system-level compromise, data theft, and full network access, all while bypassing the very security mechanisms ZTNA is designed to enforce.

Defensive Implications

▶ Watch: Zscaler: JWT disclosure in SAML redirect ('better bug') (7:00)

The findings presented by Dave and Rich offer critical insights for organizations currently using or considering ZTNA solutions. Implementing robust defenses requires a multi-faceted approach, addressing both immediate vulnerabilities and broader architectural weaknesses.

1. Prioritize NetScope Secure Enrollment: For NetScope customers, the most urgent action is to immediately enable secure enrollment. Despite being available for some time, many organizations still operate in the vulnerable IDP mode. Even with secure enrollment, organizations must understand that if their secure enrollment token is leaked (e.g., from a compromised MDM environment), an attacker can still impersonate any user.

1. Maintain Vigilant Client Updates: Regardless of whether a CVE has been published, organizations must ensure ZTNA clients are always updated to the latest versions. The talk highlighted instances where fixes were rolled back or server-side patches were deployed without CVEs, meaning relying solely on CVE notifications is insufficient. Regular updates are crucial for mitigating undisclosed or silently patched vulnerabilities.

1. Enable Cryptographically Secure and Server-Side Checks: Where supported, organizations should enable cryptographically secure checks or server-side validated compliance checks. Zscaler, for example, supports this feature since version 4.4. Relying solely on client-side posture checks is demonstrably insecure, as these can be easily bypassed through API hooking and hardware ID spoofing.

1. Implement Robust Reauthentication Policies: To limit the impact of config theft and token replay, organizations should require frequent reauthentication with short reauthentication periods. This minimizes the window of opportunity for attackers using stolen credentials or tokens.

1. Minimize Attack Surface for Privilege Escalation: Reduce the attack surface for client-side privilege escalation vulnerabilities by disabling client-side access to non-essential features such as debugging tools and verbose logging. These features can often provide attackers with valuable information or unintended execution paths.

1. Strictly Scope Steering Bypass Policies: App-based or domain-based steering bypasses, while sometimes necessary, should be narrowly scoped, meticulously reviewed, and regularly audited. Overly broad or misconfigured bypasses can create significant security holes, allowing malicious traffic to circumvent inspection and controls.

1. Enhanced Logging and SIEM Integration: Organizations must ingest vendor-provided logs into their Security Information and Event Management (SIEM) systems. Key indicators of compromise include:

• Newly registered devices: Especially those from unexpected locations or with unusual hardware IDs.
• Rapid changes in posture check status: Devices quickly switching between passing and failing checks.
• Unexpected locations or operating systems: A user typically on a Mac suddenly enrolling a Windows device, or devices connecting from unusual geographic regions.

1. Leverage EDR for Endpoint Detection: Endpoint Detection and Response (EDR) solutions are vital for detecting malicious activities that underpin these attacks:

• Reading sensitive registry keys or files: As seen with device token and enrollment key extraction.
• Process injection: A common technique used to bypass signature checks and manipulate IPC.
• Unexpected child processes: ZTNA processes spawning unusual or unauthorized child processes.

1. DPAPI Auditing for Config Theft Detection: While vendors don't flag ZTNA config data as auditable, enabling debug logging for the Microsoft Windows Crypto DPAPI log (as detailed in Google's blog on browser cookie theft) can provide critical telemetry. This generates Event ID 16385, which can be correlated with the data description (e.g., "client configuration" for Zscaler) and the caller Process ID (PID) to identify attempts at decrypting sensitive configurations.

1. SACLS for Registry and File Access Auditing: Configure System Access Control Lists (SACLs) on sensitive registry keys and configuration files (e.g., HKLM\SOFTWARE\Zscaler\Zscaler Client Connector\DeviceToken or NetScope's enrollment key location). This will raise Event ID 4663 in the security log when an attacker attempts to read or export these values, providing a clear audit trail of potential config or token theft.

By implementing these comprehensive defensive measures, organizations can significantly reduce their exposure to the types of vulnerabilities highlighted in this talk, moving closer to the true "never trust, always verify" ideal of Zero Trust.

Key Takeaways

• ZTNA is Not a Magic Bullet: Despite marketing, Zero Trust Network Access products are susceptible to "same old bug classes reimagined" for a new technology stack, not fundamentally more secure by design.
• Over-reliance on Client-Side Trust: Vendors place too much trust in client-side components for authentication, posture checks, and device identity, making them vulnerable to bypasses.
• Inadequate Vulnerability Communication: Vendors need to clearly and effectively communicate vulnerability fixes, especially for server-side patches or those requiring customer configuration changes, even without a CVE.
• "Always Trust, Never Verify" in Practice: The practical implementation of ZTNA often falls short of its "never trust, always verify" promise, frequently operating as "always trust, never verify."
• Critical Need for NetScope Secure Enrollment: NetScope customers must immediately enable secure enrollment to mitigate known authentication bypasses, understanding that token leakage remains a risk.
• Universal Vulnerabilities: Privilege escalation, configuration theft, and posture/hardware ID bypasses are common across ZTNA products, requiring robust endpoint protection and detection strategies.

About the Speaker(s)

Dave and Rich are security researchers and red teamers who work at Amberwolf, a UK-based consultancy. Their expertise lies in red teaming engagements and vulnerability research, which provides them with deep insights into the practical security posture of widely adopted enterprise technologies, including Zero Trust Network Access solutions. Their work focuses on uncovering and responsibly disclosing critical security flaws that impact real-world organizations.