deagreez - stock.adobe.com
LLMs in der Malware-Analyse: Chancen und Grenzen
KI-Modelle versprechen in der Malware-Analyse Effizienzgewinne. Sie können Analyseprozesse beschleunigen. Aber ohne fachliche Steuerung bleiben die Ergebnisse fehleranfällig.
Die Untersuchung moderner Schadsoftware gehört zu den zeitintensivsten Aufgaben im Security-Umfeld. Analysten müssen komplexe Binärdateien untersuchen, verschleierte Codeabschnitte rekonstruieren und das Verhalten von Malware in isolierten Analyseumgebungen nachvollziehen. Besonders bei mehrstufigen Loadern oder stark obfuskiertem Code kann eine vollständige Analyse viele Stunden oder sogar Tage in Anspruch nehmen.
Vor diesem Hintergrund erscheint der Einsatz von Large Language Models (LLM) vielversprechend. Die Modelle können große Mengen Dateien und Code schnell verarbeiten, Zusammenhänge zwischen Funktionen erkennen und Vorschläge für mögliche Interpretationen liefern. Für Security-Teams klingt das nach einer massiven Beschleunigung bestimmter Analysephasen. Gleichzeitig wirft der Einsatz generativer KI in sicherheitskritischen Bereichen grundlegende Fragen auf: Wie zuverlässig sind die Ergebnisse solcher Systeme – und welche Rolle sollten sie im Analyseprozess tatsächlich spielen?
Der Testaufbau
Um diese Fragen zu beantworten, wurde ein Setup mit zwei VMs aufgesetzt. Eine mit Remnux und die andere mit Windows 10. Auf der Remnux-VM wurden Claude und OpenCode installiert und über verschiedene MCP-Server (Model Context Protocol) wie remnux, x64dbg oder ssh-mcp sicher mit externen Datenbanken und Werkzeugen verbunden.
Das SSH- und das x64dbg-MCP sind mit der Windows-10-VM gekoppelt. Diese VM ist – abgesehen von einem internen Netzwerkadapter – isoliert und dafür vorgesehen, schädlichen Code auszuführen, während die KI Remnux für die statische Analyse nutzen soll. Die Remnux-VM benötigt eine Internetverbindung, damit die KI-Clients funktionieren.
Getestet wurden drei Modelle: OpenAI GPT-5.1, OpenAI GPT-5.1-mini und Claude Sonnet 4.6. Beispielhaft berichten wir hier von zwei Versuchen, der eigentliche Test beinhaltete jedoch deutlich mehr.
Beispiel-Versuch Nummer 1: CVE-2017-11882
Mit GPT-5.1-mini wurde ein Office-Dokument mit einem Equation-Editor-Exploit (CVE-2017-11882) untersucht. Die Ergebnisse waren jedoch enttäuschend. Denn bei komplexeren Aufgaben zog das Modell häufig falsche Schlussfolgerungen und lieferte letztlich keine brauchbaren Informationen. Außerdem war GPT-5.1-mini der Meinung, das Sample sei unbedenklich, da es keine Makros enthalte. Allerdings sei die Domain decalage.info sehr verdächtig. Hierbei handelt es sich aber um die legitime Website von oletools – einer Suite von Python-Tools zur Analyse von MS-Office-Dateiformaten. Die KI konnte hier den Standard-Text der oletools nicht von den Analyseergebnissen unterscheiden.
Insgesamt war die Analyse-Qualität von GPT-5.1-mini so schlecht, dass für weitere Tests nur noch GPT 5.1 zum Einsatz kam. GPT 5.1 stellte zwar fest, dass es sich um ein ungewöhnliches Sample handelt, konnte jedoch keinen eindeutigen Nachweis für bösartiges Verhalten erkennen. Erst mit der expliziten Aufforderung, den Equation-Editor-Exploit zu suchen, fand es erfolgreich den Shellcode, der die nächste Stufe lädt, emulierte diesen mit Mandiants Speakeasy und gab die URL aus.
Sonnet 4.6 erkannte automatisch, dass es sich um einen Equation-Editor-Exploit handelt, lieferte ein korrektes Urteil und identifizierte die Position des Shellcodes. Allerdings konnte es die URL der nächsten Stufe nicht eigenständig extrahieren. Sonnet durchsuchte alle extrahierten Dateien mit Hilfe von Regulären Ausdrücken nach URL-Mustern, fand jedoch nichts, da die URL vom Shellcode zur Laufzeit zusammengebaut wird.
Beispiel-Versuch Nummer 2: Komplexere Aufgaben
Anschließend wurden die LLMs mit einem deutlich schwierigeren Sample konfrontiert. Für dessen Analyse brauchte ein Mensch mehrere Stunden Handarbeit, um die Funktionsweise zu verstehen und ein statisches Entschlüsselungsskript zu schreiben, das generisch für ähnliche Samples funktioniert. Das Ziel für die KI war dasselbe: herausfinden, wie sich die Dateien extrahieren und entschlüsseln lassen und anschließend ein Python-Entschlüsselungsskript erstellen. Das Ergebnis war beeindruckend. Sowohl GPT 5.1 als auch Sonnet 4.6 waren erfolgreich – statt mehrerer Stunden benötigten sie jedoch nur etwa 30 Minuten, um ein samplespezifisches Python-Skript zu erstellen. Dieses Skript musste noch mit einer weiteren halben Stunde Arbeit manuell angepasst werden, um generisch zu funktionieren, trotzdem ist der Zeitgewinn deutliche Verbesserung.
Das Feintuning der Analyseumgebung
Da in Vergleichstests Sonnet 4.6 günstiger, aber qualitativ gleichwertig war, bildete das Modell gemeinsam mit Opus die Basis für den Feinschliff des Analyseprozesses. Oberste Priorität war es, faktisch korrekte und leicht überprüfbare Berichte zu erstellen. Dafür kamen sogenannte Skills zum Einsatz – das sind ausgelagerte Anweisungen an die KI, welche nur in deren Kontext geladen werden, wenn bestimmte Schlüsselwörter genannt werden. Im ersten Schritt entstand ein Erstelle-einen-Report-Skill, der nicht nur die finalen Analyseergebnisse auflistet, sondern die LLMs anweist, jeden einzelnen Schritt darzustellen, den ein Analyst zur Verifikation durchführen müsste. Darüber hinaus wurde ein Verifikations-Skill für kritische Daten wie IP-Adressen, Hashes, Dateinamen, Pfade, Registry-Keys, Offsets, Zeilennummern und ähnliche Informationen hinzugefügt.
Sechs Erkenntnisse für bessere Analysen
1. Man kann Berichten nicht trauen
Von LLMs verfasste Analyseberichte sind grundsätzlich nicht vertrauenswürdig. Selbst mit fünf Verifikationsdurchläufen gibt es häufig Fehler an zentralen Stellen des Berichts – darunter bei IoCs (Indicator of Compromise), bei den Beziehungen zwischen Dateien sowie bei Persistenz-Mechanismen und deren Speicherorten. Deswegen ist eine manuelle Verifikation der Daten weiterhin notwendig und wird mit Hilfe der vom LLM erstellten Verifikationsschritte einfacher als eine vollständige manuelle Analyse.
2. Urteile sind nicht belastbar
Aussagen, ob ein Sample schädlich oder harmlos ist, sind am problematischsten. LLMs bewerten die Funde häufig falsch und entscheiden sich auch ebenso schnell um. Das liegt daran, dass sie falsche Annahmen treffen und vorschnell Schlussfolgerungen ziehen. Es braucht einen erfahrenen Analysten, der gezielte Rückfragen stellt, erkennt, wo Fehlbewertungen entstehen und die LLMs in die richtige Richtung lenkt. Zum jetzigen Zeitpunkt kann man LLMs bei der Urteilsfindung nicht vertrauen.
3. Tooling ist entscheidend
Für Qualität und Geschwindigkeit der Analyse macht es einen enormen Unterschied, ob dem Modell die richtigen Werkzeuge zur Verfügung stehen – inklusive klarer Vorgaben, wann und wie diese einzusetzen sind. Mit der Zeit ergibt es daher Sinn, spezifische Skills für bestimmte Sample-Typen zu erstellen, zum Beispiel einen dedizierten Skill für die JavaScript-Analyse, der geeignete Werkzeuge empfiehlt. Andernfalls verbraucht das LLM unnötig viele Tokens, weil es per Trial-and-Error erst herausfinden muss, welches Tooling für das jeweilige Sample funktioniert.
4. LLMs können mehr Dinge in kürzerer Zeit abdecken
LLMs können komplexe Programme und Setups in relativ kurzer Zeit detailliert analysieren. Sie sind deutlich schneller und finden daher interessante Bereiche, Indikatoren und Dateien, die menschliche Analysten möglicherweise übersehen würden, weil sie sich nicht manuell tausende von Dateien ansehen können.
5. LLMs verfügen über ein breiteres Wissensspektrum
Jeder Reverse Engineer hat seine Spezialgebiete, in denen er besonders stark ist und über viel Fachwissen verfügt. Daher erstellen Malware-Analysten häufig gemeinsam Berichte, um das jeweilige Spezialwissen aller Beteiligten zu nutzen. LLMs hingegen verfügen auch in den Bereichen über Wissen, die einer Einzelperson selbst weniger vertraut sind. Gerade wenn man Malware ohne Team analysiert, ist dieser zusätzliche Kontext eine große Hilfe. Er verbessert den Bericht und ganz nebenbei kann man selbst noch etwas Neues lernen.
„Die Praxis zeigt, dass KI-Modelle ohne fachliche Steuerung keine verlässlichen Analyseergebnisse liefern. Fehlinterpretationen und Halluzinationen bleiben ein strukturelles Problem generativer KI. Der größte Nutzen entsteht daher in hybriden Analyseprozessen.“
Karsten Hahn, G DATA CyberDefense
6. Skripte statt Berichte
Der große Vorteil von Skripten ist, dass LLMs hier eine Feedback-Schleife haben, die unmittelbar zeigt, ob das Skript funktioniert oder nicht. Diese Art von Rückmeldung gibt es für die meisten anderen Teile eines Berichts in dieser Form nicht. Die Feedback-Schleife erlaubt es dem LLM sich selbst zu korrigieren bis ein ausführbares Skript mit den erwarteten Ergebnissen vorliegt.
Indem man das LLM anweist, einen Konfigurations-Extractor, einen statischen Entpacker oder ein Deobfuskationsskript zu erstellen, lässt sich viel Zeit bei der Validierung der Berichtsdaten sparen. So kann ein Analyst schnell prüfen, ob ein Skript schummelt. Man führt es auf dem Sample aus – und ist fertig. Ein Entpacker-Skript verifiziert beispielsweise nicht nur, welche Payload entpackt wird und in welchem Verhältnis die beiden Stufen zueinander stehen, sondern auch, wo und wie die verschlüsselte Payload gespeichert ist und welche Algorithmen zur Entschlüsselung erforderlich sind.
Fazit: (Des-)Informationszeitalter
Es ist deutlich, dass autonome LLM-Analysen ein äußerst nützliches Werkzeug sind, das Analysezeiten erheblich verkürzt. LLMs entscheiden selbstständig, welcher Schritt als nächstes sinnvoll ist. Wenn man sie richtig einsetzt, können Malware Analysten ihre Effizienz steigern, ohne dabei Qualität einzubüßen.
Gleichzeitig zeigt die Praxis, dass KI-Modelle ohne fachliche Steuerung keine verlässlichen Analyseergebnisse liefern. Fehlinterpretationen und Halluzinationen bleiben ein strukturelles Problem generativer KI. Der größte Nutzen entsteht daher in hybriden Analyseprozessen.
Über den Autor:
Karsten Hahn ist Principal Malware Researcher bei G DATA CyberDefense.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
