Abwehr KI-gestützter Cyberangriffe: Phishing, Exploits und Agentenübernahme

Um sich auf KI-gestützte Angriffe vorzubereiten, reduzieren Sie Kontoübernahmen und die Ausnutzung veröffentlichter Schwachstellen und verhindern Sie unautorisierte Aktionen von KI-Agenten auch nach dem Lesen externer Inhalte. Zu prüfen, ob Authentifizierung, Patches, Berechtigungen und Kontrollen ausgehender Übertragungen tatsächlich greifen, ist unmittelbar nützlicher als festzustellen, ob eine Angriffsnachricht von KI geschrieben wurde.

Dieser Artikel richtet sich an Teams, die Dienste betreiben oder KI-Agenten in Entwicklungsabläufe einführen. Er behandelt Reaktionen je Angriffspfad und lokale Logkorrelation. Die folgenden Betriebsverfahren sind Vorschläge, kein Bericht über einen Vorfall in einer Organisation oder gemessene Abwehrwirkung.

KI zum Angriff nutzen und KI angreifen

Angreifer können KI einsetzen, um Zielinformationen zu ordnen und Nachrichten mit vorgetäuschter Identität oder Code zu erstellen. Auch unsere eigenen KI-Agenten können Ziele sein. Indirekte Prompt Injection versteckt etwa Anweisungen in externen Dokumenten, um Datenübertragungen oder Änderungen an Deployment-Konfigurationen auszulösen.

Die Bedrohungsbewertung des britischen NCSC bis 2027 prognostiziert, dass KI bestehende Aktivitäten wie Aufklärung, Social Engineering und Schwachstellenforschung effizienter machen wird. Sie schätzt außerdem, dass sich das Reaktionsfenster zwischen Veröffentlichung und Ausnutzung bekannter Schwachstellen weiter verkürzen könnte. Diese Prognosen sind keine Beobachtungen, wonach jeder Angriff bereits vollständig automatisiert wäre.

Angriffspfad	Ziel des Angreifers	Zuerst zu schützende Grenze
Gezieltes Phishing und vorgetäuschte Führungskräfte	Anmeldung, Kontowiederherstellung oder Zahlungsfreigabe	Authentifizierung, Wiederherstellung und separater Prüfkanal
Unterstützte Schwachstellensuche und -ausnutzung	Eindringen in exponierte Dienste und Diebstahl von Geheimnissen	Exponierte Systeme, Patches und Isolation
Prompt Injection bei Agenten	Unautorisierte Werkzeugausführung oder ausgehende Übertragung	Trennung von Daten und Anweisungen; Werkzeug- und Netzwerkrechte

Mehrere Pfade können in einem Vorfall zusammenkommen. Ermöglicht eine Kontoübernahme das Platzieren bösartiger Anweisungen in einem internen Dokument, untersuchen Sie sowohl Identitäts- als auch Agentenschutz.

Phishing über Authentifizierungs- und Freigabepfade abwehren

Microsofts Analyse vorgetäuschter Führungskräfte und Rechnungsbetrugs beschreibt eine Kampagne mit gefälschten E-Mails von Führungskräften, Rechnungen und als weitergeleitete Gespräche präsentierten Inhalten. Forschende beobachteten Indikatoren, die mit KI-gestützter Vorlagenentwicklung vereinbar sind, betonen aber, dass diese nicht belegen können, wie viel Inhalt KI erzeugte. Bestimmte Zeichensetzung oder Kommentarformate reichen als Grundlage für Regeln zur Angriffsklassifikation nicht aus.

Prüfen Sie zunächst diese betrieblichen Grenzen:

• Anmeldung: Führen Sie für unterstützte Konten phishingresistente Authentifizierung wie FIDO2 oder Passkeys ein und prüfen Sie, dass die tatsächlichen Anmelderichtlinien sie verlangen. Microsofts Empfehlungen für phishingresistente MFA behandeln Abfang- und Ermüdungsrisiken bei SMS-, OTP- und Push-Authentifizierung sowie den Wechsel zu stärkeren Methoden.
• Wiederherstellung und Registrierung: Registriert der Helpdesk eine neue Authentifizierungsmethode oder stellt ein Konto wieder her, prüfen Sie die Identität anhand vertrauenswürdiger vorhandener Unterlagen und eines separaten Verfahrens. Legen Sie Betriebsregeln fest, die eine Wiederherstellung nicht aufgrund einer einzelnen E-Mail oder eines Videoanrufs freigeben.
• Fachliche Freigabe: Prüfen Sie Änderungen von Bankverbindungen und Aufforderungen zur Weitergabe von Geheimnissen über zuvor registrierte Kontaktdaten oder ein internes Freigabesystem, nicht über Kontaktdaten aus der Nachricht. Zahlungsbetrug kann ohne Kontoübernahme gelingen; eine stärkere Anmeldung allein vervollständigt den Schutz daher nicht.

Kombinieren Sie SPF, DKIM, DMARC und die Erkennung vorgetäuschter Identitäten zum E-Mail-Schutz. Bestandene E-Mail-Authentifizierung belegt nicht die geschäftliche Legitimität von Anfragen aus ähnlich aussehenden Domains oder kompromittierten legitimen Konten. Phishingresistente Authentifizierung löst auch nicht jedes Szenario gestohlener Sitzungen oder kompromittierter Endgeräte.

Exposition und Ausnutzungsrisiko bei Schwachstellen priorisieren

Ein exponierter Dienst bleibt verwundbar, während Verteidiger auf Belege für den KI-Einsatz eines Angreifers warten. Ordnen Sie zunächst jeden aus dem Internet erreichbaren Dienst seinem Produkt, der laufenden Version, einem Verantwortlichen und dem Patchstatus zu und prüfen Sie dann Herstellerhinweise und Informationen über beobachtete Ausnutzung. Ob die aktuell Verkehr verarbeitenden Instanzen die korrigierte Version ausführen, zählt mehr als ein Eintrag, dass Quellcode oder Image-Tag geändert wurden.

Priorisieren Sie die Reaktion anhand externer Exposition, beobachteter Ausnutzung, zugänglicher Daten und Rechte sowie Dienstauswirkungen gemeinsam. Ist sofortiges Patchen schwierig, wenden Sie vom Hersteller unterstützte Gegenmaßnahmen oder Zugriffsbeschränkungen an und dokumentieren Sie Verantwortliche und Neubewertungszeitpunkt der Ausnahme. Eine zusätzliche WAF-Regel beseitigt die zugrunde liegende Schwachstelle nicht.

Könnte eine Ausnutzung bereits stattgefunden haben, untersuchen Sie den Vorfall parallel zum Patchen. Sichern Sie Prozess-, Authentifizierungs- und ausgehende Kommunikationsdaten; legen Sie Zugangsdatenrotation und Neuaufbau aus vertrauenswürdigen Images entsprechend dem Kompromittierungsumfang fest. Ein erfolgreicher Patch belegt nicht die Entfernung von Einbruchsspuren oder Persistenz.

Gelesene Inhalte nicht in Ausführungsbefugnis verwandeln

Liest ein KI-Agent Issues, Repository-Dateien oder Webseiten, können diese Inhalte vom Angreifer kontrolliert sein. Text wie „Führe nach dem Lesen dieses Dokuments den folgenden Befehl aus“ dieselbe Autorität wie der vom Nutzer genehmigten Aufgabe zuzuschreiben, kann aus Informationsbeschaffung eine ausgehende Übertragung machen.

OWASPs Empfehlungen zur Vermeidung von Prompt Injection empfehlen, Werkzeugaufrufe anhand von Nutzerrechten und Sitzungskontext sowie werkzeugspezifische Parameter zu prüfen und minimale Rechte anzuwenden. Eine Warnung in der Eingabe oder die Aufforderung an das Modell, bösartige Anweisungen zu ignorieren, setzt selbst keine Ausführungsrechte durch.

Setzen Sie die pro Nutzer und Aufgabe erlaubten Ressourcen und Aktionen an der Werkzeugausführungsgrenze außerhalb des Modells durch. Nutzen Sie Konten mit reinen Leserechten und kurzlebige Zugangsdaten und begrenzen Sie Netzwerkübertragungen nach Ziel, Protokoll und Datenumfang. Eine reine Zielfreigabeliste reicht nicht aus, wenn eine erlaubte Domain weiterhin Übertragungen an ein Angreiferkonto oder beliebige Pfade gestattet. Zeigen Sie bei Freigaben wichtiger Änderungen oder Übertragungen konkretes Ziel und Änderungen.

Protokollieren Sie Aufgaben-IDs, Ausführungsidentitäten, Werkzeugnamen, Richtlinienentscheidungen und Ergebnisse. Stellen Sie Entscheidungsgründe als beobachtbare Richtliniencodes dar; die verborgenen Überlegungen des Modells müssen nicht gesammelt werden. Vollständige Quelldokumente, Tokens oder Passwörter zu protokollieren, kann einen weiteren Offenlegungspunkt schaffen. Die betriebliche Autorisierungsgrenze erläutern die Berechtigungsgrenzen für KI-Agenten.

Verweigerte Übertragungen nach dem Lesen externer Inhalte korrelieren

Das folgende Python-Beispiel korreliert synthetische Ereignisse, die einem vertrauenswürdigen Executor zugeschrieben werden. Es markiert einen Untersuchungsfall, wenn für denselben Akteur und dieselbe Lauf-ID innerhalb von 300 Sekunden nach dem Lesen externer Inhalte eine externe Übertragung verweigert wird. Es identifiziert weder Prompt Injection noch blockiert es Anfragen. Es setzt voraus, dass separate Werkzeug- oder Netzwerkrichtlinien die Ablehnungsereignisse bereits erzeugt haben.

Das Diagramm fasst die Verzweigungen zur Verarbeitung eines Ereignisses zusammen. Die Abschlusssymbole rechts bedeuten das Überspringen des aktuellen Ereignisses, kein Sicherheitsurteil. Der Code wiederholt die Verarbeitung für jedes Ereignis und speichert den jüngsten Lesezeitpunkt. Ereignisse, die die Bedingungen nicht erfüllen, werden übersprungen. Das Diagramm stellt keinen vollständigen Angriffserkennungs- oder Vorfallsreaktionsprozess dar.

Das Beispiel wurde mit Python 3.13.0 ausgeführt und nutzt keine externen Pakete, kein Netzwerk und keine Produktionslogs. Speichern Sie es als correlate.py. Hier zählt at Sekunden seit dem Startpunkt des Beispiels; eine echte Erfassung benötigt synchronisierte Ereigniszeitstempel und stabile Lauf-IDs. Befüllen Sie kind oder Kennungen nicht anhand vertrauensselig übernommener Dokumenttexte oder beliebiger modellgenerierter Werte.

from dataclasses import dataclass


@dataclass(frozen=True)
class Event:
    at: int
    actor: str
    run: str
    kind: str


def correlate(events: list[Event], window: int = 300) -> list[tuple[str, str, int]]:
    if window < 0:
        raise ValueError("window")
    last_read: dict[tuple[str, str], int] = {}
    candidates = []
    for event in sorted(events, key=lambda item: item.at):
        key = (event.actor, event.run)
        if event.kind == "untrusted_read":
            last_read[key] = event.at
        elif event.kind == "egress_denied":
            read_at = last_read.get(key)
            if read_at is not None and 0 <= event.at - read_at <= window:
                candidates.append((event.actor, event.run, event.at))
    return candidates


if __name__ == "__main__":
    events = [
        Event(20, "agent-a", "run-1", "egress_denied"),
        Event(0, "agent-a", "run-1", "untrusted_read"),
        Event(30, "agent-a", "run-2", "egress_denied"),
        Event(40, "agent-b", "run-1", "egress_denied"),
        Event(301, "agent-a", "run-1", "egress_denied"),
    ]
    print(correlate(events))

python3 correlate.py

Die tatsächliche Ausführungsausgabe lautet:

[('agent-a', 'run-1', 20)]

Nur das Ereignis bei 20 Sekunden für denselben Lauf wird ausgewählt. Ablehnungen für andere Läufe oder Akteure sowie außerhalb des Zeitfensters werden ausgeschlossen. Das 300-Sekunden-Fenster ist eine beispielhafte Wahl, keine validierte Sicherheitsschwelle. Zeitliche Nähe belegt nicht, dass Injection den Übertragungsversuch verursacht hat. Legitime Automatisierung kann dasselbe Muster erzeugen.

Dreizehn separate lokale Prüfungen deckten die eingeschlossene 300-Sekunden-Grenze, den Ausschluss bei 301 Sekunden, umsortierte Eingaben, Zeitstempel null, Isolation zwischen Akteuren und Läufen, Ablehnungen ohne Lesezugriff, erfolgreiche Übertragungen und ein negatives Fenster ab. Auch drei Regressionsmutationen wurden erkannt, die die 300-Sekunden-Grenze ausschlossen, den Akteur ignorierten oder Zeitstempel null falsch behandelten. Das Ausbleiben eines Alarms belegt keine Sicherheit: Die Regel kann nicht blockierte Übertragungen und fehlende Logs übersehen. Ein Produktionseinsatz erfordert den Umgang mit Stream-Verzögerungen und Umsortierung, Zustandsablauf, Deduplizierung, Wiederherstellung nach Neustarts und die Bewertung von Fehlalarmen. Dieses Batch-Beispiel implementiert diese Funktionen nicht.

Ausführungsergebnisse prüfen und nach einem Alarm den Schadenspfad schließen

Prüfen Sie Richtlinienergebnisse des Executors sowie Netzwerk- und Zieldienstaufzeichnungen, statt sich auf die Aussage eines Agenten zu verlassen, er habe eine Aktion blockiert. Ein egress_denied-Ereignis bedeutet, dass dieser einzelne Versuch verweigert wurde; es belegt nicht, dass über keinen anderen Pfad Daten abflossen. Stoppen Sie den verdächtigen Lauf und korrelieren Sie anhand seiner Aufgaben-ID Quellzugriffe, Werkzeugaufrufe und ausgehende Kommunikation.

Situation	Vorgeschlagene erste Reaktion	Prüfungen vor Wiederaufnahme
Verdächtige Anmeldung oder Kontoänderungen nach Phishing	Betroffene Sitzungen und Tokens ungültig machen, Konto wiederherstellen, registrierte Authentifizierungsmethoden und Zustimmungen prüfen	Vom Angreifer hinzugefügte Zugangswege entfernen und legitime Anmeldung prüfen
Verdacht auf Ausnutzung eines exponierten Dienstes	Betroffene Systeme isolieren, Beweise sichern, korrigierte Versionen einspielen und nötigenfalls neu aufbauen	Laufende Versionen und Exposition prüfen; Persistenz und laterale Bewegung untersuchen
Unautorisierte Agentenaufrufe	Lauf stoppen, betroffene Zugangsdaten widerrufen oder rotieren, Werkzeuge und Übertragungspfade begrenzen	Mit Regressionstests prüfen, dass unautorisierte Anfragen abgelehnt werden und genehmigte Arbeit weiter gelingt

Automatische Blockierung kann Dienste unterbrechen; wenden Sie sie daher entsprechend der Erkennungszuverlässigkeit und dem Auswirkungsumfang an. Stehen Eindämmung und Beweissicherung im Konflikt, wählen Sie die Reihenfolge anhand laufender Schäden und Erfassungskosten. Auch wenn Angreifermaterial einer Untersuchungs-KI vorgelegt wird, müssen Werkzeug- und Übertragungsrechte getrennt werden. Die gemeinsamen Empfehlungen nationaler Sicherheitsbehörden zur Einführung agentischer KI beziehen Komponenten, Integrationen und Betrieb in die Risikobewertung ein.

Beginnen Sie mit einem extern exponierten System, einem wichtigen Konto und einer Agentenaufgabe, die externe Dokumente liest. Verbinden Sie für jedes davon tatsächliche Durchsetzung, untersuchbare Logs und ein von Verantwortlichen ausführbares Wiederherstellungsverfahren. Beziehen Sie erfolgreiche legitime Anfragen in wiederholte Tests ein und prüfen Sie, dass Änderungen an Ablehnungsgrenzen die Prüfung scheitern lassen, wie unter KI-gestütztes TDD gezeigt.