Overview
As revealed in the 2022 Unit 42 Ransomware Threat Report, attackers are extorting an increasing amount of money from victims using ransomware. To improve their security posture, many organizations want to test their security products and validate if they can prevent never-before-seen ransomware without resorting to running malware, but are these simulations good enough?
In this article we will go through the building blocks of a ransomware, which tactics and techniques attackers leverage as part of a ransom attack, and what are the main faults and merits of the existing ransomware simulators.
Ransomware building blocks
Ransomware is a piece of software that generally implements the following techniques in order:
- Initial access can be done in multiple ways, usually phishing, leveraging valid accounts on externally open services or by exploiting public-facing services.
- Execute code using any execution tactic, usually leveraging multiple techniques to evade detection.
- Optional - injects code into a trusted context such as a system service
- Optional - disable the existing security software
- Discover existing drives, removable media, shared drives and shares
- Optional - laterally move to other hosts and infect them with the same ransomware code, starting from step #2. This is usually done leveraging exploits and by stealing credentials.
- Deletes existing backups to hinder recovery
- Enumerates existing files by iterating over all discovered resources in step #4, encrypting every file that the author deemed relevant - sometimes based on specific extensions (such as documents), sometimes some folders are excluded (like system folder) and sometimes only specific folders are encrypted (such as the documents, pictures and the desktop)
- Optional - send original file content prior to the encryption
- for an increased ransom potential.
- Opens a C2 channel and sends a message to the attacker with the host details & encryption key
- Drops a visible ransom note
- Optional - modifying browser homepage, desktop wallpaper and more
A typical ransomware attack sequence
Ransomware simulators
Looking at all of these steps done by ransomware, let’s try and evaluate existing ransomware simulators and see where they fall short:
Blunder #1 - Encrypting the files you dropped
As many ransomware simulator authors do not want to affect the existing system and are aware that their code might be used by malicious actors, they opt to code the simulation to drop new files on the systems and then encrypt them using the same context. This sounds like a valid test but it doesn’t recreate real ransomware. If endpoint protection products blocked this type of activity, they would also block many legitimate tools. Many existing tools drop files onto the disk and then manipulate them; even the simplest compression tool will behave similarly.
Since the Cortex XDR agent’s anti-ransomware module is focused on preventing only real ransomware activity, by design it ignores cases where the process encrypts the files it drops as no ransomware really behaves like that. Building a detection that blocks encryption for files that the same software drops will result in blocking legitimate backup, compression and other software as many of these perform similar actions as part of their standard operations.
Example of tools implementing this incorrectly:
- QuickBuck
- Ransomware-Simulator - only encrypts remote directories
Example of tools implementing this correctly:
- PSRansom (depends on the configuration done by the operator)
- Py-ran (depends on the configuration done by the operator)
Blunder #2 - Dropping known extensions
Some ransomware simulators do not even encrypt, but simply drop empty files with extensions that ransomware have been seen using in the past. This kind of test only verifies indicators of compromise (IOC) based detection mechanisms as these are known cases and these are easy to bypass and mainly test how much effort is being put into tracking each ransomware family and not true zero-day behavioral protection. This test has merit when testing classical signature-based endpoint products, but attackers can easily evade these IOC-based detections in real world attacks. Behavioral-based detection is a much more effective way to block quickly evolving ransomware. As a result, using rare IOCs to simulate ransomware, such as dropping empty files, is not a good way to test ransomware protection.
Example of tools using this technique instead of real ransomware behavior:
Blunder #3 - Not deleting backups
A critical aspect of being able to ransom a victim is deleting the existing backups prior to encrypting to inhibit recovery. This crucial step is often not executed by ransomware simulation tools and it’s a critical control point for security providers to provide protection. As long as the backups are intact there’s still hope to recover all the missing files and to ignore the ransom entirely by doing a rollback. Cortex XDR has multiple mechanisms to help prevent deleting and disabling backups and prevents ransomware even prior to starting the encryption process by blocking this activity.
Example of tools not deleting backups:
Example of tools implementing this correctly:
Blunder #4 - Context is everything
Ransomwares usually act from specific contexts, sometimes as a full blown portable executable, sometimes using living off the land techniques like LOLBINs and sometimes by injecting into other processes. Most of the simulation tools we have seen require a user to manually execute the tool, usually by executing a script or using a UI which changes how behavioral protection mechanisms observe those activities. Real ransomwares act quite differently from a behavioral perspective, thus enabling more protection opportunities. Cortex XDR uses context to decide if the activity is legitimate or not, so that backup tools will be able to work without issues, but if malware injects code into the backup service, it would be blocked.
Example of tools not implementing real ransomware context:
Example of tools implementing this correctly:
- QuickBuck - using the macro staging capability
Blunder #5 - No command and control
No ransomware operator can ransom you without knowing that you’ve been ransomed, and they can’t really decrypt your files without knowing which key was used. Most of the ransomware simulation tools we’ve looked at didn’t implement a command and control (C2) channel that sends the encryption key or even fakes a connection.
Cortex XDR Analytics and NGFWs can help provide C2 coverage and might block the connect backs to the ransomware, and in most cases blocking or detecting malware activity prior to executing the encryption payload, preventing a successful attack.
Example of tools not implementing C2:
Example of tools implementing C2:
Blunder #6 - No remote encryption and shared drives
Many ransomware operators understand that in many cases the interesting files do not reside on the workstation itself but on shared drives used by the entire organization and have adapted their tools to encrypt those as well. Most ransomware simulation tools do not scan for remote drives let alone encrypt remote files. This is usually the main concern for an organization and without simulating it, you can't verify the protections against it.
Cortex XDR helps protect against encryption from unmanaged devices and to unmanaged devices.
Example of tools implementing remote encryption:
Blunder #7 - Only remote encryption and shared drives
While there’s merit in testing remote encryption, none of the ransomware we’ve tested actually implement remote encryption without local encryption. Some ransomware simulation tools do not implement local encryption at all and that doesn’t replicate real ransomware behavior.
Example of tools implementing remote encryption without local encryption:
Blunder #8 - Using real ransomware, but not executing it
Some tools do opt to use real ransomware samples in a controlled environment to test coverage but in many cases the tools are configured to only drop the samples or do not execute them with the proper context or command line arguments to trigger a full encryption cycle. By dropping or executing without context, the behavioral aspects of the ransomware do not happen and the test coverage only pertains to IOC and static analysis mechanisms, thus not really testing against zero-day ransomware.
Summary
| Initial access/
Execution |
Defense evasion / Correct context | Disables security mechanisms | Deletes backups | Enumerate existing files | Exfiltration of files prior to encryption | Encrypts local files | Remote encryption | C2 channel | |
|---|---|---|---|---|---|---|---|---|---|
| QuickBuck | V | V | X | V | X | X | V | X | X |
| Ransomware-Simulator | X | X | X | X | V | X | X | V | X |
| ShinoLocker | X | X | X | V | V | X | V | X | V |
| PSRansom | X | X | X | X | X | V | V | X | V |
| CashCatRansomwareSimulator | X | X | X | X | V | X | X | X | X |
| Py-ran | X | X | X | X | X | X | V | X | X |
Conclusion
When testing ransomware activity using ransomware simulators, it’s important to understand the limitations of each tool to assess the meaning of successful or unsuccessful detection. As shown in this blog post, most ransomware simulators have shortcomings, and none of them provide a full simulation of a real ransomware attack.
While it’s possible for security vendors to update their products’ defenses to detect the IOCs and techniques used by today’s ransomware simulators, we believe this strategy doesn’t demonstrate true security efficacy and may instead provide organizations with a false sense of security. The only accurate way to validate ransomware protection is by executing actual ransomware in an isolated environment like the recent ransomwares and wipers used in Russia-Ukraine cyber attacks, as well as the latest variants of REvil, Conti, Ryuk, and other real world ransomware.
Why are some simulation tools not listed here?
We have opted to test only a set of example open source (OSS) tools that can be code reviewed and verified that do not have any functionality that is hidden to not do a disservice to any vendor that provides a ransomware simulation tool in a closed source manner. We do not endorse any of these tools and there are many other OSS and closed source ransomware simulation tools that we haven’t looked into that might behave in similar manners to the tools we have listed.
Additional Resources