By Vasileios Friligkos and Florian Guilbert (security analysts)
During the last months, there has been a rather important increase in the number of new (or rather new-ish) ransomware variants on the loose. While these variants are by no means advanced or complex pieces of malware (or even new), they do pose a risk for everyone and the reason is simple: they do not care about propagation, exploitation of vulnerabilities, persistence, obfuscation or any other “advanced” malware techniques. They solely care about your data and how to cypher it in order to ask you for a ransom. So, what do they do? They spread through email campaigns –who can accuse a commercial employee for opening a “payment notification” or a human resources employee for opening a candidate’s CV – and, every now and then, they mutate in order to avoid anti-virus signatures. Occasionally, they even have the opportunity to evolve, as in the case of cryptodefense that firstly deletes the volume shadow copies and then encrypts your files, in order to prevent data recovery (volume shadow recovery was a popular technique against cryptolocker).
Inevitably, in our professional environment we have come across some cases where a system has been infected by such a ransomware and the totality of the files – locally and even remotely, on shared disks – were encrypted. And after our forensic analysis all we could say was: “Yes, you were indeed infected. Hope you have backups because there is nothing we can do. Bye now.”
Kind of disappointing…
Trying to find a solution that could help mitigate this kind of threat, we started implementing a kind of “honeyfiles” concept. The principle of honeypots is old and very well known: you create a fake “target” that will serve as a lure for any potential attacker and since the attacker as an outsider cannot distinguish between a legitimate target and your honeypot, he will be caught on the act. Awesome! So, let’s get down to the details of our proof of concept.
Implementation
We used a file system minifilter driver that monitors all I/O transactions (IRP) occurring on a drive. The minifilter used is actually minispy from Microsoft with some modifications allowing us to use it as desired. Typically, for every device object there is a driver stack where several drivers and filters process each IRP received. This is where you can find backup components, anti-virus modules etc. and the reason why we decided to intercept file access actions at that point is mainly because it is really low level (cf. chart below), secondly because it does not necessitate hooking or modifying legitimate processes and services (therefore as less intrusive as possible) and lastly because we were following the KISS principle.
Having our minifilter installed and running, we then deploy multiple honeyfiles, using file extensions that we wish to protect (.doc, .jpg, .txt, etc.), across our system on strategic locations (cf. chart below) and we launch a watchdog process, called Honeyfile Monitor, responsible to cooperate with the minifilter and detect all “suspicious actions” on the honeyfiles. What we define as “suspicious action” is every attempt to modify, delete or rename a file, which includes more than one ways to achieve the same result using combinations of IRPs and their arguments. For instance, in order to delete a file we can issue a Set Information IRP with proper arguments or issue a Create IRP with the appropriate options.
If Honeyfile Monitor detects an IRP trying to modify a honeyfile, it obtains the issuer’s PID and acts upon. So, given that the ransomware will eventually touch one of the honeyfiles and will start encrypting it, we can be certain that the malware will raise an alert.
Once we have the process responsible for the modification, the most obvious solution is to try and kill it, together with its father and why not together with its siblings and the whole family as well; you know George R. R. Martin’s way. However, as the malicious code is already executed (we did not prevent its execution, we merely detected it), we cannot trust our system since we do not know what the malware could also be doing. What if, for example, it has some kind of persistence mechanism, responsible to monitor the cyphering processes and respawn them in case of unexpected termination? Potentially, avoiding the last processed file before the termination.
The best course of action we decided to take was to either shut the machine down either intercept and block all IRPs –we already have our minifilter deployed– and prevent all modifying actions. Both solutions seem radical and will probably cause user’s data loss but given the alternative it actually remains a much preferable solution. Especially in the case where there are shared folders, on a file server for example.
Results
In order to test our PoC, we used a clean install of Windows 7 on a virtual machine where we deployed multiple honeyfiles inside different folders. We also placed several witness-files that were used after the infection as an indicator of the percentage of files that were encrypted by the ransomware. For our tests we used mainly three pieces of ransomware –Riseup, CryptoDefense and BitCrypt– and we tried placing the honeyfiles inside different folders in our system. Results show that, in the case where we have multiple honeyfiles dispersed across our user’s folders (Documents, Pictures, Desktop, etc.), approximately 60% of the witness-files were saved using Honeyfile Monitor, which actually gives us exactly what we expected to see: some files are necessarily encrypted and thus “lost” but at least we managed to save a portion of the data.
We should also ask ourselves what the malware authors could do in order to bypass this kind of technique. Simple enough, not to touch the honeyfiles. So, let’s use arbitrary honeyfile names and make the attacker try to guess the name or the naming algorithm. Sounds a lot like trying to detect DGA’s, not? Only this time it’s the other way round, it’s the attacker trying to find out how our algorithm works.
What if the malware tries to check which files were lastly modified or more generally, tries to determine which files stand out of the baseline in order to avoid them? Well, in that case we can access and modify the honeyfiles at random intervals, trying to simulate a normally used file, or any other way that will have the same result.
What if then, the malware calls its bigger brother, the rootkit, to join the fight? Well, nothing to do here in that case.
Conclusion
What is important to understand is that the concept of Honeyfile does not offer protection, does not make you ransomware-proof and even in the few and specific cases where it gets to be useful, it does not even save all of the user’s data. What it does though, is to make the job of malware’s authors a little bit more difficult and the impact of a ransomware infection less critical.
Unfortunately, such a concept cannot stand by itself: having yet another security related product to be installed on a user’s machine for such a specific threat is too much to expect. However, it would be really interesting to have instead yet another anti-virus module implementing the honeyfile concept because of three reasons:
- Anti-virus products already have file system drivers deployed
- Anti-virus products already provide multiple security services under the same hood
- Anti-virus products already have the necessary infrastructure to control a whole IT system with deployed agents while being managed by a central server
So, if anyone is ever interested in implementing such a PoC, we would be delighted to make it happen!
