Good Grief, Getting Over the Pain of IOCs
Nicholas Carroll
IT and Cybersecurity Professional, Tech Educator, Former CISO and CTO, Current Cyber Threat Intelligence Researcher
The other day I had a brief Twitter interaction with SOS Intel about Clop ransomware group’s page being down temporarily.
The reminder that Grief has been down for long enough to be considered potentially abandoned brought me back to the last time Grief went silent…
A Ransomware Group by Any Other Name
In 2017, a group of former GameOver Zeus network affiliates referring to themselves as “The Business Club” changed the tactics they had been using for the past few years to adopt ransomware as their primary method. This ransomware, dubbed BitPaymer, was often delivered by Dridex malware or RDP attacks and had great early success against the UK’s NHS.
BitPaymer would terrorize multiple large entities over the next couple of years until a new variant started hitting targets in 2019. This variant, DoppelPaymer, shared quite a bit of code with BitPaymer.
DoppelPaymer expanded on BitPaymer with a better encryption mechanism and enhanced evasion techniques. And it hit the ground running hard in 2019, claiming German and American medical service providers before adding a TOR dark web site to shame and double extort victims in 2020. DoppelPaymer was not shy in naming victims, going so far as to run a Twitter account alongside their TOR site to harass victims.
DoppelPaymer operatives would also call victims to harass them into paying the ransom. Successful attacks occurred throughout 2020 and into early 2021 until the group went silent for a short period of time. On May 6, 2021, the group seemed to stop operations. On May 17, 2021, the first Grief (aka PayorGrief) ransomware sample was compiled.
Grief was a ‘new’ ransomware group, except it really was not.
Grief was DoppelPaymer with a fresh coat of paint and some light changes.
Guess which screen shot is from the DoppelPaymer site and which is Grief.
Here is a page with a bigger change…
The left page is Grief’s payment page, and the right is DoppelPaymer. The most critical difference is the shift from accepting payments in Bitcoin to Monero which was most likely in response to the FBI’s ability to reclaim part of the Bitcoin payment made to Darkside as part of the Colonial Pipeline Incident.
Thanks for the history lesson, but what does this have to do with IOCs?
“The Business Club” started with Dridex malware in 2014, switched to ransomware in 2017, changed their ransomware in 2019 and then changed it again in 2021 (maybe they will do it again in 2022). In fact, they changed from DoppelPaymer to Grief almost exactly one year ago as of writing this post. Every time they changed, they invalidated IOCs that would be used for historical artifact hunting. That is most likely the reason they made the changes and could be making changes now. Indicators of Compromise are easily swapped by threat actors by recompiling malware to change hashes, changing IPs and URLs, etc. So, someone who was trying to use IOCs to hunt for BitPaymer would not catch DoppelPaymer, and someone using IOCs to hunt for DoppelPaymer would not catch Grief. This puts organizations’ security teams behind the attacker at each rebrand and change. But if IOCs can lead us to be behind the attacker and potentially in a world of pain when the attacker slips into our network and brings chaos with them, how do we get ahead?
Getting Over Grief: Accepting the Fault in IOCs
So, if IOCs only let us look at historical snapshots and potentially trap our monitoring in the past, the way to get into the present or ahead of the future is to look at TTPs: Tactics, Techniques, and Procedures. While IOCs changed each time the group has rebranded, many of the overall techniques the group has used remained the same. This is the way that researchers such as those at Crowd Strike and other major security companies track attribution to these groups (Check out Doppel Spider and Indrik Spider, the name Crowd Strike gives to the groups behind these malware families https://adversary.crowdstrike.com/en-US/adversary/doppel-spider/ and https://malpedia.caad.fkie.fraunhofer.de/actor/indrik_spider). The group originally known as “The Business Club” started with Dridex malware and continued to use Dridex versions as part of its attack chain even when operating the Grief ransomware strain. This part of their playbook rarely varied in almost seven years of operation. Dridex was also part of the early attack chain leading into a Grief infection, so detecting this malware would help an organization get ahead of the ransomware attack. But if we want to detect Dridex without using IOCs, what do we look for?
Dridex malware tends to use similar techniques during its infection chain, even though the hash of the malware will most likely change between attacks. Just because the hash changes, the operation of the malware does not. So, if we can catch suspicious actions on a host that align with the operation of the Dridex family, we can try to head the attackers off before completing their final ransomware and data exfiltration objective. Dridex infections often incorporate the technique of hijacking DLL search order to get their malicious payloads to execute on systems. In the MITRE ATT&CK framework, this would be sub-technique T1574.001 (https://attack.mitre.org/techniques/T1574/001/). The MITRE page even gives some great mitigation resources for defenders looking to stop this technique in its tracks.
Those on the monitoring side would want to look at the Detection section.
Let us look at some practical applications for monitoring. Because Dridex uses more than just this one technique, we can take multiple actions that Dridex often performs and combine them into a detection query or rule. Outside of T1574.001, Dridex will often also perform some initial information discovery about the host/network it is infecting. These kinds of actions typically fall under MITRE ATT&CK techniques T1135 for Network Share Discovery (https://attack.mitre.org/techniques/T1135/) and T1033 for System Owner/User Discovery (https://attack.mitre.org/techniques/T1033/). Combining looking for these types of actions followed by some sort of process injection or DLL hijacking would be a great combination to catch Dridex in the act, no IOCs involved. Common built-in Windows tools that Dridex can use to perform these discovery actions, and that Dridex has been observed using, includes ‘whoami.exe,’ ‘net.exe,’ and ‘svchost.exe.’ Security Boulevard has a great visual representation of that process:
领英推荐
We are looking to catch it in the act, about the point Dridex would be using ‘net.exe’ and ‘whoami.exe’ from the System32 folder, leading into the point where Dridex is moving to injection. About here:
Really, there are multiple excellent detection points in the chain, this is just an easy one to build a query for. And it is a query that I do not have to reinvent the wheel on compliments of Florian Roth and the Sigma project. They’ve already created a similar rule for Dridex at https://raw.githubusercontent.com/SigmaHQ/sigma/dd7576e4b34058061769941b51ff3e8f3e19d68b/rules/windows/process_creation/proc_creation_win_malware_dridex.yml. Here is that rule:
title: Dridex Process Pattern
id: e6eb5a96-9e6f-4a18-9cdd-642cfda21c8e
status: stable
description: Detects typical Dridex process patterns
author: Florian Roth, oscd.community
references:
? - https://app.any.run/tasks/993daa5e-112a-4ff6-8b5a-edbcec7c7ba3
date: 2019/01/10
modified: 2021/11/27
logsource:
? category: process_creation
? product: windows
detection:
? selection1:
??? Image|endswith: '\svchost.exe'
??? CommandLine|contains|all:
????? - 'C:\Users\'
????? - '\Desktop\'
? selection2:
??? ParentImage|endswith: '\svchost.exe'
? selection3:
??? Image|endswith: '\whoami.exe'
??? CommandLine|contains: 'all'
? selection4:
??? Image|endswith:
????? - '\net.exe'
????? - '\net1.exe'
??? CommandLine|contains: 'view'
??condition: selection1 or selection2 and (selection3 or selection4)
falsepositives:
? - Unlikely
level: critical
tags:
? - attack.defense_evasion
? - attack.privilege_escalation
? - attack.t1055
? - attack.discovery
? - attack.t1135
? - attack.t1033n
Using the Sigma rule, we can follow along and make a sample query for Elastic…
((process.executable:*\\svchost.exe AND process.command_line:*C\:\\Users\\* AND process.command_line:*\\Desktop\\*) OR (process.parent.executable:*\\svchost.exe AND ((process.executable:*\\whoami.exe AND process.command_line:*all*) OR (process.executable:(*\\net.exe OR *\\net1.exe) AND process.command_line:*view*))))
Or Splunk…
(source="WinEventLog:*" AND ((Image="*\\svchost.exe" AND CommandLine="*C:\\Users\\*" AND CommandLine="*\\Desktop\\*") OR (ParentImage="*\\svchost.exe" AND ((Image="*\\whoami.exe" AND CommandLine="*all*") OR ((Image="*\\net.exe" OR Image="*\\net1.exe") AND CommandLine="*view*")))))
Or Defender for Endpoint…
DeviceProcessEvents | where ((FolderPath endswith @"\svchost.exe" and ProcessCommandLine contains @"C:\Users\" and ProcessCommandLine contains @"\Desktop\") or (InitiatingProcessFolderPath endswith @"\svchost.exe" and ((FolderPath endswith @"\whoami.exe" and ProcessCommandLine contains "all") or ((FolderPath endswith @"\net.exe" or FolderPath endswith @"\net1.exe") and ProcessCommandLine contains "view"))))
Or any number of other SIEM and EDR tools. These can easily be generated by using the Sigmac tool from https://github.com/SigmaHQ/sigma or manually by reading the critical pieces from the rule. If I were feeling bold, I could make my own detection rule/query for Dridex, too, focused on catching the infection chain in process based on the intel we have seen here. And catching Dridex in the act will go a long way to protecting our environment from ransomware attacks tied to BitPaymer, DoppelPaymer, Grief, or whatever name they take next, because after using Dridex as part of their playbook for about seven years, there is little chance they change that on their next rebrand.