{
	"id": "9f23e608-6486-4f8e-9d02-e51a53694763",
	"created_at": "2026-04-06T00:09:13.704525Z",
	"updated_at": "2026-04-10T03:24:24.650245Z",
	"deleted_at": null,
	"sha1_hash": "5bd333a77d96d1798885f97ce59f70b7949135f5",
	"title": "Red Canary Intel: When Dridex and Cobalt Strike give you Grief",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 125256,
	"plain_text": "Red Canary Intel: When Dridex and Cobalt Strike give you Grief\r\nBy susannah.matt@redcanary.com\r\nArchived: 2026-04-05 14:54:08 UTC\r\nGrief is a combination ransomware-extortion threat that first emerged in May 2021. The group behind Grief\r\nmaintains a public leak site where it posts stolen victim data. Despite the handful of attacks publicly attributed to\r\nGrief, there’s been very little technical intelligence published about the ransomware and the precursor behaviors\r\nthat precede it.\r\nRed Canary’s visibility into this threat has been limited, but—through a series of short-term incident response\r\nengagements—we’ve noticed certain conspicuous patterns in the malicious activities leading right up to the point\r\nof encryption. We haven’t seen the initial infection vectors nor—importantly—the actual process of files getting\r\nencrypted. However, we’ve seen the aftermath of the encryption and many of the behaviors that come before it.\r\nWe also performed dynamic analysis on a Grief sample in order to get a better idea of what happens during the\r\nencryption process.\r\nIn this report, we’re going to share technical intelligence on how we’ve detected precursor activity and helped\r\ncustomers respond to Grief outbreaks over the last couple months.\r\nThe link between Dridex and Grief\r\nGrief often turns up in environments where there’s been a Dridex infection and in which there’s evidence of the\r\npost-exploitation tool Cobalt Strike. Though we were unable to definitively determine that Grief originated from\r\nDridex and Cobalt Strike in the environments we examined, we assess it’s likely that these environments were\r\ninitially compromised via a Dridex infection and that the adversaries, in turn, leveraged Cobalt Strike and\r\nsubsequently deployed Grief. This assessment is at least partially validated by Dell SecureWorks, which has also\r\nobserved a relationship between Dridex, Cobalt Strike, and Grief. Just a few days ago, Zscaler published a report\r\ncompellingly arguing that Grief is a rebranded version of the now inactive DoppelPaymer ransomware. This is\r\nimportant because DoppelPaymer has been a second-stage payload delivered after Dridex many times in the past,\r\nwhich further supports the idea that the Dridex activity we saw is related to Grief.\r\nWe published numerous strategies for detecting Dridex and Cobalt Strike in the 2021 Threat Detection Report.\r\nThose detection strategies continue to hold up, and, as you’ll see below, many of them helped us detect and\r\nrespond to Grief incidents with our incident response partners.\r\nDridex\r\nWe’ve observed adversaries leveraging DLL Search Order Hijacking (T1574.001 Hijack Execution Flow: DLL\r\nSearch Order Hijacking) when deploying Dridex in the leadup to a Grief infection. In general, this technique\r\ninvolves adversaries relocating native system binaries and executing them from a non-standard directory such as\r\nappdata\\roaming . In cases where Dridex preceded Grief, we’ve seen adversaries relocate the system information\r\nhttps://redcanary.com/blog/grief-ransomware/\r\nPage 1 of 10\n\nbinary ( msinfo32.exe ) to the appdata\\roaming directory in order to load a malicious dynamic link library\r\n(DLL) into memory.\r\nThe following image represents a timeline of events on a single endpoint that illustrates what this behavior looks\r\nlike in telemetry:\r\nFigure 1\r\nAs you can see, the Task Scheduler Engine ( taskeng.exe ) spawns the relocated version of msinfo32.exe in the\r\nappdata\\roaming directory. From there, msinfo32.exe loads a malicious DLL from the appdata\\roaming\r\ndirectory that masquerades as a legitimate DLL ( mfc42u.dll ). (T1036.005 Masquerading: Match Legitimate\r\nName or Location)\r\nDetection opportunity 1\r\nAs observed in the above telemetry, msinfo32.exe is executing without a corresponding command line, which\r\ngives us our first detection opportunity. Look for a parent process that appears to be taskeng.exe running in\r\nconjunction with a process path that includes users and appdata/roaming but without any corresponding\r\ncommand-line arguments.\r\nFollowing that malicious DLL load, a cascade of different signed executables—almost always spawning from\r\nexplorer.exe —launch from the appdata\\roaming directory and load additional DLLs. Despite being named\r\nfor legitimate DLLs, they too are malicious. In some cases, we’ve seen control panel (CPL) files instead of DLLs,\r\nbut they serve the same functional purpose. The following image illustrates what this behavior looks like in\r\nendpoint telemetry, with the legitimate Windows dialer process ( dialer.exe ) loading a malicious DLL that’s\r\nbeen named to look like the telephony API client DLL ( tapi32.dll ).\r\nhttps://redcanary.com/blog/grief-ransomware/\r\nPage 2 of 10\n\nDetection opportunity 2\r\nLook for any processes executing from a non-standard directory or process path.\r\nFollowing the example in Figure 2 above, you can look for the execution of a process that is dialer.exe from an\r\nnon-standard process path.* Standard process paths may vary from one binary to another, but dialer.exe\r\nusually exists in windows\\system32 , windows\\syswow64 , or windows\\sysarm32 directories.\r\n*Note: This is easier said than done because you need to understand native Windows binaries and the file or\r\nprocess paths from which they are supposed to execute. Lucky for us, our colleague Shane Welcher and Michael\r\nHaag from Splunk already did the hard work of cataloguing the expected file path for every System32 binary (as\r\nwell as other process metadata like internal binary names), on display in an article we published in early June.\r\nWe consider that a foundational resource for anyone looking to bolster their coverage against DLL Search Order\r\nHijacking and Masquerading, because it can help you develop methods for reliably detecting when binaries\r\nexecute from non-standard file paths or directories or with unexpected file names. While it’s not tailored\r\nspecifically to catch Dridex or other Grief-related activity, it will almost certainly help you develop better depth of\r\ncoverage.\r\nSome of the other binaries executing from non-standard directories include:\r\ndialer.exe\r\nsystempropertiesperformance.exe\r\nsystempropertiesdataexecutionprevention.exe\r\nsystempropertieshardware.exe\r\nsigverif.exe\r\ncomputerdefaults.exe\r\ntabcal.exe\r\nwusa.exe\r\ntpminit.exe\r\nigfxsdk.exe\r\nupdate.exe\r\nThe malicious DLLs and CPLs loaded by the above binaries include but aren’t limited to the following names:\r\nhttps://redcanary.com/blog/grief-ransomware/\r\nPage 3 of 10\n\nmfc42u.dll\r\nsysdm.cpl\r\nwtsapi32.dll\r\nversion.dll\r\ntapi32.dll\r\ndpx.dll\r\nCobalt Strike\r\nCobalt Strike is one of the most common pre-ransomware payloads we observe, and it frequently follows malware\r\nfamilies like Qbot, IcedID, or in this case, Dridex. In cases where Cobalt Strike precedes Grief, we’ve observed\r\nthe Windows Service Host ( svchost.exe ) executing without any commands in the command line. Under normal\r\ncircumstances, you’d always expect to see svchost.exe with a command line that includes the -k command\r\nand specifies a service group. As you can see in the following image, our detection included neither. This is likely\r\nthe result of a Cobalt Strike Beacon injecting code into svchost.exe (T1055 Process Injection).\r\nFigure 3\r\nWhile we observed the adversary injecting into svchost.exe in this particular instance, Cobalt Strike often\r\ntargets a variety of other system binaries for injection. From a high level, a Cobalt Strike Beacon injects code into\r\nmemory by manipulating the memory space of a native Windows binary. When examining the telemetry\r\nassociated with this behavior, we generally observe that the manipulated binaries execute without any\r\ncorresponding command-line arguments. Importantly, if you take a step back and analyze what is normal activity\r\nfor many of the system binaries abused by Cobalt Strike Beacons, it is not normal for them to execute without\r\ncorresponding command lines.\r\nDetection opportunity 3\r\nSince it’s abnormal, alerting on the following processes when they execute without a command-line argument can\r\nbe a good way to detect Cobalt Strike, whether it’s delivering Grief or serving some other malicious purpose:\r\nrundll32.exe\r\nwerfault.exe\r\nsearchprotocolhost.exe\r\nhttps://redcanary.com/blog/grief-ransomware/\r\nPage 4 of 10\n\ngpupdate.exe\r\nregsvr32.exe\r\nsvchost.exe\r\nmsiexec.exe\r\nTo narrow this down even more, you can look for a process that appears to be one of these binaries executing\r\nwithout any corresponding command-line arguments and making an external network connection. You can see an\r\nexample of this in Figure 3 for svchost.exe .\r\nBonus malicious behavior\r\nDuring one of these intrusions, we also observed the Windows Print Spooler (`spoolsv.exe’) making an external\r\nnetwork connection. While we aren’t able to associate this behavior with a specific threat (though we suspect it is\r\nrelated to Dridex), it’s nonetheless suspicious—and has helped us detect a variety of suspicious and malicious\r\nbehaviors.\r\nDetection opportunity 4\r\nYou can reliably detect this by looking for a process that is explorer.exe spawning spoolsv.exe along with an\r\nexternal network connection.\r\nGrief counseling\r\nAll of this precursor activity leads up to the point where the Grief ransomware starts gathering permissions and\r\nencrypting files. We have not had great visibility into how Grief performs encryption, but we do have good insight\r\ninto the activity directly preceding file encryption.\r\nGetting permission\r\nIn addition to the Dridex and Cobalt Strike activity that we assess is related to Grief, we observed the Windows\r\nDLL Host ( rundll32.exe ) loading a malicious DLL (T1218.011 Signed Binary Proxy Execution: Rundll32).\r\nThat DLL is arbitrarily named and performs a variety of functions. Based on dynamic analysis and process\r\nlineage, we assess that this DLL:\r\ncreated processes\r\nwrote registry values\r\nencrypted file contents\r\nmodified Windows Services\r\nmodified Windows boot options\r\nmodified Windows Defender settings\r\nmodified Windows filesystem permissions\r\nhttps://redcanary.com/blog/grief-ransomware/\r\nPage 5 of 10\n\nIn the Dridex section above, we described how the adversary used relocated executables to load malicious DLLs\r\nwith legitimate names, thereby subverting the proper DLL search order in a technique known as DLL Search\r\nOrder Hijacking. Here, the adversary is using rundll32.exe exactly as intended: to load and launch an arbitrary\r\nDLL. Of course, the DLL itself is malicious and kicks off a series of malicious events.\r\nIn the following image, you can see rundll32.exe running from the proper directory and loading a randomly\r\nnamed DLL, sbtbku~1.dll . In fact, the telemetry includes two DLLs. The payload is housed within the first\r\nDLL, sbtbku~1.dll . The purpose of anything beyond the DllRegisterServer function in the below command\r\nline is currently an intelligence gap, as we’re unsure the purpose it serves for the adversary. Note that when we\r\nremoved either alphanumeric string ( -B5S8CD or iUcicPOiYXwBS54S ) or the trailing DLL ( abc.dll ) at the end\r\nof this command line, the malicious payload would not execute. If you have more info on this to help fill our gap,\r\nwe’d love to hear from you!\r\nNote: We renamed the above DLLs and strings because their names are arbitrary and some of them are unique to\r\neach affected endpoint. We have not determined why this is the case, but the DLL and random string in the front\r\nhalf of the command line ( SBmceio\\sbtbku~1.dll and -B5S8CD ) changed from one endpoint to the next while\r\nthe trailing DLL and random alphanumeric string ( abc.dll and iUcicPOiYXwBS54S ) remained constant.\r\nFigure 4\r\nDetection opportunity 5\r\nAs is illustrated in Figure 4, one way to detect Grief is by looking for the execution of a process that appears to be\r\nrundll32.exe executing with DllRegisterServer in the command line. This particular analytic is applicable to\r\na wide variety of threats, including Qbot.\r\nSimilarly, you may also be able to detect this and other malicious activity by alerting on command lines that\r\ninclude DllRegisterServer and follow-on arguments, as is illustrated in Figure 4 and further below in Figure 7.\r\nThe DllRegisterServer function, by design, is not supposed to implement parameters.\r\nThe first DLL in Figure 4 ( sbtbku~1.dll ) initiates multiple actions to facilitate encryption or manipulate\r\nbackups. It launches a takeown.exe command that allows an administrator to take ownership of files relating to a\r\nbackup, recovery, and data protection software called Veritas. It also launches an icacls.exe command that\r\nhttps://redcanary.com/blog/grief-ransomware/\r\nPage 6 of 10\n\nresets access permissions for the same files (T1222.001 File and Directory Permissions Modification: Windows\r\nFile and Directory Permissions Modification). As the following image shows, takeown.exe and icacls.exe\r\nspawn as children of rundll32.exe because Rundll32 launched sbtbku~1.dll .\r\nFigure 5\r\nLast but certainly not least, sbtbku~1.dll launches the Boot Configuration Data Editor ( bcdedit.exe ) and uses\r\nit to set the default safeboot configuration for minimal functionality (preventing victims from accessing the\r\ninternet, among other things) and to disable Windows recovery (T1490 Inhibit System Recovery).\r\nFigure 6\r\nDetection opportunity 6\r\nThe detection opportunity illustrated in Figure 6 is helpful for rooting out adversaries attempting to reconfigure\r\nWindows recovery settings. You can detect this by looking for a process that is bcdedit.exe spawning from a\r\nparent of rundll32.exe along with a command line containing “recoveryenabled” and ” no”.\r\nLeaving a note\r\nhttps://redcanary.com/blog/grief-ransomware/\r\nPage 7 of 10\n\nInterestingly, sbtbku~1.dll also modified the Windows LegalNoticeCaption and LegalNoticeText registry\r\nkeys (T1112 Modify Registry), enabling them to display a ransom message customized to each victim\r\nenvironment immediately at logon.\r\nFigure 7\r\nThe following image (Figure 8) shows how the manipulated Windows LegalNoticeCaption and\r\nLegalNoticeText registry keys displayed a ransom message customized to each victim environment. Under\r\nnormal circumstances, these are the registry keys that IT administrators often use to display legal warnings at\r\nbootup on corporate-owned computers (e.g., “This computer is property of [company name]. Everything is\r\nmonitored.”).\r\nhttps://redcanary.com/blog/grief-ransomware/\r\nPage 8 of 10\n\nFigure 8\r\nAdditional observations\r\nWe received a sample of Grief from a third-party incident response partner and confirmed it was in fact Grief\r\nransomware based on the .payorgrief file extension, the fact that the ransom linked to a known Grief TOR site,\r\nand the graphic in the ransom note. Our dynamic analysis of this sample helped us confirm much of the analysis\r\nabove, along with the following additional observations:\r\n1. Ransomware usually deletes shadow copies (T1490 Inhibit System Recovery), but we did not observe\r\nGrief doing this. This could be because Grief was designed for the operator to manually delete shadow\r\ncopies, or for some other reason. This is significant because if a victim has shadow copies enabled on a\r\nmachine, they may be able to restore lost data. If you can confirm that you have observed shadow copy\r\ndeletion in Grief incidents, please reach out to us.\r\n2. The Grief sample manipulated Windows Defender using Windows Registry modifications. We often\r\nobserve malware issuing PowerShell commands to disable or modify Defender. In this case, Grief set the\r\nPolicies\\Microsoft\\Windows Defender\\Real-Time\r\nProtection\\LocalSettingOverrideDisableRealtimeMonitoring and Policies\\Microsoft\\Windows\r\nDefender\\DisableAntiSpyware keys (T1562 Impair Defenses). These changes would intentionally\r\ncounteract settings applied by administrators via Group Policy Objects.\r\n3. Grief setting the system to boot from safe mode with minimal services available and no network\r\nconnectivity is noteworthy because very few ransomware families do this.\r\n4. Grief has a peculiar way of setting itself up for persistence. It modifies a legitimate Windows Service\r\nconfiguration to run the malware. Grief selects a legitimate Windows Service and replaces the ImagePath\r\nregistry value of the service’s configuration to execute the ransomware again at the next boot (T1543.003\r\nhttps://redcanary.com/blog/grief-ransomware/\r\nPage 9 of 10\n\nCreate or Modify System Process: Windows Service). This ensures that the next time the system starts,\r\nGrief runs again and returns the system to safe mode.\r\nA note about indicators\r\nMany teams include indicators of compromise in their blog posts. We have chosen to focus on behavioral\r\ndetection opportunities instead, as we find these much more durable than sharing hash values that change quickly.\r\nAdditionally, the hash value of the Grief sample we analyzed is specific to a single victim (as were many of the\r\nfile names and IP addresses associated with the threat), meaning it will not be useful for future detection. The\r\nsame is true for Dridex, as hashes change between victims. In the interest of helping researchers discover similar\r\nsamples to ours, we do want to disclose the import table hash of the Grief sample:\r\nE1433a76b58c119fa5508912c531e476\r\nHuge thanks to Detection Engineer Dan Cotton for his contributions to this research. \r\nSource: https://redcanary.com/blog/grief-ransomware/\r\nhttps://redcanary.com/blog/grief-ransomware/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://redcanary.com/blog/grief-ransomware/"
	],
	"report_names": [
		"grief-ransomware"
	],
	"threat_actors": [
		{
			"id": "610a7295-3139-4f34-8cec-b3da40add480",
			"created_at": "2023-01-06T13:46:38.608142Z",
			"updated_at": "2026-04-10T02:00:03.03764Z",
			"deleted_at": null,
			"main_name": "Cobalt",
			"aliases": [
				"Cobalt Group",
				"Cobalt Gang",
				"GOLD KINGSWOOD",
				"COBALT SPIDER",
				"G0080",
				"Mule Libra"
			],
			"source_name": "MISPGALAXY:Cobalt",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434153,
	"ts_updated_at": 1775791464,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5bd333a77d96d1798885f97ce59f70b7949135f5.pdf",
		"text": "https://archive.orkl.eu/5bd333a77d96d1798885f97ce59f70b7949135f5.txt",
		"img": "https://archive.orkl.eu/5bd333a77d96d1798885f97ce59f70b7949135f5.jpg"
	}
}