Evil XDR: Researcher Turns Palo Alto Software Into Perfect Malware

It turns out that a powerful security solution can double as even more powerful malware, capable of granting comprehensive access over a targeted machine.

A creative exploit of Palo Alto Networks extended detection and response (XDR) software could have allowed attackers to puppet it like a malicious multitool.
In
a briefing at Black Hat Asia this week
, Shmuel Cohen, security researcher at SafeBreach, described how he not only reverse-engineered and cracked into the companys signature Cortex product but also weaponized it to deploy a reverse shell and ransomware.
All but one of the weaknesses associated with his exploit have since been mended by Palo Alto. Whether other, similar XDR solutions are vulnerable to a similar attack is as yet unclear.
There is an inescapable devils bargain when it comes to using certain kinds of far-reaching security tools. In order for these platforms to do their jobs, they must be granted highly privileged carte blanche access over every nook and cranny in a system.
For instance, to perform
real-time monitoring and threat detection
across IT ecosystems, XDR demands the highest possible permissions, and access to very sensitive information. And, to boot, it cant be easily removed. It was this immense power wielded by these programs that inspired in Cohen a twisted idea.
I thought to myself: Would it be possible to turn an EDR solution itself into malware? Cohen tells Dark Reading. Id take all these things that the XDR has and use them against the user.
After picking a laboratory subject — Cortex — he began reverse-engineering its various components, trying to figure out how it defined what is and isnt malicious.
A lightbulb switched on when he discovered a series of plaintext files the program relied on more than most.
But those rules are inside my computer, Cohen thought. What would happen if I manually removed them?
It turned out that Palo Alto had thought of this already. An anti-tampering mechanism prevented any user from touching those precious Lua files — except the mechanism had an Achilles heel. It worked by protecting not each individual Lua file by name, but the folder that encapsulated them all. To reach the files he wanted, then, he wouldnt have to undo the anti-tampering mechanism, if he could just reorient the path used to reach them and bypass the mechanism altogether.
A simple shortcut probably wouldnt have sufficed, so he used a hard link: the computers way of connecting a filename with the actual data stored on a hard drive. This allowed him to point his own new file to the same location on the drive as the Lua files.
The program was not aware that this file was pointing to the same location in the hard disk as the original Lua file, and this allowed me to edit the original content file, he explains. So I created a hard link to the files, edited and removed some rules. And I saw that as I removed them — and did another little thing that caused the app to load new rules—I could load a vulnerable driver. And from there, the whole computer was mine.
After taking complete control in his proof of concept attack, Cohen recalls, What I did first was change the protection password on the XDR so it cannot be removed. I also blocked any communication to its servers.
Meanwhile, Everything seems like its working. I can hide the malicious activities from the user. Even for an action which wouldve been prevented, the XDR wont provide a notification. The endpoint user will see the green marks that indicate everything is OK, while underneath Im running my malware.
The malware he decided to run was, first, a reverse shell, enabling full control over the targeted machine. Then he successfully deployed ransomware, right under the programs nose.
Palo Alto Networks was receptive to Cohens research, working closely with him to understand the exploit and develop fixes.
There was one vulnerability in his attack chain, however, that they chose to leave as is: the fact that Cortexs Lua files are stored entirely in plaintext, with no encryption whatsoever, despite their highly sensitive nature.
That seems alarming, but the reality is that encryption wouldnt be much of a deterrent for attackers, so after discussing the matter, he and the security company agreed that they didnt need to change that. As he notes, The XDR eventually needs to understand what to do. So even if its encrypted, at some point in its operation it will need to decrypt those files in order to read them. So attackers could just catch the content of the files then. It would be one more step for me in order to read those files, but I can still read them.
He also says that other XDR platforms are likely susceptible to the same kind of attack.
Other XDRs will implement this differently, maybe, he says. Maybe the files will be encrypted. But no matter what they will do, I can always bypass it.

Last News
▸ ArcSight prepares for future at user conference post HP acquisition. ◂ Discovered: 07/01/2025 Category: security	▸ Samsung Epic 4G: First To Use Media Hub ◂ Discovered: 07/01/2025 Category: security	▸ Many third-party software fails security tests ◂ Discovered: 07/01/2025 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Evil XDR: Researcher Turns Palo Alto Software Into Perfect Malware