Infostealer-Logs offenbaren Tausende wiederverwendbare KI-Tokens, die MFA umgehen können

Ein 7-GB-Dump legte Authentifizierungsdaten von 5.871 Systemen offen

Infostealer geben Cyberkriminellen zunehmend etwas Nützlicheres als Passwörter: aktive Session-Tokens und API-Schlüssel für Dienste der künstlichen Intelligenz.

Die jüngsten Erkenntnisse wurden am 9. September 2026 bekannt und drehen sich um ein 7-GB-Stealer-Log-Archiv, das am 2. August 2026 auf Telegram veröffentlicht wurde. Der Datensatz enthielt Informationen, die von 5.871 infizierten Rechnern in 162 Ländern gesammelt wurden.

Oktas Analyse des Infostealer-Dumps identifizierte 44.791 eindeutige JSON Web Tokens (JWTs). Die Ermittler schätzten, dass 555 davon wahrscheinlich mit der Authentifizierung für KI-Dienste in Verbindung standen.

Das Archiv enthielt außerdem 2.937 JSON Web Encryption-Strukturen, bekannt als JWEs. Die meisten waren mit OpenAI verbunden, das das Authentifizierungsframework NextAuth.js verwendet. Obwohl diese Strukturen verschlüsselte JWTs enthalten, hindert die Verschlüsselung einen Angreifer nicht unbedingt daran, sie erneut abzuspielen.

An dem Tag, an dem das Archiv auftauchte, waren 1.843 JWTs und JWEs noch nicht abgelaufen. Das bot jedem mit Zugriff auf den Dump ein potenzielles Zeitfenster für eine Kontoübernahme.

Beim Scannen mit TruffleHog wurde eine weitere Kategorie offengelegter Zugangsdaten gefunden: 24 API-Schlüssel, die für Google Gemini, OpenAI, Groq und OpenRouter weiterhin gültig waren. Andere Token im Datensatz gehörten zu Google, Microsoft, Anthropic, Amazon, Gamma, Notion, Character.ai, Cursor, Poe.com und Pika AI.

Dabei handelt es sich nicht um eine Schwachstelle, die eine bestimmte Softwareversion betrifft. Es sind keine anfälligen Produktversionen oder Sicherheits-Patches beteiligt. Die Offenlegung resultiert daraus, dass Authentifizierungsmaterial von kompromittierten Endpunkten extrahiert und an anderer Stelle wiederverwendet wird.

Warum ein gestohlenes Token MFA irrelevant machen kann

Ein gültiges Sitzungstoken repräsentiert ein bereits erfolgtes Authentifizierungsereignis. Wenn ein Dienst dieses Token akzeptiert, behandelt er die Person, die es vorlegt, möglicherweise als authentifizierten Benutzer, ohne erneut nach einem Passwort oder einer Multifaktor-Authentifizierung zu fragen.

Das ändert das Ziel des Angreifers: Statt die MFA beim Login zu überwinden, stiehlt er das Artefakt, das nach erfolgreicher MFA erzeugt wurde.

JWTs enthalten üblicherweise Claims, die von Anwendungen zur Identifizierung von Benutzern, Sitzungen, Berechtigungen, Ausstellern, Zielgruppen und Ablaufzeiten verwendet werden. Im analysierten Archiv enthielten 17,7 % der 44.791 JWTs außerdem personenbezogene Daten im Klartext, darunter Namen, Telefonnummern oder E-Mail-Adressen.

Daraus ergeben sich zwei getrennte Risiken. Ein Token kann den Zugriff auf ein Konto ermöglichen, solange es gültig ist, und sein lesbarer Inhalt kann Identitätsdaten offenlegen, selbst nachdem das Token abgelaufen ist.

JWEs verbergen ihre internen Claims durch Verschlüsselung, aber das macht sie nicht harmlos. Ein Angreifer muss ein gestohlenes JWE nicht unbedingt entschlüsseln, wenn der empfangende Dienst dies tun kann. Wenn das Token weiterhin gültig ist und als Bearer-Zugangsdaten akzeptiert wird, kann das erneute Abspielen des verschlüsselten Objekts die Sitzung des Opfers wiederherstellen.

API-Schlüssel stellen ein ähnliches Problem dar. Sie autorisieren oft direkten programmatischen Zugriff statt eines interaktiven Browser-Logins. Ein Angreifer, der einen gültigen Schlüssel besitzt, kann potenziell Modellressourcen verbrauchen, APIs aufrufen oder automatisierte Workloads unter dem Konto und den Abrechnungslimits des Opfers ausführen.

Passkeys lösen dieses Stadium des Angriffs nicht. Phishing-resistente Authentifizierung kann viele Kompromittierungen durch Passwörter und Login-Phishing verhindern, entwertet aber Sitzungsdaten oder API-Geheimnisse, die von einem infizierten Gerät kopiert wurden, nicht automatisch.

Anti-Detect-Browser erleichtern die Wiederverwendung gestohlener Sitzungen

Das erneute Abspielen eines Sitzungstokens ist nicht immer so einfach wie das Einfügen einer Zeichenkette in einen Browser. Anwendungen können von mehreren Cookies, Browser-Speicherwerten und Umgebungsmerkmalen abhängen, die gemeinsam rekonstruiert werden müssen.

Angreifer verwenden Tools wie den Open-Source-Anti-Detect-Browser Camoufox und das Browser-Automatisierungsframework SeleniumBase, um gestohlene sessionStorage- und localStorage-Daten aus Dateien zu importieren. Dadurch kann genug vom Browser-Zustand des Opfers wiederhergestellt werden, damit ein Dienst die bestehende Sitzung erkennt.

Proxy-Infrastruktur trägt dazu bei, sichtbare Abweichungen zu verringern. Wenn ein gestohlenes Token plötzlich aus einem entfernten Land oder einem unbekannten Netzwerk auftaucht, können Impossible-Travel-Regeln und andere Risikokontrollen ausgelöst werden. Wird das Replay über eine Adresse geleitet, die näher am erwarteten Standort des Opfers liegt, kann die Aktivität unauffälliger werden.

Verhaltensbasierte Erkennung bleibt möglich. Neue Geräte, ungewöhnliche Nutzungsmuster, abnormer Modellverbrauch und gleichzeitige Token-Nutzung können allesamt Signale liefern. Der Angreifer beginnt die Sitzung jedoch mit einem gültigen Artefakt statt mit einem offensichtlich falschen Passwort.

Jeremy Kirk, Oktas Director of Threat Intelligence, bezeichnete Sitzungstokens und API-Schlüssel als sehr begehrt, da sie die credentialbasierte Authentifizierung umgehen können. Sobald ein Replay erfolgreich ist, befindet sich der Angreifer faktisch im LLM-Konto, ohne einen herkömmlichen Login abgeschlossen zu haben.

Die im Zusammenhang mit dieser Aktivität genannten Malware-Familien umfassen Lumma Stealer und Vidar. Die verfügbaren Informationen geben nicht an, welche Familie jeden der 5.871 Rechner infiziert hat, und nennen weder einzelne Opfer noch öffentliche Indikatoren für die betroffenen Endpunkte.

Gestohlener KI-Zugang ist zu einem kommerziellen Produkt geworden

Stealer-Logs werden über Untergrundforen und Messaging-Plattformen verkauft, doch der Markt wird zunehmend spezialisierter. Einige kriminelle Dienste bündeln gestohlene Tokens inzwischen mit Browserprofilen oder Anti-Detect-Konfigurationen, um den Kontozugriff zu vereinfachen.

Okta identifizierte einen Telegram-Anbieter, der vergünstigten Zugang zu Claude, Cursor, ChatGPT und Gemini bewarb. Der Verkäufer pries kontinuierlichen Support und Geld-zurück-Garantien an – eine Sprache, die darauf ausgelegt ist, illegalen Zugriff wie ein herkömmliches Abonnementgeschäft aussehen zu lassen.

Eine andere Operation, die sich „Poison Claude“ nennt, behauptet, Zugang zu Anthropic-Modellen zu verkaufen, die als Opus 4.8, Opus 4.7, Opus 4.6 und Sonnet 4.6 bezeichnet werden. Dabei handelt es sich um Angaben des Anbieters; eine unabhängige Validierung des beworbenen Zugangs wurde nicht offengelegt.

Die Google Threat Intelligence Group hat eine zunehmende Zahl von Käufern und Verkäufern beobachtet, die in Cybercrime-Communitys mit KI-bezogenen Konten handeln. Die Nachfrage umfasst Zugangsdaten für Claude und Gemini sowie autonome Codierungsumgebungen wie Cursor Pro und Devin.

Die potenzielle Nutzung geht über den preiswerten Zugang zu Chatbots hinaus. Gestohlene Konten können private Unterhaltungen, hochgeladene Dokumente, generierten Code, proprietäre Prompts und andere in KI-Plattformen gespeicherte Informationen offenlegen.

Der Missbrauch von APIs ermöglicht auch Ressourcendiebstahl, manchmal als LLMjacking bezeichnet. Das Modell ähnelt dem illegalen Kryptowährungs-Mining: Angreifer führen rechenintensive Aktivitäten aus, während sie Infrastruktur- oder Nutzungskosten auf das Opfer abwälzen.

Mandiant stieß im Rahmen eines Incident-Response-Einsatzes auf eine umfassendere Version dieses Problems. Ein Bedrohungsakteur gelangte mithilfe eines offengelegten GitHub Personal Access Token in die Cloud-Umgebung eines Opfers, implementierte dann nicht autorisierte KI-Infrastruktur und skalierte Hochleistungsrechenressourcen.

Die Folgen reichen von Abrechnungsbetrug bis zu Wirtschaftsspionage

Für Einzelpersonen kann eine Kontoübernahme persönliche Unterhaltungen und Identitätsinformationen offenlegen. Die in einigen JWTs im Klartext gefundenen personenbezogenen Daten können zudem gezieltes Phishing, Identitätsbetrug und Social-Engineering-Kampagnen unterstützen.

Die Folgen für Unternehmen sind umfassender. Ein Angreifer könnte auf sensible Prompts, interne Dokumente, Quellcode, Kundenmaterial oder Forschungsdaten zugreifen, die an einen KI-Dienst übermittelt wurden. Kompromittierte Konten könnten auch weiterverkauft oder als Ausgangspunkt für Erpressung und Spionage genutzt werden.

Finanzielle Auswirkungen können sich schnell summieren, wenn gestohlene API-Schlüssel automatisierte Anfragen ermöglichen. Selbst wenn der Angreifer nicht auf gespeicherte Daten zugreifen kann, verursacht der Verbrauch des Token-Budgets oder der Cloud-Compute-Zuteilung des Opfers direkte Kosten.

Das Vorhandensein von Authentifizierungsdaten aus 162 Ländern zeigt, dass dies nicht auf eine Region oder einen Dienst beschränkt ist. Allerdings ist die Zahl der erfolgreich erneut abgespielten Tokens nicht bekannt. Ebenso ist unklar, wie viele der offengelegten Konten persönliche Abonnements, Entwicklerkonten oder unternehmensverwaltete Identitäten waren.

Abwehrmaßnahmen müssen sowohl Sitzungen als auch Logins schützen

Unternehmen sollten darauf achten, ob dasselbe Sitzungstoken von unerwarteten IP-Adressen, Geräten oder Standorten verwendet wird. Gleichzeitige Nutzung aus verschiedenen Umgebungen, abrupte Änderungen der Browser-Merkmale und ungewöhnlicher KI-Verbrauch können ebenfalls auf ein Replay hinweisen.

IP-Allowlisting kann den Zugriff auf genehmigte Netzwerke beschränken, insbesondere für administrative oder API-Funktionen. Es ist keine vollständige Abwehr, da Angreifer Proxys verwenden oder Infrastruktur innerhalb eines erlaubten Bereichs kompromittieren können.

API-Schlüssel sollten eng definierte Berechtigungen, Nutzungsquoten und eine kontinuierliche Verbrauchsüberwachung haben. Verdächtige Schlüssel sollten widerrufen und ersetzt werden, während betroffene Browser-Sitzungen beendet werden sollten, um den gestohlenen Zustand zu invalidieren.

OAuth-2.0-Bereitstellungen sollten kurzlebige Zugriffstokens bevorzugen, um den Zeitraum zu verkürzen, in dem ein kopiertes Token nützlich bleibt. Langlebige Zugangsdaten schaffen nach einer Endpunkt-Kompromittierung ein größeres Replay-Fenster.

Die Device Bound Session Credentials von Chrome bieten eine direktere Gegenmaßnahme. DBSC verknüpft Sitzungsanmeldeinformationen kryptografisch mit einem Gerät und verhindert so, dass ein exportiertes Token auf einem anderen System akzeptiert wird.

Endpunktsicherheit bleibt zentral, da der Diebstahl auf dem Rechner des Benutzers beginnt. Passkeys können den Login absichern, aber Unternehmen, die KI-Dienste einführen, müssen auch API-Geheimnisse inventarisieren, Browsersitzungen kontrollieren und Infostealer-Infektionen als potenzielle Kompromittierung jedes aktiven Cloud- und KI-Kontos auf dem Gerät behandeln.