Ransomware has become a huge problem in the last few years, and the task of detecting it remains a challenge. This piece provides some examples of SIEM rules for detecting common
ransomware behaviors, including high-frequency file deletion, process termination/service termination, ransomware extension files and more.
Using Your SIEM to Detect Ransomware Attacks
Companies use different software to detect ransomware attacks, such as AV, endpoint detection and response (EDR), and SIEM solutions. In the case of a
ransomware attack, your SIEM can help in multiple stages of the infection, including detecting:
- Execution parameters the ransomware runs with
- Privilege escalation, e.g., user account control bypass using CMSTPLUA COM interface
- Disablement of Windows behavior monitoring
- High-frequency file deletion, process termination and service termination
- High-frequency creation of ransomware notes
- Modification of wallpaper
- Persistence techniques (e.g., scheduled tasks, registry run keys, Windows services)
- Ransomware extension files (e.g., .clop, .psfux, .lsnwx)
- Deletion of volume shadow copies
- Data exfiltration (e.g., Rclone usage)
SIEMs like Splunk offers tips for writing rules to detect Clop, DarkSide and REvil ransomware. Below, we provide some Splunk rules for detecting the Conti ransomware. Please note: Not all rules apply to all ransomware families.
- Detecting execution parameters (three cases eliminated because of false positives - see screenshot below)
- High-frequency creation of ransomware notes (usually called readme.txt – see screenshot)
- Deletion of volume shadow copies (wmic and COM objects – see screenshot below)
Common Ransomware Rules Pitfalls
Some common mistakes to be aware of when writing detection rules for ransomware include:
- Creating a rule that doesn’t match the desired behavior. For example, in the case of the Conti ransomware, it doesn’t make sense to create a rule that detects the ransomware extension files (.lsnwx), because the malware uses the MoveFile API to rename the targeted files, and it doesn’t generate FileCreate events (Event ID 11).
- Going too broad. Some teams try to create rules designed to capture as many ransomware families as possible, but this tends to generate too much noise. It’s better to refine or revise the rule for each family (as we’ve done in the case of the first rule for Conti ransomware).
- Reinventing the wheel. It’s always easier to use a preexisting and well-tested rule vs. writing your own from scratch. However, sometimes an old rule won’t detect new versions of ransomware. In that case, you should generalize the detection (for example, instead of looking for .psfux and .lsnwx Conti ransomware extensions, use a regex such as \.[A-Z]{5} to capture both cases).
Getting Started with SIEM
A SIEM solution can be very helpful in mitigating
ransomware attacks. To improve your chances of success organizations should consider:
- Do your homework: Before creating a detection rule, always research to see if there is a similar rule available.
- Test in a virtual environment: Download Splunk Enterprise and install it on a virtual machine. Then download and run a ransomware sample, and use the rules described above to detect the malicious activity.
- Take a holistic approach: A SIEM solution should be just one tool in your arsenal against ransomware activity. Be sure to take a holistic approach to detection that includes EDR, AV and regular patching.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.