Estimated Reading Time: 6 minutes

What do all of the above have in common? Let’s see shall we?

Before we go any further, I should state that this vulnerability was reported to Palo Alto and it was determined that

“it does not impact the confidentiality, integrity, or availability of the agent. No agent updates or content updates will be created for this.”

This is true. The much vaunted CIA triangle for the agent remains unimpacted. It just makes it super easy to deploy ransomware on any systems ‘protected’ by Cortex XDR. Others have also found the knowledge of the canary files the last hurdle – see https://www.metabaseq.com/honey-i-bypassed-the-xdr-with-ransomware/

Onwards we go then – imagine you are a ransomware author, and you want to make sure that when you pop GlobalCorp Inc you don’t want to have your attack caught early because to tried to encrypt one of those pesky canary/decoy files that some EDRs use to alert on.

 It sounds good in principle, but how would you know which files are the decoys? Take Cortex for example (https://www.paloaltonetworks.co.uk/cortex/endpoint-detection-and-response) – it has a folder C:\ProgramData\Cyvera\Ransomware\<18 digit random number>\ where it stores these files. We can’t brute force the directory name and as a standard user we don’t have read permissions on the \Ransomware folder.

Figure 1.Pretty unlikely we are going to guess these files for exclusion

Turns out Cortex is doing something rather odd that lets you discover the files, but also the directory they are in so you can grab a handy list of files that you shouldn’t touch. Which is great if you are a ransomware author, not so great if you are relying on the canary files to save you.

I noticed this when I was doing some web app testing from a machine that had Cortex installed. I went to install one of my standard plugins for working with JWTs (https://github.com/PortSwigger/token-refresh <- shameless self promotion, sorry I never got it working for Mac)  and hit the Burp Open File Dialog

Figure 2. I don’t remember downloading them!

What the heck are all those files? Checking in Explorer I see something completely different (source: trust me bro – I can’t show you that screenshot, too much identifying information).

Trying to figure out what they were, I fired up ProcMon and found a path :

Figure 3. So that is where you actually live

A little Googling took me to here : https://live.paloaltonetworks.com/t5/cortex-xdr-discussions/strange-files-malware/td-p/552442 where it was stated (by I believe an official Palo Alto employee) : “these are honeypot/decoy files deployed by cortex xdr agent to prevent against ransomware events. The methodology of ransomware detection of Cortex XDR is by the method of deploying honeypot files in different locations depending upon the mode and any attack which is vectored at file modification will be prevented when the attacker process touches any of these files.”

Great – OK, now we know what they are, I’m not being hacked by the Italians for my famously good creamy pasta recipe, we can stand down. But curious minds and all that. Let’s look at another directory and see if we see the same thing

My user folder

Figure 4. Nothing to see here

Looks all good – but what does Java see

Figure 5. Are you OK Java? You want to talk about it?

Why are they different? Different behaviour is good though, it gives us a reference to work from – find the differences, examine them and try and make something work. What about Explorer –

Figure 6. Again, nothing to see here

Hmmm – same as from the command line.

At this point, it looks like Cortex tried to hide the files from the user and I guess Java has a different methodology of accessing the directory structure (or there is no hook present to hide the files from it). I guess you could just take a command line output of all the files and pump it into the ransomware encrypter but it seems more elegant just to have an exclusion list, so let’s see if we can make one.

 Let us have a peek and see if there are any other ways of spotting a difference. PowerShell perhaps?

Figure 7. Either we have decoy files, or Cortex has started reading my blog posts and then giving them a name …

Well that looks promising. We have a way of discovering files that do not exist from the command line but do from PowerShell. We can’t realistically be dropping ProcMon and interacting with files each time to figure out where they actually are, so let’s have a peek at the file properties

From within PowerShell, we can do a Get-Item <filename> | Format-List -Property * and have a look at the output

Figure 8. Hello there

Bingo. So all we need to do now is automate taking a directory listing from a place (or several) that are likely to have canary files in from the command line, again from PowerShell, look at the differences and retrieve the Target properties for those files. Once we have a target directory, anyone can read the contents thanks to the Modify flag (I guess you need to be able to interact with them to trigger cyserver):

Figure 9. Properties for the Ransomware folder

Let’s do that in PowerShell – purely because that is much more likely to exist on a system and absolutely nothing to do with the fact that I can’t code for toffee in Java. The below script starts in the user folder and if nothing is found, continues to walk through common directories (downloads, documents etc) to see if it can find a difference

Figure 10. Tooling output

It is worth noting however, for those eagle eyed amongst us, that not all of the links are one-to-one translations – i.e. you’re not going to find the same filenames in all of the locations – if we refer to the previous image :

Figure 11. Not 100% Mapping

Simple way around this – they all share the original file attributes and naming convention (first 5 characters are the same for multiple filetypes). There would be very little work involved in building a template to say ignore jpg files starting with XORXOR or sql files starting with ZZZZZ, or even just ignore pst files with a size of exactly 350000

Let’s see if we can make this a thing and hopefully show why I believe this to be important, even if the CIA of the agent itself is unaffected.

Let’s modify Honeypot.ps1 and instead of printing out the list of files found, let’s just feed that into an array of filetypes and filesizes – we can ignore the filename as we can see that that doesn’t always translate and this would be the easiest route to patch this attack vector.  We can also ignore a lot of the files that come back with a zero byte file size – pointless encrypting those anyway.

The CIA_IS_OK script is just a simple check of files in a target directory to see if they match any of the known file types. If they do match, they are then checked for file size. If the file size does not match any of the files in the Cyvera\Ransomware folder then it is considered a viable candidate and encrypted. This script is slow and just XORs the target file with 0xBB so not true encryption as such, but enough to show that knowledge of the canary files is enough to not need to tamper with the CIA of the agent and achieve your goal.

All Scripts can be found on my GitHub : https://github.com/t3hbb/CortexCanary/

Figure 12. BuT ThE CiA oF ThE AgEnT iS Ok

Disclosure Timeline

• 07/06/2024 – Initial details disclosed to Palo Alto
• 07/06/2024 – Report acknowledged (D2LKJQ0GMJ) and triage started
• 12/06/2024 – Report forwarded to product team, internal ID CPATR-25032
• 11/07/2024 – Chased for further information
• 16/07/2024 – Responded indicating they were taking the final steps in the investigation
• 19/07/2024 – Deemed non-issue. No action will be taken