Wie KI die Angriffsfläche vergrößert und Patchen ineffektiv macht

Im Jahr 2025 ist die Einstiegshürde für komplexe Cyberangriffe eingebrochen: Jugendliche ohne technische Kenntnisse führten mithilfe von Systemen auf Basis großer Sprachmodelle Einbrüche mit Millionen von Datensätzen und Erpressungen in Millionenhöhe durch, und die durchschnittliche Zeit von der Veröffentlichung einer Schwachstelle bis zum Auftauchen eines Exploits im Einsatz verkürzte sich von über 700 Tagen im Jahr 2020 auf 44 Tage im Jahr 2025; vor diesem Hintergrund funktioniert die traditionelle Strategie „schneller patchen als die Angreifer“ nicht mehr, und Organisationen, die Open Source und öffentliche Paket-Repositories nutzen, müssen zur strukturellen Beseitigung ganzer Klassen von Schwachstellen und zu einer strikten Kontrolle der Software-Lieferkette übergehen.

Technische Details und Schlüsselmetriken der Jahre 2025–2026

Beispiele für Angriffe unter Einsatz von KI

Nicht-technische Angreifer begannen im Jahr 2025 Operationen durchzuführen, die zuvor das abgestimmte Vorgehen eines erfahrenen Teams erforderten:

• Im Dezember 2025 wurde ein siebzehnjähriger Jugendlicher in Osaka nach dem japanischen Gesetz über unbefugten Zugriff festgenommen, weil er Schadcode ausgeführt hatte, mit dem personenbezogene Daten von mehr als 7 Mio. Nutzern des Netzwerkes der Internetcafés Kaikatsu Club exfiltriert wurden; das Motiv war der Kauf von Pokémon‑Karten.
• Im Februar 2025 entwickelten drei Jugendliche (14, 15 und 16 Jahre) ohne Programmiererfahrung mit Hilfe von ChatGPT ein Tool, das die Systeme von Rakuten Mobile etwa 220.000‑mal angriff; die erzielten Erlöse wurden für Spielkonsolen und Online‑Glücksspiele ausgegeben.
• Im Juli 2025 führte ein einzelner Angreifer unter Nutzung der agentenbasierten Programmierplattform Claude Code innerhalb eines Monats eine Erpressungskampagne gegen 17 Organisationen durch: Die KI entwickelte Schadcode, systematisierte die gestohlenen Dateien, analysierte Finanzberichte zur Kalibrierung der Forderungen und verfasste die Texte der Erpresserschreiben.
• Im Dezember 2025 brach ein anderer Einzeltäter mithilfe von Claude Code und ChatGPT in mehr als 10 Behörden der mexikanischen Regierung ein und stahl über 195 Mio. Datensätze von Steuerzahlern.

All diese Fälle zeigen: Die Rolle der KI ist nicht mehr nur unterstützend, sondern durchgängig – von der Entwicklung von Exploits bis zur Automatisierung von Finanzanalysen und Kommunikation.

Evolution der Angriffe auf Open Source und Paket-Repositories

Einer der aussagekräftigsten Indikatoren war das Wachstum bösartiger Pakete in öffentlichen Repositories:

• Im Jahr 2022 wurden etwa 55.000 bösartige Pakete registriert;
• bis 2025 stieg die Zahl auf 454.600, mit deutlichen Sprüngen in den Jahren 2023 (Erscheinen von GPT‑4) und 2025 (massive Verbreitung agentenbasierter KI‑Programmierwerkzeuge).

Im September 2025 kompromittierte der Angriff Shai-Hulud auf das npm-Ökosystem mehr als 500 Pakete. Geheimnisse von 487 Organisationen wurden offengelegt, und aus der Krypto‑Wallet Trust Wallet wurden 8,5 Mio. US‑Dollar entwendet, nachdem Angreifer mit kompromittierten Zugangsdaten deren Chrome‑Erweiterung manipuliert hatten.

Charakteristisch war, dass sich die bösartigen Pakete als populäre Bibliotheken tarnten (zum Beispiel chalk, debug), Dokumentation, Modultests und Code enthielten, der Telemetrie‑Modulen ähnelte. Klassische statische Analysewerkzeuge und signaturbasierte Scanner ließen sie passieren, da die Struktur wie „normale“ Software wirkte. Das deckt sich mit der allgemeinen Tendenz, Angriffsverhalten auf der Ebene von Taktiken und Techniken zu beschreiben, etwa in der Matrix von MITRE ATT&CK, statt über statische Signaturen.

Verkürzung der Zeit bis zur Ausnutzung von Schwachstellen

Eine weitere Kennzahl ist die time to exploit, also die Zeit vom Bekanntwerden einer Schwachstelle bis zum Auftauchen eines Exploits „im Feld“:

• Im Jahr 2020 lag sie bei über 700 Tagen;
• im Jahr 2025 verringerte sie sich auf 44 Tage.

Der Bericht M-Trends 2026 des Unternehmens Mandiant zeichnet ein noch beunruhigenderes Bild: Das Zeitfenster ist faktisch negativ geworden, da Exploits immer häufiger vor den Patches auftauchen und 28,3 % der CVE-Einträge innerhalb von 24 Stunden nach der Offenlegung ausgenutzt werden. Vor diesem Hintergrund werden Schwachstellenkataloge wie die NVD für Kriminelle zur Aufgabenliste, die sich mithilfe von KI schnell automatisieren lässt.

Ungleichgewicht zwischen Angriffs- und Verteidigungsgeschwindigkeit

Daten von Edgescan für das Jahr 2025 zeigen, dass die durchschnittliche Behebungszeit für bekannte Schwachstellen mit hoher und kritischer Priorität 74 Tage beträgt und 45 % der Schwachstellen in der Infrastruktur großer Unternehmen (ab 1000 Mitarbeitenden) überhaupt nicht beseitigt werden. Angesichts der durchschnittlichen Exploit-Entwicklungszeit (44 Tage) und des Anteils der Angriffe in den ersten 24 Stunden nach Offenlegung entsteht ein dauerhaftes Übergewicht zugunsten der Angreifer.

Wachsende KI-Fähigkeiten für die Codeentwicklung

Mit der Verbesserung der Ergebnisse von Frontiersystemen (ChatGPT, Claude, Gemini) in Benchmarks der Softwareentwicklung (etwa SWE-bench) stieg ihr Beitrag zu offensiven Operationen deutlich:

• Im August 2024 lösten Spitzenmodelle automatisch etwa 33 % realer Aufgaben aus GitHub auf SWE-bench;
• bis Dezember 2025 erreichte dieser Wert fast 81 %.

Das bedeutet, dass der Großteil der routinemäßigen und mittelkomplexen Entwicklung von Exploits und Hilfswerkzeugen Angreifern nun als Service und nicht mehr als eigene Kompetenz zur Verfügung steht.

Versuch einer strukturellen Antwort: Chainguard Libraries

Vor dem explosiven Anstieg von Angriffen auf die Lieferkette entsteht ein Ansatz, der nicht auf eine Beschleunigung der Reaktion abzielt, sondern auf die Eliminierung ganzer Risikoklassen. Ein Beispiel sind die Chainguard Libraries, bei denen jede Open‑Source‑Bibliothek aus geprüftem, attribuiertem Quellcode neu gebaut wird. Das architektonische Ziel ist es, Folgendes unmöglich zu machen:

• die Übernahme von CI/CD‑Prozessen durch Austausch von Abhängigkeiten;
• Angriffe vom Typ dependency confusion;
• Diebstahl und Missbrauch langlebiger Tokens beim Build;
• Angriffe auf die Infrastruktur zur Verteilung von Paketen.

Bei Tests mit 8.783 bösartigen Paketen für npm blockierten die Chainguard Libraries 99,7 % davon; bei rund 3.000 bösartigen Python‑Paketen waren es etwa 98 %. Das illustriert, wie viel wirkungsvoller Maßnahmen sind, die in die Architektur der Lieferkette selbst eingebaut sind, verglichen mit der bloßen Hinzufügung neuer Detektionsschichten.

Bedrohungskontext: wer und wie am stärksten betroffen ist

Aus den angeführten Beispielen wird deutlich, dass Angriffe folgende Bereiche treffen:

• den öffentlichen Sektor – von den japanischen Strafverfolgungsbehörden bis zu Regierungsbehörden Mexikos, wo die Offenlegung von 195 Mio. Steuerdatensätzen langfristige Risiken für Betrug und politische Manipulationen schafft;
• Telekommunikationsbetreiber und kritische Infrastrukturen – der Vorfall bei Rakuten Mobile zeigt, dass sogar Jugendliche massive Lasten oder betrügerische Operationen gegen Telekom‑Plattformen auslösen können;
• Finanzdienste und Kryptoplattformen, wie im Fall von Trust Wallet und dem Diebstahl von 8,5 Mio. US‑Dollar durch die Vergiftung einer Browsererweiterung;
• jedes Unternehmen, das von npm, PyPI und anderen Open‑Source‑Repositories abhängt, in denen Hunderttausende bösartige Pakete das Grundrisiko selbst für triviale Abhängigkeiten erhöhen.

Der gemeinsame Nenner ist die massenhafte Abhängigkeit von externer Software und externen Diensten, bei der das traditionelle Modell „Antivirus aktualisieren und regelmäßig Patches einspielen“ keinen akzeptablen Restrisikopegel mehr bietet. Das bestätigen auch Analysen von Organisationen wie der CISA, die den Fokus konsequent auf architektonische Prinzipien von „secure by design“ verlagern.

Bewertung der Auswirkungen auf Geschäft und Betrieb

• Operationelle Risiken: erzwungene Code‑Freeze‑Phasen nach Angriffen auf Repositories (wie nach Shai-Hulud) führen zu Release‑Verzögerungen, dem Verfehlen von Roadmaps und wachsender technischer Schuldenlast.
• Finanzielle Verluste: direkte Diebstähle (Millionenbeträge im Fall Trust Wallet), Lösegeldzahlungen, Serviceausfälle und anschließende Investitionen in beschleunigte Sicherheitsverbesserungen.
• Risiken für Vertraulichkeit und regulatorische Sanktionen: die Offenlegung von 7 Mio. Kundendatensätzen des Kaikatsu Club und 195 Mio. Steuerdatensätzen in Mexiko wirft nicht nur Fragen zu Bußgeldern auf, sondern auch zu der Unmöglichkeit, bereits abgeflossene Daten „zurückzurufen“.
• Reputation und Vertrauen: das Bewusstsein der Nutzer, dass Cyberverbrechen inzwischen „jeder mit einem KI‑Assistenten“ begehen kann, erhöht die Sensibilität für Meldungen über Vorfälle und senkt die Toleranz gegenüber Störungen.

Ein qualitativ neues Problem ist die wachsende Schnittmenge zwischen denen, die zu Angriffen bereit sind, und denen, die sie durchführen können. Früher war dies eine kleine Gruppe; jetzt wächst sie dank KI schnell, und das Ausmaß der Angriffe hängt immer weniger von Größe und Reife der kriminellen Gruppierung ab.

Praktische Empfehlungen zur Risikoreduzierung

1. Als Grundlage akzeptieren: Der Exploit erscheint, bevor Sie patchen können

• Prozesse des Schwachstellenmanagements so planen, dass davon ausgegangen wird, dass eine Ausnutzung in den ersten 24 Stunden nach Offenlegung (oder früher) möglich ist – selbst dann, wenn noch kein Patch verfügbar ist.
• Einen separaten Prozess für die Behandlung kritischer Schwachstellen mit aggressiveren SLOs (Stunden bis wenige Tage) einrichten, einschließlich temporärer kompensierender Maßnahmen (Abschalten von Funktionen, Einschränkung exponierter Dienste, Traffic‑Filterung).

2. Die Software-Lieferkette strikt kontrollieren

• Einen internen Abhängigkeits‑Repository (Spiegel von npm, PyPI usw.) einrichten, in dem nur geprüfte Versionen von Bibliotheken freigegeben und veröffentlicht werden.
• Eine obligatorische Prüfung aller Pakete (statische Analyse, manuelle Reviews, Abgleich mit bekannten legitimen Quellen) vor ihrer Aufnahme in das produktive Repository vorschreiben.
• Lösungen in Betracht ziehen, die Open‑Source‑Bibliotheken aus attribuiertem Quellcode neu bauen und Unveränderlichkeitsgarantien für Builds ähnlich wie Chainguard Libraries bieten, sodass ganze Angriffsklassen (dependency confusion, Kompromittierung von CI/CD, Austausch von Binärdateien) technisch unmöglich werden.

3. Angriffserkennung auf Verhaltensebene, nicht nur auf Codeebene stärken

• Sich nicht auf signaturbasierte Scanner zur Erkennung bösartiger Pakete verlassen: KI‑generierter Code lässt sich leicht als „normaler“ Code mit Dokumentation und Tests tarnen.
• Das Verhalten von Abhängigkeiten überwachen: Netzwerkzugriffe bei der Installation, Versuche, auf vertrauliche Dateien zuzugreifen, Start externer Prozesse aus install‑Skripten heraus.
• Isolierte Umgebungen (Sandbox) einsetzen, um neue Pakete vor ihrer Nutzung in CI/CD und Produktion zu testen.

4. Zugriff auf KI‑Entwicklungstools steuern

• Eine formalisierte Richtlinie zur Nutzung von Systemen wie ChatGPT und Claude Code einführen: Verbot der Übermittlung sensibler Codefragmente und Geheimnisse, Anforderungen an das Logging von Sessions.
• Entwickler und Analysten zu Risiken nicht nur des Datenabflusses, sondern auch des Missbrauchs von KI schulen – von der unbewussten Generierung verwundbaren Codes bis hin zur Unterstützung beim Umgehen interner Kontrollen.

5. Vorbereitung auf Vorfälle in der Lieferkette

• Vorab ein Verfahren zur schnellen „Einfrierung“ von Abhängigkeiten und zum Rollback auf frühere Versionen festlegen, falls eine Paketkompromittierung festgestellt wird.
• Ein Verzeichnis der verwendeten Bibliotheken und ihrer Herkunft führen (im Grunde eine interne Inventarisierung analog zu einer Software‑„Stückliste“), um bei einem neuen Angriff auf npm oder ein anderes Register schnell zu bestimmen, wer betroffen ist.

Die zentrale Schlussfolgerung: In einer Situation, in der sich die Ausnutzung von Schwachstellen schneller beschleunigt als sich Release‑Zyklen für Patches verkürzen, ist eine reine Fokussierung auf Reaktionsgeschwindigkeit zum Scheitern verurteilt; höchste Priorität muss der Aufbau eines kontrollierten internen Abhängigkeits‑Repositorys und die Verlagerung aller Build‑ und Deployment‑Prozesse dorthin haben, um Angriffsarten auf die Lieferkette so weit wie möglich abzuwehren, noch bevor sie in Ihren Verantwortungsbereich gelangen.