Datenklau bei [Firma]: [Ransomware Gang] veröffentlicht [Zahl] GByte

Hat ein Hacker oder eine Ransomware Gang Geschäftsdaten aus dem Netzwerk der Organisation ausgeleitet und diese veröffentlicht, ist es manchmal notwendig, diese Daten forensisch zu untersuchen um zu verstehen, welche Informationen konkret abgeflossen sind. Anschließend können mit dem betroffenen Fachbereich die Kritikalität besprochen und möglicherweise ex post Schutzmaßnahmen festgelegt werden.

Zwar kann man fast täglich in öffentlichen Medien die Schreckensbotschaft lesen, dass bei einer Organisation eine bestimmte Ransomware Gang Daten veröffentlicht hat, ein Zugriff auf diese Daten und damit eine unerlaubte Drittverwertung ist allerdings nicht in allen Fällen möglich. Das Geschäftsmodell der Cyberkriminellen ist mit der Veröffentlichung der Daten abgeschlossen. Cyberkriminelle haben kein Interesse daran, dass Dritte leicht und schnell an die Daten herankommen können, da darin keine Einnahmequelle gesehen wird.

Dies führt dazu, dass veröffentlichte Daten in manchen Fällen nur sehr, sehr langsam heruntergeladen werden können, in einzelnen Archiven verpackt sind, die in Summe fehlerfrei heruntergeladen werden müssen oder einfach zu groß für den Download sind. In manchen Fällen verhindert der nicht leicht erreichbare Darknet-Server bzw. das Forum im Internet, dass „Hinz und Kunz“ auf die Daten zugreifen können. Für die betroffene Organisation ergibt sich de-facto die glückliche Situation, dass die Daten trotz Veröffentlichung nicht zugreifbar sind.

Sollte man doch einmal für einen Mandant Zugriff auf ausgeleitete Daten erhalten und hat vorher die Rechtmäßigkeit des Zugriffs geklärt (die Daten stellen Diebesgut dar und können geschützte Geschäftsgeheimnisse enthalten), so stellt man schnell fest, dass die Server der Ransomware Gangs im Darknet lediglich ein Protokoll zum Download anbieten: HTTP. Protokolle wie FTP, SCP und SFTP werden nicht angeboten, damit sind die üblichen komfortablen und fehlertoleranten Download-Tools nicht einsetzbar.

Hier kann das Schweizer Taschenmesser curl Aushilfe schaffen. Es ist ein äußerst mächtiges Tool, um Daten zu transferieren. Bei Verbindungsabbrüchen kann es selbstständig den Datentransfer neu aufnehmen und ist auch in der Lage, mehrere Dateien auf einmal herunterzuladen. Es ist sogar in der Lage, dem Server der Ransomware Gang gewisse Informationen („server header“) zu entlocken.

In einer einfachen Form des Befehls curl weißt man den Download einer Datei <DATEINAME> vom Server <SERVER-NAME>.onion im Verzeichnis <VERZEICHNIS> an:

$ curl -x socks5h://localhost:9050 http://<SERVER-NAME>.onion/<VERZEICHNIS>/<DATEINAME> --output <DATEINAME>

Auch wenn manche Hacker wie USDoD ihre ausgeleiteten Dateien nicht im Darknet sondern auf Untergrundforen veröffentlichen, gehe ich im Weiteren vom Darknet aus, da hier fast alle Cyberkriminellen ihre name-and-shame Seiten haben. Daher verwende ich die Top Level Domain „.onion“ des TOR Netzwerkes.

Im TOR Netzwerk werden Netzwerkverbindungen anonymisiert. Damit verlässt eine Netzwerkverbindung nicht wie sonst üblich den Client mit dessen IP-Adresse, sondern wird erst einmal lokal über einen SOCKS-Proxy geleitet, über den im TOR Netzwerk alle TCP-Verbindungen getunnelt werden. curl unterstütz zum Glück SOCKS und baut dabei Verbindungen über TCP auf. Die Option dazu lautet „-x socks5h://localhost:9050“. Mein Client mit dem Betriebssystem Linux Tails 5 verwendet aktuell die SOCKS-Version 5h auf Port 9050.

curl gibt beim Download auf der Standardausgabe stdout permanent Informationen („progress meter“) über den Status des Transfers aus, solange man dies nicht mit der Option „- -silent“ unterdrückt:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0  525G    0 2560k    0     0    734      0    8890d  0:59:30   8890d 3688

Die Aussage, dass der Datentransfer noch 8890 Tage benötigt, wird den einen oder anderen sicher entmutigen.

Nachfolgend ein Beispiel, bei dem der Cyberkriminelle die ausgeleiteten Daten in einzelne Archive im RAR-Format gepackt hat, die am Zielort in Summe zu einem Archiv zusammengebaut werden müssen:

Mit nur einem Befehl können diese Archive heruntergeladen werden:

curl -x socks5h://localhost:9050 http://<NAME DES WEBSERVERS>.onion/MWTp/MWT.part[01-18].rar -R --retry 10 --retry-delay 60 --output "MWT.part#1.rar"

curl wird dabei angewiesen, die Dateien des Schemas „MWT.part[01-18].rar“ vom Server <NAME DES WEBSERVERS>.onion herunterzuladen. Bei Datentransferproblemen versucht curl 10 Mal die Verbindung neu aufzunehmen („- -retry 10“) und wartet jeweils 60 Sekunden zwischen diesen Versuchen („- -retry-delay 60“):

Warning: Problem : HTTP error. Will retry in 60 seconds. 10 retries left.

Die Dateien werden im aktuellen Verzeichnis wie in „- -output“ spezifiziert abgelegt. Mit der Option „-R“ versucht curl den Zeitstempel der heruntergeladenen Datei wie im Original zu belassen, was für die Forensik sehr wichtig ist.

Stößt curl auf ein Problem, zum Beispiel weil die Datei nicht vorhanden ist oder der Server nicht reagiert, dann wird die Fehlermeldung des Servers in der unter „- -output“ spezifizierten Datei als HTML-Text ausgegeben. Am Beispiel einer auf dem Server nicht vorhandenen Datei:

<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.14.2</center>
</body>
</html>

Überlastete und dadurch extrem langsame Server sind im Darknet keine Seltenheit. In diesem Fall kann der Server ein „TooManyRequests“-Fehler als Text ausgeben.

<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>TooManyRequests</Code><Message>Deadline exceeded while waiting in incoming queue, please reduce your request rate</Message><Resource>/blog-v2/136/YOFU.zip</Resource><RequestId>17A7B10624A65D8B</RequestId><HostId>dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8</HostId></Error>

Dieses Verhalten kann man mit der Option „-f“ bzw. „- -fail“ kontrollieren, so dass der curl Befehl sich besser in Skripten verhält, in denen man u.U. auf einen Fehler anders reagieren möchte. curl gibt in diesem Fall den Fehlercode 22 auf stderr aus:

curl: (22) The requested URL returned error: 503 Service Unavailable

Ist curl nicht in der Lage alle Dateien herunterzuladen, dann wird der Fehlercode 18 ausgegeben:

curl: (18) transfer closed with 563829595755 bytes remaining to read

Zu guter Letzt kann man in den Anfragen an den Server der Cyberkriminellen die Informationen über den eigenen Client mit der Option „- -user-agent „<ZEICHENKETTE>““ verschleiern. Beispiele dafür findet man im Internet unter der Suche  „User-Agent request header“.