The Gentlemen RaaS & GentleKiller: Analyzing the 400-Process Kill Switch
Has anyone else dug into the technical writeups for the GentleKiller framework used by the Gentlemen RaaS? It's pretty wild—this isn't just a batch script task-killing Defender; it's a full-fledged modular framework specifically designed to take out roughly 400 security processes before encryption starts.
What stands out to me is the scope. They aren't just targeting Microsoft Defender; they're going after CrowdStrike, SentinelOne, and smaller niche tools. If they can't kill the process via standard API calls, they reportedly fall back to third-party tools or vulnerable drivers.
For detection, we're looking at mass process termination events. Here is a basic KQL query I'm using to hunt for these patterns in Sentinel, focusing on the velocity of terminations:
DeviceProcessEvents
| where ActionType == "ProcessTerminated"
| where InitiatingProcessAccountName != "SYSTEM"
| summarize count() by InitiatingProcessFileName, bin(Timestamp, 1m)
| where count_ > 5
| order by count_ desc
We are also recommending blocklisting the specific process hashes associated with the framework currently being shared in intel communities.
With the rise of these "EDR Killer" suites, are any of you shifting towards EDR solutions that rely heavily on kernel-level callbacks or utilizing hardware-based virtualization (HVCI) to make these user-mode process terminations harder to execute?
We caught a variant of this last week in a sandbox environment. The key is that they often try to disable Sysmon first to blind you. Make sure you have monitoring on Event ID 4 (Sysmon service state change) and Event ID 5 (Process termination).
If you see an unsigned process terminating MsMpEng.exe or CSFalconService.exe, it's game over for that host unless you have PPL (Protected Process Light) enabled on your sensors.
From a Red Team perspective, these frameworks are becoming standard because EDRs are getting better at API hooking. If API termination fails, they almost always load a vulnerable signed driver (BYOVD) to patch the kernel and kill the EDR that way.
I'd suggest monitoring for suspicious driver loads using this PowerShell snippet on critical assets:
Get-WinEvent -FilterHashtable @{LogName='System'; ID=6} | Where-Object {$_.Message -match 'Unsigned'} | Select-Object TimeCreated, Message
We've moved to strictly enforcing Allow-listing for drivers via Windows Defender Application Control (WDAC). It's a pain to manage initially, but it stops the BYOVD aspect of GentleKiller dead in its tracks. You can't kill the EDR if you can't load the vulnerable driver to unhook it.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access