Im Darknet werden eine Vielzahl an illegalen Waren gehandelt. Unter anderem finden sich in Datenmärkten verschiedene Klassen an Daten. Darunter ebenfalls Passwörter, die aus Leaks oder Breaches stammen. Diese geleakten Passwörter sind von hoher Wichtigkeit für die Cybersecurity-Industrie. Einerseits sollten die betroffenen Benutzer über die Gefahr ihrer öffentlich gewordenen Passwörter informiert werden. Andererseits können aus Auswertungen dieser Passwörter Rückschlüsse auf das Verhalten und die Sicherheit gezogen werden, so wie wir dies in einem vorangehenden Beitrag diskutiert haben.

Dieser Artikel bespricht die Sammlung und Auswertung von Passwörtern, um Analysen umsetzen zu können. Hierzu muss sich verschiedenen Herausforderungen gestellt werden. Die Leaks müssen zuerst gefunden, gesammelt, normalisiert und geprüft werden. Erst dann können sie effizient in eine Datenbank, die zuvor designt und optimiert werden muss, importiert werden. Dadurch werden zum Schluss entsprechende Abfragen und Auswertungen möglich, die sich sowohl im defensiven als auch im offensiven Bereich einsetzen lassen.

Passwort-Leaks finden und sammeln

Die Auswertung von Passwort-Leaks beginnt mit der Sammlung dieser. Man muss also in den Besitz der geleakten Passwort-Daten kommen. Dies geschieht üblicherweise auf den jeweiligen Datenmärkten. Auf diesen werden verschiedene Daten, darunter auch Passwort-Leaks, gehandelt. Es gibt ebenso Marktplätze, die ausschliesslich solche Passwort-Leaks handeln. Die Transaktionen können in den Märkten selber oder auf anderen Plattformen, in den letzten Jahren hat sich zum Beispiel Telegram etabliert, durchgeführt werden.

Dabei wird zwischen zwei Arten von Märkten unterschieden:

• Tauschhandel: Wer neue Daten haben möchte, muss diese ebenso selber anbieten. Dies geschieht entweder im direkten Kontakt zwischen den Interessenten (innerhalb eines Foren-Threads oder des Austauschs mittels Private Messages) oder im Rahmen eines Punktesystems. Bei letztgenannten können oftmals sogenannte Credits – auch als Reputation oder Karmapunkte bezeichnet – gesammelt werden. Durch das Anbieten von Daten werden diese zusammengetragen, so dass sie in einem späteren Schritt für den Erwerb neuer Daten eingesetzt werden können. Dadurch wird eine virtuelle Währung auf dem Marktplatz geschaffen. Deren Gegenwert sind in erster Linie die Daten. Manche Märkte erlauben den Kauf von Credits durch Echtgeld, meist in Tranchen (z.B. USD 100 haben einen Gegenwert von 10 Credits). Auf anderen Märkten können kommerzielle Abonnemente abgeschlossen werden, die im Rahmen des Einkaufs für eine bestimmte Zeit den direkten oder mindestens erleichterten Zugriff auf Daten ermöglichen können.
• Kauf/Verkauf: Bei rein kommerziellen Märkten diktiert eine Währung den Verkauf und Kauf von Daten. Wer Daten verkauft, verlangt dafür Geld, das der Käufer zu entrichten hat. Interessierte Käufer können aber auch Ausschreibungen machen, um willige Verkäufer finden zu können. Als Währung werden traditionell Kryptowährungen bevorzugt, da die ein gewisses Mass an Anonymität der Geschäftspartner versprechen. In manchen Bereichen werden aber auch harte Währungen (z.B. USD) und die Abwicklung über Zwischenmänner, sogenannte Money Mules bzw. Smurfer, möglich.

Interessenten kennzeichnen ihre Posts manchmal im Betreff, um ihre Absicht deutlich zu machen:

• WTB: Want to Buy (kaufen)
• WTS: Want to Sell (verkaufen)
• WTT: Want to Trade (tauschen)

Gerade dort wo topaktuelle und hochbrisante Daten gehandelt werden, ist der Zugang oft erschwert. Meist werden Einladungen (engl. invites) vorausgesetzt. Eine Person, die schon im Markt akzeptiert ist, lädt eine neue Person ein. Dabei bürgt der bestehende Nutzer für den neuen Nutzer. Falls letztgenannter Probleme macht, wird auch erstgenannter seinen Status verlieren.

Einmal infiltrierte Märkte werden durch uns regelmässig nach neuen bzw. spannenden Leaks durchsucht. Hierzu kommen unter anderem auch Bots zum Einsatz, die dank Texterkennung spannende Angebote und Dialoge als solche erkennen und melden können. Sobald diese ausfindig gemacht wurden, werden sie für eine spätere Verarbeitung heruntergeladen und abgelegt.

Ältere Leaks, die schon mehrfach verkauft und getauscht wurden, werden irgendwann kostenfrei einem breiteren Publikum zugänglich gemacht. Dies kann ebenso in halböffentlichen Foren, auf File-Sharing-Seiten oder Peer-to-Peer-Netzen (z.B. Torrent) geschehen.

Leaks normalisieren und prüfen

Eine enorme Herausforderung besteht im Normalisieren der Leaks. Die Daten müssen geprüft und in ein einheitliches Format gebracht werden, um in einem nächsten Schritt den Import möglichst effizient und reibungslos umsetzen können.

Leak-Daten kommen in verschiedenen Dateiformaten daher. In vereinzelten Fällen fand eine vollumfängliche Kompromittierung einer Organisation statt, so dass verschiedene Dateien unterschiedlicher Formate gegeben sind. Dies können Emails oder Office-Dokumente sein. Manchmal werden ganze DB-Dumps angeboten, die üblicherweise als SQL-Export, natürlich mit einzigartigen Tabellen und Spalten, bereitstehen. In beiden Fällen werden individuelle Parser zur Normalisierung erforderlich. Dieses können teilweise hochgradig aufwendig ausfallen, um mit den unstruktierten Datenformaten umgehen zu können.

Im Idealfall, und das ist im Passworthandel stets bevorzugt, werden sogenannte Combolisten angeboten. Hierbei handelt es sich im weitesten Sinn um eine CSV-Datei. Pro Zeile wird ein Datensatz abgelegt. Dieser besteht aus einem Datenpaar, das meist aus zwei Datenteilen besteht. Typische Beispiele:

Mailadresse ↔ Passwort

Benutzername ↔ Passwort

Die Datenteile werden durch ein Trennzeichen voneinander getrennt. Typischerweise kommt ein Doppelpunkt : zum Einsatz und manchmal wird auf einen Strichpunkt ; zurückgegriffen. Nur in seltenen Fällen werden andere Trennzeichen (zum Beispiel \t als Tabulator) genutzt. Es passiert immer wieder, dass Trennzeichen mitten in Leaks ändern. Vor allem dann, wenn es sich um Kompilationen, diese sind bei Combolisten nicht unüblich, handelt. Diese zu erkennen und zu korrigieren kann eine sehr mühsame Aufgabe darstellen.

Es gilt ebenfalls zwischen Leaks zu unterscheiden, die die Begriffe NOHASH und HASH nutzen. Bei NOHASH handelt es sich um Passwörter, die im Klartext gegeben sind. Entweder sind diese schon so im Original-Leak enthalten gewesen oder wurden mittels Passwort-Cracking entschlüsselt. Bei HASH werden keine Passwörter im Klartext sondern Password-Hashes angeboten. Diese müssen zuerst selber geknackt werden. In vereinzelten Fällen wird NOHASH+HASH angezeigt, wobei beide Varianten in einem Leak enthalten sind.

In jedem Fall muss eine sorgfältige Prüfung und etwaige Normalisierung stattfinden, denn auch diese Daten wurden vorgängig normalisiert. Cyberkriminelle sind nicht immer um Perfektion bemüht, weshalb deren Aufbereitung nicht selten fehlerhaft ist. Dies kann im späteren Schritt des Imports zu Problemen führen, indem falsche Daten importiert oder bestehende Datensätze übersprungen werden (da falsch formatiert). Zum Beispiel weisen Combolisten zwischendurch doppelte at-Zeichen bei Mailadressen auf (wahrscheinlich wegen fehlerhafter Concatenation).

Als erstes ist es wichtig herauszufinden, wie die Datei strukturiert ist: Welche Datenpaare werden eingesetzt und wie sind diese voneinander getrennt. Mit head -n 2 *.txt | grep -v "@" kann unkompliziert geprüft werden, ob in der zweiten Zeile einer Datei ein at-Zeichen @ vorkommt. Dadurch können Leaks mit Benutzernamen von denen mit Mailadressen unterschieden werden.

Eine genaue Prüfung, ob überall Mailadressen eingesetzt werden, ist durch grep -v '.\{1,50\}@.\{3,50\}:.\{0,50\}' *.txt möglich. Hier werden alle Zeilen durchsucht und die potentiellen Mailadressen auf ihre syntaktische Korrektheit hin analysiert. In vielen Leaks kommen jedoch syntaktisch inkorrekte Mailadressen zum Einsatz. Zum Beispiel, weil jemand statt foo.bar@example.com nur foo.bar@example.co (ohne endendes m) eingegeben hat. Es stellt sich somit die Frage, ob diese Datensätze (die gesamte Zeile) ignoriert werden will, ob man sie in ihrem vermeintlich kaputten Format dennoch abspeichern will, ob sie automatisch korrigiert werden soll oder ob nur der korrekte Teil des Datenpaars (in diesem Fall das Passwort) importiert werden darf.

Im Idealfall ist eine intelligente Kombination dieser Ansätze umzusetzen. Als erstes gilt es fehlerhafte Strukturen zu korrigieren. Dies kann sehr effizient mit klassischen Tools wie sed und awk stattfinden. Falls dies nicht erforderlich wird oder ein Minimum an Korrektheit gegeben ist, wird der defekte Datenteil importiert. Andernfalls wird nur der korrekte Teil des Datenpaars berücksichtigt (z.B. Passwort) und der inkorrekte Teil (z.B. Mailadresse) verworfen.

Eine unliebsame Schwierigkeit besteht darin, einmal fehlerhafte importierte Daten nachträglich korrigieren oder entfernen zu können. Die Relationalität der Datenbank erschwert Eingriffe. Und die enorme Datenmenge, die über längere Zeit angehäuft werden kann, macht Anpassungen sehr zeitaufwendig.

Datenmodell erstellen und optimieren

Das Ziel der Datensammlung ist die Ablegbarkeit, Analysierbarkeit und Durchsuchbarkeit einer Datenbank. Zu diesem Zweck müssen die Rohdaten der Leaks in eine Datenbank importiert werden. Bevor dies getan werden kann, muss ein Datenmodell erstellt werden. Dieses gibt vor, welche Daten in welcher Form abgelegt werden.

Bei Combolisten, mit denen bevorzugt gearbeitet wird, handelt es sich um zweidimensionale Datenstrukturen. Diese Tabellen-Dateien könnten direkt als Pseudo-Datenbank herhalten. Zusammengestellte Combolisten werden abgelegt und können durch klassische Tools wie grep durchsucht werden. Selbst bei einem grossen Leak wie ANTIPUBLIC #1 mit seinen fast 2.8 Milliarden Zeilen ist das möglich. Der grosse Vorteil dieses Quick-and-Dirty Ansatzes ist, dass das mühsame Importieren in eine echte Datenbank wegfällt.

Dafür werden Nachteile, die bei der Anhäufung weiterer Daten zunehmen, eingeführt. Daten werden mit hoher Redundanz abgelegt werden. Obschon Speicherplatz in den letzten Jahren immer günstiger wurde, ist dieser Effekt nicht zu unterschätzen. Es ist nicht unüblich, dass Datensätze in mehreren Leaks enthalten sind. Entweder, weil sie effektiv in den unterschiedlichen Quellen vorgekommen sind. Oder weil sie als Teil zusammengeführter Combolisten nicht gefiltert wurden. Neben der Verschwendung von Speicherplatz wird mit jeglicher Zunahme des Datenbestand dessen Auswertung und Durchsuchen aufwendiger. Abfragen können immer länger dauern und so die Praktikabilität mindern.

Das Ziel sollte sein, Redundanzen möglichst verhindern und normale Abfragen für einzelne Datensätzen innert weniger Sekunden zu ermöglichen. Hierzu bietet sich eine relationale Datenbank an. In dieser werden die Daten ansich in einzelnen Tabellen, aber auch die Relationen zueinander in Zwischentabellen abgelegt.

Nachfolgende Grafik listet die Tabellen, wie sie sich für das Zusammentragen von Mailadressen und Passwörtern anbieten. Dabei sind die relativen Anzahl Zeilen und die Grösse des Speicherplatzes in MByte angegeben. Die in Klammern angegebenen Werte zeigen an, wieviele Indizes auf einer Tabelle angewendet werden.

Domains in tbl_domain und Passwörter in tbl_password werden separat gespeichert, wodurch Redundanzen verhindert werden können. Die Assoziationen von Passwörtern zu Mailadressen sind in tbl_mail_password vorgesehen. Die Verknüpfung zu den Quellen in tbl_source findet separat mit tbl_source_mail und tbl_source_password statt. Mit diesem Ansatz wird eine Gratwanderung zwischen Einfachheit, Effizienz und Relationalität eingeschlagen. Dadurch werden weniger Redundanzen und eine bessere Performance erreicht.

Ein besonderes Augenmerkt sollte auf das Erstellen der Index gelegt werden. Diese sollten möglichst klein (kurz) sein, um die Speicherbelastung gering zu halten. Zeitgleich sollen sie aber auch effizient genug sein, um langwierige Queries und eine hohe CPU-Auslastung zu vermeiden. Vor allem Multi-Column-Indizes sollten optimiert werden. Bei diesen gilt es sich mit der Kardinalität der einzelnen Spalten und der daraus resultierenden Priorisierung auseinanderzusetzen. Die Index-Anforderungen können sich über Zeit ändern. Nach mindestens 1 Millionen importierten Datensätzen sollte geprüft werden, ob die Index-Definitionen noch immer den aktuellen Bedürfnissen entsprechen. Dabei gilt es zu bedenken, dass das Löschen und Neugenerieren der Indices kann bei zunehmender Anszahl Datensätze sehr zeitintensiv werden (pro Tabelle mehrere Stunden).

Daten in Datenbank importieren

Nachdem die Leaks gesammelt, normalisiert und die Datenbank vorbereitet wurde, können diese importiert werden. Bei einem Import werden die Rohdaten validiert, umgewandelt und in der Datenbank abgelegt. Dadurch können in einem späteren Schritt entsprechende Auswertungen und Abfragen möglich werden.

Die Combolisten werden von einem Skript eingelesen und Zeile für Zeile, also jeder Datensatz separat, verarbeitet. Der Delimiter muss bekannt sein oder identifiziert werden können, so dass ein Split der Elemente stattfinden kann. Diese sind dann entsprechend in den jeweiligen Tabellen zu speichern. Ebenfalls muss in den Zwischentabellen die Beziehungen zwischen den Elementen umgesetzt werden.

Hierbei kann eine zusätzliche Validierung erfolgen, um zum Beispiel Fehler beim Validieren und Parsen der Rohdaten zu erkennen und darauf zu reagieren. Es ist vom Paradigma abhängig, ob und in welcher Phase (Normalisierun oder Import) die entsprechenden Massnahmen ergriffen werden sollen.

Einer der Gründe, warum eine relationale Datenbank bevorzugt werden soll, ist der effiziente Umgang mit Duplikaten. Der Einfachheit halber kann zum Beispiel in tbl_domain auf die Spalte name die Definition UNIQUE erfolgen. Dadurch wird verhindert, dass die gleiche Domain zwei Mal in der Tabelle abgelegt wird. Falls ein Duplikat angelegt werden will, wird dieses INSERT verworfen.

Hierbei wird zwar die Aufgabe der Duplikaterkennung effizient durch die Datenbank durchgeführt. Gleichzeitig wird aber ein vollumfänglicher Index auf das Feld, das mit UNIQUE versehen wurde, angelegt. Bei der anfallenden Datenmenge kann dies zu einem extremen Index führen. Dieser kann so gross werden, dass seine Verarbeitung (z.B. im RAM) nicht mehr oder nur noch verlangsamt möglich ist.

Aus diesem Grund ist angeraten, dass das Import-Skript für den Umgang mit Duplikaten zuständig ist. Als erstes sollte es mit einer SELECT Abfrage prüfen, ob das vermeintlich neue Datenfragment schon in der entsprechenden Tabelle vorhanden ist. Falls dies nicht der Fall ist, wird es mit einem INSERT hinzugeführt. Falls das Datenfragment hingegen schon vorhanden ist, wird die ID als solche erkannt und für das Erstellen der Beziehung verwendet. Auch dort wird eine Duplikaterkennung dieser Art stattfinden. Da die gleichen Datenfragmente in verschiedenen Leaks vorkommen können, ist es nicht unüblich, dass nur das Datenfragment selber schon vorhanden ist, die neue Beziehung zum Leak aber noch nicht.

Das Erkennen und Verwerfen von Duplikaten führt dazu, dass immer weniger neue Datenfragmente eingefügt werden müssen. Dies fördert die Geschwindigkeit der Imports. Zudem nimmt mit der Zeit die Chance zu, dass auch das Aufblähen der Datenbank dank der Duplikaterkennung verhindert werden kann.

Erfahrungsgemäss kann ein solcher Import nicht ohne weiteres von der Mehrkern-Architektur moderner CPUs Gebrauch machen. Die Auslastung wird mit wenigen Prozent des Gesamtsystems sehr gering ausfallen und bei einem einzelnen Thread nur mit moderater Performance aufwarten können. Aus diesem Grund sollte ein Multi-Threading Import angestrebt werden. Dabei lohnt sich die Anzahl der Threads auf 90% der Anzahl der CPU-Cores zu erhöhen. Das System wird dann jeweils den Grossteil der CPU-Auslastung eines Threads pro Kern anwenden. Dadurch kann ein Vielfaches der Geschwindigkeit erreicht werden.

Es lohnt sich die Einstellungen für Webserver, PHP und Datenbank zu optimieren. Sämtliche Einstellungen zu Verbindungen, Speicher und Index-Verhalten sind zu berücksichtigen. Da eine Vielzahl an Datenbank-Anweisungen innert kürzester Zeit erfolgen, können minimal wirkende Optimierungen über längere Zeit einen enormen Einfluss haben.

Auf einem HP DL380 G9 mit zwei E5-2680v3, 256 GB RAM und RAID5 mit SSD können nach Optimierungen bis zu 300’000 Datensätze pro Minute verarbeitet werden. Das System wartet mit 48 Kernen auf. Diese erlauben den Import von bis zu 432 Millionen Datensätze pro Tag. Eine Geschwindigkeit dieser Grössenordnung anzustreben ist zu empfehlen, um mit der rasanten Anzahl neuer Veröffentlichung von Leaks und Combolisten mithalten zu können.

In dem Moment, in dem die CPU-Auslastung die Marke von 90% überschreitet, sollte die Effizienz der Indizes nochmals geprüft werden. Falls an diesen keine weiteren Optimierungen mehr möglich sind, ist das Limit des Systems erreicht.

Daten suchen und auswerten

Sind die Daten einmal in der Datenbank eingetragen, können diese abgefragt werden. Um maximalen Komfort zu erreichen, lohnt sich die Entwicklung eines Webfrontends. Auf diesem können über ein Formular entsprechende Datensätze abgefragt werden. Dabei können sowohl geleakte Login-Daten als auch Assoziationen mit den entsprechenden Leaks ausgewiesen werden. Um Missbrauch zu verhindern, lohnt sich das Ausblenden von Passwörtern und das Protokollieren der Zugriffe.

Die simple Datenstruktur der Tabellen führt dazu, dass gezielte Abfragen sehr schnell umsetzbar sind. Das Abfragen von spezifischen Mailadressen oder weniger populären Domains ist innerhalb weniger Sekunden möglich.

Komplexe Abfragen (z.B. mit Regex) und Abfragen für umfangreiche Resultate (z.B. alle Mailadressen mit der Top-Level-Domain .com) können ressourcenintensiv ausfallen. Selbst auf dem zuvor skizzierten Server-System können solche extremen Anfragen mehrere Stunden in Anspruch nehmen.

Neben direkten Abfragen für einzelne Datensätze können auch erweiterte Statistiken umgesetzt werden. Dabei können durchschnittliche Passwort-Längen ermittelt und priorisierte Wortlisten für Dictionary-Attacks generiert werden. Gerade letztgenannte stellen wir einzigartig in unserem öffentlichen GitHub-Repository zur Verfügung.

Fazit

Das Auswerten von Passwort-Leaks bringt verschiedene Vorteil mit sich. Einerseits kann die eigene Angreifbarkeit ermittelt und reduziert werden. Andererseits lässt sich das erworbene Wissen im Rahmen von Red Teaming Tests einsetzen.

Doch bis diese Möglichkeiten erreicht sind, gilt es verschiedene Hürden zu nehmen. Das Finden und Sammeln qualitativ hocherwertiger Leaks, und dies auch noch zeitnah, kann schwierig sein. Danach müssen verschiedene Dateiformate normalisiert werden. Dadurch kann der Import ohne Zwischenfälle durchgesetzt werden. Erst im letzten Schritt kann dann durch Abfragen und Auswertungen von den Mühen profitiert werden.

Eine solche Aufgabe eignet sich nicht für jedes Unternehmen. Auch nicht im Sicherheitsbereich, denn ein solches Projekt lässt sich nicht mal nur nebenher betreiben. Doch wer die Mühen auf sich nimmt, der kann sich ein durchschlagkräftiges Werkzeug erarbeiten, auf das man zukünftig zurückgreifen kann.

Über die Autoren

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Security Frameworks, Routing, Firewalling und Log Management.

Links

• https://github.com/scipag/password-list
• https://towardsdatascience.com/indexing-very-large-tables-569811421ee0
• https://twitter.com/mruef/status/1407391964207759362
• https://use-the-index-luke.com/sql/where-clause/the-equals-operator/concatenated-keys