Am 2. September 2026 veröffentlichte Unit 42 von Palo Alto Networks die Details einer Untersuchung zum Einbruch in ein Unternehmensnetzwerk. Die Zahl, die den Bericht trug: Der Angreifer startete bei einem öffentlich erreichbaren Webdienst und hatte in unter zehn Stunden Root-Zugriff auf die gesamte Umgebung, eine Arbeit, für die ein menschliches Team etwa zwei Wochen braucht.

Wichtiger ist, was dabei keine Rolle spielte. Kein Zero-Day. Keine seltenen Methoden. Der Angriff nutzte mehr als 50 Techniken, die bereits im MITRE-ATT&CK-Framework katalogisiert sind, also dokumentierte, veröffentlichte Techniken, die Verteidiger kennen. Geändert hat sich nicht die Methode, sondern das Tempo. Statt jede Phase von Hand auszuführen, steuerte der Angreifer KI-Agenten, die in einer einzigen ununterbrochenen Schleife beobachteten, bewerteten, handelten und neu planten, ohne Pause und ohne Schlaf.

Was in diesen zehn Stunden geschah

Der Ablauf, wie ihn der Bericht beschreibt:

  1. Eindringen. Ein öffentlich erreichbarer Webdienst wurde kompromittiert, anschließend wurde ein Tunnel ins interne Netzwerk aufgebaut.
  2. Aufklärung. Ein automatisierter Agent kartierte die internen Microservices ohne menschliches Zutun.
  3. Abgreifen von Secrets. Sub-Agenten durchkämmten die Code-Repositories nach Zugriffstoken und Dienstpasswörtern, die direkt im Code standen.
  4. Rechteausweitung. Diese Token öffneten das Secrets-Management-System, das Master-Administratorzugangsdaten mit Root-Zugriff auf die gesamte Umgebung lieferte.
  5. Die Pipelines. Build- und Deployment-Pipelines wurden über eigene Workflows gekapert, um Cloud-Zugriffsschlüssel abzuziehen.
  6. Die Umkehrung. Mit diesen Schlüsseln wurden die eigenen KI-Endpunkte des Opfers in Post-Compromise-Infrastruktur für den Angreifer verwandelt.

Lesen Sie diesen letzten Schritt noch einmal. Das eigene KI-Abonnement des Unternehmens wurde zum Werkzeug in den Händen des Eindringlings, betrieben über dessen Konto und auf dessen Rechnung. Das ist ein neues Muster, das in Ihr Risikoregister gehört: Jeder API-Schlüssel für ein KI-Modell ist zugleich ein operatives Asset und ein Kostenposten.

Die Zahl, die Sie betrifft, sind nicht die zehn Stunden

Zehn Stunden sind eine eindrucksvolle Zahl, sie stammt aber aus einem einzigen Vorfall. Die Zahl, die Ihre Planung tatsächlich verändern sollte, steht im CrowdStrike 2026 Global Threat Report, der die Breakout-Zeit misst: die Spanne zwischen dem ersten Zugriff eines Angreifers und dem Moment, in dem er sich zu anderen Systemen im Netzwerk bewegt.

  • Die durchschnittliche Breakout-Zeit im eCrime ist auf 29 Minuten gesunken, eine Beschleunigung um 65% gegenüber dem Vorjahr.
  • Schnellster dokumentierter Fall: 27 Sekunden.
  • Ein Anstieg um 89% bei Angriffen, die KI-gestützten Angreifern zugeschrieben werden.
  • 82% der Erkennungen im Jahr 2025 waren malwarefrei, das heißt, der Angreifer meldet sich mit gültigen Zugangsdaten an, statt einen Virus einzuschleusen.
  • Ein Anstieg um 266% bei Cloud-bewussten Angriffen staatsnaher Akteure.

Was 29 Minuten in der Praxis bedeuten: Ein Reaktionsplan, der davon ausgeht, dass jemand den Alarm am Morgen bemerkt und das Team nach dem Mittagessen zusammenkommt, ist ein Plan für eine Ära, die vorbei ist. Und die Zahl von 82% sagt etwas noch Härteres. Ihr Virenschutz sieht den Angriff nicht, weil der Angriff nichts mitbringt, was er sehen könnte. Ein moderner Einbruch ist keine schädliche Datei, die ankommt, sondern ein legitimes Konto, das missbraucht wird.

Warum es funktionierte: Secrets im Code

Die Agenten knackten keine Verschlüsselung und erfanden keine Schwachstelle. Sie fanden Passwörter dort, wo Passwörter niemals stehen sollten, in den Projektdateien. Ein einziges gültiges Token öffnete den Secrets-Manager, und der Secrets-Manager öffnete alles.

Das ist kein Problem, das nur Großunternehmen betrifft. Gehen Sie diese Liste für Ihre eigenen Projekte durch:

  • Schlüssel für Zahlungs-Gateway oder Messaging-Dienst in einer Konfigurationsdatei, die mit dem Code eingecheckt wurde.
  • Ein Datenbankpasswort in einem alten Deployment-Skript, das niemand öffnet.
  • Zugriffstoken eines Mitarbeiters oder externen Entwicklers, der vor einem Jahr gegangen ist, und die noch gültig sind.
  • Ein Repository, das privat war und nach einer Migration oder einem Kontowechsel öffentlich wurde.
  • Eine Sicherungskopie einer Konfigurationsdatei auf dem Laptop von irgendjemandem.

Der Unterschied zwischen einem Agenten und einem menschlichen Angreifer liegt hier nicht in der Intelligenz, sondern in Geduld und Durchsatz. Der Agent liest das gesamte Repository, jeden Branch und jede alte Version in der Historie, übersieht keine Datei und ist in Minuten fertig. Jedes Secret, das Sie einmal eingecheckt und später gelöscht haben, lebt in der Repository-Historie weiter, und genau dort sucht er.

Was Sie diese Woche tun sollten

Fünf Schritte. Der erste braucht weder Budget noch externen Dienstleister:

  1. Durchsuchen Sie Ihre Repositories nach Secrets. Werkzeuge zum Secret-Scanning sind verfügbar und in die großen Code-Plattformen integriert. Lassen Sie sie über die gesamte Historie laufen, nicht nur über den aktuellen Stand.
  2. Machen Sie Schlüsselrotation zur Routine, nicht zur Notmaßnahme. Ein Schlüssel, der sich seit zwei Jahren nicht geändert hat, ist ein geleakter Schlüssel, den Sie nur noch nicht entdeckt haben. Und wenn Sie nach einem Leak rotieren, dann überall, wo er verwendet wurde, nicht nur an einer Stelle.
  3. Bereiten Sie ein einziges Widerrufs-Playbook vor. Das ist die direkte Empfehlung von Unit 42: eine synchronisierte Eindämmung ausführen können, die Zugangsdaten, OAuth-Sitzungen, CI/CD-Pipelines und Cloud-Konten gemeinsam widerruft. Widerrufen Sie nur die Hälfte, geben Sie dem Angreifer Zeit, über die andere Hälfte wieder einzudringen.
  4. Steuern Sie KI wie Kerninfrastruktur. Führen Sie ein Inventar aller eingesetzten Modelle und Schlüssel, setzen Sie Ratenbegrenzungen, wenden Sie das Prinzip der minimalen Rechte an und aktivieren Sie Diagnoseprotokolle. Der Bericht empfiehlt das ausdrücklich, und genau das macht aus dem obigen Vorfall statt einer stillen Katastrophe eine Frühwarnung.
  5. Verlangen Sie Code-Reviews durch mehrere Personen und Branch-Schutz. Besonders bei Infrastructure-as-Code-Repositories, denn das ist die Tür, durch die eine einzeilige Änderung eine Hintertür einbaut. Achten Sie außerdem auf Verhalten statt auf Signaturen: stoßweise API-Anfragen und schnelle Zustandswechsel sind der Fingerabdruck eines automatisierten Agenten.

Im saudischen Kontext sind diese Schritte keine optionale gute Praxis. Die Essential Cybersecurity Controls der Nationalen Cybersicherheitsbehörde (NCA) enthalten ausdrückliche Bereiche für Identitäts- und Zugriffsmanagement sowie für Änderungs- und Entwicklungssicherheit, und die Verantwortung für den Schutz personenbezogener Daten liegt nach dem Gesetz zum Schutz personenbezogener Daten (PDPL) bei der Organisation. Ein Einbruch, der mit einem im Quellcode stehenden Schlüssel begann, verringert diese Verantwortung in keiner Weise.

Die Sicht von Origami

Wir lesen diesen Vorfall als das Ende einer Vorstellung: dass Sicherheit eine Sammlung von Werkzeugen ist, die man kauft. Der Angreifer stand hier nie vor einer Firewall und umging nie einen Virenschutz, denn keines von beidem stand ihm im Weg. Er kam mit einem gültigen Schlüssel herein, den er aufgeschrieben fand, und handelte mit Berechtigungen, die tatsächlich vergeben worden waren. Kein Produkt, das Sie kaufen, behebt das. Was es behebt, ist Disziplin darin, wie Code geschrieben wird, wie Secrets gespeichert werden und wie Berechtigungen vergeben und entzogen werden.

Ein Muster, das wir bei Kunden immer wieder sehen: Die gefährlichsten Secrets liegen selten im Hauptsystem. Sie liegen in den Nebenprojekten, einem einmal geschriebenen Datenmigrationsskript, einem internen Reporting-Dashboard, das ein externer Auftragnehmer gebaut hat, einer vorübergehenden Lieferantenanbindung, die seit zwei Jahren läuft. Diese kommen nie in ein Sicherheitsreview, weil niemand sie als System zählt. Der Angreifer macht diesen Unterschied nicht. Wenn wir die Umgebung eines Kunden prüfen, beginnen wir genau hier: wo die Schlüssel liegen, wer welche Berechtigung hat und was passiert, wenn heute Nacht ein Schlüssel geleakt wird. Wenn Sie ein Review aus diesem Blickwinkel möchten, finden Sie uns auf der Kontaktseite.

Fazit

Die Angriffsmethode hat sich nicht geändert. Ihre Geschwindigkeit schon. Mehr als 50 bekannte Techniken liefen in unter zehn Stunden ab, weil automatisierte Agenten sie ohne Pause ausführten, und die durchschnittliche Breakout-Zeit im Netzwerk liegt jetzt bei 29 Minuten. Eine Verteidigung, die darauf angewiesen ist, dass jemand es rechtzeitig bemerkt, reicht nicht mehr. Beginnen Sie mit der einfachsten und schwierigsten Frage: Wissen Sie, wo Ihre Schlüssel gerade liegen und wer sie lesen kann?

Quellen