Intro

On October 28th, the FireEye Threat Research team released the following threat report: https://www.fireeye.com/blog/threat-research/2020/10/kegtap-and-singlemalt-with-a-ransomware-chaser.html on the UNC1878 threat actor group and their KEGTAP/BEERBOT, SINGLEMALT/STILLBOT and WINEKEY/CORKBOT campaigns that deploy RYUK ransomware on compromised hosts. The post contains some great IOCs specific to this campaign as well as the comprehensive remediation guidance you’ve come to expect from our posts.

In this post, we wanted to highlight some host-focused hunting and detection strategies based on the tooling and techniques outlined in the FireEye post.

Foothold

According to the FireEye report, these threat actors use frameworks such as Cobalt Strike, Metasploit and EMPIRE – these frameworks have various customization options available so hunting strategies for the various launchers and C2 profiles will vary widely.

For Cobalt Strike specifically, we will, however, highlight the following Sigma Rules that look for default Cobalt Strike behavior:

• https://github.com/Neo23x0/sigma/blob/de5444a81e770ec730aa5e3af69781ab222f021a/rules/windows/process_creation/win_meterpreter_or_cobaltstrike_getsystem_service_start.yml
• https://github.com/Neo23x0/sigma/blob/de5444a81e770ec730aa5e3af69781ab222f021a/rules/windows/builtin/win_meterpreter_or_cobaltstrike_getsystem_service_installation.yml
• https://github.com/Neo23x0/sigma/blob/master/rules/windows/sysmon/sysmon_cobaltstrike_process_injection.yml

Please be aware that Cobalt Strike profiles allow for a wide range of customizations, some of which may slip past the above rules.

Although the report does not specify which particular Meterpreter payload was used, if we look at the logs generated by windows/meterpreter/reverse_tcp using the PSExec payload, a few events stick out.

First, we see an Event ID 7045 and an Event ID 7009 in the System Log Channel, let’s take a look at the 7009 event:

And the 7045 Event:

We see two main things that stick out, the randomly generated service name and the big blob of PowerShell in the ImagePath field of the 7045 event.

Let’s write a simple Splunk query that looks for abnormally long text blocks in this field:

index=winlogs EventCode=7045
| eval ImagePathLength=len(ImagePath)
| where ImagePathLength > 500
| table service,ImagePath

And our results:

If we have Sysmon logs available, we can use the same "measurement" technique to look for this activity in Sysmon Process Creation events:

index=sysmon EventCode=1
| eval CommandLineLength = len(CommandLine)
| where CommandLineLength > 500
| table Image,ParentImage,CommandLine

Using the PowerShell Empire’s ( https://github.com/BC-SECURITY/Empire ) stager/windows/launcher_bat launcher and the same Splunk query used above, we can see this execution as well:

We love using the Sysmon Process GUID field as a pivot point, so let’s find what ProcessGuid this event had, adding ProcessGuid to the last line in our Splunk query.

In our case the ProcessGuid was: {b4c14a3b-223f-5f9a-6e02-000000001100} and with the following query:

index=sysmon ProcessGuid = "{b4c14a3b-223f-5f9a-6e02-000000001100}" 
| stats values(RuleName)

We can see what other Sysmon named rules our malicious PowerShell process hit:

Now we have a bunch more data points associated with the malicious PowerShell process that we can go and take a closer look at.

These rule names come from the Sysmon configuration that I’m using: https://github.com/olafhartong/sysmon-modular

It’s important to note here that while we covered some log-based IOCs for the tooling noted above, it is necessary to test your rules and coverage against a more varied set of launchers and configurations as these tools have various methods for changing these host-based indicators.

Scheduled Task Persistence

According to the FireEye report, one of the methods for establishing persistence was using scheduled tasks – let’s take a look.

One method of looking at Scheduled Tasks is hunting for schtasks.exe on the command line through either Sysmon Event ID 1 or Windows Security Event ID 4688 – here we wanted to highlight Event ID 4698 which occurs when a scheduled task is created.

In order for this log to be generated, the Audit Other Object Access Events log category needs to be enabled.

For testing purposes, we created a scheduled task on our host to simply launch Calculator, now let’s take a look at this activity in Splunk:

index=winlogs EventCode=4698
| xmlkv EventData_Xml
| table name,Command,Data,Enabled

I’m using the xmlkv operator here to split up the information regarding the scheduled task that’s in XML format, within an XML event:

And taking a look at our Splunk results:

Although not shown here, this event also contains information regarding the timing of the task, when it’s run and how long to run it for – this additional information can be used for both baselining and hunting efforts.

More information regarding this event can be found here: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698

Startup Folder Shortcut

Another persistence mechanism noted in the report is the creation of a shortcut in the Windows startup folder, on Windows 10 those locations are:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp
C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

I’ve gone ahead and created a shortcut in the startup folder for all users, we can use Sysmon FileCreate events to detect this activity, using the following Splunk query:

index=sysmon EventCode=11 TargetFilename=*StartUp* AND TargetFilename=*.lnk*
| table Image,TargetFilename

And looking at the results:

While we cannot see exactly what our shortcut file contains, we can see that one was created – although this may not be something you alert on, it is a useful data point to be aware of.

Scheduled BITS Job

Let’s set our simulated BITS job up:

We can hunt on the bitsadmin usage on the command line, and we can also see what spawned out of our bits process with the following Splunk query:

index=sysmon ParentCommandLine="C:\\Windows\\System32\\svchost.exe -k netsvcs -p -s BITS"
| table ParentCommandLine,Image,ParentImage,CommandLine

And the results:

The Microsoft-Windows-Bits-Client/Operational log channel will also have some useful information for hunting:

Suspicious processes spawning out of the BITS client as well as suspicious hosts in the BITS client log are great and high-fidelity events!

Registry Persistence

According to the article, the attackers use the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon registry key for persistence. Luckily for us Olaf’s Sysmon Configuration has us covered here.

We can use the following Splunk query:

index=sysmon EventCode=13 TargetObject=*Userinit*
| eval RuleNameSplit = split(RuleName,",")
| eval technique_name=mvindex(RuleNameSplit,1)
| eval TechniqueSplit = split(technique_name,"=")
| eval TechniqueNameOnly = mvindex(TechniqueSplit,1)
| table TechniqueNameOnly,RuleName,Details,TargetObject,Image

And get the results:

All the eval` and `mvindex commands are for extracting the technique_name from the RuleName Sysmon field, as perhaps you want to separate the technique name from the technique id for ease of analysis.

PowerLurk

The blog posts notes that PowerLurk was used to register WMI events that were used to kill various security tools running on a potentially infected host, let’s simulate this activity.

We configure PowerLurk to open calc.exe when the notepad.exe process starts:

And then take a look in the Microsoft-Windows-WMI-Activity/Operational log channel for Event IDs 5861 and 5859 examine this activity:

We can also take a look at Sysmon Event IDs 19 and 20 with the following Splunk query:

index=sysmon EventCode = 19 OR EventCode=20
| fillnull value="-"
| table EventType,Operation,EventNamespace,Query,Type,Destination

And the results:

We can see both the WmiFilter as well as the WmiConsumer events returned in our query and can see that calc.exe will execute when the notepad.exe process is started.

Active Directory Attacks

According to the blog post, the attackers utilized tools such as BloodHound, SharpHound and Kerbrute to attack victim Active Directory environments – We won’t go into detail regarding these attacks in this post, however, our recent post on Active Directory Attacks & Enumeration at the Network Layer might be helpful in detecting this kind of activity: https://www.lares.com/blog/active-directory-ad-attacks-enumeration-at-the-network-layer/

PsExec

Running PsExec with the following syntax:

PsExec.exe \\192.168.1.158 cmd.exe where 192.168.1.158 is our "victim" machine we can observe the following in Windows Event ID 4688 logs, with the following Splunk query:

index=winlogs EventCode=4688 *PSEXESVC*
| table ParentProcessName,NewProcessName,CommandLine

And the results:

We can see services.exe launching PSEXESVC.exe and then PSEXESVC.exe launching cmd.exe.

Looking at our old friend Event ID 7045 we can also see a service with the name of PSEXESVC being created:

Looking at Sysmon Create and Connect Pipe events, Registry Events, and File Creation events also gives us a ton more information regarding our PSExec execution, with the following query:

index=sysmon EventCode=18 OR EventCode=13 OR EventCode=17 OR EventCode=11 *PSEXESVC*
| fillnull value="-" 
| table EventType,PipeName,Image,TargetObject,TargetFilename

And the results, we can see pipe connections with the PSEXESVC value, as well as the PSEXESVC service starting up, in addition to a PSEXESVC executable being created in the C:\Windows directory.

JPCert provides a great overview of the event log artifacts left behind by a PSExec execution: https://jpcertcc.github.io/ToolAnalysisResultSheet/details/PsExec.htm

WMIC

The Ryuk ransomware itself, according to the blog post, was launched using WMIC with the /node flag used in order to start a process on a remote host.

Let’s start by executing our test command:

Commands executed in this manner will spawn from WmiPrvSE.exe, so let’s take a look at this activity:

index=sysmon EventCode =1 ParentImage = *WmiPrvSE.exe*
| table ParentImage,ParentCommandLine,CommandLine,Image

And the results:

Pivoting off the cmd.exe /c calc value, we can see if calc.exe spawned from cmd.exe with the following query:

index=sysmon EventCode =1 ParentImage = *cmd.exe*
| table ParentImage,ParentCommandLine,CommandLine,Image

And the results:

Conclusion

One sentence in FireEye’s fantastic blog post struck me:

The operators conducting these campaigns have actively targeted hospitals, retirement communities, and medical centers, even in the midst of a global health crisis, demonstrating a clear disregard for human life.

It is for this reason why we are sitting here at 1AM writing this; We wanted to contribute something which may help organizations protect themselves from these potentially devastating attacks. Although the FireEye post and some of the resources linked below provide much more granular IOCs – including file hashes, certificates and C2 domains – we wanted to take a more "macro" view and analyze some of the host-based tactics, techniques and procedures used by these threat actors.

References

The FireEye Report: https://www.fireeye.com/blog/threat-research/2020/10/kegtap-and-singlemalt-with-a-ransomware-chaser.html

UNC1878 IOCs provided by Aaron Stephens: https://twitter.com/x04steve/status/1321547740552351747

A great thread by Kevin Beaumont tracking these threat actors: https://twitter.com/GossiTheDog/status/1321566181359296519

The DFIR Report has a great write-up on Ryuk: https://thedfirreport.com/2020/10/08/ryuks-return/

Katie Nickels had a really helpful Twitter thread live-tweeting a SANS Webinar regarding Ryuk: https://twitter.com/likethecoins/status/1321470506198028289

Kyle Ehmke provides some additional Ryuk IOCs: https://twitter.com/kyleehmke/status/1321737401530753026?s=20