KI-gestützte Malware-Erkennung: Was Domänenwissen verändert

Ein npm-Paket kann ordentlich dokumentiert sein, plausiblen JavaScript-Code enthalten und trotzdem Schadsoftware mitbringen: versteckt in einer kompilierten Binärdatei. Für Unternehmen, die Anwendungen und Datenprodukte mit Open-Source-Abhängigkeiten entwickeln, ist das ein relevantes Lieferkettenrisiko. Eine Untersuchung von Databricks Threat Research zeigt, wie KI-gestützte Malware-Erkennung an solchen Dateien scheitert – und wie strukturiert eingebrachtes Domänenwissen die Bewertung verbessern kann.

Kurz gesagt: Databricks Threat Research ergänzt die LLM-basierte Prüfung von npm-Paketen um regelbasierte Profile, die sicherheitsrelevante Befunde vor der Modellbewertung einordnen. In einem kontrollierten Test mit sieben kostengünstigen Modellen sank der Anteil verfehlter Erkennungen dadurch von 35 auf drei bei jeweils 70 Modell-Payload-Prüfungen. Das spricht für die Kombination aus statischer Analyse und Fachwissen, ist aber kein Nachweis einer allgemein zuverlässigen Malware-Erkennung.

Was ist neu an der KI-gestützten Malware-Erkennung?

Neu an dem untersuchten Ansatz ist die gezielte Übergabe regelbasiert bewerteter Sicherheitsbefunde an ein LLM, bevor es über ein verdächtiges Paket urteilt. Das Modell erhält nicht nur technische Rohdaten, sondern zusätzlich eine strukturierte Einordnung möglicher Angriffstechniken.

Dafür verwendet das Forschungsteam sogenannte Capability Profiles. Diese beschreiben beispielsweise den Diebstahl von Zugangsdaten, die Übertragung von Daten an externe Systeme oder die Einrichtung eines dauerhaften Zugangs. Gewichtete Bedingungen legen fest, wann vorhandene Befunde einen definierten Verdachtsgrad erreichen.

Der Ablauf besteht aus drei Schritten:

• Befunde sammeln: Statische Werkzeuge untersuchen Paketinhalt, JavaScript, Metadaten und kompilierte Dateien. Zum beschriebenen Scanner gehören unter anderem YARA und Semgrep.
• Muster bewerten: Die Capability Profiles prüfen die Befunde auf Kombinationen, die zu bestimmten Angriffstechniken passen.
• Urteil unterstützen: Bei erreichten Schwellenwerten gelangt eine strukturierte Zusammenfassung in den Prompt. Das LLM bewertet anschließend die kombinierte Evidenz.

Wichtig ist die Abgrenzung zum Training: Das Fachwissen wird bei der Ausführung bereitgestellt, nicht durch erneutes Training in die Modellgewichte eingebaut. Im Experiment durfte das Modell die Einschätzung eines Profils sogar vollständig verwerfen. Die Profile waren damit Entscheidungshilfen, keine zwingenden Sperrregeln.

Warum sind Binärdateien in npm-Paketen problematisch?

Binärdateien sind problematisch, weil ein LLM aus sauberem Begleitcode und unauffälligen Metadaten nicht auf die Unbedenklichkeit des kompilierten Inhalts schließen kann. Gerade diese falsche Entwarnung beobachtete das Forschungsteam jedoch wiederholt.

npm-Pakete können native Node.js-Erweiterungen als .node-Dateien enthalten. Das ist für sich genommen nicht verdächtig. Werden jedoch Symbole entfernt und Zeichenketten verschleiert, fehlen leicht lesbare Hinweise auf das tatsächliche Verhalten. Eine professionelle README oder plausible Paketbeschreibung kann dann mehr Vertrauen erzeugen, als die technischen Befunde rechtfertigen.

Im untersuchten Bestand von 11.413 Paketversionen mit durch OSV-Meldungen bestätigter Malware enthielten 432 eine Binärdatei, entsprechend 3,8 Prozent. Diese Zahlen beschreiben den untersuchten Malware-Bestand, nicht die Verbreitung schädlicher Pakete im gesamten npm-Verzeichnis.

Für die Prüfung war diese kleine Gruppe besonders anspruchsvoll: Bei Paketen mit Binärdateien blieb ein eindeutiges Schadsoftware-Urteil häufiger aus als bei Paketen ohne solche Dateien. Für deine Sicherheitsprozesse heißt das: Ein seltener Dateityp kann überproportional viel Prüfaufwand und Aufmerksamkeit benötigen.

Was belegen die Testergebnisse tatsächlich?

Die Ergebnisse belegen eine deutlich bessere Erkennung innerhalb eines kleinen, gezielt konstruierten Tests – keine universelle Schutzwirkung gegen Schadsoftware.

Das Team entwickelte fünf Typen schädlicher nativer Erweiterungen und prüfte insgesamt zehn Payload-Varianten. Dazu gehörten unter anderem der Diebstahl von Zugangsdaten, eine Reverse Shell und Mechanismen für dauerhaften Zugriff. Die Binärdateien waren jeweils in ansonsten plausibel wirkende Pakete eingebettet.

Deutlicher Unterschied bei kostengünstigen Modellen

Jede Variante wurde mit und ohne Capability Profiles geprüft. Bei sieben kostengünstigen Modellen ergaben sich pro Bedingung 70 Prüfungen:

• Ohne Profile verfehlten 35 von 70 Prüfungen die definierte Erkennungsschwelle.
• Mit Profilen blieben drei von 70 Prüfungen unter dieser Schwelle.
• Mit Profilen wurde keine der schädlichen Testvarianten mehr als unbedenklich eingestuft.

Als erfolgreiche Erkennung zählten die Urteile „HIGHLY_SUSPICIOUS“ oder „MALICIOUS“. Ein lediglich als „SUSPICIOUS“ bewerteter Schadcode galt als verfehlte Erkennung. Die verbleibenden drei Fehler waren also keine Entwarnungen, sondern zu schwache Einstufungen.

Ein richtiges Urteil reicht nicht aus

Die Untersuchung berichtet außerdem von erfundenen Begründungen, selbst wenn das Ergebnis korrekt war. Für den betrieblichen Einsatz solltest du deshalb zwei Dinge getrennt prüfen: Stimmt die Entscheidung, und wird sie durch tatsächlich vorhandene Befunde getragen?

Aus den genannten Tests mit schädlichen Varianten lässt sich zudem keine belastbare Fehlalarmrate für legitime Pakete ableiten. Genau diese Rate entscheidet jedoch mit darüber, ob ein Verfahren im Entwicklungsalltag praktikabel bleibt.

Wie lässt sich der Ansatz mit Azure und Databricks nutzen?

Für Unternehmen mit Azure und Databricks lässt sich der Ansatz als Architekturprinzip für eine nachvollziehbare Analysepipeline nutzen, nicht als im Beitrag angekündigte, sofort aktivierbare Plattformfunktion.

Ein sinnvoller Ausgangspunkt ist die Verbindung bestehender Sicherheitsprüfungen mit zentral gespeicherten Befunden. Eine Datenplattform kann Paketversionen, Prüfergebnisse, verwendete Profile und Modellurteile zusammenführen. Databricks kann dabei die Verarbeitung und Auswertung dieser Daten unterstützen; spezialisierte Sicherheitswerkzeuge bleiben für die eigentliche technische Untersuchung erforderlich.

Vier Schritte für einen begrenzten Pilotbetrieb

1. Den Prüfumfang festlegen. Beginne mit einem klar abgegrenzten Paketbestand aus deinem Entwicklungsprozess. Prüfe auch, an welchen Stellen npm-Abhängigkeiten tatsächlich in Anwendungen oder Build-Prozesse gelangen.
2. Evidenz nachvollziehbar speichern. Verknüpfe jedes Urteil mit Paketversion, Artefakt-Hash, Scanner-Befunden, Profilversion und eingesetztem Modell. So bleiben Änderungen später erklärbar.
3. Gegen einen Vergleichsbestand testen. Verwende bekannte schädliche und legitime Pakete, insbesondere legitime Pakete mit nativen Erweiterungen. Vergleiche Ergebnisse mit und ohne Profile.
4. Eskalationen vorab definieren. Lege fest, welche Befunde eine manuelle Prüfung auslösen. Behandle ein LLM-Urteil nicht automatisch als Freigabe für den produktiven Einsatz.

Verdächtige Pakete sollten dabei nicht auf produktiven Daten- oder Entwicklungsumgebungen ausgeführt werden. Falls dynamische Analysen erforderlich sind, gehören sie in eine dafür vorgesehene, isolierte Sicherheitsumgebung.

Welche Entscheidung sollten Verantwortliche daraus ableiten?

Verantwortliche sollten zuerst die Qualität der Sicherheitsbefunde und ihrer fachlichen Einordnung verbessern, bevor sie allein auf ein größeres Sprachmodell setzen. Der Versuch zeigt, dass fehlendes Domänenwissen ein eigenständiges Problem ist.

Für die Budgetplanung zählt deshalb nicht nur der Preis eines Modellaufrufs. Ebenso relevant sind die Pflege der Profile, zusätzliche Fehlalarme und der Aufwand manueller Nachprüfungen. Eine belastbare KI-Strategie berücksichtigt diese Betriebskosten ebenso wie klare Verantwortlichkeiten zwischen Entwicklung, Security und Datenplattform-Team.

Der übertragbare Kern: Ein LLM sollte belastbare Fachbefunde erklären und zusammenführen – nicht fehlende Evidenz durch überzeugend klingende Vermutungen ersetzen.

Was das für dich bedeutet

Wenn du KI für Sicherheitsbewertungen einsetzen willst, starte mit einer begrenzten Fragestellung, nachvollziehbaren Befunden und messbaren Prüfkriterien. Domänenwissen im Prompt kann die Qualität verbessern; menschliche Eskalationswege und unabhängige Sicherheitskontrollen bleiben notwendig.

Du möchtest klären, wie sich Analyseergebnisse und KI-Bewertungen auf deiner Azure-/Databricks-Datenplattform nachvollziehbar zusammenführen lassen? Sprich mit Ailio über Databricks-Beratung.

Redaktionelle Aufbereitung und Einordnung auf Basis eines Beitrags im Databricks-Blog.