Ransomware is defined as a type of malware that blocks access to data until a sum of money is paid. This niche type of cybercrime is now big business due to the rise of cryptocurrency and the ransomware as a service (RaaS) business model.
The FBI’s Internet Crime Complaint Center (iC3) stated that in 2020 reported losses from ransomware were above $4.1 billion, which is a 61 percent increase from 2019. The U.S. Treasury department identified cryptocurrency payments of $5.2 billion going to wallets associated with the top ten ransomware variants between January and June of 2021. Ransomware attacks have been reported by all industries, but government, education, and healthcare are at the top of the list for being most affected. All these statistics come from incidents reported to the U.S. government, so actual numbers are even higher.
Even with some wins against RaaS, like the recent arrest of REvil affiliates, no one expects the number of ransomware attacks to decrease. RaaS allows relatively unskilled criminals to get their foot in the door of the cybercrime industry and cryptocurrency makes the extorted money hard to trace.
Ransomware Detection and Prevention
As a cybersecurity professional, how can you prepare for a ransomware attack and prevent it from reaching the end stages of encryption and extortion? Prevention by email filtering and user training are a required start, but it’s also necessary to detect a compromise when it happens.
Users will fall for phishing and other social engineering attacks — no matter how much training they receive. For example, I saw a recent attack that started with phishing emails targeting employees’ Gmail accounts to get around corporate email filtering. Several employees fell for this leading to a compromise.
How MITRE ATT&CK Matrix Can Help Detect Ransomware
The MITRE ATT&CK matrix has been a huge development for cybersecurity as it allows professionals to collaborate, breakdown, and categorize malware.
LogRhythm Labs has identified the MITRE ATT&CK techniques most used by ransomware to help guide the development of our MITRE module and our upcoming ransomware module.
Top MITRE ATT&CK Techniques
Here are the most common top MITRE techniques used by ransomware. Most of the techniques already have AIE rule detections available in our MITRE ATT&CK module. We will be releasing the rest shortly.
- T1027: Obfuscated Files or Information
- T1059.001: PowerShell
- T1059.003: Windows Command Shell
- T1082: System Information Discovery
- T1083: File and Directory Discovery
- T1106: Native API
- T1489: Service Stop
- T1490: Inhibit System Recovery
- T1562.001: Disable or Modify Tools
Full use of the MITRE ATT&CK module requires additional auditing on endpoints to be enabled. Most of our MITRE detections rely on logs from Sysmon, PowerShell, and Security logs that show command line parameter logging. It is recommended to enable all three of these additional auditing logs.
How to Enable the MITRE ATT&CK Module:
The MITRE ATT&CK module (like all threat detection and compliance modules) is not enabled by default. You can enable it in the Knowledge Base Manager in the thick client.
Now you can go to the AI Engine (AIE) rules tab and enable the detection rules. Below, I will walk you through examples and best practices for how to go about this.
Tuning MITRE/Ransomware AIE Rules
I highly recommend letting the rules run without alarming when you first enable them. By default, our threat module AIE rules are not set to alarm. When an AIE rule is enabled, it generates an event log whenever the rule criteria are met.
You can search for these events to see how often the rule is being triggered. You can use the search criteria below to see all the AIE rules (alarming and non-alarming) that have triggered. If you reach the maximum number of results, you can try searching for one AIE rule at a time. To do this, search the Platform Manager (Events Database) for the Common Event that corresponds to the AIE rule you want to tune. AIE rules have a Common Event that is the same as their rule name.
You can look through the AIE events to find instances of the AIE rules triggering on benign, expected events that you want to tune out. I usually don’t tune out events that occur infrequently. I look for logs that occur daily that I can tune out to lower the volume of the AIE rule. You will have to drill down on AIE events that are returned in this search to get the log(s) that triggered the AIE rule. For example, I see a service account that is triggering the Native API AIE rule multiple times per day and I want to exclude it before I set the rule to alarming.
When I drill down on several of the AIE events, I find out that the service account is always running the same command and that is expected behavior.
Some fields that make good exclude filters include: Process, Parent Process, User, Host, and Command. Making an exclusion with two fields together makes it more likely you won’t accidentally exclude malicious activity. I decide to exclude User and Command together in the Native API rule. I would not want to exclude user alone in case that account is compromised and starts acting suspicious. Changes to AIE rules can only be made in the LogRhythm thick client. Include and exclude filters added to canned AIE rules will not be overwritten by KB updates to the rule.
Now that I have excluded the noisy user/command combination I rarely see a Native API event. Now I can set the rule to alarm! You may have to revisit the tuning process of changes are made in your environment. This process will allow you to tune rules before setting them to alarm so you don’t accidentally flood your alarms dashboard or enrage your security team.
When I find myself adding more than a couple exclude filters to a rule, I always question if the rule would work better non-alarming and on a Web Console Dashboard or if I want to clone the rule and make significant edits. Some MITRE rules (e.g., PowerShell) may never be good candidates to alarm on. This is because the MITRE ATT&CK doesn’t distinguish between malicious and non-malicious use of techniques. In the case of the PowerShell rule, I leave the original rule running as non-alarming and create a new similar rule that looks for PowerShell with suspicious parameters. I alarm on my custom cloned rule and can use the original rule for dashboards and threat hunts.
Testing Your Rules
Now that we have tuned our MITRE/Ransomware rules, how do we prove that they will alarm on malicious behavior? Red and Purple team exercises are a good way to prove the rules work and to make sure you haven’t excluded anything you want to alarm on. There are many options available for Red/Purple team exercises. Red Canary’s Atomic framework offers a safe way to recreate MITRE techniques.
There are several ransomware simulators available that you can run to test ransomware rules. Watch this webinar with Ultimate Windows Security and LogRhythm covering three ransomware simulators that are available for free.
Care should be taken when using any ransomware or malware simulator. You should be familiar with how to safely run Red/Purple team exercises before trying these simulators.
Get Started using Top MITRE Techniques Today!
The bad news is that ransomware attacks are not stopping anytime soon. The good news is that popular strains of ransomware are not very inventive and often use the same MITRE techniques which can be detected. Take advantage of our MITRE ATT&CK Module to improve your threat detection efforts and stay tuned for more updates as we release new ransomware detection rules. Happy Hunting!
 LogRhythm does not vet or support any third-party malware/ransomware simulators and is not responsible for any damage they might cause.