Während des Zweiten Weltkriegs wurde Abraham Wald gefragt, an welchen Stellen Bomber mit Panzerung versehen werden sollten. Der Instinkt des Militärs war es, die zurückgekehrten Flugzeuge zu untersuchen und genau dort Verstärkungen anzubringen, wo sich die Einschusslöcher häufen. Wald riet jedoch, genau das Gegenteil zu tun. Die Flugzeuge vor ihm hatten Treffer an diesen Stellen bereits überstanden. Genau deshalb konnte er sie überhaupt untersuchen. Die Flugzeuge, die Treffer am Triebwerk oder am Cockpit abbekommen hatten, kehrten gar nicht erst zurück, um untersucht zu werden.
Die Erkennungstechnik hat denselben blinden Fleck, und er ist leicht zu übersehen, da die überlebenden Flugzeuge ein vollständiges Bild ergeben, wenn man sich nie fragt, was nicht direkt vor einem liegt. Jede Regel, die wir aufstellen, und jedes Muster, das wir als „bekannt schlecht“ bezeichnen, stammt aus Angreiferpaketen, die es zurück zu uns geschafft haben – was bedeutet, dass sie abgefangen wurden. Wir untersuchen die Einschusslöcher an den zurückkehrenden Flugzeugen und bezeichnen dies als das vollständige Bild dessen, was da draußen vor sich geht. Kriminologen haben einen Begriff für das Phänomen, mit dem sie sich beschäftigen: die „Dark Figure of Crime“. Das ist die Lücke zwischen den Vorfällen, die entdeckt werden, und den Vorfällen, die tatsächlich passieren. Jede Kriminalstatistik basiert auf den Tätern, die gefasst wurden. Diejenigen, die sich damit beschäftigen, wissen das und berücksichtigen es.
Die Konsequenz für die Erstellung von Regeln ist unbequem, aber wichtig. Regeln auf String-Ebene können nur Angreifer abfangen, die bereits bekannte Artefakte wiederverwenden. Sie können naturgemäß keinen Angreifer abfangen, der so raffiniert vorgeht, dass er noch nie in unseren Tracking-Daten aufgetaucht ist – genauso wenig wie man durch die Untersuchung aller zurückgekehrten Flugzeuge jemals herausfinden kann, wo die Flugzeuge getroffen wurden, die nicht zurückgekehrt sind. Regeln auf Verhaltensebene sind unsere einzige echte Chance gegen das Unbekannte. Der Angreifer muss die Daten immer noch exfiltrieren, den Code immer noch ausführen und immer noch „nach Hause“ funken. Was er tut, ist begrenzt. Wie er es nennt, wie er es verschleiert und wohin er es sendet, ist es nicht.
Doch die Erkennung von Verhaltensmustern hilft nur, wenn wir überhaupt wissen, wie ein normales Verhalten aussehen soll. Wald konnte auf die vermissten Flugzeuge hinweisen, weil er bereits wusste, wie ein intaktes, unbeschädigtes Flugzeug aussah. Dadurch konnte er jedes Einschussloch an jedem zurückkehrenden Flugzeug mit einer vollständigen erwarteten Form abgleichen – Flügel, Rumpf, Heck, Triebwerk, Cockpit, einfach alles. Sobald er diese vollständige Übersicht hatte, fiel ihm nicht auf, wo die Schäden waren, sondern wo sie nicht waren.
Die Erkennungstechnik bekommt das nicht einfach so geschenkt. Wenn wir kein klares, vollständiges Bild davon haben, wie sich ein Paket normalerweise verhält, wird ein unerwarteter Netzwerkaufruf oder die Erstellung eines unbekannten Prozesses nicht als Lücke in irgendetwas registriert. Es sieht einfach nur nach zusätzlichem Rauschen in einem System aus, das nicht abgebildet ist.
Die tatsächlichen Kosten eines unvollständigen Verhaltensdatensatzes gehen über das Fehlen der einen oder anderen Regel hinaus. Sie bestehen darin, dass wir nicht einmal mehr erkennen können, wie das, was fehlt, aussieht. Ein Angreifer, der in unseren stringbasierten Erkennungsmechanismen nie auftaucht, muss dennoch handeln, und diese Handlung wird nur dann als anomal erkannt, wenn wir die Basislinie definiert haben, von der sie abweicht. Ohne diese Basislinie bleiben die unsichtbaren Pakete aus einem zweiten Grund zusätzlich zum ersten unsichtbar. Sie haben es nicht nur vermieden, eine Signatur zu hinterlassen, sondern agieren auch in einem Bereich, den wir nie beschrieben haben – daher erscheint an ihnen nichts als falsch, solange wir uns nicht mit den Fähigkeiten und dem Verhalten der Pakete befassen.
Kostengünstige String- und IOC-Regeln stellen einen sinnvollen Einsatz von Ressourcen dar. Die Strategien, die in der überwiegenden Mehrheit der schädlichen Pakete zum Einsatz kommen, sind wenig ausgefeilt und werden wiederverwendet, wobei dieselbe Nutzlast über eine ganze Welle von Paketen hinweg kopiert wird. Eine Wegwerf-String-Regel fängt diese gesamte Welle nahezu ohne Kosten ab, wird in dem Moment unwirksam, in dem der Angreifer seine Strategie ändert, und lässt sich ebenso kostengünstig neu schreiben. Dass kostengünstige String-Regeln „früh sterben“, bedeutet, dass die kostengünstige Stufe genau die Aufgabe erfüllt, für die sie entwickelt wurde. Eine aufwendige Verhaltensbasislinie für Bedrohungen zu fordern, die bereits durch eine in fünf Minuten erstellte String-Regel gestoppt werden, wäre eine ineffiziente Nutzung der Zeit.
Die Antwort ist ein Portfolio an Regeln, das sich über die gesamte Pyramide erstreckt. Kostengünstige Regeln der unteren Ebenen bewältigen das hohe Volumen. Teure Regeln der oberen Ebenen sind unsere einzigen Mittel, um die wenigen raffinierten Angreifer zu erreichen, die sich in der „dunklen Zahl“ verstecken. Verschiedene Ebenen, verschiedene Aufgaben – und welche davon man wählt, hängt ganz davon ab, welchen Angreifer man zu fassen versucht. Genau das veranschaulicht die folgende angepasste Pyramide.
Eine abgewandelte Pyramide
David Biancos „Pyramide des Schmerzes“ [1] bietet uns die Möglichkeit, dies schichtweise zu betrachten, anstatt die Erkennung als eine einzige flache Kategorie zu behandeln; sie wurde hier an den Kontext der Lieferkette für Softwarepakete angepasst. Wir können Indikatorarten danach einstufen, wie viel es einen Angreifer kostet, sie zu verändern – von trivial bis nahezu unmöglich. Dies reicht von zufälligen Vorkommnissen wie Hash-Werten bis hin zu ganz bewusst gewählten Verhaltensweisen wie Techniken und Strategien.
Jede Ebene bis auf die oberste wurde vom Angreifer selbst gewählt. Eine Domäne, ein Kodierungsschema, ja sogar ein Tool – all das sind Entscheidungen, und diese Entscheidungen werden in dem Moment neu getroffen, in dem sie für den Angreifer nicht mehr funktionieren. Genau das macht die oberste Ebene der Pyramide zum Ort, an dem dauerhafte Regeln erstellt werden müssen, und genau das ist auch der Ort, an dem es am schwierigsten ist, solche Regeln zu schreiben, da Erkennungsmechanismen auf technischer und strategischer Ebene eine solide Grundlage benötigen, sonst funktionieren sie überhaupt nicht.
Das wirft die naheliegende Frage auf, woher diese Basislinie stammt, denn die Pyramide liefert sie uns nicht einfach so. Die Einstufung von Indikatoren danach, wie aufwendig ihre Änderung ist, zeigt uns, wo die beständigen Regeln liegen – nicht aber, wie wir eine Abweichung überhaupt erst erkennen können. Der praktischste Weg, sich dieses Bild zu verschaffen, besteht darin, nicht mehr nach einer universellen Basislinie zu suchen (die es nicht gibt), sondern stattdessen das normale Verhalten nach Paketart zu erfassen. Ein Build-Tool, ein Befehlszeilenprogramm, ein Web-Framework und ein kleines Dienstprogramm mit reinen Funktionen sind unterschiedliche Arten von Software mit unterschiedlichen Fähigkeiten.
Ein Build-Tool, das bei der Installation untergeordnete Prozesse startet und auf das Dateisystem zugreift, verhält sich wie erwartet, während ein Hilfsprogramm zur Zeichenfolgenformatierung, das dasselbe tut, dies nicht tut. Die Funktionen und Aktionen des Pakets bestimmen das akzeptable Verhalten, und dieselben Paketkategorien verhalten sich in der Regel bei npm, PyPI und NuGet ähnlich, sodass das Profil stabil genug ist, um wiederverwendet zu werden. Wenn wir diese Karte ausreichend vervollständigen, wird eine unbekannte Aktion nicht mehr als Störsignal wahrgenommen, sondern als Lücke in der erwarteten Struktur – und genau darum geht es. Es ist ein großer Arbeitsaufwand, und die Karte wird immer unvollständig bleiben, aber erst diese Arbeit macht es überhaupt möglich, die Spitze der Pyramide zu erreichen.
Die Form abbilden
Jedes Paket, das „ Aikido Security“ empfängt, wird statisch gescannt und in einer Sandbox ausgeführt, die aufzeichnet, was es tatsächlich getan hat. Das ist nichts Ungewöhnliches. Neu ist jedoch, dass ein Indikator nun mehr als nur die Tatsache enthält, dass er ausgelöst wurde. Jeder Indikator beschreibt, wozu der abgeglichene Code in der Lage ist und welche Art von Beweismaterial er darstellt, sodass ein Signal, das für sich genommen wenig aussagt, mit den anderen umgebenden Signalen abgeglichen werden kann.
Dadurch kann eine Erkennungsregel eine Form statt einer Zeichenfolge beschreiben. Code, der bei der Installation ausgeführt wird, auf Anmeldedaten zugreift, auf die er keinen Zugriff haben sollte, Daten nach außen sendet – und das in einem Paket, dessen angegebene Funktion nichts davon erklärt. In einer solchen Regel gibt es keine Domäne, keinen Hash und keinen Paketnamen. Es gibt darin nichts, was ein Angreifer variieren könnte.
Am 4. August 2026 haben wir eine neu veröffentlichte Version von Keyv identifiziert, die sich als dasselbe beliebte und vertrauenswürdige Schlüssel-Wert-Dienstprogramm präsentierte, das bereits 600 Millionen Mal von NPM heruntergeladen wurde. Diesmal führte es bei der Installation jedoch eine stark verschleierte JavaScript-Datei aus, die daraufhin Bun (einen alternativen JavaScript-Runner anstelle von Node.js) herunterlud und schließlich eine weitere verschleierte JavaScript-Datei ausführte. Diese Verhaltensmerkmale und Techniken reichten aus, damit unser System das Paket erkennen konnte. Hätten wir uns nur auf benannte Indikatoren verlassen, hätten wir dieses Paket übersehen. Da wir jedoch nach dem Unerwarteten Ausschau halten, sind wir in der Lage, solche Pakete abzufangen, die andernfalls in diese Grauzone fallen würden.
Unser System kam zu folgendem korrekten Schluss, obwohl es aufgrund der starken Verschleierung nicht das gesamte Bild erkennen konnte: „Die Kombination aus verdeckter Ausführung während der Installation, dem Abruf von Binärdateien aus der Ferne, der Vorbereitung der Payload und deren Start reicht für eine mit hoher Sicherheit getroffene Malware-Einstufung aus, auch wenn das endgültige Verhalten der Payload und etwaige Ziele des Datendiebstahls nicht vollständig entschlüsselt wurden.“
Es ist derzeit – und war schon immer – zumindest schwierig, verschleierte Malware zu entschlüsseln und zu verstehen, insbesondere aus Sicht der statischen Analyse. Das ist schließlich auch der Grund, warum die Angreifer sie so gestaltet haben. Was wir stattdessen nachweisen können, ist, dass das Verhalten der schädlichen Pakete ausreicht, um die „dunklen Zahlen“ zu ermitteln.
Eine kleine dunkle Silhouette ist noch zu erkennen. Auch Wald hat die abgestürzten Flugzeuge nie gesehen. Er konnte nur deshalb herausfinden, wo sie getroffen worden waren, weil er die Form eines ganzen Flugzeugs so gut kannte, dass er bemerkte, wo das Muster unterbrochen war. Unsere Version dieser Form ist eine Basisvorstellung davon, wie sich ein normales Paket verhält – eine, die stets auf dem neuesten Stand gehalten und nicht einfach angenommen wird –, und jedes Paket, das wir triage hinzufügen, ergänzt diese. Die Angreifer, die wir noch nicht gefasst haben, sind nach wie vor durch die Anforderungen eingeschränkt, die der Code erfüllen muss, um etwas zu stehlen. Jede dieser Einschränkungen ist ein Loch, dessen Position wir bereits kennen – in einem Flugzeug, das nicht zurückgekehrt ist.
Sehen Sie sich an, was wir auf Aikido Intel aufspüren. Wir erkennen Malware innerhalb von Minuten. Verbinden Sie Ihr Repository mit Aikido , um die Abhängigkeiten Ihrer App kontinuierlich auf schädliche Pakete zu überprüfen.
Referenzen
[1] Bianco, D. J. (2013). Die Pyramide des Schmerzes. Enterprise Detection and Response. http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html (überarbeitet am 17. Januar 2014, Ergänzung der Ebene „Hash-Werte“).
