24 Milliarden Datensätze sind eine gute Zahl für schlechte Schlagzeilen. Groß genug für Rekordrhetorik, ungenau genug für Panik und praktisch genug, damit jeder noch schnell „größter Leak aller Zeiten“ darüber schreiben kann.
Der wichtigere Punkt ist aber nicht die Zahl. Einzelne Credential-Leaks sind bereits gefährlich genug. Sie erlauben Account-Übernahmen, VPN-Zugriffe, SaaS-Missbrauch, Passwort-Reuse-Angriffe und gezielte Folgeoperationen. Und sie hören nicht auf. Während ein alter Bestand ausgewertet wird, entstehen schon die nächsten: durch Infostealer, kompromittierte Integrationen, schwache Remote-Access-Systeme oder schlecht verwaltete Identitätsketten.
Der aktuelle 24-Milliarden-Fall ist deshalb vor allem wegen der zweiten Stufe interessant: Nach den derzeit sichtbaren Berichten lag das Material nicht einfach als Dump herum, sondern in einem offenen Elasticsearch-Bestand von rund acht Terabyte. Also in einer Form, die auf Suchen, Filtern, Korrelation und Wiederverwertung ausgelegt ist. Aus gefährlichem Rohmaterial wird damit ein durchsuchbarer Arbeitsbestand. Und dieser Arbeitsbestand war offenbar selbst nicht brauchbar abgesichert.
Das ist die eigentliche Geschichte. Nicht „schon wieder viele Passwörter“, sondern: Credential-Material wird laufend neu erzeugt, anschließend zusammengeführt und verwertbar gemacht – und in diesem öffentlich gewordenen Fall war ausgerechnet diese Aggregationsschicht offen genug, um gefunden zu werden.
Einzelne Leaks reichen schon
Man muss Aggregation nicht dramatisieren, um sie gefährlich zu finden. Schon ein einzelner brauchbarer Credential-Leak kann reichen.
Ein wiederverwendetes Passwort öffnet vielleicht ein Mailkonto. Ein lokaler VPN-Account öffnet vielleicht das interne Netz. Ein altes Integrationscredential öffnet vielleicht eine SaaS-Vertrauenskette. Ein Session-Token kann manchmal mehr wert sein als ein Passwort, weil er nicht erst erraten, eingegeben oder phishbar gemacht werden muss. Er ist bereits akzeptiertes Vertrauen.
Deshalb ist die übliche Reaktion auf solche Vorfälle oft zu klein. „Bitte Passwort ändern“ ist nicht falsch. Es ist nur häufig die kleinste Einheit von Schadensbegrenzung. Die eigentliche Frage lautet: Wo wurde aus einem Credential eine Beziehung? Zu welchem Dienst, welchem Gerät, welcher App, welchem Tenant, welchem Datenbestand, welchem Netzwerk?
Es kommt ständig neues Material nach
Der Klue/Salesforce-Vorfall zeigt diese Dynamik von der SaaS-Seite. Klue beschreibt öffentlich, dass ein Angreifer über ein kompromittiertes Legacy-Credential Zugriff auf einen Teil der Integrationsinfrastruktur bekam. Daraus wurden OAuth-Tokens erlangt, mit denen Klue an Drittplattformen wie Salesforce angebunden war. Anschließend wurden Daten aus verbundenen Kundenumgebungen abgerufen.
Das ist nach bisherigem Stand kein Salesforce-Hack im engen Sinn. Es ist auch kein glamouröser Zero-Day. Es ist Missbrauch bereits erteilten Vertrauens. Eine Anwendung durfte im Auftrag ihrer Kunden mit Salesforce sprechen. Als diese Integrationskette kompromittiert wurde, wurde aus einer produktiven Verbindung ein Datenabflusskanal.
FortiBleed zeigt eine andere Kante desselben Problems. Die Berichte dazu sprechen von zehntausenden offengelegten Fortinet-Zugangsdaten, darunter offenbar VPN- und lokale Admin-Credentials. Eine Firewall hält in einer ordentlich betriebenen Umgebung normalerweise nicht die halbe Unternehmensidentitätssammlung. Aber sie hält genau die Art von Zugang, die operativ weh tut: Fernzugang, Administration, Edge-Vertrauen. Wenn dort Credentials abfließen, ist das kein abstrakter Passwortfund, sondern potenziell ein direkter Einstiegspunkt.
Diese beiden Fälle erklären den offenen Elasticsearch-Bestand nicht. Sie sind keine Fortsetzung desselben Vorfalls. Es gibt nach derzeitiger Quellenlage auch keinen belastbaren Hinweis, dass Klue-Daten oder FortiBleed-Credentials Teil genau dieses 24-Milliarden-Bestands waren. Der Punkt ist schlichter und reicht völlig: Neues Zugangsmaterial entsteht laufend. Später kann es in Sammlungen, Suchsystemen und Folgeangriffen wieder auftauchen.
Aggregation ist der Multiplikator
Ein Leak ist ein Ereignis. Ein aggregierter, durchsuchbarer Bestand ist Infrastruktur.
Wenn die öffentlich genannten Eckdaten grob stimmen, ging es bei dem 24-Milliarden-Fall um eine offen erreichbare Elasticsearch-Instanz mit Datensätzen aus vielen Quellen: Stealer-Logs, Telegram-Sammlungen, ältere Breaches und weitere zusammengeführte Bestände. Der Dublettenanteil ist unklar. Das Alter der Datensätze ist unklar. Die Zahl sagt also nicht, wie viele eindeutige Menschen oder Accounts betroffen sind.
Aber die Form sagt etwas anderes. Acht Terabyte Elasticsearch baut man nicht, weil man einen besseren USB-Stick sucht. Dafür braucht es Storage, RAM, I/O, Ingest, Normalisierung und den Wunsch, Material nicht nur zu besitzen, sondern abfragbar zu halten.
Das macht Aggregation gefährlicher als den einzelnen Dump. Sie erlaubt andere Fragen:
- Welche Credentials gehören zu derselben Person?
- Welche Domains tauchen immer wieder auf?
- Welche Accounts haben geschäftliche Mailadressen?
- Welche Zugänge passen zu VPN, SaaS, Hosting, Developer-Plattformen oder Admin-Oberflächen?
- Welche alten Passwörter lassen sich gegen aktuelle Dienste probieren?
Das ist nicht mehr bloß Beute. Das ist Vorverarbeitung.
Der offene Suchindex war selbst der Fall
Gerade deshalb ist der offene Elasticsearch-Teil so lehrreich. Wer kompromittierte Zugangsdaten operativ nutzen will, würde sie idealerweise nicht als riesigen, schmutzigen, redundanten und offen erreichbaren Suchindex herumstehen lassen. Für Angriffe wären kleinere Teilmengen nützlicher: dedupliziert, priorisiert, nach Ziel, Dienst, Region, Wertigkeit oder Validierungsstatus sortiert. Schmaler, leiser, gebrauchsfertiger.
Der öffentlich gewordene Bestand wirkt eher wie eine Zwischenstufe: Rohmaterial sammeln, korrelieren, durchsuchen, auswerten. Nicht unbedingt die fertige Angriffskonsole, sondern die Werkbank davor.
Das macht ihn nicht harmloser. Es macht ihn interessanter.
Denn ausgerechnet diese Werkbank war offenbar selbst schlecht abgesichert. Jemand investiert mutmaßlich Aufwand, um riesige Mengen kompromittierter Identitätsdaten zusammenzuführen und abfragbar zu halten, und lässt die Umgebung dann offen genug stehen, dass andere sie finden.
Das ist lächerlich. Es ist aber leider nicht beruhigend.
Schlampig bedeutet nicht ungefährlich
Der Fehler wäre, aus der schlechten Absicherung des Aggregators Entwarnung abzuleiten. Das Gegenteil ist näher an der Wahrheit.
Solches Material muss nicht in perfekt gehärteter, professionell betriebener Infrastruktur liegen, um gefährlich zu sein. Mittelmäßige Betriebsdisziplin reicht, wenn das Material verwertbar genug ist. Ein offener Suchindex kann gleichzeitig peinlich für den Betreiber und nützlich für den nächsten Angreifer sein. Sicherheitsprobleme haben selten den Anstand, nur von kompetenten Leuten verursacht zu werden.
Das ist die unangenehme Verteidigungslektion: Nicht nur einzelne Zugangsdaten sind das Problem. Das Problem ist ihre spätere Verwertbarkeit. Solange Passwörter wiederverwendet werden, Fernzugänge schwach geschützt sind, OAuth-Scopes zu großzügig bleiben und alte Integrationszugänge weiterleben, bleibt Credential-Material auch nach Jahren noch nützlich.
Die Lehre ist nicht „Elasticsearch absichern“
Natürlich sollte ein solcher Bestand nicht offen erreichbar sein. Diese Erkenntnis ist nicht falsch, nur etwas dünn.
Die eigentliche Lehre liegt bei Identität und Vertrauen. Kompromittierte Identitätsdaten sind längst nicht mehr nur Beifang einzelner Vorfälle. Sie werden gesammelt, normalisiert, korreliert, weitergegeben und später in besser verwertbare Teilmengen überführt. Manchmal professionell. Manchmal schlampig. Beides reicht.
Wer sich bei Identitätsschutz noch immer vor allem auf Passwortwechsel nach Vorfällen, freundliche Awareness-Mails und die Hoffnung auf vernünftiges Nutzerverhalten verlässt, verteidigt ungefähr auf dem Niveau, auf dem andere Leute bereits Datenberge zusammenführen und durchsuchbar halten. Das schließt an dieselbe unangenehme Grundfrage an, die ich schon in Der gefährlichste Angriff ist oft schon eingeloggt beschrieben habe: Nicht nur das Passwort selbst ist das Problem, sondern der gesamte Vertrauensraum um verwertbare Identität.
Passkeys, phishing-resistente MFA, weniger Passwort-Wiederverwendung, stärkere Session-Kontrollen, engere OAuth-Scopes, regelmäßig geprüfte SaaS-Integrationen und konsequent gehärtete Remote-Access-Systeme sind deshalb kein hübsches Modernisierungszubehör. Sie sind die Antwort auf ein ziemlich schlichtes Problem: Credential-Leaks hören nicht auf. Aggregation macht sie skalierbarer. Und manchmal ist sogar die Infrastruktur, die sie verwertbar macht, selbst ein offenes Scheunentor.
Quellen und Einordnung
Als derzeit erkennbare Primärquelle für den 24-Milliarden-Fall erscheint:
Nachgelagerte Berichte mit ähnlicher Darstellung:
Für den Klue/Salesforce-Teil ist Klues eigenes Update die sauberste Primärquelle:
Die Zuordnung zu „Icarus“ und der breitere Kontext zu Salesforce-Datendiebstahl stammen aus Sekundärberichten, unter anderem von BleepingComputer. Diese Attribution sollte man nicht härter formulieren als die Quellenlage es hergibt.
Für FortiBleed stütze ich mich derzeit vor allem auf Berichte von BleepingComputer sowie auf die technische Einordnung von Kevin Beaumont bei DoublePulsar. Der gemeinsame belastbare Nenner ist hier nicht eine Verbindung zum offenen Elasticsearch-Bestand, sondern die Aussage, dass separat Fortinet-Credentials in großem Umfang offengelegt wurden.
Falls sich später belastbare Zusatzquellen oder Widersprüche auftun, gehört genau das nachgepflegt. Im Moment ist die sauberste Einordnung: einzelne Credential-Leaks sind bereits gefährlich, es entstehen ständig neue, Aggregation macht sie deutlich verwertbarer – und der aktuelle öffentlich gewordene Aggregator war offenbar selbst schlecht abgesichert. Klue, FortiBleed und der offene Elasticsearch-Bestand sind nach derzeitiger Quellenlage keine direkt verbundenen Fälle. Sie zeigen unterschiedliche Stationen desselben Problems: kompromittierte Identität entsteht, zirkuliert, wird gesammelt, durchsuchbar gemacht und wieder benutzt.