Palo Alto GlobalProtect : Remote Full Compromise Exploit Chain

Summary

This article delves into vulnerabilities in the Palo Alto GlobalProtect VPN client discovered by Michelin Red Team (Yassine Bengana and Myself) and identified as CVE-2024-5921, CVE-2025-0117, CVE-2025-0118 & CVE-2025-2183. We will see how they enable an attacker to execute code on Windows GlobalProtect clients located in the same network. The key attack vectors discussed include :

1. Certificate Verification Bypass: The VPN client can be tricked into bypassing certificate verification, allowing attackers to impersonate the VPN portal and deliver malicious payloads.

2. Arbitrary Root CA Insertion: Attackers can insert a malicious root CA into the system, enabling them to issue fraudulent certificates and potentially install malware.

3. Embedded Browser Exploits: The use of an embedded browser for authentication can be exploited to deliver malicious content, such as HTA files, leading to remote code execution.

4. Privilege Escalation: Abusing the Impersonation Mechanism or the Weak System Update to get system privileges.

We will go through all the steps, try to understand GlobalProtect thoroughly, and pave the way towards a full chain exploit.

Affected Versions

According to Palo Alto :

Architecture & Normal Connection Flow

Here is how a connection would normally go using GlobalProtect :

1. Client Initialization: The GlobalProtect client is launched on the user's device.
2. DNS Resolution: The client performs a DNS query to resolve the IP address of the GlobalProtect portal.
3. Portal Connection: The client establishes a connection to the GlobalProtect portal using the resolved IP address.
4. Certificate Verification: The client verifies the portal's SSL certificate to ensure it is connecting to a legitimate server.
5. Authentication: The user is prompted to authenticate, typically through an embedded browser or other authentication methods supported by the portal.
6. Gateway Selection: Upon successful authentication, the portal provides the client with a list of available gateways.
7. Gateway Connection: The client selects a gateway (usually based on location or load balancing) and establishes a secure tunnel to the gateway, the user's traffic will be routed through this gateway.
8. Tunnel Establishment: The secure VPN tunnel is established, encrypting all traffic between the client and the gateway.
9. Network Access: The user can now access internal network resources securely through the VPN tunnel.

Attack Scenario

In order to achieve the full exploit chain, we will place ourselves in the case of an attacker with either :

• AiTM (Adversary-in-The-Middle) capability in the network (ie. ARP Poisonning, network devices management)
• DHCP/DNS configuration capability (ie. the victim connects to the attacker's rogue access point)

This diagram represents a full exploit chain for Palo Alto Global Protect with a hardened configuration, which outlines a step-by-step attack scenario leading to either user compromise or full compromise

Untrusted DNS usage

In this context, the victim then tries to establish a tunnel using GlobalProtect (on Windows).

As the first DNS query for VPN gateway's hostname is sensitive, most VPN clients allow the configuration of a trusted DNS that will be the only one used.
GlobalProtect does not allow for such configuration, making it possible for a rogue access point to deliver via DHCP an arbitrary DNS that will be used by the Global Protect client when connecting to the gateway.

GlobalProtect warns the user when there is a mismatch between the certificate’s CN and the domain name. However, users can still connect to a rogue GlobalProtect gateway by ignoring the warning and clicking a button on the dialog box, thereby potentially compromising security.

Later, we proved that it was possible to impersonate the configured portal and avoid this warning message.
This configuration injection can be used for many different things, and even allow for Remote Code Execution using HTA files or forcing an update.

Certificate Verification Bypass

Full chain certificate verification could be enforced by configuration, by setting the full-chain-cert-verify option to yes.

Once this setting is enabled, the user cannot connect to an unsecure portal, even willingly, as the popup dialog allowing to bypass the certificate check is no longer displayed.

The certificate check is now also a condition for adding a new root CA certificate from the configuration.
By default, this setting is set to false, which means that default configurations are still vulnerable to this attack (reference).

Palo Alto suggested that we turn this setting on after the first demo of our full chain exploit leading to code execution.

However, it appeared that verification could be bypassed, which increased the global severity of the full chain exploit.
Prior to connecting to the gateway, GlobalProtect executes a login workflow as defined in the response to the first request, wich is sent to the /prelogin.esp URL of the GlobalProtect portal.
Once the client reversed, it appeared that the certificate verification was only applied on this endpoint.

In practice, GlobalProtect authentication is often delegated to an enterprise-managed IdP using SAML. The login is made through an embedded browser. After checking manually, it seemed that the certificate verification could not be bypassed on these particular endpoints.

Once the user/password/MFA was entered and validated, the SSO service redirects the user to the SASE portal on the /SAML20/SP/ACS endpoint, which delivers the pre-login cookie. This request could be impersonated to deliver a malicious HTA file.

However, the user received a warning about an unknown certificate that had to be accepted in order to deliver our exploit. This prelogin cookie is then used by the PanGPA.exe process for requesting the configuration using /get_config.esp.

During this particular step, the client did not perform proper certificate verification for the portal’s certificate, as any certificate with the correct Common Name (signed by any CA, even invalid) was accepted: this allows us to impersonate the GlobalProtect portal.

The EvilRedirector is a purpose-built Python tool designed to exploit this misconfiguration. By leveraging the Twisted framework for asynchronous communication and OpenSSL for TLS/SSL interception, this tool intercepts and manipulates network traffic to redirect users to malicious endpoints. It dynamically monitors sockets creation thresholds and triggers redirection to an “evil portal” or gateway.

Evil Root CA injection

A root CA is responsible for issuing digital certificates, which are used for authenticating websites, software, and users. If a malicious root CA is installed on a Windows system, it can issue fraudulent certificates that can be used for impersonation or adversary-in-the-middle attacks, compromising the authenticity of websites and individuals. Malicious root CAs can also be used to install malware on a system. If a root CA is compromised, it can be used to push malware to any Windows device that trusts it, providing attackers with an entry point into the system and potentially compromising the entire network.
In this case, PANGPS installed a new Root CA as System based on the data received from the /global-protect/getconfig.esp portal endoint inside the <root-ca> tag.

The root CA is only inserted if the portal is considered secure by the service. This operation checks if the portal certificate is valid and if the CN corresponds to the URL used. In the default configuration where any user is able to change the portal used, the user may use a simulated portal with a legitimate certificate to execute this operation.
In the case of locked configuration (like Michelin), the attacker could use the Untrusted DNS Usage & Certificate Verification Bypass to insert a root CA.
This makes it possible for an unprivileged user to add an arbitrary certificate to the Computer Root CA trust store, which can lead to a second privilege escalation, by using the update feature to install malicious .msi file, signed by this newly added CA.

Embedded Browser ecosystem

In our example, an IdP was used to login. Once the portal is reached, an embedded browser is launched to display the login web page for SAML authentication.
In our configuration, the embedded browser appeared to be Internet Explorer on a Michelin laptop and Edge on Windows 11 vanilla. This will prove to be interesting for us.

What is interesting here is what happens when the browser attemps to display a malicious HTA file.

If the evil portal is located in a remote network then a warning message is displayed prior to the execution but if the client tries to connect to a portal that is in the trusted zone (which contains the local network by default), the warning is bypassed.

ActiveX is also available on both versions, however in our configuration, security configurations prevented us from loading any plugin.

Interestingly, the out-the-box version on Windows 11 allowed ActiveX plugins to be loaded. Only code signature was required for executing the payload.

Unfortunately, as mentioned later, this check could be bypassed using root CA certificate injection, making it possible to execute arbitrary code.

These pages could be displayed using a simple simulated portal that enables an external authentication with a SAML request.

Soft Failure on Impersonation Mechanism

To avoid performing some sensitive tasks as NT AUTHORITY\SYSTEM, the PanGPS.exe service resorts to impersonation to keep the logged-on user's privileges while executing these tasks. However, it was found on multiple occasions that the code portions used for finding out which user to impersonate could fail for (at the time) unknown reasons, as it suprisingly happened multiple times to us during testing.
When failing, PanGPS.exe chooses to log the impersonation failure and simply continue with the operation that should have been impersonated, and running it as NT AUTHORITY\SYSTEM. This behavior is very risky, as it was shown that it could be exploited to escalate privileges.

While most of the bugs were caused by undetermined reasons, one easily exploitable situation was found. Right before setting impersonation privileges to the process, PanGPS.exe will try to find out which user is running PanGPA.exe, to do so it will try to enumerate active sessions on the Windows host as well as processes named explorer.exe and PanGPA.exe. If no process is found (this can be achieved on purpose as these processes can both be killed), the check will fail, and no impersonated access rights will be set, effectively leading to the action being performed as NT AUTHORITY\SYSTEM.

Weak IPC communication & Weak client disconnection

During the assessment, the article Decrypting and Replaying VPN Cookies, which focuses on reverse-engineering the encryption used by VPN cookies, had not yet been released. At the time, there was no publicly available information or research detailing the encryption mechanisms of Palo Alto GlobalProtect VPN cookies. This lack of prior knowledge or references made the assessment more challenging, as we had to independently analyze and exploit the vulnerabilities. The eventual release of this article later validated our findings and methodology, confirming that the encryption mechanisms in GlobalProtect were susceptible to decryption and replay attacks.

The Global Protect agent is composed of two processes: PanGPA.exe, which runs with the logged-on user rights, and PanGPS.exe running with NT AUTHORITY/SYSTEM rights. This design is vastly adopted among other VPNs, to allow user interaction between an UI (PanGPA.exe), and a service that can perform privileged operations like mounting a VPN tunnel (PanGPS.exe). For both components to work together, an IPC (Inter Process Communication) protocol must be used, as the service must act accordingly to what the user chooses in the UI. To do this, GlobalProtect uses local TCP communications over the locally exposed port 4767. To prevent another process spoofing the client and communicating directly with the service, a few protections are in place, however we will show that these could be bypassed.

Firstly, the communication is encrypted using the AES-256-CBC OpenSSL implementation, with a null IV, and a static 128 bit key, repeated twice. As PanGPA.exe is allowed to communicate with PanGPS.exe, we know that PanGPA somehow contains the key, and as it is run by the logged-on user, we can debug this program and extract this key from memory, allowing us to decrypt and encrypt traffic on the fly, without having to reverse engineer the key generation process.

According to our analysis, it appeared that the encryption key was the same across installations we made on the same machine. To our surprise, when we first wrote our exploit, we found that it stopped working when used against any machine other than the one used for development. After invastigating, we later realized that different keys were used on other machines. This meant that the encryption key was likely to be generated from hardware parameters, making it different across machines.

Secondly, PanGPS.exe does not accept any TCP connection on port 4767 that does not originate from a program named C:\Program Files\Palo Alto Networks\PanGPA.exe. This guarantees that the program is indeed the client that was written by Palo Alto Networks, as an unprivileged user cannot simply replace this program with a rogue client, since unprivileged users do not have write access to C:\Program Files\Palo Alto Networks.

A way to bypass this protection is to abuse WSADuplicateSocketW to duplicate the socket already opened by PanGPA.exe and send traffic through this socket, as PanGPS.exe already considers this socket safe, this allows a rogue client to communicate with the service directly and send commands to it. We rewrote a Proof-of-Concept ourselves, but the technique and code were previously documented under the name "Shadowmove" here.

By combining the dumped cryptographic keys and the duplicated socket it is then possible to write a rogue client sending arbitrary commands to the PanGPS.exe service by instrumenting PanGPA.exe.

All the messages are formatted using XML and specify a <type></type> attribute, allowing them to be recognized on both ends. Depending on the type of message, its content can vary greatly, containing all the needed options for the specific type of message.

Now all we have to do is encrypt our message, and format it to fit PanGPS's expected format, composed of a hex-encoded size element, which is a few bytes long, and the hex-encoded encrypted content.

As illustrated later, we will see that this is indeed a problem, because in addition to using insecure IPC communication, the service allows the client to perform a number of potentially dangerous operations that could not be tested in the given time of the analysis (two weeks). However it was shown that at least one of them allowed a privilege escalation from any unprivileged user to NT AUTHORITY\SYSTEM.

In general, the client holds a lot of power regarding the behavior of the PanGPS.exe service. It is possible for the client to issue disable requests that will disconnect the VPN tunnel, allowing the user to bypass all corporate restrictions without administrative rights.

Note that while the request needs a valid password (pwd) attribute to be accepted, this password can be read by either:

• reading the log files panGPA.log and panGPS.log during the first connection to the gateway in dump mode, as the entire gateway configuration is then dumped in the log output.
• proxifying the HTTPS traffic from the panGPA.exe process and reading the configuration sent by the gateway.

Weak Update mechanism

Update installations are done using the following procedure:

1. PanGPA.exe requests the update link to the current portal using /global-protect/getmsi.esp endpoint. According to the nominal behavior, the client is redirected to a S3 bucket owned by Palo Alto Networks.
2. PanGPA.exe downloads the latest version of Global Protect from Palo Alto Networks website.
3. PanGPA.exe sends an update message to PanGPS.exe, indicating the location of the file that was downloaded.
4. PanGPS.exe verifies the signature of the .msi file.
5. If the signature is valid and the issuer of the certificate is named exactly 'Palo Alto Networks', copy the file to C:\Program Files\Palo Alto Networks\Global Protect.msi.
6. Impersonate the logged-on user and delete the original .msi file.
7. Check the signature again.
8. If the signature is correct, install the .msi file.

While this way of updating certainly protects against installing an arbitrary unsigned .msi file, the file deletion operation is what interests us here. As was presented earlier, the impersonation routines of Global Protect are weak and can be bypassed in a way that will force the operations to run as NT AUTHORITY\SYSTEM. It is possible to then replace the .msi file to be deleted with a symlink (using James Foreshaw's technique) to trigger deletion of an arbitrary file on the system, which ultimately leads to privilege escalation.

By replacing the .msi file at the last second with a symlink to C:\Config.MSI::$INDEX_ALLOCATION (::$INDEX_ALLOCATION is a NTFS trick allowing us to delete a folder instead of a file) and running the exploit provided by Zero Day Initiative, it was proven possible to escalate privileges to NT AUTHORITY\SYSTEM.

Note that while the main attack vector relies on a race condition to trigger the deletion of C:\Config.MSI, ZDI's exploit uses a clever trick, involving OPLocks, to achieve the same results reliably without any race condition. We will use a "bait and switch" approach, in order to trick the PanGPS.exe process into validating our symlink by making it point to a valid .msi file for the few first times when a check is being made, and using OPLocks, we will switch our symlink to point to the C:\Config.MSI folder, which will make the PanGPS.exe process delete the folder for us, allowing us to escalate our privileges by using ZDI's technique.

A full exploit has been developed by the Michelin CERT team. The exploit performs the following operations:

1. Retrieving the encryption key from memory by debugging PanGPA.exe.
2. Restarting PanGPA.exe.
3. Hijacking the TCP socket used by PanGPA.exe for IPC.
4. Setting up a symlink chain for a given .msi file to a legit GlobalProtect msi file.
5. Killing both PanGPA.exe and explorer.exe.
6. Start the installation of a .msi file as an unprivileged user, and set an OPLock on it that will serve as trap.
7. Running ZDI's exploit, in order to prepare the "file deletion to SYSTEM" primitive.
8. Sending an update message to panGPS.exe pointing to the symlink.
9. After GlobalProtect is done checking the .msi file, our symlink chain will point to the C:\Config.Msi folder.
10. Once the folder is erased, an OPLock will be triggered to insert a malicious .rbs file that will insert a HID.dll file inside C:\Program Files\Common Files\microsoft shared\ink\ upon cancelation of the install.
11. The install will be canceled, and the DLL file will be created.
12. Opening osk.exe and pressing CTRL+ALT+DEL will open a shell as NT AUTHORITY\SYSTEM.

Important note:
PanGPA.exe should normally be restarted by PanGPS.exe when killed, making the exploit fail. However it was discovered that keeping an handle open to the socket that was used by the killed PanGPA.exe somehow prevented PanGPA.exe from restarting as a side-effect. There are probably other simpler ways of keeping the process from starting normally, but this is the trick we used in our own exploit.

Conclusion

This research into Palo Alto GlobalProtect vulnerabilities demonstrates how small misconfigurations and overlooked security controls can escalate into severe compromise scenarios.
By exploiting weaknesses described in this article, attackers can achieve remote code execution and privilege escalation.

While Palo Alto Networks has remediated the critical remote-exploitation vector in its recent updates, our analysis indicates that a notable attack surface enabling privilege escalation persists. Weak inter-process communication mechanisms and arbitrary file deletions provide avenues for attackers to gain elevated privileges. Recent vulnerabilities (CVE-2025-0120 and CVE-2025-0131) corroborate this conclusion.

These weaknesses, if left unaddressed, could allow unprivileged users to compromise systems entirely, even in environments running the latest versions.
Organizations should remain vigilant, as these privilege escalation vectors highlight the importance of continuous testing and hardening of both configurations and inherent software mechanisms to mitigate potential risks effectively.

Timeline

Acknowledgement

I would like to extend my heartfelt thanks to my colleague Yassine Bengana from Abicom for his outstanding contribution to the research and writing of this article. His active involvement and expertise have been instrumental in the depth and quality of this work.