Sechs Stunden: Wann Incident Response zu langsam ist

Eine kompromittierte Cloud-Ressource. Weniger als sechs Stunden später eine geplante, gebaute und ausgeführte Kampagne zum Abgreifen von Zugangsdaten. Diesen Ablauf beobachtete die Google Threat Intelligence Group im zweiten Quartal 2026.

Die Zahl ist keine neue Frist für jedes Security-Team. Sie macht aber sichtbar, wie sich das Verhältnis zwischen Angriff und Reaktion verschiebt. Wenn ein Angreifer Aufklärung, Fehlersuche und wiederkehrende Arbeitsschritte automatisiert, wird der menschliche Entscheidungsvorlauf zum Engpass.

Nicht die KI ist der Angreifer

Google beschreibt keinen vollautomatischen Angriff ohne Menschen. In dem beobachteten Fall nutzte ein Angreifer einen KI-Programmierassistenten, Prompts und Agentenanweisungen als Arbeitsgerüst. Die Agenten konnten Schwachstellen suchen, Fehler während des Angriffs beheben und die technische Ausführung anpassen. Das senkte die Zeit zwischen einem ersten Zugang und seiner Ausnutzung erheblich.

Die Konsequenz ist nüchtern: Bekannte Schwächen in Identität, Cloud-Konfiguration oder extern erreichbaren Diensten werden schneller ausgeschöpft. Ein Patchrückstand oder ein offener Zugang, der bisher einige Tage unentdeckt blieb, kann unter diesen Bedingungen in Stunden zum Folgeschaden führen.

Eindämmung ist die erste Entscheidung

Viele Incident-Response-Prozesse sind auf gründliche Analyse ausgelegt. Das ist richtig, solange die Untersuchung den Angreifer nicht ungestört weiterarbeiten lässt. Bei einem beschleunigten Angriff braucht es schon vor der vollständigen Ursachenklärung Entscheidungen, die den möglichen Schaden begrenzen.

Eindämmung bedeutet, den möglichen Angriffsweg früh zu unterbrechen: einen kompromittierten Cloud-Zugang sperren, einen Schlüssel rotieren oder eine riskante Integration trennen. Sie verlangt keine vollständige Gewissheit über Ursache und Umfang. Sie verlangt einen vorher definierten Entscheid, welche Massnahme bei welcher Beweislage ausgelöst werden darf.

Der öffentlich verfügbare AAISM-Prüfungsrahmen von ISACA nennt Eindämmung ausdrücklich als Bestandteil der Behandlung von KI-Vorfällen. Sie steht dort nicht nach der vollständigen Analyse, sondern neben Meldung, Eskalation, Beseitigung und Wiederherstellung. Das ist das richtige Prinzip auch für diesen Fall: Zuerst den Schaden begrenzen, zugleich Beweise sichern und danach den Umfang belastbar aufklären. Wer auf Gewissheit wartet, während die Ausnutzung weiterläuft, entscheidet faktisch für das Restrisiko.

KI-Assets sind Teil der Angriffsfläche

Google beobachtet zudem Angriffe auf Modelle, Quellcode, Prompts, API-Zugangsdaten und Cloud-Rechenkapazität. Künstliche Intelligenz, kurz KI, schafft damit nicht nur neue Anwendungen. Sie schafft neue Werte, Zugänge und Kostenrisiken, die einem klaren Eigentümer und einer technischen Schutzgrenze brauchen. Ein gestohlener Schlüssel kann nicht nur Datenzugriff ermöglichen. Er kann Rechenkapazität verbrauchen, neue Arbeitslasten erzeugen oder einem Angreifer den Zugang zu verbundenen Geschäftsprozessen verschaffen. Wer KI nur als Fachanwendung führt, übersieht diese Seite der Architektur.

Was vor dem nächsten Angriff entschieden sein muss

Der sinnvolle Massstab ist nicht die Frage, ob ein Unternehmen KI selbst entwickelt. Entscheidend ist, ob es auf die beschleunigte Angriffsgeschwindigkeit vorbereitet ist. Dazu gehören klar zuordenbare Cloud- und KI-Zugänge, kurze Wege zum Entzug von Berechtigungen und eine Reaktion, die nicht erst beginnt, wenn jede forensische Frage beantwortet ist.

Die Kontrolle muss anschliessend getestet werden. Ein dokumentierter Notfallkontakt genügt nicht, wenn niemand zeigen kann, wie schnell ein Schlüssel gesperrt, eine Sitzung beendet oder eine riskante Integration in einer realen Störung isoliert wird. Der Unterschied zwischen einem Plan und einer Reaktionsfähigkeit liegt in diesem Nachweis.

Sechs Stunden sind deshalb keine Prognose. Sie sind ein Warnsignal. Wenn die eigene Organisation in dieser Zeit weder erkennen noch wirksam begrenzen kann, ist nicht die KI das grösste Problem. Dann ist es der Abstand zwischen technischer Angriffsgeschwindigkeit und eigener Entscheidungsfähigkeit.

Quellen

• Google Threat Intelligence Group: GTIG AI Threat Tracker
• Help Net Security: Einordnung der agentischen Automatisierung
• ISACA: AAISM-Prüfungsrahmen