Bypassing Zero Trust: How Zscaler and Netskope Clients Fail at Device Posture

TLDR: Researchers at DEF CON 2025 demonstrated that popular ZTNA clients from Zscaler and Netskope rely on insecure client-side configurations, including predictable encryption keys and improper validation of SAML assertions. By exploiting these weaknesses, an attacker can impersonate legitimate users and bypass critical device posture checks to gain unauthorized network access. Security teams must prioritize enabling secure enrollment and implementing server-side validation to mitigate these risks.

Zero Trust Network Access (ZTNA) is often sold as the silver bullet for the modern, distributed workforce. The marketing pitch is simple: stop trusting the network and start trusting the identity and the device. But as the research presented at DEF CON 2025 makes clear, the security of these solutions is only as strong as the client-side implementation. When the "Zero Trust" engine relies on a client that can be manipulated, the entire security model collapses.

The Fallacy of Client-Side Trust

The core issue identified in this research is that ZTNA clients often treat the local machine as a trusted environment. Whether it is Zscaler or Netskope, these agents perform posture checks—verifying disk encryption, antivirus status, or firewall settings—and report those results back to the cloud. If an attacker can compromise the client, they can spoof these reports.

The researchers demonstrated that these clients store sensitive configuration data, including authentication tokens and encryption keys, in the Windows Registry. In many cases, these values are protected using DPAPI, but because the encryption is tied to the local machine and uses predictable entropy, any user with sufficient privileges can decrypt them. Once an attacker has a shell, they can extract these tokens, move them to their own machine, and effectively become the legitimate user.

Exploiting SAML and JWT Flows

One of the most critical findings involves the manipulation of SAML and JWT authentication flows. In several configurations, the ZTNA client performs a SAML assertion to authenticate the user. The researchers found that the server-side validation of these assertions was often flawed. Specifically, the signature on the SAML assertion was checked for presence but not properly validated against the Identity Provider’s (IdP) public key.

This allows an attacker to forge a SAML assertion, sign it with an arbitrary key, and successfully authenticate as any user within the tenant. The impact here is total account takeover. For a pentester, this is a goldmine. If you encounter a target using these ZTNA solutions, your first step should be to inspect the authentication traffic. If you can intercept the SAML response, you have a high probability of bypassing the entire authentication layer.

Automating the Bypass with RedScaler

To prove the point, the researchers released RedScaler, a tool designed to automate the exploitation of these weaknesses. RedScaler hooks into the ZTNA client process to manipulate the results of posture checks. By using MinHook, the tool intercepts Windows API calls related to registry queries and file system access.

When the ZTNA client asks the operating system, "Is the firewall enabled?", RedScaler intercepts the response and returns "True," regardless of the actual state. This is a classic Broken Access Control scenario where the client-side check is treated as a security boundary rather than a telemetry source.

Real-World Impact and Defensive Strategy

During a red team engagement, these vulnerabilities are devastating. Once you have a foothold on a machine with a ZTNA client, you are not just a local user; you are a trusted entity on the corporate network. You can bypass traffic steering restrictions, access private applications, and move laterally with the identity of a legitimate employee.

Defenders need to stop relying on the client to police itself. The most effective mitigation is to move toward server-side validation. If a device claims to be compliant, the server should verify that claim through independent, cryptographically signed telemetry whenever possible. Furthermore, organizations must enable Secure Enrollment features, which require a pre-deployed, unique token to register a new device. This prevents an attacker from simply importing a stolen configuration onto a rogue machine.

Finally, audit your logs. If you see a sudden influx of new device registrations or a user appearing from multiple, geographically disparate locations, investigate immediately. Use EDR to monitor for suspicious processes interacting with the ZTNA client’s registry keys or injecting code into its memory space.

The industry has spent years moving away from the "castle-and-moat" architecture, but we have inadvertently built new, fragile castles on our endpoints. Zero Trust is a sound principle, but it requires verifying the client, not just the user. If you are testing these environments, look for the gaps between what the client reports and what the server actually validates. That is where the real vulnerabilities live.