KI- malware -Angriffe: Wie KI Schadsoftware verändert und wie man sich dagegen schützen kann

Im September 2026 berichtete die Google Threat Intelligence Group über einen Fall, in dem ein Angreifer einen KI-gestützten Workflow nutzte, um innerhalb von weniger als sechs Stunden nach dem Erlangen eines „ cloud “-Zugangs ein massives Sammeln von Anmeldedaten zu planen, vorzubereiten und durchzuführen. Dabei handelte es sich um eine einzelne beobachtete Kampagne, nicht um eine typische Angriffsdauer. Dies verdeutlicht die operative Besorgnis hinter KI- malware -Angriffen: KI kann Teile des Angriffszyklus verkürzen, selbst wenn die zugrunde liegende Kompromittierung weiterhin auf bekannten Schwachstellen beruht.

KI- malware -Angriffe sind Einbruchsversuche, bei denen ein Angreifer KI einsetzt, um schädliche Software zu entwerfen, zu modifizieren, zu verbreiten oder zu betreiben. Der Begriff umfasst verschiedene Ebenen der KI-Einbindung. Ein Entwickler kann ein Modell zum Schreiben von Code verwenden, während ein eher ungewöhnliches Implantat während der Ausführung ein Modell abfragt, um zu entscheiden, wie es weitergehen soll. Dabei handelt es sich um unterschiedliche Bedrohungen mit unterschiedlichen Anzeichen und Abwehrmaßnahmen. Dieser Leitfaden unterscheidet zwischen ihnen, untersucht dokumentierte Fälle und bietet Sicherheitsteams praktische Möglichkeiten zur Erkennung und Reaktion.

Was gilt als KI- malware -Angriff?

Die entscheidende Frage ist, an welcher Stelle der Angriffskette KI ins Spiel kommt. „ Malware “ wird nicht zu einer neuen technischen Gattung, nur weil ein Modell beim Schreiben geholfen hat. Die Auswirkungen auf die Sicherheit hängen davon ab, was der Code tut, was der Angreifer kontrolliert und ob ein Modell nach der Bereitstellung weiterhin eine Rolle spielt.

Diese Kategorien können sich überschneiden. Sie sollten auch nicht mit der KI-Bedrohungserkennung verwechselt werden, bei der es sich um den defensiven Einsatz von KI handelt, oder mit Angriffen auf eine KI-Anwendung, wie beispielsweise prompt injection. Eine allgemeine Definition und Taxonomie finden Sie im Leitfaden „malware “.

„KI-gestützt“ ist nicht dasselbe wie „autonom“

„KI-generiert“ sagt etwas über die Herkunft der Entwicklung aus. „Autonom“ sagt etwas über die operative Kontrolle aus. Keiner der beiden Begriffe allein gibt Aufschluss darüber, ob ein Angriff erfolgreich war. Ein modellbasierter Stealer kann vollständig anhand festgelegter Anweisungen ausgeführt werden. Umgekehrt kann ein relativ kleines Programm eine eng gefasste Aufgabe, wie beispielsweise die Navigation durch eine Benutzeroberfläche, zur Laufzeit an ein Modell delegieren.

Die polymorphe „ malware “ ging der generativen KI voraus

MITRE ATT&CK beschreibt polymorphen Code als Software, die ihren Speicherbedarf zur Laufzeit verändert, dabei aber ihr Ziel beibehält. Mutations-Engines gab es bereits vor den großen Sprachmodellen. KI kann zwar die Variation von Code beschleunigen oder Varianten auswählen, doch ein sich ändernder Hash-Wert ist kein Beweis dafür, dass die KI das Beispiel erzeugt hat.

Wie Angreifer KI zum Erstellen und Betreiben nutzen malware

Das stichhaltigste Bedrohungsmodell geht von konkreten Schritten aus und nicht von der Behauptung, dass jeder Angriff vollständig automatisiert sei. Aktuelle Forschungsergebnisse belegen den Einsatz von KI bei der Entwicklung, der Verschleierung und bei operativen Entscheidungen, wobei unterschiedliche Reifegrade und Transparenzstufen zu verzeichnen sind.

Entwicklung und Iteration

Ein Angreifer kann ein Programmiermodell nutzen, um Komponenten zu entwerfen, Fehler zu erklären, Code zwischen Sprachen zu portieren, Ablenkungslogik zu schreiben oder Tests zu automatisieren. In ihrer Analyse vom Mai 2026 beschrieb die Google Threat Intelligence Group CANFAIL und LONGSTREAM, zwei Familien v malware , die bei Angriffen auf ukrainische Organisationen zum Einsatz kamen. Die Forscher fanden Code, den sie als modellgenerierten Füllcode einstuften, der dazu dienen sollte, bösartige Funktionen zu verschleiern. In LONGSTREAM identifizierten sie 32 inaktive Abfragen zum Status der Sommerzeit – ein Beispiel für harmlos wirkenden Codeumfang und nicht für ein neues Angriffsziel. Die 32 Instanzen beschreiben eine analysierte Codefamilie und stellen keine Maßzahl für die Verbreitung dar.

Für Sicherheitsverantwortliche stellt sich nach wie vor die unmittelbare Frage, ob eine bösartige Binärdatei oder ein Skript ausgeführt werden, sich dauerhaft im System etablieren, Anmeldedaten stehlen oder nach außen kommunizieren kann. Die Verwendung von KI bei der Erstellung solcher Programme mag die Zuordnung erschweren, hebt diese Verhaltensweisen jedoch nicht auf.

Verschleierung und Code-Variation

KI kann dabei helfen, Code umzuschreiben, inaktive Verzweigungen hinzuzufügen und die Paketierung zu variieren, um statische Abgleiche zu vereiteln. Die Google Threat Intelligence Group beschrieb PROMPTFLUX, einen experimentellen VBScript-Dropper, der darauf ausgelegt ist, ein Modell zur Selbstmodifikation abzufragen. In der Analyse von Google hieß es ausdrücklich, dass sich die beobachtete Version in der Entwicklung oder im Test befand und keine Fähigkeit zeigte, ein Gerät oder Netzwerk zu kompromittieren. Es handelt sich um einen Hinweis auf einen Methodenversuch, nicht um einen Beweis für einen weit verbreiteten erfolgreichen Einsatz.

Statische Datei-Hashes und Signaturen sind bei bekannten Samples nach wie vor von Nutzen. Kombinieren Sie diese mit Prozess-, Speicher-, Identitäts- und Netzwerktelemetriedaten, damit eine veränderte Dateistruktur nicht zu einer blinden Stelle wird.

Modellaufrufe während der Ausführung

Ein „ malware “ integriert einen KI-Dienst in seinen Laufzeit-Workflow. Google berichtete, dass PROMPTSTEAL, das gegen die Ukraine eingesetzt wurde, über eine API Abfragen an ein Modell richtete, um Befehle zum Sammeln von Systeminformationen und Dokumenten zu generieren. Das „ malware “ führte diese Befehle aus und sendete die gesammelten Daten an die Infrastruktur der Angreifer. Google bezeichnete dies als seine erste Beobachtung, bei der ein „ malware “ im Live-Betrieb Abfragen an ein Modell richtete. Dies ist ein stärkerer operativer Beweis als das experimentelle PROMPTFLUX-Beispiel, belegt jedoch noch nicht, dass solche „ malware “ weit verbreitet sind.

In seiner Analyse vom Mai 2026 beschrieb Google PROMPTSPY, eine Android-Backdoor, die mithilfe eines Modells den Status der Benutzeroberfläche interpretierte und Aktionen für die Gerätenavigation zurückgab. Hierbei handelt es sich um ein gerätespezifisches Beispiel. Die Android-Mechanismen für Barrierefreiheit und App-Persistenz sollten nicht auf Windows- oder Linux- malware n in Unternehmen verallgemeinert werden.

Schnellere Arbeitsabläufe für die Bediener

KI kann auch außerhalb des „ malware “ eingesetzt werden. Ein menschlicher Operator kann Agenten nutzen, um Ziele zu priorisieren, Tools zu debuggen oder das Scannen und das Sammeln von Anmeldedaten zu verwalten. Der Google-Fall vom September 2026 betraf eine agentengestützte Kampagne, die in weniger als sechs Stunden abgeschlossen wurde. Diese Geschwindigkeit ist von Bedeutung, da sich die Wartezeit auf manuelle Entscheidungen des Operators verkürzen lässt. Der Fall beweist weder, dass jeder KI-gestützte Einbruch schneller ist, noch dass „ malware “ selbst jede Entscheidung getroffen hat.

Was die Beweislage zeigt – und was nicht

Der Übergang von der Code-Unterstützung zur Nutzung von Laufzeitmodellen ist in dokumentierten Fällen tatsächlich gegeben, doch sollten einzelne Beispiele nicht mit einer allgemeinen Verbreitung verwechselt werden. Die Beweislage ist am stichhaltigsten, wenn Forscher Beispiele, Entwicklungsartefakte oder Telemetriedaten zu Vorfällen untersuchen und darlegen können, was tatsächlich beobachtet wurde.

Der praktische Trend geht hin zu einem breiteren Einsatzspektrum der KI, von der Entwicklungsunterstützung bis hin zum Aufruf von Modellen während der Ausführung. Dies unterstützt das Testen von verändertem Code und beschleunigte Arbeitsabläufe. Es stützt jedoch nicht die pauschale Behauptung, dass „ malware “ mittlerweile autonom sei, dass Signaturen nutzlos seien oder dass die meisten Infektionen von KI generiert würden. Auch in der Zusammenfassung von Googles „M-Trends 2026“ wurde darauf hingewiesen, dass die überwiegende Mehrheit der beobachteten erfolgreichen Angriffe nach wie vor auf bekannte menschliche und systemische Fehler zurückzuführen sei.

Wie sich KI- malware -Angriffe in einer Umgebung ausbreiten

Selbst ein neuartiges Implantat muss sich Zugang verschaffen, ausgeführt werden und Wirkungen entfalten. Verteidiger können ihre Untersuchungen anhand dieser beobachtbaren Phasen strukturieren, ohne sich auf einen einzigen Begriff aus der „ malware “-Familie stützen zu müssen.

1. Eindringen und Ausführung. Ein bösartiger Anhang, ein kompromittiertes Paket, ein ungeschützter Dienst oder gestohlene Anmeldedaten verschaffen dem Angreifer einen Zugang. Stellen Sie fest, was unter welcher Identität und auf welchem System ausgeführt wurde.

2. Erkennung und Anpassung. Der Code oder der Operator erfasst Software, Sicherheitskontrollen, Dateien oder cloud Dienste. KI kann bei der Interpretation dieser Beobachtungen helfen, doch ungewöhnliche Vorkommnisse bleiben weiterhin erkennbar.

3. Persistenz und Berechtigungen. Geplante Aufgaben, Änderungen an Diensten, die Verwendung von Tokens oder unbefugte Zugriffsgewährungen erweitern den Zugriff. Prüfen Sie, ob eine Änderung autorisiert ist, bevor Sie sie als böswillig einstufen.

4. Aktivitäten und Befehle. Achten Sie auf neue Remote-Sitzungen, ungewöhnliche Zugriffspfade, ausgehende Modell-/API-Aufrufe und Command-and-Control-Datenverkehr. Eine Modell-API-Anfrage allein ist noch kein Beweis für eine Kompromittierung; setzen Sie sie in Zusammenhang mit dem Prozess und den nachfolgenden Aktionen.

5. Datenerfassung und Auswirkungen. Der Zugriff auf Dateien, das Sammeln von Anmeldedaten, die Vorbereitung von Daten, die Exfiltration, die Verschlüsselung oder die Störung von Diensten zeigen das Ziel auf. Bewahren Sie Zeitstempel und Beziehungen zwischen Entitäten auf, damit der Ablauf rekonstruiert werden kann.

Diese stufenweise Betrachtungsweise ist besonders nützlich, wenn sich die Nutzlast in ihrer Form verändert. Außerdem sorgt sie dafür, dass sich das Team weiterhin auf die Auswirkungen konzentriert, falls die Frage nach dem Ursprung der KI weiterhin unklar bleibt.

So erkennen und untersuchen Sie mutmaßliche KI-gestützte malware

Die Erkennung sollte bekannte Kontrollmechanismen (malware ) mit der Analyse des Verhaltens über Endgeräte, Identitäten, Netzwerke und cloud -Dienste hinweg kombinieren. Das Ziel besteht darin, eine Angriffskette zu bestätigen, und nicht darin, jeden unbekannten Prozess als „KI- malware “ zu kennzeichnen.

Beibehaltung der herkömmlichen Steuerelemente von „ malware “

endpoint -Schutz, Patching, Überprüfungen der Softwareherkunft und den Abgleich mit bekannten Indikatoren beibehalten. Bekannte Samples und Varianten können weiterhin blockiert werden. Prozessherkunft, Skript- und Speichertelemetrie sowie Steuerungen der Ausführungsrichtlinien für Techniken hinzufügen, die einen einfachen Dateiabgleich umgehen. Der Eintrag zu polymorphem Code bei MITRE empfiehlt ausdrücklich verhaltensbasierte Methoden neben Antimalware-Kontrollen.

Verhalten über die Datei hinaus in Zusammenhang bringen

Untersuchen Sie Kombinationen wie beispielsweise einen neu gestarteten Prozess, der Berechtigungsspeicher ausliest, Kontakt zu einem unbekannten externen Dienst aufnimmt, einen Fernzugriff initiiert und Daten bereitstellt. Verknüpfen Sie den Host mit dem von ihm verwendeten Konto und den darauf folgenden „ cloud “- oder SaaS-Aktionen. Der Netzwerk- und Identitätskontext kann den Verlauf aufzeigen, wenn sich ein Datei-Hash ändert oder ein „ endpoint “-Agent keine Sichtbarkeit bietet. Der Anwendungsfall zur EDR-Lückenerkennung unter Vectra AI beschreibt diese ergänzende Sichtbarkeit; Teams sollten die tatsächliche Abdeckung in ihrer Umgebung überprüfen.

Betrachten Sie den Modellverkehr als Kontext, nicht als Urteil

Sofern dies gemäß den Richtlinien zulässig ist, protokollieren Sie den aufrufenden Prozess, das Ziel, das Konto, den Zeitpunkt, das Anforderungsvolumen und die nachgelagerten Befehle für KI-Dienste im Unternehmensbereich. Ein legitimes Entwicklertool kann ähnlichen Datenverkehr erzeugen. Eskalieren Sie den Vorfall, wenn ein verdächtiger Prozess Modellaufrufe tätigt und anschließend generierte Befehle ausführt, die Persistenz ändert oder auf sensible Daten zugreift. Vermeiden Sie die Erfassung von Eingabeaufforderungen oder Nutzdaten, die über die genehmigten Datenschutz- und Aufbewahrungsrichtlinien hinausgehen.

Verwenden Sie eine kurze Checkliste für die Untersuchung

Sollten keine Protokolle zur Modellnutzung vorliegen, geben Sie an, dass die Beteiligung der KI unbestätigt ist. Die Reaktion kann dennoch auf der Grundlage des beobachteten böswilligen Verhaltens erfolgen.

So lassen sich Risiken minimieren und Maßnahmen ergreifen

Die nützlichsten Kontrollmaßnahmen schränken ein, was ein „ malware “ oder ein KI-gestützter Operator nach dem Eindringen tun kann. Legen Sie neben der Prävention den Schwerpunkt auf Identitätszugriff, Ausführungspfade, Datenausgang und Reaktionsgeschwindigkeit.

1. Reduzieren Sie das Sicherheitsrisiko. Schließen Sie Sicherheitslücken in betroffenen Diensten, schränken Sie den Einsatz nicht vertrauenswürdiger Pakete und Skripte ein, überprüfen Sie die Berechtigungen von Entwicklertools und schützen Sie API-Schlüssel sowie Anmeldedaten von Agenten. Wenden Sie das Prinzip der geringsten Berechtigungen auf Identitäten in „ cloud “ und SaaS-Diensten an.

2. Erfassen Sie den Angriffsweg. Speichern Sie Protokolle zu „ endpoint “, Netzwerk, Identitäten, „ cloud “ sowie relevante KI-Dienstprotokolle mit synchronisierter Zeitangabe. Legen Sie fest, wer die Nachweise zur Modellnutzung einsehen darf und wie lange diese aufbewahrt werden.

3. Testen Sie verhaltensbasierte Erkennungsmechanismen. Simulieren Sie die Erkennung autorisierter Zugriffe, den Zugriff auf Anmeldedaten, die Remote-Ausführung und die Datenaufbereitung. Prüfen Sie, ob das Team Ereignisse zu einem einzigen Vorfall verknüpfen kann, ohne sich dabei auf einen bekannten Hash-Wert zu stützen.

4. Begrenzen Sie die beobachtete Kette. Isolieren Sie betroffene Hosts, wo dies angebracht ist, widerrufen Sie aktive Sitzungen und kompromittierte Tokens, blockieren Sie bestätigte bösartige Ziele und sichern Sie forensische Beweise, bevor Sie eine umfassende Bereinigung durchführen.

5. Wiederherstellung und Auswertung. Führen Sie eine Wiederherstellung anhand vertrauenswürdiger Quellen durch, stellen Sie sicher, dass alle verbleibenden Spuren beseitigt wurden, ändern Sie die betroffenen Zugangsdaten und vergleichen Sie den Zeitablauf mit den Zeitstempeln der Erkennung und Eindämmung. Aktualisieren Sie die Playbooks hinsichtlich aller übersehenen Schritte in den Bereichen Identität, Netzwerk oder „ cloud “.

Eine sinnvolle Bewertung stellt folgende Frage: Konnte das Team die kompromittierte Identität, die betroffenen Ressourcen und den nächsten Schritt des Angreifers schnell genug identifizieren, um einzugreifen? Erfassen Sie die Erkennungszeit, die Untersuchungszeit und die Eindämmungszeit separat. Eine kontrollierte Übung kann diese Frage überprüfen, ohne von der Wirksamkeit eines bestimmten Anbieters auszugehen.

Wo Vectra AI

Vectra AIDie Positionierung des Unternehmens im Bereich KI-gestützter Sicherheit und Observability ist relevant, wenn sich ein Angriff über Identitäten, Netzwerke, „ cloud “-Dienste und Endpunkte hinweg ausbreitet. Der Anwendungsfall zur Erkennung von EDR-Lücken beschreibt die Transparenz des Verhaltens über verwaltete Endpunkte hinaus. Bei KI- malware -Untersuchungen gilt es zu bewerten, ob die verfügbaren Signale den Analysten dabei helfen, den Missbrauch von Anmeldedaten, laterale Bewegungen und Datenexfiltration mit einem aktiven Einbruch in Verbindung zu bringen. Die Eignung des Produkts und die Reaktionsmaßnahmen hängen von der Bereitstellung, den Integrationen und den Berechtigungen ab; überprüfen Sie diese daher im Rahmen eines Proof of Value.

Wenn Sie Ihre Kontrollmaßnahmen abbilden möchten, beginnen Sie mit den Grundlagen zu „malware “ und dem Leitfaden zur Erkennung von KI-Bedrohungen. Teams, die Lücken jenseits der Telemetriedaten von „ endpoint “ bewerten möchten, können sich den Anwendungsfall zur EDR-Lückenerkennung ansehen. Für eine auf Ihre Bereitstellung zugeschnittene Beratung im Anschluss an diese Bewertung fordern Sie bitte eine Demo zu „ Vectra AI “ an.

Quellen- und Methodenhhinweis: Dieser auf Forschungsergebnissen basierende Leitfaden wurde am 22. Oktober 2026 anhand der Originalberichte der Forscher sowie unter MITRE ATT&CK überprüft. Bei den Fällen handelt es sich weder um eine Inzidenzstudie noch um einen unabhängigen Produkttest.

‍