Malware-Entwickler passen ihren Code und ihre Taktiken schon seit Langem an die Abwehrmaßnahmen und Überprüfungen an, die ihnen voraussichtlich im Weg stehen werden. Mithilfe verschiedener Umgehungs- und Anti-Analyse-Methoden versuchen sie regelmäßig, die Code-Analyse zu behindern oder zu verhindern, die bei einer Überprüfung das wahre Verhalten der Malware offenbart. Andere Tools – insbesondere EDR-Killer, die von ESET-Forschern ausführlich dokumentiert wurden – zielen direkt auf die Sicherheitslösungen selbst ab.
Da LLM-basierte Tools zunehmend bei verschiedenen Sicherheitsaufgaben, einschließlich Code-Triage und -Analyse, zum Einsatz kommen, war es nur eine Frage der Zeit, bis Angreifer nach praktischen Wegen suchten, auch diese zu unterlaufen. Neben herkömmlichen Tarntechniken verfolgen einige einen anderen Ansatz: Die feindlichen Eingaben, die die Analyse vereiteln sollen, werden offen sichtbar belassen.
ESET-Forscher entdeckten kürzlich einen solchen Versuch in einem VBScript, das die mit Russland verbündete Gruppe UAC-0099 in der Anfangsphase eines Angriffs auf ein Ziel in der Ukraine einsetzte. Durch das Einfügen einer Scheinanfrage nach Anleitungen zum Bau einer Atomwaffe in den Kommentar des Skripts wollte der Angreifer die Sicherheitsvorkehrungen eines LLM-gestützten Codescanners auslösen und diesen dazu bringen, die Überprüfung des restlichen Dateitextes einzustellen – noch bevor der Schadcode überhaupt erreicht wurde. Der Zweck des Skripts bestand darin, MATCHBOIL herunterzuladen und zu installieren – einen Loader, der ausschließlich von dieser Gruppe zum Ausliefern zusätzlicher Payloads verwendet wird.
Diese einfache Technik, die ESET „GuardBreaker“ getauft hat, stützt sich genau auf die Art von „Anfrage“, die LLM-Modelle bekanntermaßen ablehnen:
Im Gegensatz zu vielen anderen Tricks im Ausweichrepertoire von Angreifern ist dieser Köderkommentar für „jeden“ – insbesondere für die Modelle, die den Code analysieren – sichtbar. Zudem hat er natürlich keinerlei Auswirkungen auf das Verhalten des Skripts zur Laufzeit. Dennoch deutet sein Vorhandensein darauf hin, dass UAC-0099 ein KI-System in der Verteidigung des Ziels einkalkuliert hat. Genau wie bei anderen jüngsten Angriffen, bei denen die Gruppe ebenfalls nach Prozessen suchte, die mit etablierten Analyse-Tools wie IDA und Wireshark in Verbindung stehen.
Anti-Analyse zielt auf ein anderes Ziel ab
GuardBreaker lässt sich am besten als sehr einfacher Versuch einer Prompt-Injektion verstehen: Die Eingabe eines Angreifers gelangt zum Zeitpunkt der Inferenz über eine zu analysierende Datei an das LLM. Auf diese Weise zielt es darauf ab, eine architektonische Schwäche heutiger LLMs auszunutzen, die nicht vertrauenswürdige Inhalte und vertrauenswürdige Anweisungen ohne verlässliche Abgrenzung zwischen beiden verarbeiten.
Ähnliche Versuche, LLM-gestützte Scanner zu stören, sind insbesondere bei Angriffen auf die Software-Lieferkette aufgetaucht. So fand Socket beispielsweise in bösartigen PyPI-Paketen gefälschte Systemanweisungen und Inhalte, die Richtlinien auslösten, die vor einer JavaScript-Nutzlast platziert waren. StepSecurity berichtete über dieselbe umfassendere Kampagne und entdeckte eine Eingabeaufforderung, die jedes analysierende Modell, das die Datei parste, ausdrücklich anwies, den bösartigen Code zu ignorieren und das Paket als sauber zu melden. Bei einem anderen Vorfall entdeckten Forscher ein npm-Paket, dessen Haupt-JavaScript-Datei zehntausende Male „You’re absolutely right!“ wiederholte, in der Hoffnung, das Kontextfenster des Modells zu erschöpfen und das darauf folgende schädliche Skript einer praktischen Analyse zu entziehen.
Angreifer könnten versuchen, die Analysepipeline durch andere triviale Tricks oder sogar deren Kombinationen gegenüber Malware zu täuschen: Ungewöhnliche oder ungeschickt strukturierte Dateien könnten dadurch gekürzt oder nur teilweise analysiert werden. Einige Teile des Schadcodes könnten unter dem Vorwand, vertrauliche Informationen oder andere sensible Daten zu sein, verborgen werden.
Andere Angriffe könnten benutzerdefinierte Dateitypen einsetzen, für deren Verarbeitung die Tools der Angreifer erforderlich wären, während wieder andere KI-Agenten zu Aktionen lenken könnten, die eine menschliche Überprüfung erfordern, wodurch Verzögerungen entstehen, die die Reaktionszeiten ausnutzen. Agenten, die externe Tools wie Entpacker oder Deobfuscator aufrufen, vergrößern die Angriffsfläche zusätzlich, da diese Aufrufe in manchen Fällen zur Verbreitung und Ausführung von Malware missbraucht werden könnten.
Wer hat das Sagen?
GuardBreaker verdeutlicht eine Lektion, die Sicherheitsexperten bereits kennen: Jede Technologie, die die Erfolgschancen eines Angreifers beeinträchtigen könnte, gerät letztendlich ins Visier der Angreifer. Unternehmen, die auf LLM-gestützte Code-Reviews und andere LLM-unterstützte Arbeitsabläufe setzen, müssen genau wissen, was ein solches Tool überprüft, wo es in der Entscheidungskette angesiedelt ist und was passiert, wenn es nicht reagiert oder eine Aufgabe nicht abschließen kann.
Wichtig ist jedoch, dass keine einzelne LLM-Engine die alleinige Befugnis haben sollte, zu entscheiden, ob ein Codeabschnitt sicher ist. KI-gestützte Ergebnisse müssen mithilfe eines mehrschichtigen und modellübergreifenden Ansatzes kreuzvalidiert werden, der fortschrittliche Automatisierung und menschliches Fachwissen optimal nutzt. Gleichzeitig muss auch das Ausbleiben von Ergebnissen weitere Überprüfungen auslösen.
Unternehmen jeder Größe benötigen zudem einen klaren Weg von der Prävention über die Erkennung bis hin zur Reaktion. Für diejenigen, die nicht über eigene Sicherheitsteams mit Rund-um-die-Uhr-Einsatzbereitschaft verfügen, kann Managed Detection and Response (MDR) die erforderliche Nachverfolgung gewährleisten, bei der ein Experte verdächtige Vorfälle untersuchen kann – auch im Zusammenhang mit anderen Aktivitäten in der gesamten Umgebung – und die nächsten Schritte festlegt. Dieser Ansatz baut am besten auf jahrzehntelangem Einsatz der grundlegenden Technologien der KI, bewährten Analysemethoden, Expertenurteilen, Bedrohungsforschung und globaler Telemetrie auf. Auf diese Weise kann jedes Unternehmen sicherstellen, dass eine Aktion eines einzelnen LLM-Modells nicht zu einer Schwachstelle in der Cyberabwehr des Unternehmens wird.
