Decompiling cortex-xdr-payload.exe#

Examining the strings made it obvious that this was a packed Python executable created with PyInstaller. Using pyinstxtractor-ng, it was unpacked:

pyinstxtractor-ng cortex-xdr-payload.exe
[+] Processing cortex-xdr-payload.exe
[+] Pyinstaller version: 2.1+
[+] Python version: 3.12
[+] Length of package: 9798407 bytes
[+] Found 19 files in CArchive
[+] Beginning extraction...please standby
[+] Possible entry point: pyiboot01_bootstrap.pyc
[+] Possible entry point: pytz_zip_hook.pyc
[+] Possible entry point: hook_preload.pyc
[+] Possible entry point: pyi_rth_cryptography_openssl.pyc
[+] Possible entry point: pyi_rth_inspect.pyc
[+] Possible entry point: pyi_rth_pywintypes.pyc
[+] Possible entry point: pyi_rth_pythoncom.pyc
[+] Possible entry point: pyi_rth_pkgutil.pyc
[+] Possible entry point: pyi_rth_setuptools.pyc
[+] Possible entry point: pyi_rth_pkgres.pyc
[+] Possible entry point: pyi_rth_multiprocessing.pyc
[+] Possible entry point: main.pyc
[+] Found 1366 files in PYZ archive
[+] Successfully extracted pyinstaller archive: cortex-xdr-payload.exe

You can now use a python decompiler on the pyc files within the extracted directory

The resulting .pyc files were then decompiled using pylingual. Most other decompilers could not process Python 3.12.

The decompiled code shows the file that defines the trusted CAs:

The file contains standard CAs and not just specific ones used by Palo Alto hosts. I added the Burp Suite CA certificate to this file after disabling the Cortex agent. Using a file lock prevents the agent from overwriting it again after enabling Cortex.

Analyzing Live Terminal Network Traffic#

With this modification, I could intercept the network traffic to lrc-ch.paloaltonetworks.com:

The protocol is relatively simple and lacks command signing. This looked like a ready-made C2 for attackers, too. An attacker can specify their “C2” server and send commands via WebSockets.

Method 1: Cross-Tenant#

Surprisingly, it was even possible to use the official Live Terminal GUI for this attack. For this method, the attacker needs their own Cortex tenant:

1. The attacker starts a Live Terminal session in their own tenant.
2. The WebSocket message containing the host and token (-port 443 -server lrc-ch.paloaltonetworks.com -token [REDACTED] -d) is generated. The attacker must intercept this initial message and prevent it from reaching the legitimate agent on their own machine.
3. These host and token arguments are then used to start the cortex-xdr-payload.exe on the victim’s host.
4. The connection from the victim is then received in the attacker’s tenant.

The screenshot shows the result of this attack. WinDev2104Eval is in the attacker’s tenant, and windev11-* is the victim host:

Method 2: Creating a Custom Server#

Alternatively, an attacker without a Cortex tenant could re-implement the server-side component of the WebSocket-based communication. Based on the captured traffic, this would not require significant development effort using LLM agents.

The Python code of cortex-xdr-payload.exe includes a check for the server host, but this can be bypassed in several ways. An intrusive example is editing the hosts file, but if you look closely at the code, there is a trivial logic flaw in how the URL is validated.

def run_lrc_payload(lrc_payload_config, logger):
    lrc_exit_code = (-1)
    if not lrc_payload_config.server.endswith('.paloaltonetworks.com'):
        logger.error(f'Server address {lrc_payload_config.server} is invalid')
        return lrc_exit_code

By default, the hosts file is used:

if os.environ.get('use_custom_dns_query', 'FALSE')!= 'TRUE':
        terminal_logger.info('No bypassing hosts file enforced.')

The code above, lrc_payload_config.server.endswith('.paloaltonetworks.com'):, does not check the hostname itself, but the entire URL.

attacker.com/asdf is blocked:

attacker.com/test.paloaltonetworks.com is accepted:

Therefore, you can connect it to your own server implementation simply by appending the required string to your URL path.

Prevention Rules#

The only hurdle is that Cortex has default rules to block and detect when its own processes are started by a non-standard parent process:

Bypasses for these rules will not be published in this post.

Detection#

Legitimately, cortex-xdr-payload.exe is started by cyserver.exe, the main user-mode component of the Cortex agent. Therefore, any other parent process for cortex-xdr-payload.exe should be considered suspicious (e.g., defenders can monitor Process Creation events for anomalous ParentProcess values). InfoGuard customers are already protected from this abuse since September 2025.

Disclosure Timeline#

According to our analysis with 8.9.1 and new content updates, there is no fix for the abuse and host bypass described in this post. This was tested on 2026-02-23.