24 Milliarden kompromittierte Zugangsdaten sind in den Händen von Angreifern. Ist Ihre Control Plane vorbereitet?
Am 15. Juni 2026 haben Forscher von Cybernews die kontrollierte Abschaltung eines ungesicherten Elasticsearch-Clusters bekannt gegeben, der 8,3 Terabyte an Daten enthielt – 24 Milliarden Datensätze mit Benutzernamen und Passwörtern, aggregiert aus 36 verschiedenen Quellen, überwiegend aus Telegram-Kanälen, in denen gestohlene Zugangsdaten unter Cyberkriminellen kursieren. Rund 22,6 Milliarden dieser Datensätze stammen aus sogenannten „Collections“ – zusammengetragenen Zugangsdaten aus historischen Datenschutzvorfällen, die Sicherheitsteams in den meisten Unternehmen bereits durch Passwortwechsel oder Stilllegung der Systeme adressiert haben. Die verbleibenden Datensätze stammen jedoch aus einer völlig anderen Quelle: Infostealer-Malware-Logs, die Zugangsdaten direkt aus aktiven Unternehmensumgebungen abgreifen.
Diese Unterscheidung – historische Sammlung versus aktuelle Infostealer-Ausgabe – macht den Unterschied zwischen einer Hintergrundbedrohung und einem akuten operativen Risiko aus. Infostealer wie RedLine, Lumma und Vidar sammeln Zugangsdaten direkt von den Geräten, auf denen sich Mitarbeitende täglich authentifizieren: Browser, Desktop-Anwendungen, Passwortmanager und SaaS-Portale im Unternehmen. Die Zugangsdaten in diesen Logs stammen nicht aus einem Vorfall vor fünf Jahren. Sie kommen von Endpunkten, die aktuell produktiv genutzt werden, und die erfassten Authentifizierungsdaten bleiben gültig, bis sie geändert werden.
Für Unternehmen, die unter HIPAA-Compliance-Vorgaben, CMMC 2.0-Compliance, FedRAMP-Zertifizierung oder vergleichbaren regulatorischen Rahmenbedingungen arbeiten, ist die Rechnung klar und ernüchternd. Bei einer Belegschaft von mehreren Tausend Mitarbeitenden ist es mit nahezu statistischer Sicherheit so, dass ein Teil der Zugangsdaten in einem Aggregat von 24 Milliarden Datensätzen enthalten ist. Die entscheidende Frage für Compliance-Verantwortliche und Sicherheitsteams lautet nicht, ob diese Zugangsdaten in der Datenbank existieren. Sie lautet: Was kann ein Angreifer erreichen, wenn er sie erfolgreich nutzt, und begrenzt Ihre aktuelle Architektur dieses Risiko?
Dieser Beitrag beantwortet genau diese Frage – wie die durch Infostealer verursachte Offenlegung von Zugangsdaten funktioniert, warum regulierte Branchen asymmetrische Konsequenzen tragen und was eine Kiteworks-Steuerungsebene für sicheren Datenaustausch leisten muss, was eine reine Perimeterverteidigung nicht kann.
Wichtige Erkenntnisse
1. Infostealer-basierte Datensätze sind die eigentliche Bedrohung, nicht historische Sammlungen
Der Großteil der 24 Milliarden Datensätze besteht aus wiederverwerteten Daten aus früheren Datenschutzverletzungen. Die Infostealer-Logs sind anders – diese Zugangsdaten wurden von aktiven Unternehmenssystemen abgegriffen und sind möglicherweise noch gültig. Sie bilden das entscheidende, von Angreifern priorisierte Angriffsziel.
2. Regulierte Branchen tragen asymmetrische Haftung bei erfolgreichem Login
Bereits eine einzige erfolgreiche Kontoübernahme, die Zugriff auf geschützte Gesundheitsdaten, kontrollierte nicht klassifizierte Informationen oder regulierte Finanzdaten ermöglicht, löst Meldepflichten aus und führt zu aufsichtsrechtlichen Konsequenzen – unabhängig davon, wie viele Daten tatsächlich abgerufen wurden.
3. Passwortbasierte Sicherheit ist bei 24 Milliarden Datensätzen gescheitert
Die Annahme, dass Passwörter Unternehmensdaten ausreichend schützen, ist nicht mehr haltbar. Multi-Faktor-Authentifizierung, attributbasierte Zugriffskontrolle und kontinuierliche Audit-Logs sind keine optionalen Ergänzungen – sie sind das Mindestmaß für Umgebungen mit sensiblen Daten.
4. Die Steuerungsebene für sicheren Datenaustausch ist die letzte wirksame Verteidigung nach Credential-Diebstahl
Angreifer, die sich mit gestohlenen Zugangsdaten erfolgreich authentifizieren, zielen auf File-Transfer-Portale, sichere E-Mail-Plattformen und Kollaborationsumgebungen, in denen sensible Daten tatsächlich liegen. Eine einheitliche Steuerungsebene – eine Policy Engine, ein Audit-Log, ein Sicherheitsniveau über alle Kanäle hinweg – begrenzt, was Angreifer erreichen können und was dokumentiert wird.
5. Credential-Stuffing-Risiko gehört in Compliance-Risikoregister und Berichte auf Vorstandsebene
Die Kombination aus dem 24-Milliarden-Datensatz, aktiven Infostealer-Kampagnen und der Durchsetzungsstrategie in Gesundheitswesen, Verteidigung und Finanzdienstleistungen bedeutet: Kontoübernahmen auf Basis gestohlener Zugangsdaten sind kein rein technisches Problem mehr – sie sind eine Governance-Priorität.
Sie vertrauen darauf, dass Ihr Unternehmen sicher ist. Aber können Sie es auch nachweisen?
Jetzt lesen
Die zwei Gruppen im 24-Milliarden-Datensatz
Sicherheitsverantwortliche, die große Zugangsdaten-Aggregate als „alte Nachrichten“ abtun, liegen für den Collection-Anteil nicht ganz falsch. Der Großteil der von Cybernews identifizierten 24 Milliarden Datensätze stammt aus zusammengetragenen Datenbanken früherer Datenschutzverletzungen, die seit Jahren in Untergrundmärkten kursieren. Viele dieser Zugangsdaten wurden bereits geändert. Viele der zugehörigen Systeme existieren nicht mehr. Sicherheitsteams, die konsequente Passworthygiene betreiben, Benachrichtigungsdienste überwachen und regelmäßige Passwortwechsel durchsetzen, haben einen Großteil dieses Risikos wahrscheinlich bereits adressiert.
Die Infostealer-basierten Datensätze sind jedoch ein grundsätzlich anderes Problem.
Infostealer sind eine Malware-Kategorie, die speziell darauf ausgelegt ist, Authentifizierungsdaten von infizierten Geräten zu extrahieren. Sie lesen gespeicherte Passwörter aus Browsern, extrahieren Session-Cookies, die eine Authentifizierung ohne Passwort ermöglichen, erfassen Tastatureingaben an Login-Feldern und greifen Zugangsdaten aus Desktop-Passwortmanagern ab. Das Ergebnis – ein strukturierter „Log“ mit Benutzernamen, Passwörtern und Session-Tokens, sortiert nach Website und Anwendung – wird innerhalb von Stunden oder Tagen nach der Infektion in Untergrundmärkten verkauft.
Für Unternehmensumgebungen sind die Folgen unmittelbar. Ein Mitarbeitender, dessen Gerät von einem Infostealer infiziert wurde, hat faktisch sein gesamtes Authentifizierungsprofil an einen Angreifer übergeben. Jede Unternehmensanwendung, jedes Filesharing-Portal, jede sichere E-Mail-Plattform, auf die zugegriffen wird – alles ist im Log enthalten. Das Unternehmen erhält davon erst Kenntnis, wenn entweder das Endgerät einen Endpoint-Detection-Alarm auslöst oder der Angreifer versucht, die gestohlenen Zugangsdaten zu nutzen.
Was die FortiBleed-Kampagne, die in derselben Woche bekannt wurde – bei der 86.000 bestätigte Zugangsdaten von FortiGate-Geräten in 194 Ländern aggregiert und veröffentlicht wurden – zu einem relevanten Beispiel macht, ist der Einsatz von künstlicher Intelligenz zur Zielidentifikation und automatisierten Passwortspray-Angriffen, um den Zugangsdatenbestand zu erweitern und zu validieren. Die Kombination aus großen Zugangsdaten-Aggregaten und KI-gestützter Validierung beschleunigt die Umwandlung gestohlener Zugangsdaten in tatsächlich funktionierende Zugänge. Unternehmen, die keine konsequente MFA über alle Unternehmensanwendungen hinweg durchsetzen, sind dieser Realität unzureichend gewappnet.
Warum regulierte Branchen anders rechnen müssen
Jedes Unternehmen ist vom Credential-Stuffing-Risiko betroffen. Doch Unternehmen, die HIPAA, CMMC, FedRAMP, ITAR oder vergleichbaren Vorgaben unterliegen, tragen ein qualitativ anderes Risikoprofil, weil die Konsequenz eines erfolgreichen Authentifizierungsversuchs vollständig davon abhängt, worauf das kompromittierte Konto Zugriff hat – und welche Meldepflichten dieser Zugriff auslöst.
Unter HIPAA-Compliance-Vorgaben löst jeder unautorisierte Zugriff auf geschützte Gesundheitsdaten Meldepflichten aus – unabhängig davon, ob der Angreifer Daten exfiltriert hat. Werden die Zugangsdaten eines Mitarbeitenden genutzt, um sich in ein Gesundheitssystem einzuloggen und PHI einzusehen – selbst nur beim Durchblättern –, gilt dies als meldepflichtiger Vorfall nach der HIPAA Breach Notification Rule. Die betroffene Organisation muss die betroffenen Personen, das Department of Health and Human Services und bei Vorfällen mit über 500 Betroffenen auch die wichtigsten Medien im betroffenen Bundesstaat informieren. Die Kosten für diese Benachrichtigung und die anschließende Untersuchung können die Investitionen in Firewalls oder Endpunktschutz um ein Vielfaches übersteigen.
Unter CMMC 2.0-Compliance-Vorgaben löst ein kompromittiertes Konto mit Zugriff auf kontrollierte nicht klassifizierte Informationen (CUI) eine Meldepflicht gemäß DFARS 252.204-7012 innerhalb von 72 Stunden nach Entdeckung aus. Zudem kann eine Neubeurteilung des CMMC-Zertifizierungsstatus des Unternehmens erforderlich werden. Rüstungsdienstleister, die durch Credential-Diebstahl einen CUI-Verlust erleiden, tragen nicht nur die Kosten für die Incident Response, sondern riskieren auch den Verlust oder die Suspendierung der CMMC-Zertifizierung – und damit die Teilnahme an DoD-Ausschreibungen.
FedRAMP-Compliance schafft vergleichbare Verpflichtungen für Cloud Service Provider und Bundesbehörden: Jeder unautorisierte Zugriff auf Bundesdaten erfordert sofortige Meldung an die zuständige Behörde und CISA.
Die Asymmetrie ist eindeutig: Ein kompromittiertes Konto in einem Einzelhandelsunternehmen kann zu Betrugsfällen führen. Dasselbe Konto bei einem Gesundheitsdienstleister, Rüstungsunternehmen oder einer Behörde löst zwingende Meldepflichten, potenzielle Aufsichtsmaßnahmen und Zertifizierungsfolgen aus, die weit über die eigentlichen Vorfallkosten hinausgehen. Unternehmen, die Credential-basierte Kontoübernahmen nicht explizit in ihre Risikoanalysen für jede relevante Vorgabe aufgenommen haben, arbeiten mit einer nicht erkannten Lücke.
Das Credential-Stuffing-Playbook gegen Content-Plattformen
Zu verstehen, wie Angreifer große Zugangsdatenbanken gegen Unternehmens-Content-Plattformen einsetzen, zeigt, warum die Verteidigungsarchitektur genauso wichtig ist wie die Authentifizierungsebene.
Credential-Stuffing-Angriffe folgen einem vorhersehbaren Muster. Ein Angreifer beschafft sich einen Zugangsdaten-Satz – aus einem Collection-Aggregat wie dem von Cybernews dokumentierten, aus gekauften Infostealer-Logs oder gezieltem Phishing – und beginnt mit automatisierten Tests auf Zielplattformen. Moderne Credential-Stuffing-Tools können zehntausende Zugangsdatenpaare pro Minute gegen eine Webanwendung testen, indem sie IP-Adressen und User Agents rotieren, um Rate-Limiting und Erkennung zu umgehen. Bei Erfolg wird der Zugriff protokolliert und für manuelle oder automatisierte Folgeaktionen vorgemerkt.
Der nächste Schritt richtet sich gezielt gegen Content-Plattformen. Ein Angreifer mit bestätigtem Zugang zu einem Unternehmenskonto exfiltriert nicht sofort alle Daten – das würde volumenbasierte Erkennung auslösen. Stattdessen ahmt er normales Nutzerverhalten nach, bleibt eventuell tagelang oder wochenlang inaktiv, bevor er gezielt nach wertvollen Dateien sucht. Er nutzt den Zugang möglicherweise, um auf weitere Konten zuzugreifen, indem er interne Verzeichnisse oder Kommunikationsplattformen aufruft, auf denen weitere Zugangsdaten oder Session-Tokens geteilt werden. Wenn er aktiv wird, sucht er gezielt nach Dokumenten – Verträgen, Finanzunterlagen, technischen Zeichnungen, Gesundheitsdaten, regulierten Informationen –, die sich direkt monetarisieren oder für Erpressung nutzen lassen. Datenklassifizierungsrichtlinien, die sensible Inhalte nach Schutzbedarf kennzeichnen und den Zugriff einschränken, sind ein direktes Gegenmittel gegen dieses Vorgehen.
Der Klue-Supply-Chain-Angriff, der im selben Zeitraum bekannt wurde – bei dem Angreifer kompromittierte OAuth-Tokens nutzten, um Salesforce-Umgebungen von LastPass, HackerOne, Huntress, Jamf, OneTrust, Recorded Future, Snyk, Tanium und anderen zu kompromittieren – folgte genau diesem Muster. Die Zugangsmethode war eine andere (OAuth-Tokens statt Passwörter), aber das Ziel war identisch: Authentifizierter Zugriff auf Dokumenten-Repositorien und Unternehmensdaten im großen Stil. Die Auswirkungen auf das Supply-Chain-Risikomanagement sind erheblich: Drittanbieterzugriffe auf Unternehmensumgebungen schaffen neue Angriffsvektoren, die interne Sicherheitsprogramme allein nicht schließen können.
Für Unternehmen, die sicheren Managed File Transfer, sichere E-Mail, SFTP oder kollaborative Content-Plattformen nutzen, ist die Credential-Stuffing-Bedrohung unmittelbar. Genau in diesen Anwendungen liegen sensible, regulierte Daten – und genau dort werden die Zugangsdaten von Mitarbeitenden in Browsern gespeichert und von Infostealern abgegriffen.
Warum die Passwort-Ebene bereits überwunden ist
Das Grundproblem, Passwörter als Sicherheitskontrolle zu betrachten, liegt in der Annahme, dass das Passwort geheim bleibt. Bei 24 Milliarden offengelegten Zugangsdaten – und einem aktiven Infostealer-Ökosystem, das kontinuierlich neue Daten abgreift – ist diese Annahme für große Belegschaften nicht mehr haltbar.
Passwortwechsel-Richtlinien helfen, schließen die Lücke aber nicht. Werden die Zugangsdaten eines Mitarbeitenden von einem Infostealer abgegriffen und gilt im Unternehmen eine 90-Tage-Wechselrichtlinie, hat der Angreifer ein 90-tägiges Zeitfenster, um die Daten frei zu nutzen. Wird der Wechsel erst durch eine Benachrichtigung ausgelöst, vergeht zwischen Diebstahl und Reaktion meist ein Zeitraum von Tagen bis Wochen. Infostealer sind darauf ausgelegt, genau in dieser Lücke zu agieren.
Das Abgreifen von Session-Tokens verschärft das Problem. Moderne Infostealer erfassen nicht nur Passwörter, sondern auch Browser-Sitzungscookies, die eine Authentifizierung ohne Passwort ermöglichen – und in manchen Konfigurationen sogar MFA umgehen, da das Cookie nach einer legitimen MFA-Anmeldung ausgestellt wurde. Session-Hijacking durch gestohlene Cookies ist eine dokumentierte Angriffsmethode, die keine Kenntnis des Passworts erfordert.
Architektonisch bedeutet das: Die Verteidigung muss auch dann funktionieren, wenn ein Credential-Diebstahl angenommen wird. Das ist der Ansatz von zero trust Sicherheitsprinzipien: Die Architektur verlässt sich nicht darauf, dass der authentifizierte Nutzer tatsächlich der ist, der er vorgibt zu sein, sondern setzt auf kontinuierliche Validierung, Verhaltensanalysen und richtlinienbasierte Zugriffskontrolle, die auch bei kompromittierten Zugangsdaten greifen.
Identity- und Access-Management auf Anwendungsebene – nicht nur am Netzwerk-Perimeter – entscheidet, ob ein kompromittiertes Credential zu einem Vorfall oder zu einem blockierten, protokollierten Versuch führt. Der Unterschied zwischen einem Unternehmen, das einen Credential-Stuffing-Angriff innerhalb von Stunden erkennt, und einem, das ihn erst nach Monaten bemerkt, liegt in der Tiefe und Konsistenz der Zugriffskontrollen und Überwachung, die über die Steuerungsebene für sicheren Datenaustausch hinweg greifen. Echtzeit-Transparenz durch ein CISO-Dashboard, das anomale Zugriffsmuster über alle Content-Kanäle hinweg sichtbar macht, macht aus Audit-Logging ein operatives Erkennungsinstrument statt eines reinen Forensik-Tools.
Verteidigung auf der Steuerungsebene aufbauen
Die regulatorischen Konsequenzen von Credential-basierten Kontoübernahmen – insbesondere in Gesundheitswesen, Verteidigung und Finanzdienstleistungen – erfordern eine spezifische Architektur: Kontrollen müssen dort greifen, wo sensible Daten tatsächlich bewegt werden, nicht nur am Netzwerk-Perimeter oder beim Identity Provider.
Perimeter-Kontrollen sind wertvoll, reichen für dieses Bedrohungsmodell aber nicht aus. Ein kompromittiertes Credential authentifiziert sich definitionsgemäß durch die Perimeter-Kontrollen. Der Angreifer präsentiert ein gültiges Token von einer IP-Adresse, die zum Standort des Nutzers passt, zu einer Tageszeit, die dem normalen Nutzungsverhalten entspricht. Perimeter-basierte Erkennung kann eine kompromittierte Sitzung ohne weiteren Kontext nicht zuverlässig von einer legitimen unterscheiden.
Was zero trust Architektur liefert, ist genau dieser zusätzliche Kontext. Durch attributbasierte Zugriffskontrolle (ABAC) auf der Steuerungsebene erzwingt die Architektur feingranulare Richtlinien basierend auf Datensensitivität, Nutzerrolle, Compliance-Status des Geräts und Verhaltenskontext – nicht nur darauf, ob ein gültiges Token vorgelegt wurde. Ein Nutzer mit kompromittiertem Credential kann sich zwar authentifizieren, aber wenn sein Verhalten vom Normalwert abweicht oder er versucht, Daten außerhalb seines Rollenprofils abzurufen, verhindert die ABAC-Richtlinie den Zugriff und löst einen Alarm aus.
Kontinuierliches Audit-Logging ist das Beweismittel, das diese Architektur Compliance-fähig macht. Wenn ein Regulator oder Kläger fragt: „Was hat das kompromittierte Konto wann abgerufen?“, muss die Antwort ein spezifischer, mit Zeitstempel versehener, unveränderlicher Nachweis sein – kein allgemeiner Hinweis darauf, dass Zugriffskontrollen existierten. Unternehmen, die diesen Nachweis nicht liefern können, stehen vor demselben Beweisproblem, das Aufsichtsbehörden in Durchsetzungsverfahren zunehmend identifizieren – wie im Fall der FTC gegen Illuminate Education: Risikobewusstsein ohne nachweisbare Kontrollen ist selbst ein Compliance-Verstoß.
DLP auf der Steuerungsebene bietet eine letzte Eindämmung: Richtlinien, die ausgehende Daten auf regulierte Typen – PHI, CUI, personenbezogene Daten, Finanzunterlagen – prüfen und Übertragungen außerhalb genehmigter Kanäle blockieren, quarantänisieren oder alarmieren. Selbst wenn ein kompromittiertes Konto sensible Daten abruft, können DLP-Richtlinien die Exfiltration verhindern. Prinzipien der Datenminimierung auf Steuerungsebenen reduzieren zusätzlich das Risiko, indem Konten nur Zugriff auf die Daten erhalten, die sie für ihre Rolle tatsächlich benötigen – nicht auf alle Daten, die technisch möglich wären.
Kiteworks fungiert als Steuerungsebene für sicheren Datenaustausch – mit ABAC, Ende-zu-Ende-Verschlüsselung, unveränderlichem Audit-Logging und DLP als einheitlicher Governance-Layer über alle Kanäle, über die sensible Daten fließen: E-Mail, Filesharing, SFTP, MFT, APIs und KI-Integrationen. Diese Architektur ermöglicht es regulierten Unternehmen, die Frage zu beantworten: „Wenn ein Credential kompromittiert wird und ein Angreifer sich erfolgreich authentifiziert, worauf kann er tatsächlich zugreifen, welche Kontrollen verhindern Exfiltration und welcher Nachweis existiert über die Vorgänge?“
Was Compliance-Teams jetzt tun müssen
Das 24-Milliarden-Datensatz-Aggregat ist ein sinnvoller Anlass für eine Diskussion, die Compliance-, Rechts- und Sicherheitsteams ohnehin führen sollten – unabhängig von einzelnen Vorfällen.
Erstens sollte die Überwachung von Credential-Exponierung als kontinuierliche Risikoanalyse verstanden werden, nicht als reaktive Antwort auf Vorfälle. Kommerzielle Benachrichtigungsdienste bieten nahezu in Echtzeit Hinweise, wenn Mitarbeitenden-Zugangsdaten in bekannten Datenbanken auftauchen. Diese Informationen sollten sofortigen Passwortwechsel und Account-Überprüfung auslösen – nicht erst beim nächsten geplanten Wechselzyklus.
Zweitens muss die Durchsetzung von MFA für jede Anwendung, die auf regulierte Daten zugreift, überprüft werden – nicht nur für den primären Identity Provider. Viele Unternehmen setzen MFA am Netzwerk-Perimeter konsequent um, aber nicht in allen nachgelagerten Anwendungen, die Mitarbeitende nutzen. File-Transfer-Portale, E-Mail-Plattformen und Dokumentenkollaborationsumgebungen sind häufige Lücken.
Drittens sollten HIPAA-Compliance-, CMMC 2.0-Compliance- und FedRAMP-Compliance-Programme die Credential-Stuffing-Bedrohung explizit in ihre Risikoanalysen aufnehmen. Die Standardfrage – „Welche Bedrohungen bestehen für unsere regulierten Daten?“ – sollte eine spezifische Analyse enthalten, was passiert, wenn Mitarbeitenden-Zugangsdaten kompromittiert werden, auf welche Daten diese Zugangsdaten Zugriff gewähren und ob die vorhandenen Zugriffskontrollen und Audit-Logs ausreichen, um den Vorfall zu erkennen und einzudämmen.
Schließlich muss die Event-Logging- und Monitoring-Infrastruktur in regulierten Umgebungen gezielt auf die Bedrohung authentifizierter, aber böswilliger Sitzungen überprüft werden. Das unterscheidet sich vom Monitoring fehlgeschlagener Login-Versuche. Es erfordert Verhaltensanalysen authentifizierter Sitzungen, um Zugriffsmuster zu erkennen, die vom normalen Nutzerverhalten abweichen – eine Fähigkeit, die auf der Steuerungsebene für sicheren Datenaustausch angesiedelt ist, nicht am Netzwerk-Perimeter. Unternehmen sollten zudem sicherstellen, dass ihr Incident-Response-Plan Credential-basierte Kontoübernahmen explizit abdeckt, mit dokumentierten Runbooks für die Meldepflichten der jeweiligen regulatorischen Vorgaben.
Das 24-Milliarden-Datensatz-Aggregat wird in wenigen Monaten von einem noch größeren abgelöst werden. Das Infostealer-Ökosystem, das die gefährlichsten Datensätze zu diesen Sammlungen beiträgt, wächst weiter. Die richtige Reaktion ist nicht Alarmismus wegen einzelner Vorfälle – sondern der Aufbau einer Architektur, die Credential-Kompromittierungen zu einem begrenzten Vorfall statt zu einer Datenpanne macht.
Erfahren Sie mehr darüber, wie Kiteworks das Risiko von Credential-basierten Kontoübernahmen in regulierten Umgebungen adressiert – vereinbaren Sie jetzt eine individuelle Demo.
Häufig gestellte Fragen
Eine Credential-„Collection“ ist ein zusammengestellter Datensatz aus Benutzernamen-Passwort-Paaren, die aus mehreren historischen Datenschutzverletzungen aggregiert wurden – meist Vorfälle, die Monate oder Jahre zurückliegen. Die Zugangsdaten in einer Collection wurden oft bereits geändert oder die zugehörigen Systeme stillgelegt. Infostealer-Logs sind qualitativ anders: Sie sind das Ergebnis von Malware, die aktiv auf infizierten Geräten läuft und Zugangsdaten in Echtzeit abgreift. Infostealer-Logs enthalten frisch abgegriffene Zugangsdaten, die mit hoher Wahrscheinlichkeit noch gültig sind. Für Sicherheitsteams, die Breach-Aggregate bewerten, steht der Collection-Anteil für historische Risiken, während der Infostealer-Anteil ein aktuelles operatives Risiko darstellt. Zero trust Sicherheitsprinzipien sind speziell für Umgebungen konzipiert, in denen die Gültigkeit von Zugangsdaten nicht angenommen werden kann, und bieten kontinuierliche Validierung, die sich nicht allein auf das Credential stützt. Unternehmen sollten infostealer-spezifische Szenarien in ihre Sicherheits-Risikomanagement-Frameworks aufnehmen, um Erkennungs- und Reaktionsfähigkeiten an die Geschwindigkeit dieser Bedrohung anzupassen.
Credential Stuffing ist eine automatisierte Angriffsmethode, bei der Benutzernamen-Passwort-Paare aus Breach-Aggregaten gegen Ziel-Webanwendungen getestet werden. Moderne Credential-Stuffing-Tools rotieren durch verteilte IP-Adressen und variieren ihre Anfragen, um Rate-Limiting oder IP-Blocking zu umgehen, wodurch volumenbasierte Erkennung unzuverlässig wird. Der Angriff ist erfolgreich, wenn ein gestohlenes Credential auf der Zielanwendung noch gültig ist – meist, weil der Nutzer Passwörter mehrfach verwendet oder das Credential seit dem ursprünglichen Vorfall nicht geändert wurde. Die Erkennung erfordert Verhaltensanalysen authentifizierter Sitzungen, nicht nur die Überwachung fehlgeschlagener Logins. Audit-Logs, die jeden Zugriff mit Geräte-, Standort- und Verhaltenskontext erfassen, sind unerlässlich, um kompromittierte Sitzungen im Nachhinein zu identifizieren. Werden diese Logs in ein SIEM mit Verhaltensanalytik eingespeist, erhalten Sicherheitsteams die Echtzeit-Benachrichtigungen, die nötig sind, um zu reagieren, bevor eine Credential-Stuffing-Sitzung zur Datenexfiltration führt.
MFA erhöht die Hürde für Credential-Stuffing-Angriffe erheblich und blockiert die meisten Versuche, die auf statische Benutzernamen-Passwort-Paare setzen. Dennoch ist MFA kein absoluter Schutz. Moderne Infostealer erfassen Browser-Session-Cookies, die nach einer legitimen MFA-Anmeldung ausgestellt wurden – so ist Session-Hijacking möglich, das die MFA-Anforderung komplett umgeht. Zudem lassen sich manche MFA-Implementierungen durch SIM-Swapping, Echtzeit-Phishing oder Social Engineering aushebeln. MFA ist eine essenzielle Kontrolle, sollte aber als eine Schicht einer Defense-in-Depth-Sicherheitsarchitektur betrachtet werden, nicht als alleinige Lösung. ABAC-Kontrollen auf Steuerungsebene bleiben auch bei kompromittierter Authentifizierung wirksam, indem sie richtlinienbasierte Einschränkungen für kompromittierte Sitzungen durchsetzen. Die Kombination von MFA mit Data-Governance-Richtlinien, die den Zugriff jeder Rolle auf notwendige Daten beschränken, begrenzt den Schaden, den ein umgangener MFA-Vorfall verursachen kann.
Die Pflichten hängen davon ab, auf welche regulierten Daten das kompromittierte Konto zugegriffen hat. Unter HIPAA-Compliance gilt jeder unautorisierte Zugriff auf geschützte Gesundheitsdaten (PHI) durch eine unautorisierte Person als vermutete Datenschutzverletzung, die Benachrichtigung der Betroffenen und des Department of Health and Human Services erfordert – es sei denn, die Organisation kann mit einer Vier-Faktoren-Risikoanalyse eine geringe Kompromittierungswahrscheinlichkeit nachweisen. Unter CMMC 2.0-Compliance löst unautorisierter Zugriff auf CUI eine 72-Stunden-Meldepflicht an das DoD gemäß DFARS 252.204-7012 aus. Unter FedRAMP ist bei unautorisiertem Zugriff auf Bundesdaten eine Meldung an die zuständige Behörde und CISA erforderlich. HIPAA-Compliance- und CMMC 2.0-Compliance-Programme sollten Credential-basierte Kontoübernahmen explizit in ihre Incident-Response-Pläne aufnehmen. Unternehmen, die der DSGVO unterliegen, haben bei personenbezogenen Daten eine parallele 72-Stunden-Meldepflicht an die zuständige Aufsichtsbehörde.
Die Reaktion sollte nach Risikoprofil der exponierten Zugangsdaten gestaffelt werden. Mitarbeitende mit Zugriff auf regulierte Daten – PHI, CUI, personenbezogene Daten, Finanzunterlagen – sollten bei Hinweisen aus Breach-Benachrichtigungsdiensten vorrangig einer sofortigen Credential-Rotation und Account-Überprüfung unterzogen werden. Nächste Priorität ist die Durchsetzung von MFA für jede Anwendung, mit der diese Mitarbeitenden auf regulierte Inhalte zugreifen – nicht nur für den primären Identity Provider. Mittelfristig muss überprüft werden, ob Zugriffskontrollen und Monitoring auf Content-Ebene – nicht nur am Netzwerk-Perimeter – ausreichen, um kompromittierte Sitzungen zu erkennen und einzudämmen, bevor es zur Datenexfiltration kommt. Für Unternehmen mit HIPAA- oder CMMC-Pflichten sollte diese Überprüfung als Teil der laufenden Risikoanalyse dokumentiert werden. Ein Third-Party-Risikomanagement-Review von Dienstleistern mit Zugriff auf regulierte Datenumgebungen sollte parallel laufen, da Infostealer-Infektionen auf Endpunkten von Drittanbietern dieselbe Credential-Exponierung verursachen wie Infektionen auf internen Endpunkten.
Weitere Ressourcen
- Blogbeitrag Zero Trust Architektur: Never Trust, Always Verify
- Video Microsoft GCC High: Nachteile, die Verteidigungsunternehmen zu intelligenteren Lösungen bewegen
- Blogbeitrag Wie Sie klassifizierte Daten sichern, sobald DSPM sie erkennt
- Blogbeitrag Vertrauen in Generative KI mit Zero Trust stärken
- Video Der ultimative Leitfaden für die sichere Speicherung sensibler Daten für IT-Führungskräfte