The Advanced Endpoint Protection (aka. Traps, aka. Cyvera) from Palo Alto Networks have added a seperate ‘Cryptolocker module’ to its range of detection methods. In this post I will go over this particular module.
Setting up Booby Traps
Palo Alto Traps have a wide range of protection modules both for Exploits (EMET style) as well as various malware protection (sandboxing, local analysis, run restrictions etc.). Starting from version 4.1 they have also included ‘Cryptolocker sensing’ capabilities.
The essence of the module is pretty simple. It creates a range of Canary files in various directories and if ever one such file is touch by a process (ie. Cryptolocker), the offending process is immediately shut down.
The normal user is very unlikely to ever hit these files as they are ‘magically’ (Windows voodoo beyond what I have poked to) hidden even when enabling ‘show hidden items’ in the explorer.
The Canary files are not normally visible to the End user, and as such should not intervene with normal production.
However if a machine were to list the directory it would see a lot of different files with all sorts of extensions. This can be broken into two parts
- Filenames
- The filename is important as it often signifies the order of which the Cryptoware is going about its evil ways. If it is sorting by the top of the alphabet it will hit the ‘!!!!…’ filename and if goes from the bottom it will hit the ‘ZZZZ…’ first. This is done in order to minimize the impacted of the Cryptolocker by making it likely to hit a Canary file quickly
- Extensions
- creating a lot of different Canary files extensions have two purposes. Firstly the different strains of Cryptolockers targets different file extensions, so in order to catch them all multiple extensions are presented. Secondly, and more importantly, there is no telling which extensions a malware may target first so again in order to make it hit a Canary file quickly a lot of different extensions is made possible for it to hit.
When looking on a directory listing in Powershell, we can see all the different Canary files
If a process interact with on of the Canary files the local Traps agent immediately catches it and shuts down the process and generates an alert for the administrator to look at. In the example below a simple delete action is performed on a Canary file.
Trying to delete a Canary file with the powershell rm command triggers the Traps agent and shuts down the powershell instance
Looking into the Endpoint Security Manager (ESM) console we can see all the details of the ‘attack’.
This is how the resulting ESM event would appear for a Cryptolocker event
Layered Defenses are the most successful
The Traps agent is by design a multi-defense approch, meaning that many modules try to stop the same from happening. Just one of these are the CryptoLocker module.
An analogy of this is going through a minefield with several lines of mines (for this analogy we go with ten lines of mines). Each line has a fifty-fifty chance of detonating when passing it. By simple statistical math this yield a success rate of coming through the minefield as 0.5 to the power of ten equals 0,0009765625 or 0.09%
Also note that not all these ‘lines of defense’ need to be on the endpoint… also considering NGFW, IPS, Mail Security, DNS, URL, DLP, Sandboxing etc.
Multiple defensive mechanisms are vital for creating a strong protection
Below here are shown what happens if an actual current Cryptolocker (thx to Brad over at malware-traffic-analysis.net) is run on the Traps protected host. In this particular case we never get past the initial sandbox verdict of the file (which accurately is deemed malicious). The Cryptolocker module should largely be seen as ‘just’ another line of mines in case something gets past the many lines already in place.
The Palo Alto Traps agent stopping a Cryptolocker based on Sandboxing analysis alone.
Final thoughts
Is a Canary approach for Cryptolocker prevention bulletproof? By no means, but it does make it much harder for a malware navigate a file system, if it at all times needs to be aware of what files it touches. The Canary files listed in this post are the Traps 4.1 initial files but it is trivial to add others to the mix at a later stage making it much harder to evade for cryptolockers.
Using Canary files can also be highly effective on other security related challenges. They can serve as watchguard for compromised accounts and misuse of credentials and so on. At least in my opinion they should be considered for any decent security architecture as it is both cheap and easily implemented.
In other word I find that it is both a useful and ‘low hanging fruit’ that Palo Alto Networks have implemented in their, for the time being, newest Traps version (4.1).
Be the first to comment on "Palo Alto Networks Traps 4.1 – Cryptolocker Module"