For those who missed my initial blogpost about Capricorn, I’ll give a short recap about the program its functionalities. Capricorn creates folders and files on the computer. These files are monitored and a change to any of the files will trigger Capricorn to commence shutdown, regardless of the open files on the computer. These folders are called honeypot folders, because the ransomware is likely to encrypt files in these folders.
After the computer is shut down, the user should use a live boot, such as a Linux distribution, to back-up important files. When the computer is properly booted again, there is a log on the desktop which contains the location of the files in the honeypot folders which have been encrypted and a timestamp of the happening. Afterwards, one can use the “-scan” option to scan for encrypted files in the honeypot folders. The honeypot concept worked great during the development of the first stable version, but how would it perform when I used malware samples that have been used in the wild?
Testing Capricorn with actual malware
Upon testing the first stable release of Capricorn with malware samples that have been spotted in the wild, I wanted to test how effective this approach would be. The hashes of the tested samples are shared in the last part of this blog.
None of the malware samples that I tested were able to encrypt anything outside the honeypot folders. From previous testing, the amount of encrypted files in the honeypots using the same sample can differ a couple of hundred files each time the sample is executed.
The single exception to this is WannaCry, which didn’t start browsing down the user’s home directory into the Documents, Downloads and similar folders. WannaCry was started from the Desktop folder on the test machine. Yet, it only managed two encrypt two files outside the honeypot folders. Needless to say, this is significantly less than without the usage of Capricorn. The explanation for this is rather simple, as WannaCry also encrypts files in the folder it was started from.
The test environment
In the laboratory, I tested the ransomware samples on an unpatched Windows 10 system. Windows Defender was completely disabled during the testing and the internet adapter of the virtual machine was not connected nor plugged in to prevent a sample from spreading.
On this system, I placed multiple files filled with the text ‘MY GRADES ARE GETTING WORSE AND WORSE. WHAT DO I DO?’. The text is bold, cursive and underlined because this causes the rich text file (RTF) to contain more than just the text. Using the same text in the emulated user files, I avoided any ‘lorum ipsum’ checks that the ransomware might do but also made it easy for me to see if anything changed in a file without having to dig deep into the possible changes.
The execution and aftermath of every sample I executed, has been recorded and can be viewed here. The set-up and the settings of the VM, the sample itself are known, so anyone can reproduce the results as they are shown in the videos. If you’ve got additional samples you want to test, feel free to do so, I’d love to see the results of them.
Impact on the user
After the ransomware executed, got detected and the system was shut down, I booted the virtual machine. In the log, which is located in the desktop folder, one can view the changes that were detected, together with a time and date stamp. After checking the log, I ran the “-scan” option of Capricorn with the encrypted extension to detect the amount of encrypted files in the honeypots. In some videos the scanning is done within seconds, even though there are >40,000 files in the folders. This is because of caching: it wasn’t the first time I executed the search function in a previous take of the recording but made a mistake somewhere else in the video.
In conclusion, the impact on the user is minimal. Generally, no files were lost besides the two files that were encrypted by WannaCry. Using the “-repair” function after the system booted, the user could’ve proceeded with their day to day tasks. Servers filled with files of users would’ve rebooted and would be safe again. Although it is hard to say, a global ransomware outbreak of these tested samples would’ve been prevented using Capricorn.
This does not mean that a future version is not able to encrypt user files. Additionally, I tested the Petya ransomware (not the one used in global outbreak called NotPetya, but the older version) as well and there was no success in blocking this attack. The approach of Petya is completely different and does not encrypt anything in the honeypot folders, as it rewrites the master boot record (MBR) and then causes the machine to blue screen, which forces a reboot.
Currently, I’m investigating how to speed up the shutdown process. One idea I have, is to force a Blue Screen of Death (BSoD) to instantly shut the computer down. Another improvement I have, would be to add headers to the honeypot files. This would make it even harder for ransomware to distinguish the difference between my honeypot files and actual files on the user’s computer.
If you’ve got feedback, suggestions, samples or anything related to this subject to share with me, feel free to e-mail me at [info][at][maxkersten][dot][nl]. Additional videos of users who test samples and record it will be mirrored on my Youtube channel after I verified the test.