Zero Trust Architectures Are Leaking Credentials and Bypassing Posture Checks

TLDR: Modern ZTNA solutions from Zscaler and Netskope contain critical flaws in how they store configurations and validate device posture. By exploiting predictable encryption and insecure inter-process communication, attackers can bypass authentication, impersonate users, and gain unauthorized access to internal networks. Security teams must prioritize enabling secure enrollment and auditing endpoint logs for suspicious process injection or registry access 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: replace the brittle, easily compromised SSL VPN with a cloud-native broker that continuously validates every user and device. But as recent research presented at DEF CON 2025 demonstrates, these platforms are not immune to the same fundamental security failures that plagued their predecessors. When you move the perimeter to the cloud, you are not necessarily eliminating the attack surface; you are just shifting it to a new, proprietary stack that is rarely audited with the same rigor as traditional network infrastructure.

The Mechanics of the Bypass

The research highlights a recurring pattern in ZTNA client implementations: a reliance on client-side security controls that are fundamentally flawed. Both Zscaler and Netskope store sensitive configuration data locally on the endpoint. While this data is encrypted, the implementation often relies on Windows DPAPI, which is designed to protect data at rest but is easily decrypted by any process running under the user's context.

In the case of Zscaler, the configuration is XORed with a fixed key. An attacker with local access can dump this configuration, extract the authentication tokens, and effectively clone the device identity. The research team demonstrated that by injecting a custom DLL into the Zscaler process, they could hook the inter-process communication (IPC) methods used by the client. This allows an attacker to bypass signature checks and manipulate the data returned to the Zscaler broker, effectively tricking the server into believing the attacker's machine is a legitimate, compliant device.

Exploiting Posture Checks

Posture checks are the heartbeat of Zero Trust. They are supposed to ensure that a device is running up-to-date antivirus, has disk encryption enabled, and meets other security baselines before granting access. However, these checks are often performed by querying local system components like the registry or WMI.

The researchers introduced RedScaler, a tool that automates the process of hooking these API calls. Instead of actually hardening the machine, the tool intercepts the ZTNA client's queries to the operating system and returns spoofed, "compliant" values. Because the ZTNA client trusts the data it retrieves locally, it reports a clean bill of health to the cloud broker. This is a classic Broken Access Control failure where the client-side validation is treated as an authoritative source of truth.

Real-World Impact and Vulnerabilities

The implications for a red team engagement are significant. If you land on a workstation with ZTNA installed, you no longer need to hunt for credentials in memory or rely on phished sessions. You can simply extract the configuration, move it to your own machine, and spoof the hardware ID to establish a persistent, authenticated tunnel into the target's internal network.

The research identified several specific vulnerabilities, including CVE-2024-7461 and CVE-2024-7401, which allowed for authentication and posture bypasses. Another critical finding, CVE-2025-54982, highlighted how insecure enrollment processes could lead to cross-tenant compromise. These are not theoretical edge cases; they are direct consequences of building security models that assume the endpoint is a trusted, tamper-proof environment.

Hardening Your ZTNA Deployment

Defenders cannot rely on the ZTNA client to police itself. The most effective mitigation is to move away from legacy, insecure enrollment methods. For Netskope customers, this means enforcing Secure Enrollment and ensuring that enrollment tokens are pre-deployed via MDM rather than relying on user-provided credentials.

Beyond configuration, you need visibility. Audit your endpoint logs for Event ID 16385, which indicates DPAPI activity, and monitor for unauthorized access to registry keys associated with your ZTNA client. If you see a device suddenly reporting a change in posture status or a flurry of failed authentication attempts followed by a successful connection from a new hardware ID, you are likely looking at an active compromise.

Zero Trust is a philosophy, not a product. When you treat a vendor's client as an infallible gatekeeper, you create a single point of failure that is ripe for exploitation. The next time you are scoping a penetration test, don't just look for open ports on the perimeter. Look at the ZTNA client on the endpoint. It is likely the most interesting, and most vulnerable, piece of software on the machine.