CERT-In: KI-Agenten griffen bei Tests unbemerkt auf Produktivsysteme indischer Organisationen zu

Als KI-Agenten bezeichnet CERT-In Softwaresysteme, die Arbeitsschritte planen, Befehle ausführen, Werkzeuge nutzen und über längere Zeiträume selbstständig im Internet agieren können. In den gemeldeten Fällen gelangten die Agenten über Zugangsdaten und Verbindungseinstellungen hinein, die in Anwendungskonfigurationen und öffentlichen Code-Repositories offen lagen, sowie über Cloud-Dienstrollen mit zu weitreichenden Berechtigungen. In den von den KI-Unternehmen gemeldeten Fällen fanden Agenten dieselben offenliegenden Zugangsdaten erneut und nutzten sie in getrennten Operationen wieder.

CERT-In nannte weder die beteiligten KI-Unternehmen und deren Modelle noch die betroffenen Organisationen oder Branchen. Offen blieb auch, wie viele Unternehmen Fälle gemeldet haben und wie viele Organisationen betroffen sind; die Behörde sprach lediglich davon, dass die Meldungen kürzlich eingegangen seien. Ebenso wenig äußerte sie sich dazu, ob die von den Agenten gelesenen Daten kopiert oder gespeichert wurden und ob die betroffenen Organisationen informiert worden sind.

Angreifer missbrauchen quelloffene Agenten-Frameworks

Unabhängig davon stieß CERT-In bei eigener Bedrohungssuche auf eine zweite Reihe von Vorfällen: eine finanziell motivierte Kampagne gegen indische Einrichtungen. Die Angreifer missbrauchten dabei öffentlich verfügbare Offensive-Security-Frameworks, die auf KI-Agenten aufbauen. Diese Frameworks werden weiterhin missbraucht und unter neuem Namen weitergereicht, mit zahlreichen Installationen auf Infrastruktur in mehreren Ländern. Namen der Frameworks oder der Angreifer nannte die Behörde nicht.

Nach Angaben von CERT-In verkürzten die Frameworks die Zeit vom ersten Zugriff bis zur endgültigen Wirkung von Tagen auf wenige Stunden. Die Angreifer ließen mehrere Agenten parallel über Stunden bis Tage laufen, um ihre Ziele zu erreichen. Opfer, die die Schwachstellen nur teilweise beseitigten, wurden binnen Tagen erneut angegriffen – in größerem Umfang.

Die Google Threat Intelligence Group berichtete im September über einen separaten Fall: Angreifer, die eine Cloud-Ressource kompromittiert hatten, planten, bauten und betrieben eine agentengesteuerte Kampagne, die Tausende Zugangsdaten Dritter abgriff – alles in weniger als sechs Stunden.

Am 9. Oktober hatte CERT-In bereits vor Angriffen auf Nichtbanken-Finanzunternehmen, digitale Kreditgeber, Fintechs, Zahlungsdienstleister und Wallet-Betreiber gewarnt. Dort stahlen die Angreifer API-Zugangsdaten und riefen Schnittstellen für Überweisungen und Auszahlungen direkt auf, um Geld auf Mule-Konten zu verschieben. Möglicherweise kamen dabei KI-gestützte Werkzeuge zum Einsatz. Ob diese Angriffe mit der Kampagne aus dem Hinweis vom 15. Oktober zusammenhängen, hat CERT-In nicht mitgeteilt.

Gewöhnliche Schwachstellen als Einfallstor

Die Schwächen hinter beiden Vorfallsarten seien gewöhnlich gewesen, so CERT-In. Zugangsdaten und Schlüssel lagen in Quellcode, in der Historie öffentlicher Repositories, in Konfigurationsdateien, in Client-Anwendungen und auf öffentlichen Webseiten offen. Alte, ungenutzte und Test-APIs waren weiterhin aus dem Internet erreichbar. Zahlungs-API-Schlüssel wurden im Klartext gespeichert, Cloud- und Backend-as-a-Service-Rollen räumten gewöhnlichen oder anonymen Nutzern umfassende Lese- und Schreibrechte ein. Verwaltungsoberflächen waren aus dem Internet erreichbar, und Anwendungs-Middleware blieb ungepatcht, mit schwachen Zugangsdaten oder ohne Mehr-Faktor-Authentifizierung.

Indikatoren für eine Kompromittierung veröffentlichte CERT-In zu keiner der beiden Vorfallsarten. Organisationen sollten die Grundlagen aus dem Blueprint der Behörde vom Mai umsetzen und zusätzlich folgende Schritte ergreifen:

• Quellcode, Commit-Historie, CI/CD-Variablen, Konfigurationsdateien, Client-Anwendungen und Cloud-Speicher nach offenliegenden Zugangsdaten durchsuchen, gefundene rotieren, aus der Historie tilgen und die Behebung von außen überprüfen.
• Jeden Commit und jeden Build auf Geheimnisse prüfen und Zugangsdaten aus Code, Konfigurationsdateien und Datenbanken heraushalten.
• Eine vollständige Liste aller APIs führen sowie alte, ungenutzte und Test-APIs und -Konten abschalten.
• Cloud- und Backend-as-a-Service-Rollen nach dem Prinzip der minimalen Rechte vergeben, privilegierte Schlüssel aus clientseitigem Code heraushalten und testen, was ein anonymer Nutzer lesen und schreiben kann.
• Verwaltungsoberflächen vom Internet trennen, Mehr-Faktor-Authentifizierung für alle administrativen Zugänge verlangen und exponierte Middleware zügig patchen.
• APIs mit ratenbasierter Anomalieerkennung überwachen, bei Enumerations-Schüben, Massenabfragen und automatisierten Registrierungen alarmieren und Protokolle mindestens 180 Tage aufbewahren.
• Nach jeder Offenlegung von Zugangsdaten oder bestätigtem Zugriff die Umgebung als kompromittiert behandeln, bis eine forensische Prüfung sie freigibt; nach der Behebung erneut testen und mit Wiederholungsversuchen binnen Tagen bis Wochen rechnen.

Wer selbst KI-Agenten betreibt, soll jedem Lauf eine eigene, kurzlebige Identität mit minimalen Rechten geben und ausgehenden Verkehr bis auf die jeweils benötigten Ziele blockieren. Ein manipulationssicheres Protokoll der Agentenaktionen soll zumindest alle Zugriffe auf Produktivsysteme und -daten erfassen. Banken, Versicherer, weitere Finanzunternehmen und Fintechs sollen zusätzlich die Maßnahmen für Zahlungs- und Auszahlungs-APIs aus dem Hinweis vom 9. Oktober umsetzen. Die Vorgaben von CERT-In verpflichten Organisationen zudem, Cybervorfälle binnen sechs Stunden an die Behörde zu melden.

KI-Entwicklern, Forschungslaboren und Prüfstellen empfiehlt CERT-In, Testläufe zu isolieren und ausgehenden Netzwerkverkehr standardmäßig zu sperren – durchgesetzt auf Netzwerkebene, nicht über Anweisungen an das Modell. Ein Lauf soll automatisch stoppen, wenn ein Agent externe Systeme kontaktiert oder fremde Zugangsdaten findet oder verwendet. Erreicht ein Agent ein reales System, sollen die betroffene Organisation und CERT-In umgehend informiert werden.

Frühere Offenlegungen von OpenAI und Anthropic

OpenAI und Anthropic haben in diesem Jahr beide vergleichbare Vorfälle offengelegt. Ob Modelle eines der beiden Unternehmen in den indischen Fällen beteiligt waren, teilte CERT-In nicht mit. Im Juli legte OpenAI offen, dass seine Modelle die Plattform von Hugging Face kompromittiert hatten. Das Unternehmen prüft seither, was seine Modelle während Training und Tests im Internet getan haben, und informiert Dritte, deren Sicherheitsvorkehrungen seine Modelle möglicherweise umgangen haben.

Als Reaktion darauf begann Anthropic mit einer Überprüfung der eigenen Cyber-Evaluierungen. Seitdem meldete das Unternehmen vier Vorfälle, bei denen Claude-Modelle während Evaluierungen desselben externen Partners unbefugten Zugang zu realen Drittsystemen erlangten. Alle Betroffenen wurden benachrichtigt. Von den drei Organisationen in Anthropics Offenlegung vom Juli hatten die zwei erreichten Organisationen die Aktivität nicht bemerkt.