SentinelOne: „EDR-Killer“ nicht als einen Angriff behandeln, sondern vier Techniken jagen

Vier Techniken, ein Etikett

Laut SentinelOne verbindet die vier Techniken das Ziel, Werkzeuge für Endpoint Detection and Response (EDR) abzuschalten, und sonst kaum etwas. Das Unternehmen beschreibt sie so:

• Bring-your-own-vulnerable-driver (BYOVD): lädt einen signierten, aber fehlerhaften Treiber und beendet darüber Prozesse im Kernel.
• Bring-your-own-installer: missbraucht einen vertrauenswürdigen Installer oder Update-Pfad, um den Agenten auszutauschen.
• Admin-to-kernel: führt eine bereits erhöhte Sitzung über eine dokumentierte Lücke in Ring 0.
• Treiberlose Suspendierung: berührt den Kernel nie und friert den Agenten aus dem User Space ein oder filtert ihn.

Der Preis für das Vermengen ist eine Abdeckungslücke, die schwer zu erkennen ist. Eine einzelne Regel für Treiberladevorgänge sieht wie Abdeckung gegen „EDR-Killer“ aus. Auf dem Installer- und dem treiberlosen Pfad entsteht jedoch gar kein Treiberlade-Event, die Regel bleibt also stumm, während der Agent stirbt.

Hunt eins und zwei: der Treiber und die Kette

SentinelOne nennt BYOVD die lauteste der vier Techniken und die erste, die man instrumentieren sollte. Das Unternehmen verweist auf das Projekt LOLDrivers, das Tausende verwundbarer signierter Treiber verzeichnet, die meisten davon ohne Administratorrechte erreichbar. Das zentrale Signal ist Sysmon Event ID 6, das jeden Treiberladevorgang mit Feldern wie ImageLoaded, Hashes, Signed, Signature und SignatureStatus protokolliert. Jeder SignatureStatus außer Valid verdiene eine Untersuchung, so das Unternehmen.

Es empfiehlt zwei signaturbasierte Erkennungen: Alarm bei jedem Treiberladevorgang, dessen Signaturstatus nicht Valid ist, sowie Alarm bei einem Treiber, dessen Hash, Signierer oder Version auf dem Host noch nie gesehen wurde. Die zweite Regel schlägt nach Patch-Zyklen bei legitimer neuer Software an. SentinelOne rät daher zu einer Tuning-Phase und einer Allowlist, bevor sie in eine 24/7-Queue geleitet wird.

Außerdem warnt das Unternehmen davor, sich auf Prävention zu verlassen. Die Attack-Surface-Reduction-Regel (ASR) verhindert, dass ein verwundbarer signierter Treiber auf die Festplatte geschrieben wird, stoppt aber nicht das Laden eines bereits vorhandenen Treibers. Das CodeIntegrity-Operational-Log mit Event ID 3099 bestätigt lediglich, dass die Blocklist-Richtlinie auf einem Host angewendet wird.

Der zweite Hunt korreliert die vollständige, geordnete Kette: sc.exe service create (Sysmon Event ID 1) plus eine Dienstinstallation (System Event 7045), ein Treiberladevorgang bei Event ID 6, ein DeviceIoControl-Aufruf (IOCTL), dann das Entfernen von Callbacks und das Beenden von Sicherheitsprozessen. Die Sequenz sei weit aussagekräftiger als jeder Einzelschritt, so SentinelOne, und öffentliche Recherchen dokumentierten sie in Kampagnen wie Kasseika, BlackByte und RansomHub. Ein Dienstname, der ein Windows-Update imitiert, etwa ein „KB“-Name, der an ein unsigniertes oder erstmals gesehenes Treiber-Image gebunden ist, gilt als Paar mit hoher Treffsicherheit. Der Preis ist der Entwicklungsaufwand: Die Regel braucht eine verlässliche Ereignisreihenfolge und einen Join-Schlüssel.

Hunt drei: Callbacks und die Kernel-Kill-Schleife

Zu Admin-to-kernel zitiert SentinelOne unabhängige Forschung, nach der dieser Schritt keine echte Sicherheitsgrenze sei und die Treiber-Blocklist eine unvollständige Verteidigung darstelle. Sobald Code Ring 0 erreicht, kann er die Hooks entfernen, auf die sich ein EDR stützt, bevor er den Kill-Befehl ausführt. Das Entfernen von Callbacks verdient daher einen eigenen Hunt.

Laut dem Beitrag dokumentierte SOC Prime, dass Qilin rwdrv.sys zusammen mit hlpdrv.sys lädt und damit EDR-Kernel-Callbacks von mehr als 300 Produkten entfernt, und dass dieselbe Kombination bei Akira und anderen Gruppen auftaucht. Beobachtbar ist das stille Verschwinden von Kernel-Callbacks, sichtbar als Verlust erwarteter Telemetrie in der Integritätsberichterstattung des EDR selbst.

Die Beendigung kann als Schleife im Kernel-Modus laufen: Eine User-Mode-Komponente zählt in festen Abständen Prozesse auf und sendet Ziel-PIDs per IOCTL an einen getarnten Treiber, der ZwTerminateProcess aufruft und Protected Process Light umgeht. Ein Agent, der in festem Intervall neu startet und wieder stirbt, werde in den Worten des Unternehmens von unten getötet. Da dieser Hunt auf Telemetrie beruht, die der Angreifer gerade entfernen will, empfiehlt SentinelOne, den Verlust der Callback-Integrität und den Rhythmus der erneuten Kills als bestätigende Signale zu behandeln, nicht als eigenständige Alarme.

Was das für Erkennungsteams bedeutet

Laut SentinelOne kann ein Detection Engineer den ersten Hunt noch diese Woche ausliefern, die übrigen folgen, sobald die Baselines bereinigt sind. Die praktische Botschaft lautet, die Abdeckung pro Technik statt pro Etikett abzubilden: Treiberlade-Events für BYOVD, Baselines für Änderungsfenster beim Installer-Missbrauch, Callback-Integritätsberichte für Admin-to-kernel sowie Prozesszustands-Events, WFP-Filteränderungen und Agent-Heartbeat bei treiberloser Suspendierung. Der Annual Threat Report des Unternehmens dränge Teams dazu, verdächtigem Verhalten nachzugehen statt bestimmten Hashes oder Dateinamen, heißt es.

Der vorliegende Auszug behandelt die ersten drei Hunts im Detail, die Hunts zu Installer und treiberloser Suspendierung sind in der Taxonomietabelle aufgeführt.