Malware-Analyse Chancen und Risiken beim Einsatz von Large Language Models

Anbieter zum Thema

G DATA CyberDefense AG

FTAPI Software GmbH

KI-Modelle versprechen Effizienzgewinne – auch in der Malware-Analyse. Denn noch ist ein großer Teil davon teils mühevolle und langwierige Hand­arbeit. Doch ohne fachliche Einordnung und klare Vorgaben bleiben die Ergebnisse einer KI fehleranfällig und unzuverlässig.

Zu den zeitintensivsten Aufgaben im Security-Umfeld zählt die Analyse moderner Schad­soft­ware. Analysten untersuchen komplexe Binärdateien, rekonstruieren verschleierte Code­ab­schnit­te und vollziehen das Verhalten von Malware in isolierten Analyseumgebungen nach. Eine vollständige Analyse nimmt bei mehrstufigen Loadern oder stark obfuskiertem Code viele Stun­den oder sogar Tage in Anspruch. Daher liegt der Einsatz von LLMs nahe. Die Modelle kön­nen schnell große Mengen Dateien und Code verarbeiten, Zusammenhänge zwischen Funk­tio­nen aufzeigen und liefern Vorschläge für mögliche Interpretationen. Security-Teams können von einer massiven Beschleunigung bestimmter Analysephasen profitieren. Gleich­zei­tig wirft der Einsatz generativer KI in sicherheitskritischen Bereichen Fragen auf. Wie zuverlässig sind die Ergebnisse und welche Rolle sollten sie in der Analyse tatsächlich spielen?

Generative KI

Risiken von Large Language Models

Der Versuchsaufbau

Um die Probe aufs Exempel zu machen, wurde ein Set-up 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 kann schädlichen Code ausfü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 LLMs: OpenAI GPT-5.1, OpenAI GPT-5.1-mini und Claude Sonnet 4.6. Beispielhaft stellen wir hier zwei Versuche vor, der eigentliche Test beinhaltete jedoch wesentlich mehr.

Update: Einschätzung von Googles VP Threat Intelligence

Diese enorme Gefahr geht von Anthropics neuem KI-Modell aus

Test Nummer 1: CVE-2017-11882 / EUVD-2017-3478

Mit GPT-5.1-mini wurde ein Office-Dokument mit einem Equation-Editor-Exploit (CVE-2017­11882 / EUVD-2017-3478) untersucht. Die Ergebnisse waren enttäuschend: bei kom­plex­er­en Aufgaben zog das Modell mehrfach falsche Schlussfolgerungen und lieferte letztlich keine brauchbaren Informationen. Außerdem kam GPT-5.1-mini zu dem Schluss, das Sample sei unbedenklich, da es keine Makros enthalte. Allerdings sei die Domain decalage.info sehr ver­dä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 war nicht in der Lage, den Standard-Text der oletools von den Analyseergebnissen zu unterscheiden.

Insgesamt war die Analyse-Qualität von GPT-5.1-mini so schlecht, dass nur noch GPT 5.1 für weitere Tests 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 er­ken­nen. Erst mit der expliziten Aufforderung, den Equation-Editor-Exploit zu suchen, fand es er­folgreich 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, lie­fer­te 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 extra­hier­ten Dateien mithilfe von Regulären Ausdrücken nach URL-Mustern, fand jedoch nichts, da die URL vom Shellcode zur Laufzeit zusammengebaut wird.

Low statt Critical

KI-Patch-Dienst stuft Schwachstelle fatal falsch ein

Test 2: Komplexere Aufgaben

Anschließend wurden die LLMs mit einem deutlich schwierigeren Sample konfrontiert. Für dessen Analyse benötigt ein Mensch mehrere Stunden „Handarbeit“, um die Funktionsweise zu verstehen und ein statisches Entschlüsselungsskript zu erstellen, das generisch für ähnliche Samples funktioniert. Das Ziel für die KI war dasselbe: erkennen, wie sich die Dateien extra­hier­en und entschlüsseln lassen und anschließend ein Python-Entschlüsselungsskript schreiben. Das Ergebnis war beeindruckend. Sowohl GPT 5.1 als auch Sonnet 4.6 hatten Erfolg: Statt mehr­er­er Stunden dauerte es jedoch nur etwa 30 Minuten, um ein samplespezifisches Python-Skript zu erstellen. Dieses Skript musste noch in einer weiteren halben Stunde Arbeit manuell an­gepasst werden, um generisch zu funktionieren. Trotzdem ist der Zeitgewinn eine klare Verbesserung.

Sicherheitspraktiken für Softwareentwicklung mit KI-Hilfe

KI-Tools in der Entwicklung schaffen neue Angriffsflächen

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 Prozesses. Oberste Priorität war dabei, faktisch korrekte und leicht überprüfbare Berichte zu erstellen. Dafür wurden sogenannte Skills eingesetzt. Das sind ausgelagerte Anweisungen an die KI, welche nur in deren Kontext geladen werden, wenn bestimmte Schlüsselwörter fallen. 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 ergänzt.

DoS und RCE

Forscher entdecken 12 OpenSSL-Zero-Days mit KI

Sechs Erkenntnisse für bessere Analysen

1. Man kann Berichten nicht trauen
Von LLMs erstellte 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, bei den Beziehungen zwischen Dateien sowie bei Persistenz-Mechanismen und deren Speicherorten. Deswegen ist eine manuelle Verifikation der Daten weiterhin erforderlich und wird mithilfe 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 be­ur­teilen die Funde häufig falsch und entscheiden sich auch ebenso schnell um. Der Grund: Sie treffen Entscheidungen basierend auf falschen Annahmen und ziehen vorschnell Schluss­fol­gerungen. Es ist ein erfahrener Analyst erforderlich, der gezielte Rückfragen stellt, erkennt, wo Fehlbewertungen entstehen und die LLMs in die richtige Richtung lenkt. Zum jetzigen Zeitpunkt ist die Urteilsfindung von LLMs nicht vertrauenswürdig.

3. Tooling ist entscheidend
Die Qualität und Geschwindigkeit der Analyse hängt von den Werkzeugen ab, die das Modell nutzt. Gleichzeitig braucht es klare 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. An­dern­falls 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 untersuchen. 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 gut ist und über viel Fachwissen verfügt. Daher arbeiten Malware-Analysten häufig in Teams, 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 macht den Bericht besser und ganz nebenbei kann man selbst noch was lernen.

6. Skripte statt Berichte
Der große Vorteil von Skripten ist, dass LLMs hier eine Feedback-Schleife haben, die un­mit­tel­bar zeigt, ob das Skript funktioniert oder nicht. Diese Art von Rückmeldung gibt es für die meis­ten 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. Ob ein Skript „schummelt“, indem es beispielsweise nur hartkodierte Ergebnisse aus­gibt, kann ein Analyst durch Lesen des Skripts schnell feststellen. Danach führt man 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 zueinanderstehen, sondern auch, wo und wie die verschlüsselte Payload gespeichert ist und welche Algorithmen zur Ent­schlüsselung erforderlich sind.

Model Confusion

Vortrainierte KI-Modelle lassen sich verwirren und angreifen

Fazit: (Des-)Informationszeitalter

Es ist erkennbar, dass autonome LLM-Analysen ein nützliches Werkzeug sind, das Analyse­zei­ten erheblich reduziert. LLMs entscheiden selbstständig, welcher Schritt als nächster Sinn macht. 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 Ergebnisse liefern. Fehlinterpretationen und Halluzinationen bleiben ein strukturelles Problem generativer KI. Der größte Nutzen entsteht zurzeit in hybriden Analyseprozessen.

Über den Autor: Karsten Hahn ist Principal Malware Researcher bei G DATA CyberDefense.

Google Cloud Next 2026

So will Google Cloud seine Kunden zu AI-Unternehmen machen

(ID:50829323)