# See what it's like to have a partner in the fight.

**redcanary.com/blog/grief-ransomware/**

[Grief is a combination ransomware-extortion threat that first emerged in May 2021. The](https://www.zscaler.com/blogs/security-research/doppelpaymer-continues-cause-grief-through-rebranding)
group behind Grief maintains a public leak site where it posts stolen victim data. Despite the
handful of attacks publicly attributed to Grief, there’s been very little technical intelligence
published about the ransomware and the precursor behaviors that precede it.

Red Canary’s visibility into this threat has been limited, but—through a series of short-term
incident response engagements—we’ve noticed certain conspicuous patterns in the
malicious activities leading right up to the point of encryption. We haven’t seen the initial
infection vectors nor—importantly—the actual process of files getting encrypted. However,
we’ve seen the aftermath of the encryption and many of the behaviors that come before it.
We also performed dynamic analysis on a Grief sample in order to get a better idea of what
happens during the encryption process.

In this report, we’re going to share technical intelligence on how we’ve detected precursor
activity and helped customers respond to Grief outbreaks over the last couple months.

## The link between Dridex and Grief

Grief often turns up in environments where there’s been a [Dridex infection and in which](https://redcanary.com/threat-detection-report/threats/dridex/)
[there’s evidence of the post-exploitation tool Cobalt Strike. Though we were unable to](https://redcanary.com/threat-detection-report/threats/cobalt-strike/)
definitively determine that Grief originated from Dridex and Cobalt Strike in the


-----

environments we examined, we assess it s likely that these environments were initially
compromised via a Dridex infection and that the adversaries, in turn, leveraged Cobalt
Strike and subsequently deployed Grief. This assessment is at least partially validated by
[Dell SecureWorks, which has also observed a relationship between Dridex, Cobalt Strike,](https://www.secureworks.com/research/threat-profiles/gold-heron)
and Grief. Just a few days ago, [Zscaler published a report compellingly arguing that Grief is](https://www.zscaler.com/blogs/security-research/doppelpaymer-continues-cause-grief-through-rebranding)
a rebranded version of the now inactive DoppelPaymer ransomware. This is important
because DoppelPaymer has been a second-stage payload delivered after Dridex many
times in the past, which further supports the idea that the Dridex activity we saw is related
to Grief.

We published numerous strategies for detecting Dridex and Cobalt Strike in the 2021
Threat Detection Report. Those detection strategies continue to hold up, and, as you’ll see
below, many of them helped us detect and respond to Grief incidents with our incident
response partners.

**Dridex**

[We’ve observed adversaries leveraging DLL Search Order Hijacking (T1574.001 Hijack](https://redcanary.com/threat-detection-report/techniques/dll-search-order-hijacking/)
Execution Flow: DLL Search Order Hijacking) when deploying Dridex in the leadup to a
Grief infection. In general, this technique involves adversaries relocating native system
binaries and executing them from a non-standard directory such as `appdata\roaming . In`
cases where Dridex preceded Grief, we’ve seen adversaries relocate the system
information binary ( msinfo32.exe ) to the `appdata\roaming directory in order to load a`
malicious dynamic link library (DLL) into memory.

The following image represents a timeline of events on a single endpoint that illustrates
what this behavior looks like in telemetry:


-----

Figure 1
As you can see, the Task Scheduler Engine ( taskeng.exe ) spawns the relocated version
of `msinfo32.exe in the` `appdata\roaming directory. From there,` `msinfo32.exe loads`
a malicious DLL from the `appdata\roaming directory that masquerades as a legitimate`
[DLL ( mfc42u.dll ). (T1036.005 Masquerading: Match Legitimate Name or Location)](https://attack.mitre.org/techniques/T1574/001/)

### Detection opportunity 1

As observed in the above telemetry, `msinfo32.exe is executing without a corresponding`
command line, which gives us our first detection opportunity. Look for a parent process that
appears to be `taskeng.exe running in conjunction with a process path that includes`
```
users and appdata/roaming but without any corresponding command-line arguments.

```
Following that malicious DLL load, a cascade of different signed executables—almost
always spawning from `explorer.exe —launch from the` `appdata\roaming directory and`
load additional DLLs. Despite being named for legitimate DLLs, they too are malicious. In
some cases, we’ve seen control panel (CPL) files instead of DLLs, but they serve the same
functional purpose. The following image illustrates what this behavior looks like in endpoint
telemetry, with the legitimate Windows dialer process ( dialer.exe ) loading a malicious
DLL that’s been named to look like the telephony API client DLL ( tapi32.dll ).


-----

### Detection opportunity 2

Look for any processes executing from a non-standard directory or process path.

Following the example in Figure 2 above, you can look for the execution of a process that is
```
dialer.exe from an non-standard process path.* Standard process paths may vary from

```
one binary to another, but `dialer.exe usually exists in` `windows\system32,`
```
windows\syswow64, or windows\sysarm32 directories.

```
_*Note: This is easier said than done because you need to understand native Windows_
_binaries and the file or process paths from which they are supposed to execute. Lucky for_
_[us, our colleague Shane Welcher and](https://redcanary.com/authors/shane-welcher/)_ _[Michael Haag from Splunk already did the hard work](https://twitter.com/M_haggis)_
_of cataloguing the expected file path for every System32 binary (as well as other process_
_[metadata like internal binary names), on display in an article we published in early June.](https://redcanary.com/blog/system32-binaries/)_
_We consider that a foundational resource for anyone looking to bolster their coverage_
_against_ _[DLL Search Order Hijacking and](https://redcanary.com/threat-detection-report/techniques/dll-search-order-hijacking/)_ _[Masquerading, because it can help you develop](https://redcanary.com/threat-detection-report/techniques/masquerading/)_
_methods for reliably detecting when binaries execute from non-standard file paths or_
_directories or with unexpected file names. While it’s not tailored specifically to catch Dridex_
_or other Grief-related activity, it will almost certainly help you develop better depth of_
_coverage._

Some of the other binaries executing from non-standard directories include:

```
systempropertieshardware.exe

```

-----

The malicious DLLs and CPLs loaded by the above binaries include but aren t limited to the
following names:
```
mfc42u.dll
sysdm.cpl
wtsapi32.dll
version.dll
tapi32.dll
dpx.dll

```
**Cobalt Strike**

Cobalt Strike is one of the most common pre-ransomware payloads we observe, and it
[frequently follows malware families like Qbot,](https://redcanary.com/threat-detection-report/threats/qbot/) [IcedID, or in this case, Dridex. In cases where](https://redcanary.com/threat-detection-report/threats/icedid/)
[Cobalt Strike precedes Grief, we’ve observed the Windows Service Host ( svchost.exe )](https://redcanary.com/threat-detection-report/techniques/windows-service/)
executing without any commands in the command line. Under normal circumstances, you’d
always expect to see `svchost.exe with a command line that includes the` `-k command`
and specifies a service group. As you can see in the following image, our detection included
[neither. This is likely the result of a Cobalt Strike Beacon injecting code into](https://redcanary.com/threat-detection-report/techniques/process-injection/) `svchost.exe`
[(T1055 Process Injection).](https://attack.mitre.org/techniques/T1055/)

Figure 3
While we observed the adversary injecting into `svchost.exe in this particular instance,`
Cobalt Strike often targets a variety of other system binaries for injection. From a high level,
a Cobalt Strike Beacon injects code into memory by manipulating the memory space of a
native Windows binary. When examining the telemetry associated with this behavior, we
generally observe that the manipulated binaries execute without any corresponding
command-line arguments. Importantly, if you take a step back and analyze what is normal
activity for many of the system binaries abused by Cobalt Strike Beacons, it is not normal
for them to execute without corresponding command lines.

### Detection opportunity 3


-----

Since it s abnormal, alerting on the following processes when they execute without a
command-line argument can be a good way to detect Cobalt Strike, whether it’s delivering
Grief or serving some other malicious purpose:
```
rundll32.exe
werfault.exe
searchprotocolhost.exe
gpupdate.exe
regsvr32.exe
svchost.exe
msiexec.exe

```
To narrow this down even more, you can look for a process that appears to be one of these
binaries executing without any corresponding command-line arguments and making an
external network connection. You can see an example of this in Figure 3 for `svchost.exe .`

**Bonus malicious behavior**

During one of these intrusions, we also observed the Windows Print Spooler (`spoolsv.exe’)
making an external network connection. While we aren’t able to associate this behavior with
a specific threat (though we suspect it is related to Dridex), it’s nonetheless suspicious—
and has helped us detect a variety of suspicious and malicious behaviors.

### Detection opportunity 4

You can reliably detect this by looking for a process that is `explorer.exe spawning`
```
spoolsv.exe along with an external network connection.

## Grief counseling

```
All of this precursor activity leads up to the point where the Grief ransomware starts
gathering permissions and encrypting files. We have not had great visibility into how Grief
performs encryption, but we do have good insight into the activity directly preceding file
encryption.

**Getting permission**

In addition to the Dridex and Cobalt Strike activity that we assess is related to Grief, we
[observed the Windows DLL Host ( rundll32.exe ) loading a malicious DLL (T1218.011](https://redcanary.com/threat-detection-report/techniques/rundll32/)
Signed Binary Proxy Execution: Rundll32). That DLL is arbitrarily named and performs a
variety of functions. Based on dynamic analysis and process lineage, we assess that this
DLL:

created processes


-----

wrote registry values
encrypted file contents
modified Windows Services
modified Windows boot options
modified Windows Defender settings
modified Windows filesystem permissions

In the Dridex section above, we described how the adversary used relocated executables to
load malicious DLLs with legitimate names, thereby subverting the proper DLL search order
[in a technique known as DLL Search Order Hijacking. Here, the adversary is using](https://redcanary.com/threat-detection-report/techniques/dll-search-order-hijacking/)
```
rundll32.exe exactly as intended: to load and launch an arbitrary DLL. Of course, the

```
DLL itself is malicious and kicks off a series of malicious events.

In the following image, you can see `rundll32.exe running from the proper directory and`
loading a randomly named DLL, `sbtbku~1.dll . In fact, the telemetry includes two DLLs.`
The payload is housed within the first DLL, `sbtbku~1.dll . The purpose of anything`
beyond the `DllRegisterServer function in the below command line is currently an`
intelligence gap, as we’re unsure the purpose it serves for the adversary. Note that when
we removed either alphanumeric string ( -B5S8CD or `iUcicPOiYXwBS54S ) or the trailing`
DLL ( abc.dll ) at the end of this command line, the malicious payload would not execute.
[If you have more info on this to help fill our gap, we’d love to hear from you!](http://10.10.0.46/mailto:intel@redcanary.com)

_Note: We renamed the above DLLs and strings because their names are arbitrary and_
_some of them are unique to each affected endpoint. We have not determined why this is the_
_case, but the DLL and random string in the front half of the command line_
_( SBmceio\sbtbku~1.dll and_ `-B5S8CD ) changed from one endpoint to the next while`
_the trailing DLL and random alphanumeric string ( abc.dll and_ `iUcicPOiYXwBS54S )`
_remained constant._

Figure 4


-----

### Detection opportunity 5

As is illustrated in Figure 4, one way to detect Grief is by looking for the execution of a
process that appears to be `rundll32.exe executing with` `DllRegisterServer in the`
command line. This particular analytic is applicable to a wide variety of threats, including
Qbot.

Similarly, you may also be able to detect this and other malicious activity by alerting on
command lines that include `DllRegisterServer and follow-on arguments, as is`
illustrated in Figure 4 and further below in Figure 7. The `DllRegisterServer function, by`
design, is [not supposed to implement parameters.](https://docs.microsoft.com/en-us/windows/win32/api/olectl/nf-olectl-dllregisterserver%20Show%20less)

The first DLL in Figure 4 ( sbtbku~1.dll ) initiates multiple actions to facilitate encryption
or manipulate backups. It launches a `takeown.exe command that allows an administrator`
to take ownership of files relating to a backup, recovery, and data protection software called
Veritas. It also launches an `icacls.exe command that resets access permissions for the`
same files (T1222.001 File and Directory Permissions Modification: Windows File and
Directory Permissions Modification). As the following image shows, `takeown.exe and`
```
icacls.exe spawn as children of rundll32.exe because Rundll32 launched
sbtbku~1.dll .

```
Figure 5
Last but certainly not least, `sbtbku~1.dll launches the Boot Configuration Data Editor`
( bcdedit.exe ) and uses it to set the default safeboot configuration for minimal
functionality (preventing victims from accessing the internet, among other things) and to
[disable Windows recovery (T1490 Inhibit System Recovery).](https://attack.mitre.org/techniques/T1490/)


-----

Figure 6

### Detection opportunity 6

The detection opportunity illustrated in Figure 6 is helpful for rooting out adversaries
attempting to reconfigure Windows recovery settings. You can detect this by looking for a
process that is `bcdedit.exe spawning from a parent of` `rundll32.exe along with a`
command line containing “recoveryenabled” and ” no”.

**Leaving a note**

Interestingly, `sbtbku~1.dll also modified the Windows` `LegalNoticeCaption and`

`LegalNoticeText` [registry keys (T1112 Modify Registry), enabling them to display a](https://redcanary.com/blog/windows-registry-attacks-threat-detection/)
ransom message customized to each victim environment immediately at logon.


-----

Figure 7
The following image (Figure 8) shows how the manipulated Windows
```
LegalNoticeCaption and LegalNoticeText registry keys displayed a ransom

```
message customized to each victim environment. Under normal circumstances, these are
the registry keys that IT administrators often use to display legal warnings at bootup on
corporate-owned computers (e.g., “This computer is property of [company name].
Everything is monitored.”).


-----

Figure 8

## Additional observations

We received a sample of Grief from a third-party incident response partner and confirmed it
was in fact Grief ransomware based on the `.payorgrief file extension, the fact that the`
ransom linked to a known Grief TOR site, and the graphic in the ransom note. Our dynamic
analysis of this sample helped us confirm much of the analysis above, along with the
following additional observations:

[1. Ransomware usually deletes shadow copies (T1490 Inhibit System Recovery), but we](https://redcanary.com/blog/its-all-fun-and-games-until-ransomware-deletes-the-shadow-copies/)

did not observe Grief doing this. This could be because Grief was designed for the
operator to manually delete shadow copies, or for some other reason. This is
significant because if a victim has shadow copies enabled on a machine, they may be
able to restore lost data. If you can confirm that you have observed shadow copy
[deletion in Grief incidents, please reach out to us.](http://10.10.0.46/mailto:intel@redcanary.com)


-----

2. The Grief sample manipulated Windows Defender using Windows Registry

modifications. We often observe malware issuing PowerShell commands to disable or
modify Defender. In this case, Grief set the `Policies\Microsoft\Windows`
```
   Defender\Real-Time
   Protection\LocalSettingOverrideDisableRealtimeMonitoring and
    Policies\Microsoft\Windows Defender\DisableAntiSpyware keys (T1562

```
Impair Defenses). These changes would intentionally counteract settings applied by
administrators via Group Policy Objects.
3. Grief setting the system to boot from safe mode with minimal services available and

no network connectivity is noteworthy because very few ransomware families do this.
4. Grief has a peculiar way of setting itself up for persistence. It modifies a legitimate

Windows Service configuration to run the malware. Grief selects a legitimate Windows
Service and replaces the `ImagePath registry value of the service’s configuration to`
execute the ransomware again at the next boot (T1543.003 Create or Modify System
Process: Windows Service). This ensures that the next time the system starts, Grief
runs again and returns the system to safe mode.

**A note about indicators**

Many teams include indicators of compromise in their blog posts. We have chosen to focus
on behavioral detection opportunities instead, as we find these much more durable than
sharing hash values that change quickly. Additionally, the hash value of the Grief sample we
analyzed is specific to a single victim (as were many of the file names and IP addresses
associated with the threat), meaning it will not be useful for future detection. The same is
true for Dridex, as hashes change between victims. In the interest of helping researchers
discover similar samples to ours, we do want to disclose the import table hash of the Grief
sample:
```
 E1433a76b58c119fa5508912c531e476

```
_[Huge thanks to Detection Engineer Dan Cotton for his contributions to this research.](https://redcanary.com/authors/dan-cotton/)_

Look familiar? Get in touch!

If you've encountered anything resembling Grief ransomware in your environment, let us
know!

Related Articles

Detection and response

### ChromeLoader: a pushy malvertiser


-----

Detection and response

### Intelligence Insights: May 2022

Detection and response

### The Goot cause: Detecting Gootloader and its follow-on activity

Detection and response

### Marshmallows & Kerberoasting

**Subscribe to our blog**

Our website uses cookies to provide you with a better browsing experience. More
[information can be found in our Privacy Policy.](https://redcanary.com/privacy-policy)

X

**Privacy Overview**

This website uses cookies to improve your experience while you navigate through the
website. Out of these cookies, the cookies that are categorized as necessary are stored on
your browser as they are essential for the working of basic functionalities of the website. We
also use third-party cookies that help us analyze and understand how you use this website.
These cookies will be stored in your browser only with your consent. You also have the
option to opt-out of these cookies. But opting out of some of these cookies may have an
effect on your browsing experience.

Necessary cookies are absolutely essential for the website to function properly. This category
only includes cookies that ensures basic functionalities and security features of the website.
These cookies do not store any personal information.

Any cookies that may not be particularly necessary for the website to function and is used
specifically to collect user personal data via analytics, ads, other embedded contents are
termed as non-necessary cookies. It is mandatory to procure user consent prior to running
these cookies on your website.


-----