Experiment: Backdoor in einer rund 40 MB großen Binärdatei verstecken und prüfen, ob sie sich mit AI und Ghidra erkennen lässt

• Um die Möglichkeiten der AI-basierten Malware-Erkennung zu überprüfen, wurden in mehrere Open-Source-Server-Binärdateien künstlich Backdoors eingebaut und mit AI-Agenten sowie Ghidra auf ihre Erkennung getestet
• Neuere Modelle wie Claude Opus 4.6 fanden einige einfache Backdoors, doch mit einer Erkennungsrate von 49 % und einer False-Positive-Rate von 28 % ist das für den praktischen Einsatz ungeeignet
• Für das Experiment wurden C- und Rust-basierte Projekte wie lighttpd, dnsmasq, Dropbear und Sozu verwendet; die AI analysierte sie ohne Quellcode ausschließlich mit Reverse-Engineering-Tools
• Einige Modelle hielten offensichtliche bösartige Aufrufe wie execl("/bin/sh", ...) fälschlich für normale Funktionen oder konzentrierten sich auf irrelevanten Code und zeigten damit mangelndes Urteilsvermögen
• Die Forschenden bewerten AI noch nicht als vollständiges Security-Tool, sehen aber einen Entwicklungsstand erreicht, auf dem auch Nichtfachleute erste Sicherheitsprüfungen durchführen können

---

Forschungshintergrund

• Jüngste Vorfälle wie der Shai-Hulud-2.0-Lieferkettenangriff und die Kompromittierung von Notepad++-Binärdateien haben die Risiken nicht vertrauenswürdiger ausführbarer Dateien deutlich gemacht
  • Angreifer schleusen Schadcode in legitime Software ein, um Zugangsdaten zu stehlen oder Remote-Befehle auszuführen
• Auch bei Firmware und Hardware-Geräten wurden Fälle gemeldet, in denen versteckte Kommunikationsmodule oder Backdoor-Konten vorhanden waren
• Als Reaktion auf diese Bedrohungen wurde untersucht, ob AI bösartiges Verhalten auf Binärebene erkennen kann

Überblick zur Binäranalyse

• In der normalen Programmierung arbeitet man mit Quellcode, bei der Malware-Analyse müssen jedoch Binärdateien auf Maschinenebene interpretiert werden
• Beim Kompilieren gehen höherwertige Informationen wie Funktions- und Variablennamen verloren, und Optimierungen verzerren zusätzlich die Codestruktur
• Die Analyse durchläuft einen Reverse-Engineering-Prozess, bei dem Maschinencode → Assembler → Pseudo-C-Code umgewandelt wird
  • Open-Source-Tools: Ghidra, Radare2
  • Kommerzielle Tools: IDA Pro, Binary Ninja
• Diese Werkzeuge stellen zwar die Bedeutung des Codes wieder her, die Ergebnisse sind jedoch oft voller aussageloser Bezeichner wie FUN_00130550 oder bVar49

Aufbau des BinaryAudit-Benchmarks

• In mehrere Open-Source-Server wie lighttpd, dnsmasq, Dropbear und Sozu wurden Test-Backdoors eingebaut
  • Beispiel: Ausführen von Befehlen über HTTP-Header oder Shell-Kommandos über DHCP-Optionen
• Der AI wurden nur kompilierte ausführbare Dateien ohne Quellcode bereitgestellt, die sie mit Ghidra, Radare2, binutils usw. analysieren musste
• Ziel war es, das Vorhandensein einer Backdoor und die Startadresse der entsprechenden Funktion zu identifizieren
• Einige Aufgaben waren so angelegt, dass unter mehreren Binärdateien nur bestimmt werden musste, welche infiziert war

Erfolgreiche Erkennungsfälle

• Eine über den Header X-Forwarded-Debug eingebaute Backdoor in einem lighttpd-Server wurde von Claude Opus 4.5 in 5 Minuten erkannt
  • Das Modell entdeckte einen popen()-Aufruf und bestätigte per Reverse Engineering mit Radare2 die Logik zur Befehlsausführung
  • Es erkannte sogar die Struktur, bei der die Ergebnisse über den Response-Header X-Request-Trace zurückgegeben werden
• Das Modell kombinierte Befehle wie nm, strings, grep und r2 und führte damit einen automatisierten Analyseablauf aus

Fehlgeschlagene Erkennungsfälle

• Eine in den DHCP-Verarbeitungscode von dnsmasq eingebaute /bin/sh-Backdoor wurde von Claude Opus 4.6 fälschlich als legitime Funktion eingeordnet
  • Zwar wurde der Aufruf execl("/bin/sh", "sh", "-c", ...) gefunden, aber irrtümlich als Ausführung eines DHCP-Skripts interpretiert
  • Tatsächlich handelte es sich um verwundbaren Code, der den Inhalt von Client-Paketen unverändert ausführte
• Obwohl das Modell die genaue Stelle fand, verneinte es das Risiko und wechselte zu anderen Funktionen, wodurch die Erkennung verfehlt wurde

Grenzen von AI und das False-Positive-Problem

• Die durchschnittliche False-Positive-Rate von 28 % bedeutet, dass auch saubere Binärdateien häufig fälschlich als mit Backdoors versehen eingestuft wurden
  • Beispiel: Gemini 3 Pro interpretierte regulären Code zum Parsen von Kommandozeilenoptionen fälschlich als „Backdoor zur Befehlsausführung“
• Auch in der Security-Community wird die sinkende Qualität AI-generierter Berichte als Problem gesehen
  • Das curl-Projekt erklärte, dass die meisten AI-generierten Bug-Reports wertlos seien
• Für den Einsatz als praktikables Security-Tool wäre eine False-Positive-Rate von unter 0,001 % erforderlich

Einschränkungen der Open-Source-Tools

• Ghidra und Radare2 sind für die Analyse von C-Code nützlich, zeigen aber bei Rust- und Go-Binärdateien Leistungseinbußen
  • Beispiel: Der Go-basierte Caddy-Server (50 MB) benötigte in Ghidra 40 Minuten zum Laden und lieferte ungenaue Ergebnisse
  • IDA Pro lud denselben Code in 5 Minuten und stellte präzisen Code bereit
• Im Experiment lag der Schwerpunkt deshalb auf C-basierten Binärdateien, um Unterschiede in der Tool-Qualität auszuklammern

Ergebnisse und Ausblick

• Die gemessenen Erkennungsraten lagen bei Claude Opus 4.6: 49 %, Gemini 3 Pro: 44 % und Claude Opus 4.5: 37 %
• Große Binärdateien oder Backdoors, die normales Verhalten nachahmen, bleiben problematisch
• Dennoch hat sich AI bis zu einem Punkt entwickelt, an dem sie Ghidra direkt bedienen und Reverse Engineering durchführen kann
  • Dadurch können auch Nichtfachleute verdächtige ausführbare Dateien einer ersten Prüfung unterziehen
• Als nächste Entwicklungsschritte werden die Integration kommerzieller Tools und Security-Analysen mit lokalen Modellen genannt
• Der vollständige Benchmark und die Ergebnisse sind auf GitHub unter QuesmaOrg/BinaryAudit veröffentlicht

[GN⁺]

Hacker-News-Kommentare

• Sie sagen zwar, dass sie keine Obfuskation verwendet haben, aber wenn man Imports oder Symbole versteckt und Strings obfuskiert, fällt die Erkennungsrate sofort auf 0 %.
  In solchen Fällen erkennt ein LLM letztlich nur sprachliche Anomalien, die mit bösartigem Verhalten zusammenhängen, daher ist das nicht besonders beeindruckend.

  • Ich bin einer der Autoren des Papers. Diese Aufgaben waren diesmal Arbeiten auf Einsteiger-Niveau, und überraschend war einfach, dass es Modelle gibt, die schon allein beim Betrachten von Binärcode einige Muster erkennen können.
    Modelle, die zum Beispiel Tooling wie Ghidra oder Radare2 verstehen, sind im Grunde nur Opus 4.5, 4.6, Gemini 3 Pro und GLM 5.
    Den zugehörigen Benchmark gibt es hier.
    Das ist nur ein Ausgangspunkt dafür, dass AI mit Binärdateien arbeiten kann, und bis zu einer vollständigen Lösung ist es noch weit.
  • Als ich das Tool ghidra-cli für LLMs entwickelt habe, habe ich Crackmes als Test verwendet, und wenn man es nur per Prompt darauf hinweist, kam es auch mit obfuskiertem Code gut zurecht.
    Beim tatsächlichen Reverse Engineering von Software irrt es eine Weile herum, aber sobald es erkennt, dass Obfuskation vorliegt, läuft es danach recht reibungslos weiter und aktualisiert die Ergebnisse in Dokumenten wie CLAUDE.md.
  • Im Artikel steht auch ausdrücklich, dass die Symbole entfernt wurden. Echte Backdoors sind bereits mit minimalem Code obfuskiert.
    Als Beispiele kann man sich die Patches dnsmasq-backdoor und dropbear-brokenauth ansehen.
  • Mit Opus 4.5 und 4.6 habe ich obfuskierten Malware-Code mit einem Ghidra-Plugin für Claude Code vollständig reverse-engineert.
    Allerdings handelte es sich bei dem, womit ich gearbeitet habe, nicht um staatliche Backdoors, sondern eher um das Niveau von Software-Cracks.
  • Ich habe gesehen, dass LLMs solche ungewöhnlichen Muster ziemlich gut erfassen. Das liegt daran, dass sie verschiedene Verschlüsselungs- und Obfuskationstechniken gelernt haben.
    Eher komplexe Logik bringt LLMs zu Fall, aber gute Modelle erkennen diese Komplexität selbst und markieren sie entsprechend.

• Ich stelle mein ghidra-cli-Projekt vor.
  Ich habe mit Ghidra das Altium-Dateiformat (den Delphi-Teil) reverse-engineert, und die Wirkung war beeindruckend.
  Die Modelle können keinen vollständigen Parser von Grund auf schreiben, aber vor LLMs hätte man solche Versuche gar nicht erst unternommen.
  Für Security Audits würde ich mich nicht darauf verlassen, aber für Reverse Engineering von Dateiformaten sind die aktuellen Modelle durchaus brauchbar.

  • In letzter Zeit beobachte ich die Nutzung von Agenten als Hilfswerkzeug. Man verlässt sich nicht vollständig auf sie, sondern nutzt sie zur Erweiterung der eigenen Fähigkeiten.
    Zum Beispiel lasse ich sie Diagramme erzeugen, die Attack Surface kartieren oder Code erkunden, während ich mich auf die manuelle Analyse konzentriere.
    LLMs nehmen langweilige Wiederholungsarbeit ab und beschleunigen dadurch den Prozess. Wenn man ihnen aber zu viel überlässt, gerät man in eine Produktivitätsfalle.
    Mit der richtigen Kombination von Agenten mit passenden „Skills“ steigt die Effizienz definitiv.
  • Wir verwenden PyGhidra, aber CLI-Zugänglichkeit könnte besser sein.
    Die größte Einschränkung von Ghidra war für mich, dass die Analyse von Go-Code viel zu langsam ist.
  • Das ist wirklich ein großartiges Projekt. Es ist deutlich ausgefeilter als das, was ich mit Ghidra + LLM gemacht habe.
  • Das zugehörige Ökosystem ist aktiv. Kürzlich gab es auch diesen Fall mit einem MCP-Server.
    Ich habe GhidrAssistMCP, analyzeHeadless, PyGhidra usw. ausprobiert,
    und insbesondere ein Ansatz mit explizitem SKILL.md lässt sich gut mit AI-Agenten integrieren.
  • Mich würde interessieren, wie sich dieser Ansatz im Vergleich zu verschiedenen Ghidra-MCP-Servern schlägt.

• Der Kern dieses Threads ist eine methodische Diskussion.
  Die Aussage „mit zusätzlicher Obfuskation liegt die Erfolgsquote bei 0 %“ stimmt, aber Ziel des Experiments war zu prüfen, ob AI wie ein erfahrener Reverse Engineer mit nicht obfuskierten Binärdateien umgehen kann.
  Das ist ein Szenario mit realem Nutzen, etwa für interne Audits oder die Analyse von Legacy-Code.
  Wirklich wichtig ist die Definition des Threat Models. Für Gegner auf dem Niveau automatisierter Angreifer ist das bereits sehr nützlich,
  aber gegen fortgeschrittene Angreifer, die AI-Erkennung bewusst einkalkulieren, reicht dieser Test nicht aus.
  Die eigentliche Prüfung wäre zu sehen, wie die Leistung bei leichter Obfuskation aussieht, etwa beim Verstecken von Imports oder bei String-Encoding.

  • Aber eine obfuskierte Binärdatei nicht erkennen zu können, ist wie nicht durch ein CAPTCHA zu kommen.
    Kann man einen Roboter, der bei bewölktem Wetter keine Äpfel pflücken kann, wirklich einen „erfahrenen Apfelpflück-Experten“ nennen?

• GPT ist mit einer False-Positive-Rate von 0 % stabil, aber die Erkennungsrate liegt nur bei etwa 18 %.
  Claude Opus 4.6 hat dagegen eine höhere Erkennungsrate von 46 %, aber eine False-Positive-Rate von 22 %.
  Es wäre interessanter, mehrere Modelle zu kombinieren, sodass eines das Prüfverfahren entwirft und ein anderes die eigentlichen Exploit-Tests ausführt.

  • Tatsächlich gibt es solche Methoden zur Messung der Leistung binärer Klassifikation schon seit 100 Jahren.
    Aber mit dem Aufkommen generativer Modelle scheint das jeder vergessen zu haben.

• Der Kernpunkt ist, dass „AI zwar keine vollständige Malware-Erkennung leisten kann, es für Entwickler aber viel einfacher geworden ist, ein erstes Security Audit durchzuführen“.
  Selbst Entwickler ohne Reverse-Engineering-Erfahrung können verdächtige Binärdateien nun einer ersten Analyse unterziehen.
  Das lässt sich nicht nur auf Security ausweiten, sondern auch auf Optimierung, Debugging, Hardware-Reverse-Engineering und Architektur-Portierung.
  Letztlich ist entscheidend, AI nicht als perfekten Analysator zu betrachten, sondern als Werkzeug zur Hypothesengenerierung.

• Die ausführbaren Dateien im Benchmark bestehen aus Hunderten bis Tausenden von Funktionen, und die Backdoor macht nur wenige Zeilen davon aus.
  Deshalb muss man kritische Pfade strategisch erkunden, etwa Netzwerk-Parser oder Routinen zur Eingabeverarbeitung.
  Eine Möglichkeit wäre, dem LLM solche Strategien in Form von .md-Dateien mitzugeben.

  • Aber damit könnte das Experiment verfälscht werden. In dem Moment, in dem man sagt „es könnte eine Backdoor geben“, liefert man bereits einen Hinweis.
    Schon ein einziges subtil gewähltes Wort im Prompt kann das Ergebnis verändern.
    Am Ende explodiert die Komplexität des Versuchsdesigns, und die Robustheit der Ergebnisse leidet.
  • Wenn man aber bedenkt, dass die Aufgabenstellung in dieser Studie einfach war, sind die Ergebnisse bereits beeindruckend.
    Mit Anleitung durch Experten könnte das zu einem starken Verstärkungseffekt der Leistung führen.
  • Wenn man Strategien jedoch als Dokument vorgibt, kommt es oft vor, dass das Modell sie einfach nachahmt und nur so tut, als würde es „strategisch denken“.
    Menschliches strategisches Denken tatsächlich von AI ausführen zu lassen, ist nach wie vor schwierig.

• Den direkten Benchmark-Link gibt es hier,
  und der Open-Source-Code ist im GitHub-Repository zu finden.

• Dass Gemini die höchste False-Positive-Rate hat, deckt sich mit meiner Erfahrung.
  Ich habe ChatGPT, Claude und Gemini alle verwendet, und Gemini ist am stärksten positiv verzerrt.
  Es gibt immer die optimistischste Antwort.
  Ich hatte nach einem Benchmark gesucht, der diese Eigenschaft numerisch zeigt, und dieses Ergebnis könnte dafür ein Beleg sein.

• Ich bin kein Experte, aber ich denke, um das False-Positive-Problem zu verringern, könnte man das Modell die Backdoor selbst ausführen und verifizieren lassen.

  • Aber die meisten Modelle verweigern ein solches Verhalten wegen ihrer Sicherheitsrichtlinien.
    Dadurch wird der Vergleich zwischen Modellen schwierig, und stattdessen verlangt man meist, dass das Modell die Position der Backdoor ausdrücklich angibt.
    Wenn man ein Modell direkt anpasst oder feinabstimmt, könnte der vorgeschlagene Ansatz nützlich sein.

• Dass das beste Modell nur etwa 50 % erkannt hat, ist nicht schlecht. Es könnte sogar besser sein als ein Mensch.
  Aber ich frage mich, warum die übrigen 50 % verpasst wurden.
  Dass Claude Opus 4.6 die Backdoor findet und trotzdem zu dem Schluss kommt, „es gibt kein Problem“, ist interessant.
  Das zeigt letztlich, dass AI ohne die Unterstützung menschlicher Beurteilung nur schwer zu einem vollständigen Verständnis gelangt.