Sicherheitslösungen können eine bekannte Version eines Angriffs erfolgreich stoppen, lassen dasselbe Verhalten jedoch passieren, wenn es auf weniger offensichtliche Weise ausgeführt wird. Dies ist die zentrale Schlussfolgerung einer Analyse auf Grundlage des von Picus Labs veröffentlichten Blue Report 2026. Darin wurde die Leistung von Verhinderungs- und Erkennungsmaßnahmen in realen Kundenumgebungen anhand von mehr als 338 Millionen Angriffssimulationen gemessen, die zwischen Januar und Juni 2026 durchgeführt wurden.
Die Gesamtverhinderungseffektivität stieg auf 69 %, verglichen mit 62 % im Vorjahr, und kehrte damit auf das Niveau von 2024 zurück. Diese Zahl stellt jedoch einen Durchschnitt über das gesamte Schutzökosystem dar. Sie zeigt nicht unbedingt, was ein Angreifer nach dem Eindringen in die Umgebung oder beim Wechsel des für dasselbe Ziel eingesetzten Werkzeugs und Verfahrens tun kann.
Ein bekannter Indikator ist kein gleichbedeutender Schutz vor Verhalten
Die Analyse unterscheidet zwischen zwei Testarten. Tests anhand bekannter Indikatoren, also IOC-based testing, prüfen, ob Firewalls, Web-Agenten und Secure-E-Mail-Gateways bekannte Schadproben erkennen und deren Downloadversuche blockieren können. Diese Messung eignet sich für die Perimeterschutzebene, beantwortet jedoch eine andere Frage nicht: Kann das Schutzsystem die vom Angreifer ausgeführte Aktion unabhängig vom verwendeten Werkzeug oder Pfad verhindern?
Hier kommen verhaltensbasierte Tests auf Grundlage von Taktiken, Techniken und Verfahren (TTPs) ins Spiel. Statt zu fragen, ob das Werkzeug Mimikatz dem System bekannt ist, prüft dieser Ansatz, ob irgendein Programm auf dem Gerät Benutzeranmeldeinformationen erlangen kann. Diese Frage ist für Endpoint-Schutzwerkzeuge und Intrusion-Detection-Systeme relevant, da der Angreifer die Ausführung innerhalb der Umgebung häufig bereits begonnen hat, wenn diese Kontrollen eingreifen.
Die Verhinderungsrate für den Download bekannter Malware anhand von IOC sank den Daten für 2026 zufolge auf 50 %, gegenüber 60 % im Jahr 2025 und 71 % im Jahr 2024. Dies deutet darauf hin, dass selbst die stärker auf Signaturen angewiesene Ebene keine konstante Abdeckung bietet. Außerdem zeigt ein gutes Ergebnis bei einem Test einer bekannten Signatur nicht, was passiert, wenn sich das Verhalten oder seine Ausführungsmethode ändert.
Das Beispiel Mimikatz offenbart die Lücke
Die Kundenumgebungen verwendeten das Werkzeug Mimikatz, um dasselbe Ziel – die Extraktion von Anmeldeinformationen – über drei Pfade zu erreichen. Das Extrahieren von Daten aus dem Speicher eines LSASS-Prozesses wurde in 94 % der Versuche blockiert. Dies ist der traditionelle Pfad, den Produkte umfassend überwachen. Der Anteil sank jedoch auf 17 %, wenn mit demselben Werkzeug RDP-Anmeldeinformationen aus anderen Speicherbereichen ausgelesen wurden, und auf 3 %, wenn LSA Secrets aus der lokalen Systemregistrierung gelesen wurden.
Alle drei Fälle fallen unter dieselbe übergeordnete Technik, nämlich OS Credential Dumping (T1003), und führen zum selben Ergebnis: Der Angreifer verfügt über sensible Anmeldeinformationen. Der Unterschied lag darin, wie offensichtlich der Weg für die Sicherheitskontrollen war. Das Auslesen des Speichers von lsass.exe hinterlässt Ereignisse, die sich leichter abgleichen lassen, während das Lesen eines Registrierungshives mit SYSTEM-Berechtigungen eher wie gewöhnliche administrative Aktivität wirken kann.
Auch der erfolgreiche Schutz gegen eine bekannte Version von Mimikatz garantiert kein stabiles Ergebnis. Die von der Signatur verwendeten Zeichenfolgen können geändert, das Werkzeug neu kompiliert oder der Code in den Speicher geladen werden, ohne auf der Festplatte hinterlassen zu werden. Alternativ können von Microsoft signierte Werkzeuge wie ProcDump oder comsvcs.dll verwendet und die Daten anschließend analysiert werden. In diesen Fällen verändert sich die von den Signaturen gesuchte Spur, während Verhalten und endgültiges Ziel gleich bleiben.
Der Schutz innerhalb der Umgebung ist schwächer als der Schutz an der Grenze
Die Gesamtrate der Verhinderung lag bei 69 %, wenn sie auf Perimeterebene gemessen wurde. Selbsttests zur Einbruchssimulation, die messen, was ein Angreifer nach dem Eindringen als authentifizierter Benutzer tun kann, zeigten jedoch, dass nur 37 % der Post-Exploitation-Aktionen blockiert wurden. Anders ausgedrückt: Der Schutz wechselte von der Abwehr von etwa zwei Dritteln der Angriffe am Perimeter zur Abwehr von etwas mehr als einem Drittel der Aktionen innerhalb der Umgebung.
Aktivitäten mit höherem Geräuschpegel waren leichter zu erkennen: Die Erkennung lateraler Bewegungen lag bei etwa 90 %, die Umgehung der UAC überstieg 85 %, während die Verhinderung der Wiederverwendung von Anmeldeinformationen und des Missbrauchs von Active Directory etwa 63 % erreichte. Bei weniger offensichtlichen Aktivitäten sanken die Werte dagegen: Der Schutz von passiv aus Speicher und Registrierung ausgelesenen Anmeldeinformationen überstieg 22 % nicht und lag beim Extrahieren lokaler Registrierungsecrets unter 1 %. Auch Discovery- und Collection-Aktivitäten überschritten 10 % nicht. Domänenaufzählungen mit SharpHound und das Sammeln lokaler Dateien wurden meist ungehindert ausgeführt.
Was ändert sich in der Praxis?
Die praktische Schlussfolgerung der Analyse lautet, dass Sicherheitsvalidierungsprogramme jeden Test danach beurteilen müssen, was er misst, statt ein einzelnes Ergebnis als umfassenden Nachweis der Abdeckung zu behandeln. Tests bekannter Samples bleiben für Firewalls, Web-Agenten, Web Application Firewalls und Secure-E-Mail-Gateways geeignet. Die Endpoint- und Detection-Ebene, einschließlich EDR, IDS und SIEM-Inhalten, muss dagegen alle Wege zum selben Ziel testen: LSASS-Speicher, Registrierung, alternative Speicherbereiche, native Werkzeuge und neu kompilierte Versionen.
Der Beitrag warnt davor, dass das alleinige Testen der bekannten Aktion dazu führen kann, dass ein Punkt als geschlossen betrachtet wird, obwohl er faktisch weiterhin offen ist. Die Analyse schlägt vor, mehrere Simulationen desselben Verhaltens einzusetzen, um die vorhandenen Kontrollen zu überprüfen, anstatt sich darauf zu beschränken, nachzuweisen, dass eine einzelne Signatur ein einzelnes Werkzeug erkannt hat. Picus Swarm wird als Koordinierungsebene genannt, um diese Varianten innerhalb der Umgebung auszuführen und zu testen, und zwar im Rahmen der Produkte und Dienstleistungen des Unternehmens.
Die Empfehlung besteht nicht unbedingt darin, neue Werkzeuge hinzuzufügen, sondern die vorhandenen Kontrollen zu bestimmen, die die Angriffskette tatsächlich unterbrechen können, und anschließend für jede Gefährdung eine dokumentierte Entscheidung zu treffen: Behebung, Minderung, Überwachung oder Akzeptanz mit Nachweisen. Die Ergebnisse des Berichts sind dem Beitrag zufolge Teil einer umfassenderen Studie, die Unterschiede in der Leistung zwischen Branchen und Regionen, die am häufigsten ausgenutzten Schwachstellen, eine Protokollierungsrate von 58 % und eine Alarmrate von 14 % umfasst.