Detecting Ryuk Using Splunk Attack Range

Cybersecurity Infrastructure Security Agency (CISA) released Alert (AA20-302A) on October 28th called “Ransomware Activity Targeting the Healthcare and Public Health Sector.” This alert details TTPs associated with ongoing and possible imminent attacks against the Healthcare sector, and is a joint advisory in coordination with other U.S. Government agencies. The objective of these malicious campaigns is to infiltrate targets in named sectors and to drop ransomware payloads, which will likely cause disruption of service and increase risk of actual harm to the health and safety of patients at hospitals, even with the aggravant of an ongoing COVID-19 pandemic. This document specifically refers to several crimeware exploitation frameworks, emphasizing the use of Ryuk ransomware as payload. 

The Ryuk ransomware payload is not new. It has been well documented and identified in multiple variants. Payloads need a carrier, and for Ryuk it has often been exploitation frameworks such as Cobalt Strike, or popular crimeware frameworks such as Emotet or Trickbot. Due to the urgency of the alert and level of chatter around it we decided to execute and test Ryuk ourselves with one of our favorite tools – the open-source Splunk Attack Range.

Executing Ryuk in Attack Range

We created an environment in Attack Range Local with a Windows 2016 domain controller and a Windows 10 client. 

We then proceeded to execute a sample of Ryuk ransomware (14248fda59e7a8bf9f143abe8bbd834cb7c2aa4f) found in the wild and graciously provided to us by Reversing Labs.

First, we executed on our Windows 10 Workstation:

Then we ran Ryuk on our Windows 2016 Domain Controller: 

The above is an accurate representation of what the victim sees on their desktops when the payload is executed. This only means bad news, as the data inside our machines in the lab was rendered inoperative since many files were encrypted and had the extension .RYK added to them. We were able to log a lot of event activity related to this attack in our environment consisting of Attack Range, a Splunk Enterprise indexer and search head, Splunk Universal Forwarder and Sysmon/Windows Security Event Log logging policies. Here is a sample of how this malicious code displays in Splunk on the targeted operating systems:

OK cool story… What can I do NOW?

As malicious actors execute their campaigns, payloads will undoubtedly be modified to avoid detection mechanisms. It is likely that this payload will be delivered via different methods, and not just from the above mentioned exploitation frameworks. The file extensions may be changed as well, the packing of the payload itself will be modified to avoid AV, endpoint signature and heuristic detections, etc. 

When this blog was first published, the Splunk Threat Research team was working overtime to produce a comprehensive analytic story on Ryuk. In the blog you can find that the team provides the following detection artifacts that work with known Ryuk delivery methods.  We're happy to share that the team has released detections specific to Ryuk, Trickbot and Bazar in release 3.0.9. 

First the Low Hanging Fruit

Malicious actors always want you to know they compromised your hosts. In the case of the sample we executed, we were able to quickly spot the file “RyukReadMe.html” on the compromised desktop. The search below against Sysmon data will give you an idea how deep the payload has gone in the targeted systems. Notice the * to find ALL instances regardless of directory. 

| tstats allow_old_summaries=true count, min(_time) as firstTime, max(_time) as lastTime FROM datamodel=Endpoint.Filesystem WHERE "Filesystem.file_path"=C:\\*Ryuk* BY "Filesystem.dest", "Filesystem.user", "Filesystem.file_path"
| convert timeformat="%Y-%m-%dT%H:%M:%S" ctime(firstTime)
| convert timeformat="%Y-%m-%dT%H:%M:%S" ctime(lastTime)
| rename "Filesystem.*" as "*"

Ryuk, like many ransomware variants, creates a ton of file creation and modification activity. We saw numerous Sysmon EventCode=11 (File Create) events as Ryuk created, encrypted, and added extensions to these files. Similar events can be observed in Windows Security Event ID 5145  “A network share object was checked to see whether client can be granted desired access” - assuming that your audit policies are set correctly. 

These events look like this:

sourcetype=XmlWinEventLog ObjectType=File RelativeTargetName=*.RYK EventCode=5145 | table src_user Computer EventCode name RelativeTargetName ShareLocalPath ShareName

Notice events occur as files are accessed and renamed, in this case the .RYK extension is being appended. This search can reveal the endpoints that were compromised in this phase of the attack. Depending on the timing of this detection you may still have a chance to contain it from encrypting more files on the individual endpoint, or on other endpoints in your environment.

We also found other indicators associated with the execution of Ryuk, like the stopping of the Security Account Manager service. This is an example of the Service Stop technique (ATT&CK T1489) and is associated with preventing the interaction of this service with others. By stopping or disabling this service, the actor may facilitate evasion from SIEM alerts and other possible detection mechanisms. 

| tstats allow_old_summaries=true count, min(_time) as firstTime, max(_time) as lastTime FROM datamodel=Endpoint.Processes WHERE ("Processes.process_name"="net*.exe" "Processes.process"="*stop \"samss\"*") BY "Processes.dest", "Processes.user", "Processes.process"
| convert timeformat="%Y-%m-%dT%H:%M:%S" ctime(firstTime)
| convert timeformat="%Y-%m-%dT%H:%M:%S" ctime(lastTime)
| rename "Processes.*" as "*"

Next we found “conhost.exe 0xffffffff -ForceV1” being executed on our lab hosts, which has been observed before when Ryuk is executed. “conhost.exe” is a utility associated with Command Prompt execution (Mitre ATT&CK T1059.003) and use of Windows Explorer, a function that allows this malicious code to find and access targeted files. 

(CommandLine="*C:\\Windows\\system32\\conhost.exe 0xffffffff -ForceV1*" EventCode=4688 sourcetype=XmlWinEventLog) | table CommandLine, Computer, EventCode, SubjectUserSid

We also found the DisableAntiSpyware (Mitre ATT&CK T1562.001) registry key being modified, which again is associated with the execution of  Ryuk:

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Registry where Registry.registry_key_name="DisableAntiSpyware" AND Registry.registry_value_name="DWORD (0x00000000)" by Registry.dest Registry.user Registry.registry_path Registry.registry_value_name   | `security_content_ctime(firstTime)`| `security_content_ctime(lastTime)` | `drop_dm_object_name(Registry)`

What content does Splunk have today?

There are several Splunk searches available that are useful for detecting this threat and will work in your environment as is or with minimal adjustment.  The following searches from Splunk ES Content Update (ESCU) belong to different stories, however, they work out-of-the-box against Ryuk as there are similarities in the behavior of the delivery and execution of ransomware payloads regardless of  strain or carrier. 

The following detection searches worked without any modifications against our data from Attack Range Local. We are confident many others can be used in applicable environments and be successful as well. 

The Detect Rare Executables search found binaries which were the payloads executed during this research exercise. It has the added benefit of running against the Endpoint.Processes datamodel, which means that it will perform very quickly at massive scale.

ESCU - Detect Rare Executables - Rule (From Emotet Malware DHS Report RA18-201A)

The Prohibited Software on Endpoint search found the prohibited binaries, once we added them to Splunk Enterprise Security’s interesting processes table. It also has the added benefit of running against the Endpoint.Processes datamodel, which means that it will perform very quickly at massive scale.

Prohibited Software On Endpoint - Rule  (From Emotet Malware DHS Report RA18-201A)

The Windows Event Log Cleared search found that Ryuk attempted to clear event logs on our test victim machines several times.

ESCU - Windows Event Log Cleared - Rule (Ransomware Analytic Story)

For more detections, you can repurpose other detection search rules in the following analytic ESCU analytic stories:

• Emotet Malware DHS Report TA18-201A
• Ransomware
• SamSam Ransomware
• Suspicious MSHTA Activity

It is always important to consider delivery methods for these kinds of threats. Various delivery methods are detected by other searches in the ESCU analytic stories mentioned above. Also important is the detection of other exploitation tools that may be used within the attack process, such as MimiKatz -- which is covered and detected in our  ESCU - Credential Dumping story. 

This blog focused on what we could detect out-of-the-box when executing Ryuk samples in our controlled environment driven by Splunk Attack Range. It’s important to note that delivery methods may differ from environment to environment. An attacker may not need an exploitation framework such as Cobalt Strike or even Trickbot if they can easily gain entry via SSH or RDP or compromised VPN and simply distribute and execute their payload. In that case, most of those delivery detections change and thus are ineffective by themselves in addressing Ryuk. 

We hope that the above suggestions for Ryuk analysis and detection are a starting point  for analysts looking to detect this threat within Splunk. For more information, consult the following reference links:

• Splunk for Security Investigation: Ransomware
• Detecting Ransomware Attacks with Splunk
• Operationalize Ransomware Detections Quickly and Easily with Splunk

The Threat Research team has now released detections specific to Ryuk, Trickbot and Bazar in release 3.0.9.

About Splunk Threat Research Team

The Splunk Threat Research team is devoted to understanding actor behavior and researching known threats to build detections that the entire Splunk community can benefit from. The Splunk Threat Research team does this by building and open sourcing tools that analyze threats and actors like the Splunk Attack Range and using these tools to create attack data sets. From these data sets, new detections are built and shared with the Splunk community under Splunk Security Content. These detections are then consumed by various Splunk products like Splunk Enterprise Security, Splunk Security Essentials, and Mission Control to help customers quickly and effectively find known threats.