Auf dem Untergrundforum DarkForums tauchte kuerzlich ein aufsehenerregender Beitrag auf: Ein Nutzer mit dem Alias CamelliaBtw behauptete, den Messenger Max ueber eine 0-Day-Schwachstelle kompromittiert und dabei 142 GB Nutzerdaten mit rund 15,4 Millionen Datensaetzen erbeutet zu haben. Nur wenig spaeter widersprach das Max-Team entschieden, legte technische Gegenbelege vor – und der angebliche Angreifer raeumte ein, dass es weder eine Luecke noch einen Hack gegeben hatte. Der Vorfall zeigt exemplarisch, wie gefaehrlich Fake-Datenlecks fuer Nutzer und Unternehmen sein koennen.
Der angebliche Hack: 0-Day-Exploit und massive Datenexfiltration
Im DarkForums-Posting schilderte CamelliaBtw ein scheinbar plausibles Angriffsszenario. Er wolle bereits waehrend der Betaphase Anfang 2025 eine unbekannte 0-Day-Schwachstelle in der Media-Engine von Max entdeckt haben. Unter einer 0-Day-Luecke versteht man eine Sicherheitsluecke, fuer die es noch keinen Patch gibt und die dem Hersteller offiziell nicht bekannt ist.
Demnach soll ein manipulierter Stickerpack mit boesartigen Metadaten als Transportweg gedient haben. Diese Technik erinnert an bekannte Angriffsformen, bei denen Schadcode in Metadaten von Bildern oder Dokumenten versteckt und bei der Verarbeitung durch eine verwundbare Anwendung ausgefuehrt wird. Laut Posting habe dies einen persistenten Zugriff auf die Infrastruktur ermoeglicht, um ueber laengere Zeit unbemerkt Daten abzuziehen.
Der angebliche Angreifer gab an, zunaechst ueber ein Bug-Bounty-Programm Kontakt mit dem Max-Team gesucht zu haben. Bug Bounty bezeichnet Praemienprogramme, bei denen Hersteller Sicherheitsforscher fuer gemeldete Schwachstellen belohnen. Nachdem es angeblich keine Reaktion gegeben habe, habe er sich entschlossen, erste 5 GB der vermeintlichen Datenbank per Torrent zu veroefentlichen und praesentierte Datenfragmente, die er einer Person des oeffentlichen Lebens zuschrieb.
Technische Widersprueche: Warum das Max-Team von einem Fake spricht
Die Entwickler von Max bezeichneten die Meldung gegenueber Medien als „reinen Fake“ und lieferten mehrere konkrete technische Argumente, die die Glaubwuerdigkeit des Leaks untergraben.
Erstens betonte das Unternehmen, dass keine auslaendischen Cloud-Dienste wie Amazon Web Services genutzt wuerden und saemtliche Daten auf Servern in Russland gespeichert seien. Die vom angeblichen Angreifer beschriebene Infrastruktur passe daher nicht zur Realitaet.
Zweitens verwies das Sicherheitsteam darauf, dass Max nicht den Passwort-Hashing-Algorithmus bcrypt verwende, obwohl in den vorgelegten Datensaetzen genau dieses Format auftauchte. Hashing ist ein Verfahren, mit dem Passwoerter in kryptographische „Fingerabdruecke“ umgewandelt werden, anstatt sie im Klartext zu speichern. Das verwendete Hash-Format ist haeufig ein verlaesslicher Indikator dafuer, aus welchem System eine Leckage stammt – hier stimmte es schlicht nicht ueberein.
Drittens ergab die Analyse der Server-Logs keine Hinweise auf eine grossvolumige Datenexfiltration von 142 GB oder auf andere typische Anzeichen einer Kompromittierung. Ebenso wurde kein einziger Bug-Bounty-Report von einem Nutzer mit dem Nicknamen CamelliaBtw registriert.
Schliesslich passte auch die Struktur der angeblich geleakten Daten nicht zum tatsaechlichen Datenmodell von Max: Die Tabellen enthielten Felder wie Standort, Geburtsdatum, E-Mail, Steuer- und Sozialversicherungsnummern sowie „Account-Level“ und bestimmte Username-Formate. Laut Max werden solche Kategorien gar nicht gespeichert, und es existiert keine derartige Einstufung von Benutzerkonten. Die naheliegende Schlussfolgerung: Die Daten stammen aus einer anderen Quelle oder sind ganz oder teilweise frei erfunden.
Nach der Veroeffentlichung dieser Gegenargumente lenkte CamelliaBtw ein und bestaetigte, dass es weder Schwachstelle noch Hack gegeben habe. Der Beitrag sei bewusst falsch gewesen; er habe nicht erwartet, dass sich die Meldung in Telegram-Kanaelen derart schnell verbreiten wuerde.
Warum Fake-Datenlecks zum Risiko-Trend werden
Der Fall Max steht fuer einen deutlichen Trend: gefalschte Datenlecks und pseudo-Hacks etablieren sich als Werkzeug fuer Informationskrieg, Erpressung und Reichweitenjagd. Untergrundforen wie DarkForums oder fruehere Plattformen wie BreachForums dienen als Buehne, weil dort eine Zielgruppe aktiv ist, die an spektakulaere Leaks gewoehnt ist.
Die Motive reichen von Reputationsschaedigung ueber den Versuch, „exklusive“ Zugriffe zu verkaufen, bis hin zu Erpressung. In der Praxis kommt es vor, dass Angreifer zuerst ein angebliches Datenleck verkuenden, um dann das betroffene Unternehmen unter Zeitdruck zu setzen – in der Hoffnung, dass eine schnelle, aber unpruefbare Zahlung geleistet wird. Branchenberichte wie der Verizon Data Breach Investigations Report oder die ENISA Threat Landscape zeigen, dass Social Engineering und psychologischer Druck eine zunehmend zentrale Rolle in Cyberangriffen spielen.
Konkrete Risiken fuer Nutzer: Phishing im Windschatten von Leaks
Auch wenn sich ein Datenleck als Fake entpuppt, bleiben fuer Endnutzer reale Risiken. Cyberkriminelle nutzen die Aufmerksamkeit rund um angebliche Hacks, um Phishing-Kampagnen aufzusetzen – etwa E-Mails oder Messenger-Nachrichten, die sich als „Sicherheitsbenachrichtigung“ des betroffenen Dienstes tarnen. Nutzer werden aufgefordert, „dringend“ ihr Passwort zu aendern oder ihre Identitaet zu bestaetigen. Die bereitgestellten Links fuehren jedoch zu gefaelschten Login-Seiten, ueber die Zugangsdaten tatsaechlich gestohlen werden.
Zugleich erodieren haeufige Fake-Meldungen das Vertrauen in digitale Dienste und erschweren die Arbeit von Sicherheitsteams: Wenn staendig vermeintliche Mega-Leaks kursieren, wird es fuer Laien schwieriger, echte Sicherheitsvorfaelle von reinen Informationsmanipulationen zu unterscheiden.
Wie sich Nutzer und Unternehmen gegen Fake-Leaks schuetzen koennen
Um auf Meldungen ueber Datenlecks angemessen zu reagieren, ist ein klarer Pruefprozess entscheidend – sowohl fuer Unternehmen als auch fuer Privatpersonen.
1. Offizielle Kanaele zuerst pruefen. Bei Berichten ueber ein moegliches Datenleck sollten immer zunaechst die offiziellen Informationskanaele des Anbieters konsultiert werden: Website, verifizierte Social-Media-Auftritte, Statusseiten oder technische Blogs. Seriöse Dienste kommunizieren bestaetigte Sicherheitsvorfaelle in der Regel zeitnah.
2. Technische Details kritisch hinterfragen. Struktur und Inhalt angeblich geleakter Datensaetze sind ein wichtiger Indikator. Passen die Felder zu den Daten, die der Dienst tatsaechlich erhebt? Stimmen verwendete Technologien (z. B. Hashing-Algorithmen) mit oeffentlich dokumentierten Praktiken des Anbieters ueberein? Auffaellige Diskrepanzen sprechen fuer ein Fake-Datenleck.
3. Branchenweite Indikatoren beachten. Grosse, echte Datenlecks hinterlassen Spuren: Analyseberichte von Sicherheitsunternehmen, Meldungen nationaler CERTs, veröffentlichte Indicators of Compromise (IOC). Bleibt eine angeblich massenhafte Kompromittierung ohne jede externe technische Einordnung, ist Skepsis angebracht.
4. Vorsicht bei „Sicherheitswarnungen“ aus Drittquellen. Links in Chats, inoffiziellen Kanaelen oder fragwuerdigen Newslettern sollten grundsaetzlich misstrauisch betrachtet werden – selbst wenn sie sich auf ein reales oder vermeintliches Datenleck beziehen. Wer sein Passwort aendern moechte, sollte sich immer direkt ueber die offizielle Website oder App einloggen, Zwei-Faktor-Authentifizierung aktivieren und Updates regelmaessig einspielen.
Der Fall des gefaelschten Datenlecks beim Messenger Max fuehrt vor Augen, wie wichtig eine kritische und informierte Reaktion auf Sicherheitsmeldungen ist. Nutzer schuetzen sich am wirksamsten durch digitale Hygiene: eindeutige, starke Passwoerter, konsequente Nutzung von Zwei-Faktor-Authentifizierung, regelmaessige Updates und eine gesunde Portion Skepsis gegenueber Sicherheitswarnungen aus Drittquellen. Unternehmen sollten ihrerseits in transparente Kommunikation, leistungsfaehiges Monitoring und eingespielte Incident-Response-Prozesse investieren. Je reifer dieses Oekosystem wird, desto schwerer haben es sowohl echte Angreifer als auch Trittbrettfahrer, Angst vor Datenlecks fuer ihre Zwecke zu instrumentalisieren.
