- 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
Noch keine Kommentare.