Praxistest: Large Language Models in der Malware-Analyse: Schneller, besser, risikoreicher?

Zu den zeitintensivsten Aufgaben im Security-Umfeld zählt die Analyse moderner Malware. Gerade bei mehrstufigen Loadern oder stark obfuskiertem Code kann eine vollständige Untersuchung viele Stunden oder sogar Tage in Anspruch nehmen. Dabei analysieren Virenanalysten komplexe Binärdateien, entschlüsseln verschleierte Codepassagen und verfolgen das Verhalten von Schadsoftware in abgeschotteten Analyseumgebungen.

Vor diesem Hintergrund erscheint das Potenzial von LLMs aussichtsreich. Schließlich können die
verschiedenen Modelle eine große Anzahl von Dateien und Code schnell verarbeiten, Zusammenhänge zwischen Funktionen aufzeigen und Ideen für mögliche Interpretationen skizzieren. Security-Teams versprechen sich davon eine deutliche Zeitersparnis bei bestimmten Analysephasen.

Gleichzeitig wirft der Einsatz generativer künstlicher Intelligenz (KI) in sicherheitskritischen Bereichen zentrale Fragen auf: Wie zuverlässig sind die Ergebnisse und welche Rolle können sie im Analyseprozess tatsächlich übernehmen?

Der Testaufbau: Zwei VMs, drei Modelle

Um diesen Fragen auf den Grund zu gehen, wurde ein Set-up mit zwei virtuellen Maschinen
(VMs) aufgesetzt. Eine mit Remnux, einer auf Ubuntu basierenden Linux-Distribution mit
vorinstallierten Tools zur Malware-Analyse, und die andere mit Windows 10. Auf der Remnux-VM
wurden Claude und OpenCode installiert und über verschiedene Model-Context-Protocol-
(MCP)-Server wie remnux, x64dbg oder ssh-mcp sicher mit externen Datenbanken und Werkzeugen verbunden. MCP ist eine von Anthropic vorgeschlagene offene Schnittstelle, über die KI-Clients standardisiert auf externe Tools und Datenquellen zugreifen können.

Das SSH- und das x64dbg-MCP sind mit der Windows-10-VM verknüpft. 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: GPT-5.1 und GPT-5.1-mini von OpenAI sowie Claude Sonnet 4.6 von Anthropic. Im Folgenden stellen wir zwei Versuche exemplarisch vor; die gesamte Testreihe umfasste jedoch deutlich mehr Durchläufe.

Versuch Nummer 1: Equation-Editor-Exploit (CVE-2017-11882)

Mit GPT-5.1-mini wurde ein Office-Dokument mit einem Equation-Editor-Exploit (CVE-2017-11882) analysiert. Die Ergebnisse enttäuschten auf ganzer Linie. Bei anspruchsvolleren Aufgaben gelangte das Modell häufig zu fehlerhaften Schlussfolgerungen und lieferte letztlich keine verwertbaren Ergebnisse.

Zudem bewertete GPT-5.1-mini das Sample als unkritisch, da es keine Makros enthalte. Gleichzeitig stufte es jedoch die Domain decalage.info als hochgradig verdächtig ein. Tatsächlich handelt es sich hierbei um die legitime Website von oletools, einer Sammlung von Python-Werkzeugen zur Analyse von MS-Office-Dateiformaten. An dieser Stelle konnte die KI den standardmäßigen Ausgabetext von oletools nicht korrekt von den eigentlichen Analyseergebnissen unterscheiden.

Insgesamt erwies sich die Analysequalität von GPT-5.1-mini als so unzureichend, dass für die weiteren Tests ausschließlich GPT 5.1 verwendet wurde. Zwar erkannte GPT 5.1, dass es sich um ein ungewöhnliches Sample handelt, konnte jedoch keinen klaren Beleg für bösartiges Verhalten liefern. Erst nach der gezielten Aufforderung, nach dem Equation-Editor-Exploit zu suchen, identifizierte es den Shellcode, der die nächste Stufe nachlädt, emulierte diesen mithilfe von Mandiants Speakeasy und extrahierte schließlich die entsprechende URL.

Im Gegensatz dazu erkannte Sonnet 4.6 eigenständig, dass es sich um einen Equation-Editor-Exploit handelt, fällte eine zutreffende Bewertung und lokalisierte den Shellcode. Allerdings war es nicht in der Lage, die URL der nächsten Stufe selbstständig zu extrahieren. Stattdessen durchsuchte Sonnet sämtliche extrahierten Dateien mithilfe regulärer Ausdrücke nach URL-Mustern, blieb jedoch erfolglos, da die URL erst zur Laufzeit durch den Shellcode zusammengesetzt wird.

Versuch Nummer 2: Komplexere Aufgaben

Im Anschluss sollten die LLMs deutlich anspruchsvollere Samples analysieren. Dafür benötigt ein Mensch mehrere Stunden manueller Arbeit, um die Funktionsweise nachzuvollziehen und ein statisches Entschlüsselungsskript zu entwickeln, das sich auch auf ähnliche Samples übertragen lässt. Die Zielsetzung für die KI blieb identisch: herausfinden, wie sich die Dateien extrahieren und entschlüsseln lassen, und darauf aufbauend ein Python-Skript zur Entschlüsselung erstellen.

Das Resultat fiel bemerkenswert aus. Sowohl GPT 5.1 als auch Sonnet 4.6 waren erfolgreich – statt mehrerer Stunden benötigten sie lediglich rund 30 Minuten, um ein auf das jeweilige Sample zugeschnittenes Python-Skript zu generieren. Dieses musste anschließend noch etwa eine halbe Stunde lang manuell überarbeitet werden, um es generisch zu nutzen. Dennoch stellt der Zeitgewinn eine deutliche Verbesserung dar.

Da Sonnet 4.6 in Vergleichstests kostengünstiger war und zugleich eine vergleichbare Qualität lieferte, bildete dieses Modell gemeinsam mit Opus die Grundlage für die weitere Verfeinerung des Analyseprozesses. Oberste Priorität hatte dabei die Erstellung faktisch korrekter und leicht nachvollziehbarer Berichte. Zu diesem Zweck kamen sogenannte Skills zum Einsatz – ausgelagerte Anweisungen an die KI, die nur dann im jeweiligen Kontext geladen werden, wenn bestimmte Schlüsselwörter fallen.

Im ersten Schritt wurde ein „Erstelle-einen-Report“-Skill entwickelt, der nicht nur die finalen Analyseergebnisse auflistet, sondern die LLMs auch dazu anhält, jeden einzelnen Schritt zu dokumentieren, den ein Analyst zur Verifikation nachvollziehen müsste. Ergänzend wurde ein Verifikations-Skill für kritische Angaben wie IP-Adressen, Hashes, Dateinamen, Pfade, Registry-Keys, Offsets, Zeilennummern und ähnliche Informationen hinzugefügt.

Sechs Erkenntnisse aus der Praxis

Analyseberichten ist nicht zu trauen: Von LLMs erstellte Analyseberichte sind grundsätzlich mit Vorsicht zu genießen. Selbst nach mehreren Verifikationsdurchläufen treten häufig Fehler an zentralen Stellen auf – etwa bei Indicators of Compromise (IoCs), den Beziehungen zwischen Dateien oder bei Persistenzmechanismen und deren Ablageorten. Eine manuelle Überprüfung der Daten bleibt daher unerlässlich, wird jedoch durch die vom LLM bereitgestellten Verifikationsschritte deutlich effizienter als eine vollständig manuelle Analyse.

Urteile sind nicht verlässlich: Einschätzungen darüber, ob ein Sample schädlich oder unbedenklich ist, erweisen sich als besonders unzuverlässig.

LLMs bewerten ihre Funde häufig fehlerhaft und revidieren ihre Beurteilungen mitunter ebenso schnell. Ursache dafür sind unzutreffende Annahmen und vorschnelle Schlussfolgerungen. Es bedarf daher eines erfahrenen Analysten, der gezielt nachhakt, Fehlbewertungen erkennt und die Modelle entsprechend steuert. Zum aktuellen Zeitpunkt sind LLMs für eine belastbare Urteilsfindung ungeeignet.

Das richtige Tooling ist entscheidend: Für Qualität und Geschwindigkeit der Analyse ist es von zentraler Bedeutung, ob dem Modell die passenden Werkzeuge zur Verfügung stehen – einschließlich klarer Vorgaben dazu, wann und auf welche Weise sie einzusetzen sind. Langfristig ist es daher sinnvoll, spezialisierte Skills für bestimmte Sample-Typen zu entwickeln, etwa einen dedizierten Skill für die Analyse von JavaScript, der geeignete Werkzeuge empfiehlt. Andernfalls verbraucht das LLM unnötig viele Tokens, weil es zunächst per Trial-and-Error ermitteln muss, welches Tooling für das jeweilige Sample geeignet ist.

LLMs können in kürzerer Zeit mehr Dinge abdecken: LLMs sind in der Lage, komplexe Programme und Umgebungen in vergleichsweise kurzer Zeit detailliert zu analysieren. Durch ihre hohe Geschwindigkeit identifizieren sie häufig relevante Bereiche, Indikatoren und Dateien, die
menschlichen Analysten entgehen könnten. Insbesondere, weil diese nicht manuell Tausende Dateien sichten können.

LLMs verfügen über ein breiteres Wissensspektrum: Jeder Reverse Engineer hat bestimmte Fachgebiete, in denen er besonders versiert ist und über tiefgehendes Wissen verfügt. Deshalb entstehen Malware-Analysen häufig in Zusammenarbeit, um die jeweiligen Stärken aller Beteiligten zu bündeln. LLMs hingegen bringen auch in solchen Bereichen Kenntnisse mit, die einer einzelnen Person weniger vertraut sind. Vor allem bei der Analyse von Malware ohne ein Team im Rücken bietet dieser zusätzliche Kontext einen großen Vorteil: Er hebt die Qualität des Berichts und ermöglicht es gleichzeitig, neues Wissen zu gewinnen.

Skripte statt Berichte: Der entscheidende Vorteil von Skripten liegt darin, dass LLMs eine unmittelbare Feedback-Schleife haben, die direkt zeigt, ob ein Skript funktioniert. Für viele andere Bestandteile eines Berichts existiert eine solche Rückmeldung in dieser Form nicht. Diese Feedback-Schleife ermöglicht es dem Modell, sich iterativ selbst zu korrigieren, bis ein lauffähiges Skript mit den gewünschten Ergebnissen vorliegt.

Indem man das LLM gezielt anweist, etwa einen Konfigurations-Extractor, einen statischen Entpacker oder ein Deobfuskationsskript zu entwickeln, lässt sich der Aufwand für die Validierung der Berichtsdaten erheblich reduzieren.

Ein Analyst kann so schnell überprüfen, ob ein Skript valide arbeitet: Es wird einfach auf das Sample angewendet – und das Ergebnis liegt vor. Ein Entpacker-Skript bestätigt beispielsweise nicht nur, welche Payload extrahiert wird und in welchem Verhältnis die einzelnen Stufen zueinanderstehen, sondern auch, wo und in welcher Form die verschlüsselte Payload abgelegt ist und welche Algorithmen für deren Entschlüsselung erforderlich sind.

Mythos und das Fazit

Es ist erkennbar, dass autonome Analysen durch LLMs ein äußerst wertvolles Werkzeug darstellen und die Zeiten der Malware-Analyse deutlich verkürzen können. Die Modelle bestimmen eigenständig die nächsten sinnvollen Schritte. Bei gezieltem Einsatz können Virenanalysten so ihre Effizienz steigern, ohne Abstriche bei der Qualität machen zu müssen.

Gleichzeitig macht die Praxis deutlich, dass KI-Modelle ohne fachliche Anleitung keine verlässlichen Ergebnisse liefern. Fehlinterpretationen und Halluzinationen bleiben ein strukturelles Problem generativer KI. Den größten Mehrwert bieten daher hybride Analyseansätze.

All die oben stehenden Ansätze stammen übrigens aus den Wochen und Monaten vor der Mythos-Ankündigung von Anthropic. Software-Analyse mittels KI ist also nicht wirklich neu – Mythos macht es nur schneller und effizienter. Angeblich kann es automatisch und zuverlässig tausende Sicherheitslücken selbstständig finden. Eine solche Aussage ist natürlich auch sehr werbewirksam. Wie viel da tatsächlich dran ist, wird sich zeigen.

Ohne menschliches Review und menschliche Vorgaben wird es auch in Zukunft nicht gehen.