This blog post started as a Twitter thread, in case you were wondering if anything good ever came from Twitter. Ransomware attacks are complex and involve a lot of different aspects of security, which is why defenders need to take a “boxing match” approach to stopping ransomware attacks.
This means that, like boxing, you’re always striving for an early round knockout (KO) in a fight. But if you don’t get the KO, you can still get a technical knockout (TKO) or win by collecting more points than your opponent.
Ransomware defense is the essence of defense in depth, and these threat hunting techniques that are often overlooked by defenders can help protect your organization from a ransomware attack. These detection suggestions jump around the attack chain a little bit, so they aren’t necessarily in order of when they occur in the attack.
There’s a good chance that whatever endpoint detection tool you’ve installed, whether it’s Microsoft Defender, CrowdStrike Falcon or something else, will stop a lot of a ransomware reconnaissance activity. This is assuming the endpoint protection is configured correctly and logging properly. That is why during the reconnaissance and deployment phases of a ransomware attack, threat actors will kill the process.
Sometimes they use executables to do this, and other times they have PowerShell scripts. The point is that however it’s being done, killing your endpoint process is critical to their ability to continue the attack.
This issue is that although killing the endpoint protection will generate a log, too many organizations don’t trigger an alert on these log entries.
Part of that is understandable—endpoint systems go up and down all the time, and alerting every time that happens would generate significant false positives and waste the security operations center (SOC) analysts’ time.
But fine-tuning the alerts to fire only when third-party applications shut the endpoints down should reduce the false positives. You may have to continue fine-tuning the alerts—for example, if you find that your backup software is killing the endpoint process, you’ll probably want to exclude that as well.
With some work, however, you can turn this alert into a simple and effective early-warning system that a ransomware actor, or someone worse, is in your network.
Too many organizations refuse to turn on PowerShell logging, which is a big mistake. Ransomware (and other) actors love to use PowerShell during their attacks.
It’s true that the last thing most SOCs want is even more logs being sent to the SIEM, generating even more alerts that they have to sift through (not to mention the added annual SIEM cost by adding the logs). But PowerShell logging can be really important, and help your organization find dangers that would otherwise have gone unnoticed.
One of the best things about PowerShell logging is that it allows defenders to use some of the threat-hunting techniques Chris Sanders outlines in his excellent Practical Threat Hunting course.
Starting with looking for unusual activity. Most organizations have a few (or many) PowerShell scripts that run regularly in the network. Those aren’t interesting (unless they start acting weird). Instead, look for warning signs from PowerShell scripts, including ones that:
There are a lot of ways to detect rogue PowerShell scripts, but they all start by building a baseline of what PowerShell activity in your organization looks like and then looking for outliers, whatever those outliers may be (they can vary from organization to organization).
Also look for PowerShell scripts that add new Administrator accounts, create new scheduled tasks or engage in network mapping activity. In fact, anything PowerShell-related or not that engages in these activities should be flagged for alerting, especially if these activities occur during off hours.
Here’s a secret: a lot of ransomware actors, especially newer ones, don’t like to operate from the command line. Many of them prefer using remote desktop tools. That means looking for portable executable versions of things like the following:
This might help you find the ransomware actor during the reconnaissance phase of the attack. In addition to the file hashes, monitor for these tools’ common ports. When looking for hashes, make sure you’re looking for not just the current version, but two-to-three versions back—the ransomware actors don’t always keep the most updated version in their toolkit.
It’s also important to know what, if any, remote management tools are legitimately being used by your teams, which versions are in use, and where they’re being used. This will allow you to cut down on false positives by focusing on the tools not being used by administrators, or at least not authorized for use.
Does your organization use mega[.]io or one of its many domains for file uploads or file transfers? If not, block all the domains associated with this file upload service. Ransomware groups use it for data exfiltration, since uploads are easy and they accept payment in cryptocurrency. That is not to imply that Mega is a bad company—the reality, though, is that bad people use their service.
Mega is one example, but there are a number of file upload sites that can be blocked if there’s no business need for employees to access the sites. Blocking these sites won’t necessarily stop data exfiltration, as a savvy ransomware actor will simply build a new command-and-control server and upload data that way. But it will create an alert that someone tried to reach out to these sites, and that can start an investigation.
In addition to blocking domains, look for the tools that ransomware groups like to use to exfiltrate data, including these:
A lot of these tools will be legitimately used by people in your organization. That’s why it’s important to find out who’s supposed to have them and what their endpoints are, then focus your search elsewhere. It’s not a perfect solution, but none of these solutions have to be perfect by themselves. Remember that you’re creating a layered defense.
Using YARA and Sigma rules to look for common enumeration tools is a more advanced step, but one that significantly enhances defense in depth. If your organization is running an EDR/XDR, or has a managed service provider running EDR/XDR for you, you already have the capability to do this.
There are a number of enumeration tools used by a variety of ransomware (and other) groups that you should be looking for in your network, including:
And this is only a partial list. The good news is there are a lot of freely available and very good YARA and Sigma rules you can take advantage of for finding these tools. It’s worth noting that many red teams use these tools as well during penetration testing operations, so the worst that happens is you catch your red team trying to bypass your security measures.
There’s a lot of good advice buried in that Twitter thread, and I strongly recommend going through it. Let me know if you have any other ideas, and as we continue to collect more ways for ransomware defenders to improve the odds, we’ll publish another one of these columns.