Während des Zweiten Weltkriegs wurde Abraham Wald gefragt, an welchen Stellen Bomberpanzerungen verstärkt werden sollten. Der Instinkt des Militärs war es, die zurückgekehrten Flugzeuge zu untersuchen und die Bereiche zu verstärken, an denen sich die Einschusslöcher häuften. Wald sagte, man solle das genau Gegenteil tun. Die Flugzeuge vor ihm hatten Treffer an diesen Stellen bereits überlebt. Genau deshalb konnte er sie überhaupt untersuchen. Die Maschinen, die Treffer im Motor oder Cockpit abbekommen hatten, schafften es gar nicht erst zurück, um untersucht zu werden.
Die Detection Engineering weist denselben blinden Fleck auf, der sich leicht übersehen lässt, weil die überlebenden Maschinen ein vollständiges Bild ergeben, wenn man nie danach fragt, was sich nicht direkt vor einem befindet. Jede Regel, die wir schreiben, und jedes Muster, das wir als „bekanntermaßen schädlich“ einstufen, stammt von Angreiferpaketen, die es bis zu uns zurückgeschafft haben – sie wurden also erfasst. Wir untersuchen die Einschusslöcher an den zurückgekehrten Flugzeugen und halten dies für das vollständige Bild dessen, was da draußen existiert. Kriminologen haben einen Begriff für die Variante dieses Phänomens, mit der sie es zu tun haben: die Dunkelziffer der Kriminalität. Dies ist der Raum zwischen den Vorfällen, die entdeckt werden, und denen, die tatsächlich passieren. Jede Kriminalstatistik basiert auf den Kriminellen, die geschnappt wurden. Wer sich damit befasst, weiß das und bezieht es in die Berechnungen ein.
Die Implikation für das Schreiben von Regeln ist unangenehm, aber wichtig. String-basierte Regeln können nur Angreifer erfassen, die Artefakter wiederverwenden, die wir bereits gesehen haben. Konstruktionsbedingt können sie keinen Angreifer erwischen, der raffiniert genug ist, niemals in unseren Tracking-Daten aufzutauchen – ganz ähnlich wie keine noch so intensive Analyse zurückgekehrter Flugzeuge Ihnen jemals zeigen wird, wo die Maschinen getroffen wurden, die nicht zurückgekehrt sind. Verhaltensbasierte Regeln sind unsere einzige echte Chance gegen das Unbekannte. Der Angreifer muss nach wie vor die Daten exfiltrieren, den Code ausführen und den Heimserver kontaktieren. Was sie tun, ist eingeschränkt. Wie sie es nennen, wie sie es verschleiern und wohin sie es senden, hingegen nicht.
Aber die Verhaltenserkennung hilft nur dann, wenn wir überhaupt wissen, wie ein normaler Zustand auszusehen hat. Wald konnte auf die fehlenden Flugzeuge hinweisen, weil er bereits wusste, wie ein vollständiges, unbeschädigtes Flugzeug aussah. Das versetzte ihn in die Lage, jedes Einschussloch an jeder zurückgekehrten Maschine mit einer vollständigen, erwarteten Form abzugleichen – Flügel, Rumpf, Leitwerk, Triebwerk, Cockpit, einfach alles. Sobald er diesen vollständigen Plan hatte, fiel ihm nicht auf, wo der Schaden war. Sondern wo er nicht war.
In der Detection Engineering bekommt man das nicht umsonst. Wenn wir kein klares, vollständiges Bild davon haben, wie normales Paketverhalten aussieht, fällt ein unerwarteter Netzwerkaufruf oder ein unbekannter Prozessstart nirgendwo als Lücke auf. Es wirkt schlicht wie weiteres Rauschen in einem System, das nicht kartografiert ist.
Die wahren Kosten eines unvollständigen Verhaltensdatensatzes gehen über eine oder zwei fehlende Regeln hinaus. Sie bestehen darin, dass wir die Fähigkeit verlieren, überhaupt die Form dessen zu erkennen, was fehlt. Ein Angreifer, der in unseren String-basierten Erkennungen niemals auftaucht, muss dennoch handeln, und diese Aktion ist nur dann als anomal sichtbar, wenn wir die Baseline definiert haben, von der sie abweicht. Ohne diese Baseline bleiben die unsichtbaren Pakete aus einem zweiten Grund unsichtbar: Sie haben nicht nur vermieden, eine Signatur zu hinterlassen, sondern agieren zudem in einem Bereich, den wir nie zu beschreiben versucht haben. Daher wirkt an ihnen niemals etwas falsch – es sei denn, wir betrachten die Funktionen und das Verhalten von Paketen.
Einfache String- und IOC-Regeln stellen einen rationalen Aufwand dar. Die Strategien in der überwältigenden Mehrheit der Schadpakete sind wenig raffiniert und werden wiederverwendet, wobei derselbe Payload über eine ganze Welle von Paketen hinweg kopiert wird. Eine wegwerfbare String-Regel fängt diese gesamte Welle zu nahezu Null Kosten ab, stirbt in dem Moment, in dem der Angreifer rotiert, und wird ebenso günstig neu geschrieben. Dass günstige String-Regeln „jung sterben“, zeigt schlicht, dass diese günstige Ebene genau die Aufgabe erfüllt, für die sie entwickelt wurde. Die Forderung nach einer teuren Verhaltens-Baseline für Bedrohungen, die eine fünfminütige String-Regel ohnehin stoppt, wäre eine ineffiziente Nutzung von Zeit.
Die Antwort ist ein Portfolio aus Regeln über die gesamte Pyramide hinweg. Günstige Regeln der unteren Ebene bewältigen das hohe Volumen. Teure Regeln der oberen Ebene sind unsere einzige Möglichkeit, die raffinierten Ausnahmen zu erreichen, die sich in der Dunkelziffer verbergen. Unterschiedliche Ebenen haben unterschiedliche Aufgaben, und zu welcher Sie greifen, hängt vollständig davon ab, welchen Angreifer Sie zu fangen versuchen. Genau das zeigt die folgende, angepasste Pyramide.
Eine angepasste Pyramide
David Biancos Pyramid of Pain [1] bietet uns eine Möglichkeit, dies in Schichten zu betrachten, anstatt die Erkennung als eine einzige flache Kategorie zu behandeln – hier angepasst auf den Kontext der Paket-Lieferkette. Wir können Indikatortypen danach einordnen, wie viel es einen Angreifer kostet, sie zu ändern (von trivial bis nahezu unmöglich). Das reicht von zufälligen Vorkommnissen wie Hash-Werten bis hin zu offenkundig zielgerichteten Verhaltensweisen wie Techniken und Strategien.
Jede Ebene außer der obersten ist etwas, das sich der Angreifer ausgesucht hat. Eine Domain, ein Kodierungsschema, sogar ein Tool – all das ist eine Entscheidung, und Entscheidungen werden in dem Moment revidiert, in dem sie für den Angreifer nicht mehr funktionieren. Genau das macht die oberste Ebene der Pyramide zum idealen Ort für langlebige Regeln, aber gleichzeitig auch zum schwierigsten Ort, um eine zu schreiben, da Erkennungen auf Technik- und Strategieebene eine reale Baseline im Hintergrund benötigen, sonst funktionieren sie überhaupt nicht.
Das wirft die naheliegende Frage auf, woher diese Baseline stammt, denn die Pyramide liefert sie uns nicht frei Haus. Indikatoren danach zu ordnen, wie kostspielig sie zu ändern sind, zeigt uns, wo die langlebigen Regeln liegen, aber nicht, wie man eine Abweichung überhaupt erkennt. Der pragmatischste Weg, dieses Bild zu zeichnen, besteht darin, nicht länger nach einer universellen Baseline zu suchen (die es nicht gibt), sondern das normale Verhalten nach Pakttyp zu kartieren. Ein Build-Tool, ein Befehlszeilen-Dienstprogramm, ein Web-Framework und ein winziges, reines Funktions-Dienstprogramm sind unterschiedliche Arten von Software mit unterschiedlichen Funktionen.
Ein Build-Tool, das Kindprozesse startet und bei der Installation auf das Dateisystem zugreift, verhält sich erwartungsgemäß, während ein String-Formatierungshelfer, der dasselbe tut, dies nicht tut. Die Funktionen und Aktionen des Pakets bestimmen das akzeptable Verhalten, und dieselben Paketkategorien neigen dazu, sich über npm, PyPI und NuGet hinweg ähnlich zu verhalten, sodass das Profil stabil genug zur Wiederverwendung ist. Wenn diese Landkarte vollständig genug ist, hört eine unbekannte Aktion auf, als Rauschen gelesen zu werden, und wird stattdessen als Lücke in der erwarteten Form verstanden, worum es letztlich geht. Es ist eine große Menge Arbeit, und die Landkarte wird immer unvollständig sein, aber es ist die Arbeit, die die Spitze der Pyramide überhaupt erst erreichbar macht.
Die Form kartieren
Jedes Paket, das von Aikido Security eingelesen wird, wird statisch gescannt und in einer Sandbox ausgeführt, die aufzeichnet, was es tatsächlich getan hat. Dieser Teil ist gewöhnlich. Neu ist jedoch, dass ein Indikator nun eine Struktur aufweist, die über die bloße Tatsache hinausgeht, dass er ausgelöst wurde. Jeder von ihnen beschreibt, wozu der abgeglichene Code in der Lage ist und welche Art von Beweis er darstellt, sodass ein Signal, das allein wenig aussagt, gegen die anderen Signale in seiner Umgebung abgewogen werden kann.
Dadurch kann eine Erkennungsregel eine Form anstelle eines Strings beschreiben. Code, der zur Installationszeit ausgeführt wird, nach Anmeldedaten greift, die er keinen Grund hat zu berühren, etwas nach außen sendet – in einem Paket, dessen erklärte Aufgabe nichts davon rechtfertigt. Es gibt keine Domain in einer solchen Regel, keinen Hash, keinen Paketnamen. Nichts darin, was ein Angreifer rotieren könnte.
Am 4. August 2026 haben wir eine neu veröffentlichte Version von Keyv markiert, die sich als dasselbe beliebte und vertrauenswürdige Key-Value-Dienstprogramm ausgab, das 600 Millionen Mal von NPM heruntergeladen wurde. Diesmal führte es jedoch bei der Installation eine stark verschleierte JavaScript-Datei aus, die dann Bun (eine alternative JavaScript-Laufzeit anstelle von Node.js) herunterlud und schließlich eine weitere verschleierte JavaScript-Datei ausführte. Diese verhaltenstypenbezogenen Tools und Techniken reichten aus, um das Paket von unserem System erkennen zu lassen. Hätten wir nur benannte Indikatoren verwendet, hätten wir dieses Paket verpasst. Da wir jedoch nach dem Unerwarteten suchen, sind wir in der Lage, diese Pakete abzufangen, die sonst in diesen dunklen Raum fallen würden.
Unser System kam zu dem korrekten Schluss, obwohl es das Gesamtbild aufgrund der starken Verschleierung nicht vollständig erkennen konnte: „Die Kombination aus verdeckter Ausführung zur Installationszeit, dem Abrufen entfernter Binärdateien, dem Staging von Payloads und dem Start reicht für ein Malware-Urteil mit hoher Zuverlässigkeit aus, auch wenn das Verhalten der finalen Nutzlast und jegliches Datendiebstahl-Ziel nicht vollständig entschlüsselt wurden“.
Es ist derzeit und war schon immer mindestens schwierig, verschleierte Malware zu entschlüsseln und zu verstehen, insbesondere aus Sicht der statischen Analyse. Schließlich ist das genau der Grund, warum Angreifer sie dort platzieren. Was wir stattdessen beweisen können, ist, dass das Verhalten schädlicher Pakete für uns ausreicht, um die Dunkelziffer zu finden.
Eine kleine Dunkelziffer existiert nach wie vor. Auch Wald hat die abgestürzten Flugzeuge nie gesehen. Was ihm half herauszufinden, wo sie getroffen worden waren, war die Tatsache, dass er die Form eines vollständigen Flugzeugs gut genug kannte, um zu bemerken, wo das Muster durchbrochen wurde. Unsere Version dieser Form ist eine Baseline davon, wie gewöhnliches Paketverhalten aussieht – stets aktuell gehalten statt nur angenommen –, und jedes Paket, das wir einer Triage unterziehen, trägt dazu bei. Die Angreifer, die wir noch nicht erwischt haben, sind nach wie vor durch das eingeschränkt, was Code tun muss, um etwas zu stehlen. Jede dieser Einschränkungen ist eine Lücke, deren Position wir bereits auf einem Flugzeug kennen, das nicht zurückgekehrt ist.
Sehen Sie sich auf Aikido Intel an, was wir abfangen. Wir erkennen Malware innerhalb von Minuten. Verbinden Sie Ihr Repository mit Aikido, um Ihre Anwendungsabhängigkeiten kontinuierlich auf schädliche Pakete zu scannen.
Referenzen
[1] Bianco, D. J. (2013). The Pyramid of Pain. Enterprise Detection and Response. http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html (aktualisiert am 17. Januar 2014, um die Hash-Werte-Ebene ergänzt).
