Threat Hunting

Let's get to the heart of the ransomware attack: The stage that starts when the ransomware actor takes the handoff from the Initial Access Broker (IAB) and finishes when the ransomware is deployed.

Let's Review

•

The initial access stage is varied, with a diverse set of initial access vectors, and so is the “hands-on-keyboard” stage of a ransomware attack, with even affiliates of the same ransomware groups using different sets of tools.

•

Part of the reason ransomware groups rely on a core set of tools for reconnaissance, exfiltration, and deployment is that the tools do their work quietly and often go undetected. The other reason is that ransomware groups learn from each other and share information, which they then pass on to other ransomware actors.

•

We previously discussed the leak of the Conti ransomware group’s manual, as well as many of the tools its affiliates use. Affiliates are fluid, jumping from one Ransomware-as-a-Service (RaaS) offering to another, and are often part of multiple RaaS offerings simultaneously . Some of these affiliates will even go on to start their own RaaS offering. All the tactics, techniques, and procedures (TTPs) that affiliates pick up from one ransomware group they take with them when they move between ransomware groups.

•

Every ransomware affiliate has a slightly different take on how to use the tools, and tends to favor one tool over another. But so many ransomware attacks have been well-documented by groups such as the DFIR Report that a rigorous threat hunting program should catch most, if not all, ransomware attacks.

A Little Bit About Ransomware
and Threat Hunting

If It Was Easy, Everyone Would Do It

If a good threat hunting program can catch most ransomware attacks, why are so many ransomware attacks successful? Because threat hunting is surprisingly hard—and the challenges that come with it keep some organizations from doing it at all.

Is It Worth It?

Threat hunting is often the best chance to catch new ransomware groups during the reconnaissance, exfiltration, and deployment phases. This is the chance for defenders to take advantage of the “dwell time” discussed in Chapters 3 and 6. Keeping up with new threats from ransomware groups and acting on that new intelligence can give defenders an advantage, but it does take a lot of work to set up and maintain an effective threat hunting program.

definition

What Is Threat Hunting?

There’s some confusion about what threat hunting is. Threat hunting involves proactively searching through logs, endpoints, NetFlow traffic, DNS data, and any other security source for malicious activity on the network that may not be detected by existing security tools. Threat hunting is the first step in a process—it has to be integrated into the regular security workflow.

Hunting Loop

Threat hunting is a continuous process...

... but organizations shouldn’t be looking for the same threats on every search. In fact, that’s typically an inefficient use of precious threat hunting time. Instead, as outlined in the diagram below, it should be a loop where:

New threats are publicly reported

A threat hunting mission is carried out with the new information

The information is refined and incorporated into existing security workflows

Feedback is provided to the original source

The threat hunting loop

What type of intelligence can initiate a ...

... threat hunting mission for ransomware? It could be something as simple as a new confirmed set of IP addresses running ransomware command-and-control infrastructure. In that case, the hunting mission would involve going back through logs in the SIEM or collected from endpoints (which, hopefully, are also in the SIEM) to determine whether there was any communication from the organization to those IP addresses over recent weeks.

Of course, a threat hunting mission could be more complicated. It might involve a new Yet Another Recursive/Ridiculous Acronym (YARA) or Sigma rule to detect a new type of malware, or a method of detecting malicious actor activity. These rules may require proactively scanning endpoints or servers using endpoint detection tools to look for matches, rather than simply looking through old logs.

The point is that the type of new intelligence that can trigger a threat hunting mission can vary widely, but organizations need to be able to take advantage of all such intelligence to detect and stop new ransomware dangers.

Before Threat Hunting

Although many organizations are ...

... afraid of the idea of threat hunting, others are over-eager and want to jump in headfirst. Many defenders see it as “cool” (in fairness, it kind of is) and want to engage in these missions to find bad guys that security tools are missing.

But it’s not that simple. There are some important things an organization must do before they can start threat hunting effectively:

Good asset management: Organizations have to know where to hunt

Access to the necessary systems, such as Endpoint Detection and Response (EDR) and Security Information and Event Management (SIEM), to conduct an effective threat hunting mission

A threat hunting playbook that outlines processes for conducting the missions

Authority to act: If an indicator is found, the threat hunter must be able to act quickly and decisively to stop it

How to set up a threat hunting program is outside the scope of this chapter, but since it’s an important part of ransomware detection and deterrence, it’s worth discussing at a general level.

There's a difference between threat hunting for new threats versus standard monitoring for threats.

Threat hunting is only for new ransomware attacks—or at least new to your organization—and new techniques for detecting ransomware actors. Both standard monitoring and threat hunting are important, and organizations have to do both to be safe.

The transition from threat hunting to standard monitoring happens via refining new intelligence and adding it to existing security controls. The "Anatomy of a Modern Ransomware Attack" page shows a script ransomware that actors use to disable Windows Defender and prevent alerts. If that’s a new, emerging threat, the organization may want to see whether it has happened on their network and determine what it would look like, or whether they could detect it if it did.

There are several ways to use this Sigma rule in a threat hunting mission.

The screenshot on the right is shows a Sigma rule created by GitHub user frack113 to detect unexpected shutdowns of Windows Defender or its components. There are several ways to use this Sigma rule in a threat hunting mission. This particular rule is looking for the use of PowerShell to disable Windows Defender. If an organization is collecting PowerShell logs, the threat hunting team can run this rule against recent PowerShell logs to detect a match.

frack113’s Sigma rule for detecting unexpected shutdowns of Windows Defender and its components

If, like many organizations, your organization isn’t collecting PowerShell logs, an alternative defense is to test the script against EDR logs to see whether a similar PowerShell script was run. Most EDR tools collect PowerShell activity if configured to do so.

After completing the threat hunting mission ...

... the next step is to refine the rule. Maybe while running the Sigma rule against older logs, it generated an unacceptable number of false positives (what’s considered unacceptable will vary from organization to organization). Alternatively, the rule may have missed some suspicious activity that should’ve been flagged. Either way, an organization has to adjust the rule to be effective going forward.

Once the rule has been refined, it can be added as a detection rule to the EDR platform to allow ongoing detection. Or it can be added as a detection rule in the SIEM, which correlates it against incoming PowerShell logs.

The nice thing about threat hunting is that it generally doesn’t require purchasing new security technologies. Instead, the intelligence can be incorporated into existing tools and used to improve the efficacy of those tools.

A full-time staff isn't required ...

... for this type of threat hunting, something that most organizations can’t afford. The existing security team, on a rotating basis, can set aside a few hours each week to hunt. Even a security team of one can set aside time to do that.

A lot of great resources exist about new ransomware intelligence on sites. They range from Twitter to various vendor blogs, to notifications from Information Sharing and Analysis Centers (ISACs) or government agencies, the most notable of which is the Cybersecurity and Infrastructure Security Agency (CISA). Taking alerts from these sources and turning them into actionable threat hunting missions can improve the ongoing security of an organization.

Turning PDFs into
Threat Hunting Missions

The question of how to turn a PDF into an actionable threat hunting mission comes up repeatedly. After all, the knock on PDFs as “threat intelligence” is they’re generally not actionable. PDFs can’t be automatically ingested into other security tools, so technical information has to be manually entered.

The information contained in a PDF ...

... report can be turned into a threat hunting mission with a little bit of work. In March 2021 CISA issued an alert, CP-000142-MW, titled “Increase in PYSA Ransomware Targeting Education Institutions.” Using a couple of examples (but, by no means all), it’s possible to hunt for PYSA activity on a network. From the report:

The cyber actors use Advanced Port Scanner and Advanced IP Scanner to conduct network reconnaissance, and proceed to install open source tools, such as PowerShell Empire, Koadic, and Mimikatz. The cyber actors execute commands to deactivate antivirus capabilities on the victim network prior to deploying the ransomware.

There are five tools listed that an organization may not be monitoring for—they immediately become a hunting target:

Advanced Port Scanner

Advanced IP Scanner

PowerShell Empire

Koadic

Mimikatz

An organization may already have ...

... detections in place for some of these tools, but not all. For this example, assume there’s no detection in place for Mimikatz. A quick search for “threat hunting for Mimikatz” sources a blog on the topic by Red Canary.

Red Canary is a reliable source for ...

... this type of information and a good place to start. Using its suggestions, the threat hunting team can scan endpoints for Mimikatz using an EDR solution, or by scanning through logs in the SIEM.

The PDF file also includes six hashes associated with the ransomware attacks:

07cb2a3fe86414b054e2b002f283935bb0cb993c

52b2fc13ec0dbf8a0250c066cd3486b635a27827

728CB56F98EDBADA697FE66FBF7D367215271F10

c74378a93806628b62276195f9657487310a96fd

24c592ad9b21df380cb4f39a85d4375b6a8a6175

f2dda8720a5549d4666269b8ca9d629ea8b76bdf

These hashes should be immediately ...

... added to the EDR solution so it can start scanning for them on the endpoints. This might potentially catch a ransomware actor moving throughout the network or reveal artifacts of a failed attack.

These are just two examples of the hunting missions that can originate from this report. While PDF reports are certainly more cumbersome to work with, they contain valuable information for hunting missions.

Tools Used by Ransomware Actors

The many tools used during ...

... reconnaissance stage of a ransomware attack is discussed on the "Anatomy of a Modern Ransomware Attack" page. This section will discuss ways to detect these tools. Aside from the ransomware itself, two types of tools are generally used during the reconnaissance stage:

Repurposed red team or administrative tools

Native Windows applications

Many of the red team or administrative tools can be easily detected based on file hashes (the big exception being Cobalt Strike, which is discussed later in this section). Malicious use of Windows applications is often harder to detect, because the same tools are used by systems administrators and sometimes even legitimate applications.

Living off the Land

The "Anatomy of a Modern Ransomware Attack" page referred to the use of Windows-native tools by ransomware groups as “living off the land” (LotL). LotL activity can be particularly difficult to detect because, as mentioned in the previous section, systems administrators rely on many of the same tools.

One example of this stealth tool use is ...

... the exploitation of the net command by both IAB and ransomware actors during the initial access and reconnaissance stages. The net command is also very popular with administrators, especially for scheduled tasks. One administrator found that the net time command was run for legitimate purposes 5.4 million times over a two-week period. Depending on the organization, just looking for instances of the net command could generate so many false positives that it would be impossible to detect threatening uses.

Fortunately, Florian Roth and Markus Neis created a Sigma rule that looks for common reconnaissance commands run by ransomware actors in quick succession. The rule, shown in the screenshot below, looks for common Windows commands run by ransomware and other malicious groups during the reconnaissance stage:

tasklist

net time

systeminfo

whoami

nbtstat

net start

qprocess

nslookup

hostname.exe

netstat -an

Most importantly, the script looks for ...

... several of these commands being run within a span of 15 seconds, an indication they’re being run from a script rather than a human carrying on an investigation of some sort. This makes the rule less likely to generate false positives.

A Sigma rule created by Florian Roth and Markus Neis to detect reconnaissance commands

The beauty of Sigma rules like this is ...

... that they can be modified so that they don’t generate false positives. If you run the rule and find that it generates false positive alerts, you can adjust the commands or the time frame within which they have to be run. This kind of rule can be applied against Sysmon logs or logs collected from EDR systems.

Want More Like This?

Sign Up To Receive Our
Monthly Ransomware Newsletter

Don't Worry, We Hate Spam Too.

PsExec

Another common LotL tool used by ransomware groups is PsExec, which carries out common administrative tasks from the command line. PsExec isn’t included by default on Windows systems, but is used by so many organizations around the world that it can almost be considered Windows-native.

Which, again, is one of the reasons it's commonly targeted.

Aside from being very powerful, PsExec is also rarely flagged by security tools because it has so many legitimate uses. Most organizations don’t install PsExec on every workstation, but only those used by administrators. This restriction helps defenders check for malicious uses of PsExec in the network.

The image below shows the license agreement that has to be accepted before PsExec runs for the first time. Accepting this license agreement creates a new registry entry in Windows that looks something like this:

ComputerHKEY_CURRENT_USERSOFTWARESysinternalsPsExecEulaAccepted

Monitoring for this registry change could indicate a threat on the network, but there are a couple of caveats to this method of detection:

The ransomware actor could clean up registry entries. Proactive monitoring, however, should catch this activity.

Some cybercriminal groups use custom versions of PsExec that don’t create this registry entry (although testing by the author on PsExec binaries used in several ransomware attacks did reveal the registry entry, suggesting that detecting for its creation is still a good thing to have).

Most importantly, the script looks for...

License agreement that must be accepted the first time PsExec runs

Organizations that run Sysmon on the network can alert on Event ID 13: RegistryEvent and specifically filter for that registry path, along with DWORD: EulaAccepted. Of course, collecting RegistryEvent events generates a lot of logs, so you probably won’t generate alerts every time a RegistryEvent event happens. Filtering on this specific RegistryEvent at a high alert in the SIEM will help make this alert actionable.

Even if the ransomware actor renames PsExec or uses one of the PsExec clones ...

... the named pipe still uses the same name. Again, Sysmon can look for Event ID 17: PipeEvent (Pipe Created) or Event ID 18: PipeEvent (Pipe Connected). As with the previous PsExec discussion, to avoid being inundated with false positives, organizations can filter the alerts in their SIEM so that only named pipe events generated by PsExec create high alerts.

PowerShell

PowerShell is native to Windows, but the scripts being used by ransomware groups are written by third parties.

Disabling Is Not Enough

Disabling PowerShell won’t always deny access to a ransomware actor, so organizations need to monitor for malicious PowerShell scripts on the network. The best way to do that is to enable PowerShell logging in GPOs.

A Word of Warning

PowerShell logging can be noisy. For example, running the Invoke-Mimikatz script generates more than 2,200 events. Again, filtering at the SIEM can make these event logs more manageable and trigger alerts only for PowerShell scripts that are indicative of ransomware.

One big advantage of Microsoft’s PowerShell logging capability is that it can log “script blocks,” which are chunks of the executed script. Script block logging in PowerShell includes logging and de-obfuscating obfuscated PowerShell scripts.

Ransomware actors often use obfuscated ...

... PowerShell to avoid detection. Enabling script block logging allows the security team to do near-real-time pattern matching in the SIEM to find patterns indicative of typical ransomware PowerShell scripts, and to create high alerts when those scripts are executed.

One way to start the process of filtering malicious PowerShell scripts is to take a look at the scripts that make up the PowerSploit framework. PowerSploit is a set of PowerShell scripts written to be used by penetration testers for reconnaissance and lateral movement in a network, post-exploitation. Many ransomware operators use PowerSploit scripts or derivatives of those scripts during attacks. Reviewing unique characteristics of PowerSploit scripts and using those as a basis for malicious PowerShell detection is a good start.

school house

PowerShell Does Not
Have To Be Installed Everywhere

A common mistake many organizations make is to leave PowerShell running on all workstations in the network. That’s unnecessary and increases an organization’s security risk. PowerShell is a powerful tool that can be used to manage configuration tasks across the network, but it needs to be installed only on the machines launching the PowerShell script—not on the machines being managed.

Some administrators do write scripts that call PowerShell on each individual box. But if PowerShell doesn’t have to be on a system, why increase the security risk? Even if it means rewriting PowerShell scripts, the security tradeoffs make it worthwhile.

There are three approaches many organizations take to limiting PowerShell usage. All of them can be accomplished using Group Policy Objects (GPOs):

1. Removing PowerShell from all machines except those needing it
2. Limiting PowerShell usage to administrators only
3. Hardening PowerShell security settings and restrictions via GPOs

The problem with the first option is that the machines that need to run PowerShell may change frequently. The problem with the second option is that ransomware groups strive to gain administrative access, allowing them to bypass the protection.

This is one of those “why not both” situations. To provide the most protection, an organization should remove PowerShell from machines where it isn’t necessary and limit execution of PowerShell to administrators. The security team should work with the Windows team to remove PowerShell in a way that doesn’t disrupt workflow and to create a painless way to enable PowerShell on new machines as needs change.

No. 3 should be done in all cases, no matter which approach of the first two that you take. Look at your current settings and see if they specifically address the ransomware concerns raised here—if they don't, take immediate action to correct the situation.

Third-Party Tools

Of course, ransomware actors don’t rely just on LotL. They also use a variety of third-party tools, most of which are designed for red team testing or network administration. A few of these tools, such as ADFind and Mimikatz, are discussed on the "Ransomware and Active Directory" page, but there are other common tools used by ransomware groups.

One of these tools is LaZagne.

Available as a portable executable, it retrieves local passwords from a machine. Ransomware actors often use this tool to gather passwords from the local system to see whether they can be used to gain access to other systems on the network. Sometimes there are even cached administrator credentials on the system that can be used to gain instant administrative access.

The good news is that most antivirus and EDR programs flag LaZagne as malicious. Unfortunately, as discussed earlier, one of the first things ransomware actors do is attempt to disable any running security tools. If security teams don’t discover that their security tools have been disabled, a second layer of defense can help catch LaZagne in use.

Fortunately, there's a Sigma rule for that.

Developed by Bhabesh Raj and Jonhnathan Ribeiro, the Sigma rule takes advantage of the unique way LaZagne queries LSASS to pull the passwords down. Shown in the screenshot below, feeding this rule into the SIEM provides a secondary layer of detection for LaZagne in Windows logs.

The file hash for LaZagne is also static between version upgrades, so it is possible to detect LaZagne through a file hash search. The problem with this strategy is that the tool most commonly used for this type of search, endpoint protection, has probably been disabled.

Sigma rule for detecting the use of LaZagne in a network

There is a problem that crops up ...

... with many of these tools: They’re easy to detect in a vacuum, but when deployed with detection evasion techniques used by ransomware groups, detection becomes a lot more difficult.

On top of that, networks are noisy.

There are things employees do all the time that are innocent, but still raise security alarms. Organizations have to rely on defense in depth—using multiple ways to detect the same threat in case an alert is missed or a security control disabled—to be effective at stopping a ransomware attack.

The exfiltration stage is another area where a lot of third-party tools are commonly used. In this case, one of the detections organizations can put in place isn't a file but a site. Many ransomware groups use the MEGA upload service for exfiltrating files.

Organizations that don’t allow the use of MEGA for file uploads can block access to the MEGA domains at the edge and at the endpoint. The domains MEGA currently uses:

mega.io

mega.nz

mega.co.nz

The service may add new domains in the future, so it’s important to keep updated on its service.

Not all ransomware actors use MEGA.

Some use compromised servers at hosting providers for command-and-control infrastructure, to which they exfiltrate stolen files. The tool most often used by ransomware groups to exfiltrate the data is Rclone.

Rclone is a legitimate file transfer tool, and before implementing any alerting or blocking, organizations should find out how widespread its use is in the network. Tracking legitimate uses helps reduce the number of false positives.

Rclone is fairly static ...

... (as is the case with some of the other tools discussed in this section), so it is possible to detect activity by looking for file hashes. Ransomware actors have been known to change the name of Rclone before executing it, so a simple filename detection won’t always work (though it does work surprisingly often).

Even if the name is changed, and a ransomware actor manages to adjust the file hash, the command options won’t change. The screenshot below shows a Sigma rule developed by Aaron Greetham for detecting Rclone usage based on the options commonly used by ransomware actors.

Sigma rule for detecting Rclone usage based on command options

Note that the Sigma rule requires only ...

... one of the nine command options to be executed before it alerts. Some organizations may want to adjust these choices if they use this Rclone behavior in their networks. If Rclone is in use, it might make sense to require two or three of the suspicious command options to be used before triggering an alert, to reduce the false positives.

Cobalt Strike

Cobalt Strike is one of the most common tools used by ransomware actors. According to Cisco Talos Incident Response (CTIR), 66% of ransomware attacks in 2020 involved the use of Cobalt Strike. That percentage appears to be growing in 2021.

But it's not just ransomware exploiting ...

... Cobalt Strike and Metasploit: They accounted for 25% of all malicious command-and-control servers in 2020. Because Cobalt Strike is designed to be an adversary simulation tool, it’s purposely hard to detect, making it an ideal tool for ransomware groups. There are also a number of cracked versions available for sale on underground forums, making it easy for ransomware groups to acquire.

Cobalt Strike relies on command-and-control infrastructure for communication. The ransomware actor creates a command-and-control server, possibly with a redirect server acting as the front-ends, then configures a beacon to connect either directly to the server or to the redirect server.

When the Cobalt Strike beacon is launched in the second stage of a ransomware attack, it communicates with the command-and-control host, which either sends automated commands or has a human operator on its end to request a shell and start reconnaissance.

Sample Cobalt Strike command-and-control infrastructure

The diagram above shows an example of...

... what a Cobalt Strike command-and-control infrastructure may look like. The ransomware actor compromises several hosts and registers multiple domains to build out redirect infrastructure, concealing the real command-and-control server. More than one of the redirect servers may be used during a ransomware attack.

Communication between the Cobalt Strike beacon and the command-and-control server is conducted over DNS or HTTPS, which is the first point of detection. There are a number of oddities in the way Cobalt Strike command-and-control servers respond to requests, particularly the cracked versions of the software.

This means that researchers have been ...

... able to scan for, find, and document many command-and-control hosts. Regularly updated lists of known Cobalt Strike command-and-control servers are distributed by security and threat intelligence companies or just made readily available on Twitter and other places.

Keeping updated block lists of these servers in a proxy or firewall, or pulling them into a recursive DNS server via a mechanism such as Response Policy Zone (RPZ), is a first step toward detection and protection.

But, of course, there are so many of these servers around that it’s unlikely any one list will have them all. So there must be other ways to detect Cobalt Strike activity within a network. A lot of ransomware actors like to execute the Cobalt Strike beacons using PowerShell. The beacon injects obfuscated PowerShell code into memory, which means that a lot of the detection methods for PowerShell discussed earlier can detect Cobalt Strike activity.

When Cobalt Strike injects malicious code into processes, it creates a named pipe ...

... (sound familiar?). Cobalt Strike uses a particular set of naming conventions for its named pipes. An organization running Sysmon can look for Event ID 17: PipeEvent (Pipe Created) or Event ID 18: PipeEvent Pipe Connected) and the following pipes identified by The DFIR Report (an asterisk means that an arbitrary string can appear in that location in the name):

postex_*

postex_ssh_*

status_*

msagent_*

MSSE-*

*-server

Note that these are the default named pipe names given by Cobalt Strike, but it’s possible to change those default names. The general consensus is that ransomware actors don’t normally change them.

Another useful detection rule is to search for “sacrificial processes.” Sacrificial processes are run32dll.exe processes executed with no command arguments. This is highly unusual for legitimate processes, so looking for this type of activity is unlikely to generate false positives. As with other detection methods, the Cobalt Strike manual advises changing this behavior, but again, most ransomware actors don’t.

The screenshot to the right shows a Sigma rule ...

... created by Oleg Kolesnikov to detect this type of activity. The rule looks at two common commands run by ransomware (and other) actors without any options. This can be loaded into a SIEM or into endpoint protection to look for potential matches.

Sigma rule to detect sacrificial processes executed by Cobalt Strike

No single one of the detections outlined ...

... in this section is enough to stop all Cobalt Strike incursions by ransomware groups. In fact, deploying all of these detections may still leave you open to a skilled ransomware actor using Cobalt Strike undetected.

You have to enable these detection methods and continuously search for new and better detections to successfully protect an organization from a ransomware attack. That doesn’t apply just to Cobalt Strike, but to all of the tools discussed in this section.

watch out

Configurable DNS Servers

Cobalt Strike DNS beacons are configurable to use well-known recursive DNS servers (e.g., 8.8.8.8 or 9.9.9.9) to bypass the security protections outlined in this section. Even organizations that have their own recursive DNS often can’t block traffic to these DNS servers because legitimate applications also connect to them. Most ransomware groups don’t change the DNS servers at this point, but might do so in the future.

Tools Used by Network Defenders

IT and security teams looking to improve their ransomware defenses often ask the question: What is the single best tool to stop ransomware? The hard truth is, no one tool will stop a ransomware attack.

There are tools that disrupt different stages ...

... of a ransomware attack, but ransomware actors are nothing if not resilient and creative when it comes to devising new methods of attack.

Earlier sections of this page and the "Creating Disaster Recovery and Incident Response Plans" page outlined important log sources for detecting ransomware, which include:

Current and accurate asset inventory

Most recent internal and external vulnerability scans

VPN logs

Logs from any remote access system (RDP/Citrix/TeamViewer)

Mail server logs

Web proxy logs

DNS logs

Logs from any endpoint software (AV/EDR/Asset Management)

Firewall logs

Windows event logging

Active Directory logs

PowerShell logs

Different log sources map to ...

... the different stages of a ransomware attack. Organizations that collect, alert on, and act quickly from ransomware-related events generated by these log sources can detect and prevent ransomware attacks.

The specific vendor doesn't matter ...

... for the most part. Most security tools will do a good job of generating the logs needed and, in many cases, automating the disruption of a ransomware attack. The following factors are more important than the specific vendor used:

Its configuration is optimized for detecting ransomware

The security team is comfortable using the tool

Log data from all security sources is correlated with other security tools

The first factor can be accomplished rather easily, as most security vendors are happy to conduct a “tuneup” with their customers to ensure they’re getting the most out of the tool. Organizations should set up time with each of their security vendors to review their configuration, ask for advice to improve ransomware detection, and implement the suggested changes.

The second factor is the reason ...

... organizations shouldn't rush out to purchase the latest security tool in the hope that it will solve their ransomware problems. Most security products have a steep learning curve, and overworked security staff may not have time to fully learn yet another security tool. This means, as is often the case, that new security tools won't be implemented in a timely or effective fashion, and that instead of improving an organization’s security, it will make the organization less secure.

The last factor is the hardest, because collecting more logs means more alerts to sift through, and may initially generate more false positives while it’s being tuned. Still, the upfront work should result in more effective and accurate alerting.

The last factor is also the most challenging because even smaller organizations often have 5 to 10 different security tools. Getting them all to talk to each other in a way that allows correlation of event details across different platforms is difficult, at best.

Large organizations sometimes have ...

... hundreds of security tools, making this problem exponentially more difficult. As discussed repeatedly throughout this site, stopping ransomware attacks in progress often requires detection from multiple sources and correlating those events to understand what’s happening. It’s hard to do that when the security team has to jump from console to console to find events—it’s too easy to miss important alerts that way.

The combination of SIEM and security orchestration, automation, and response (SOAR) can help with this complexity. A well-tuned SIEM allows security teams to collect logs from all the necessary sources, create rules that generate alerts on critical events, and filter out the false positives. SIEMs are also excellent tools for threat hunting missions, when they collect relevant logs from necessary sources. But SIEMS are complex to manage and fine-tune, and SOARs are even more complex. When properly configured, SOARs provide the automation necessary to handle some of the basic or repetitive security alerts—but again, getting there is the challenge.

In short, the best tools for organizations to use are ones the security team is comfortable with, that have been properly tuned for detecting ransomware events, and are synced with other security tools to allow for comprehensive detection and analysis.

Sysmon: The Best Tool
That No One Uses

Throughout this page, there’s a common theme: Use Sysmon logging to detect events otherwise missed by standard Windows logging. The problem is that most organizations don’t use Sysmon. A poll conducted of DFIR professionals found that 61% almost never see Sysmon in use in client networks. Admittedly, that’s anecdotal data, but the story is told repeatedly by incident response professionals. Those pros love Sysmon, but most organizations don’t.

Sysmon is a free tool from Microsoft that ...

... collects "detailed information about process creations, network connections, and changes to file creation time.” Symon fills in the gaps missed by standard Windows logging, and, as detailed throughout this page, it provides a wealth of information.

Sysmon is not an alerting tool. Instead, it relies on the SIEM or other log analysis tools to analyze and create alerts based on events indicative of suspicious behavior. Sysmon events are great for detecting ransomware activity because they help distinguish between normal activity and potential indicators of ransomware (e.g., processes executing from cmd.exe with no command options).

The reason many organizations don't implement Sysmon ...

... is that it generates a lot of log traffic. This noisiness isn’t necessarily a big deal in an office with a hundred computers, but when there are thousands of computers, there’s a material cost to storing Sysmon logs. Some EDR tools will also collect much of the same information that Sysmon does, so there may be redundancies between Sysmon and EDR logs.

Organizations should look to selectively deploy Sysmon on the most critical systems in the network. Any Internet-facing system (especially if it has RDP running on it), mail servers, DNS servers, file servers and, of course, Active Directory servers could benefit from the additional logging that Sysmon provides without overwhelming the SIEM or generating too much extra work for the security team.

For most organizations, the benefit of adding Sysmon logging to critical servers outweighs the additional work required to incorporate those new logs and events into monitoring.

Liked This? You'll Love The Free 313 Page Book:
Ransomware: Understand. Prevent. Recover

Get the Book
in Your Inbox

Download The
"How To Prevent Ransomware"
Cheat Sheet

Grab this free PDF resource on how to prevent Ransomware

DOWNLOAD THE PDF

Share This Resource With Others

Embed The "How To Prevent Ransomware" resource on your site or blog using this code.

Share this Infographic On Your Site<p><strong>Please include attribution to ransomware.org with this graphic.</strong><br /><br /><a href='https://ransomware.org/how-to-prevent-ransomware/'><img src='https://ransomware.org/wp-content/uploads/2021/11/how-to-prevent-ransomware.pdf' alt='How To Prevent Ransomware' 540px border='0' /></a></p>

Want More?

This site is adapted from a book on Ransomware.
If you would like to learn more keep reading...

Label