Evil XDR: Researcher Turns Palo Alto Software Into Perfect Malware

Source: Maurice Norbert via Alamy Stock Photo

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 company’s 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.

A Devil’s Bargain in Cybersecurity

There is an inescapable devil’s 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 can’t 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. “I’d 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 isn’t malicious.

A lightbulb switched on when he discovered a series of plaintext files the program relied on more than most.

How to Turn XDR Evil

“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 wouldn’t 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 wouldn’t have sufficed, so he used a hard link: the computer’s 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 it’s working. I can hide the malicious activities from the user. Even for an action which would’ve been prevented, the XDR won’t provide a notification. The endpoint user will see the green marks that indicate everything is OK, while underneath I’m 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 program’s nose.

The Fix Palo Alto Didn’t Make

Palo Alto Networks was receptive to Cohen’s 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 Cortex’s 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 wouldn’t be much of a deterrent for attackers, so after discussing the matter, he and the security company agreed that they didn’t need to change that. As he notes, “The XDR eventually needs to understand what to do. So even if it’s 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.”

About the Author(s)

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes “Malicious Life” – an award-winning Top 20 tech podcast on Apple and Spotify – and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts “The Industrial Security Podcast,” the most popular show in its field.