Der Decryptor läuft, und die großen VMs bleiben zu
TL;DR
- Nach Babuk kamen mit dem Decryptor der Täter nur die kleinen VMs zurück. Die großen Vollsicherungen meldete Veeam als „Storage version not supported“.
- Der Angriff war bei den großen Dateien abgebrochen. Das erste MiB war verschlüsselt, der 72-Byte-Anhang mit dem Schlüssel fehlte. Ohne ihn hilft kein Decryptor.
- Ein weiterer Server kam über eine nur umbenannte Vollsicherung zurück, samt entschlüsselbarer Inkremente. Für den Hauptserver ist der Veeam-Support dran.
Der Anruf kam von einem IT-Dienstleister aus meinem Netzwerk. Sein Geschäftsführer hatte gesagt: Du postest doch immer, dass du ein bisschen Ahnung von Veeam hast.
Der Fall, den er mitbrachte, war eigentlich schon gelöst. Ein kleiner Betrieb, Ransomware, alles verschlüsselt, Endung .babyk. Ein Decryptor der Täter lag vor. Die kleinen VMs ließen sich damit wiederherstellen. Die beiden großen, auf denen die eigentliche Arbeit lag, nicht.
Wie es so weit kam
Die Umgebung hatte ein anderer Dienstleister aufgebaut. Ein Hyper-V-Host in einem Rechenzentrum, Veeam in der kostenlosen Community Edition, mehrere Sicherungsziele: ein externer Cloud-Speicher, ein NAS und eine weitere Ablage. Alle hingen per SMB oder Mount am Backup-Server. Keine Kopierjobs, die Ziele wurden direkt beschrieben.
Die Ransomware hat alle erwischt. Danach wurde am Server noch eine Weile herumprobiert, was ihn nicht besser machte. Erst dann kam der Kollege dazu.
Bemerkenswert war, was noch lief. „Alles ist lauffähig, der Hyper-V ist lauffähig, jeder kann sich da anmelden, nur die Nutzdaten sind verschlüsselt“, sagte der Kollege. Das ist Absicht: Das Opfer soll zahlen können.
Das Fehlerbild
Der Kollege hat sorgfältig gearbeitet. Sicherungen vom Cloud-Speicher heruntergeladen, Stunden pro Datei. Auf einem isolierten Rechner entschlüsselt, auf einer anderen Maschine wiederhergestellt. Mehrfach. Kleine VMs mit 10 bis 20 GB: kein Problem. Die beiden großen, jede mehrere hundert GB, scheiterten jedes Mal mit derselben Meldung:
Failed to create backup mount source. Storage version [2102807789] is not supported for read-only access.Er hatte schon vieles ausgeschlossen. Mehr Arbeitsspeicher, andere Maschinen, ein anderer Standort. Veeam 12 und die aktuelle 13. Drei unabhängige Vollsicherungen von zwei Standorten. Immer dasselbe.
Die Irrwege
Die Versionsspur. „Storage version not supported“ klingt nach einer zu alten oder zu neuen Veeam-Version. Zwei Versionen wurden durchprobiert. Es war nie die Version.
„Die großen hatten kein aktuelles Backup.“ Das war meine erste Vermutung. Falsch, die Wiederherstellungspunkte waren da.
„Wenn das ein normaler kaputter Container wäre, gäbe es mehr dazu bei Google.“ Das sagte der Kollege, und es war der richtige Instinkt. Es war kein normaler Veeam-Defekt.
Ein Kopf-Check auf eine Datei, die noch kopiert wurde. Er zeigte nur Nullen, also „sauber“. Die Kopie lief einfach noch.
Die erste Bruchstelle: Die Versionsnummer ist Datenmüll
Dann haben wir uns die ersten Bytes der Dateien angesehen. Ein intakter Veeam-Dateikopf beginnt mit einer kleinen Versionsnummer, danach kommen viele Nullen. Bei beiden großen Dateien: reines Rauschen. Die „Storage version 2102807789“ waren schlicht die ersten vier Bytes, als Zahl gelesen.
Veeam hatte also recht. Die Datei war keine lesbare Sicherung. Aber warum ausgerechnet die großen, nach einem Decryptor, der bei den kleinen funktioniert hatte?
Unsere These, und warum sie falsch war
Babuk verschlüsselt mit einer Stromchiffre. Entschlüsseln ist dabei dieselbe Operation wie Verschlüsseln. Unsere These war: Die großen Dateien wurden über das langsame SMB nie fertig verschlüsselt, und der Decryptor hat den Klartext darin erst verschlüsselt. Der Kollege kam als Erster auf den Decryptor, mein Beitrag war die Frage, wie lange mehrere hundert GB über SMB eigentlich dauern.
Die Täter sahen das anders. Auf Nachfrage hieß es, der Decryptor müsse funktionieren.
Sie hatten recht. Wir haben die Originale noch einmal heruntergeladen und mit der „entschlüsselten“ Fassung verglichen. Sie waren gleich. Der Decryptor hatte an den großen Dateien gar nichts verändert.
Die zweite Bruchstelle: Es fehlten 72 Bytes
Den Unterschied zeigte das Dateiende. Jede Datei, die Babuk fertig verschlüsselt hatte, war genau 72 Bytes größer als vorher. Dort hängt das Schlüsselmaterial für diese eine Datei, dazu eine Kennung der Täter. Genau diese 72 Bytes braucht der Decryptor. Er entfernt sie und stellt die Datei wieder her. Bei den kleinen VMs hat das funktioniert.
Bei allen großen Dateien fehlte der Anhang. Babuk hatte jeweils das erste MiB verschlüsselt, also den Dateikopf und die Verwaltungsdaten. Bis zum Anhang ist es nie gekommen. Alle diese Dateien wurden auf jeder Ablage in derselben Sekunde zum letzten Mal geschrieben. Das sieht nicht nach Zufall aus, sondern nach einem Abbruch: Prozess beendet, Server aus oder Verbindung weg.
Das ist die eigentliche Pointe. Ohne den Anhang gibt es den Schlüssel für das erste MiB nicht mehr. Nach allem, was wir über Babuk wissen, entsteht er für jede Datei neu. Weder der Decryptor noch die Täter können dieses MiB zurückholen. Ausgerechnet der Abbruch des Angriffs hat die großen Sicherungen unrettbar gemacht. Die kleinen waren fertig verschlüsselt, und genau deshalb kamen sie zurück.
Der Rest der Datei ab dem ersten MiB liegt im Klartext vor. Hunderte Gigabyte Daten, aber ohne den Kopf, der Veeam sagt, wo was liegt.
Die Lösegeldforderung hatte übrigens gewarnt: „Any attempts to modify, decrypt or rename the files will lead to its fatal corruption.“ Das stimmt so nicht, Umbenennen ändert kein einziges Byte. Kaputt gemacht hat die Dateien am Ende etwas anderes.
Nur umbenannt
Eine Überraschung gab es noch. Manche Dateien trugen die Endung .babyk, waren aber nie angefasst worden: Kopf intakt, Änderungsdatum lange vor dem Angriff. Babuk hatte sie umbenannt und ist dann nicht mehr dazu gekommen. Die Endung beweist also nichts.
Wie man das für jede Datei prüft, ohne Hunderte Gigabyte zu lesen, steht in Verschlüsselt oder nur umbenannt?
Wo der Fall steht
Ein weiterer Server ist gerettet. Auf einer der Ablagen lag eine Vollsicherung, die Babuk nur umbenannt hatte, dazu Inkremente, die fertig verschlüsselt waren und sich deshalb entschlüsseln ließen. Zusammen ergab das den Stand der Nacht vor dem Angriff. Veeam hat die Kette geprüft und importiert, die VM bootet, die Daten sind da.
Mit einem Haken: Die Sicherung war vom Vorabend, die Daten darin aber sechs Wochen alt. Warum, steht in Das Backup war frisch, die Daten nicht .
In den Logs desselben Servers fand sich ein massiver Angriff aus den Wochen davor. Er ist gescheitert, der Server war sehr wahrscheinlich nicht der Weg hinein. Wie wir das geprüft haben, steht in Der Angriff, der nicht der Einstieg war .
Für den Hauptserver gibt es auf keiner der drei Ablagen eine vollständige Kette. Beim Veeam-Support hat ein Engineer für Ransomware-Fälle übernommen. Er hält eine Reparatur der Kopfdaten für möglich und hat ein Werkzeug geschickt, das sie aus einer betroffenen Datei ausliest. Die Probe steht aus. Wie es ausgeht, tragen wir hier nach.
Was bleibt
„Das, was du hier erlebst, das glaubt uns ja leider meistens eh kein Schwein“, habe ich zu dem Kollegen gesagt. Decryptor in der Hand, und trotzdem kommen genau die Daten nicht zurück, auf die es ankommt.
Was man vorher hätte anders machen müssen, steht in drei weiteren Beiträgen:
- Ein SMB-Repository ist für Ransomware ein Netzlaufwerk
- Zwei Backup-Ziele sind kein zweites Backup
- Ein Decryptor ist kein Backup
Und was wir unterwegs selbst gelernt haben, zum Teil auf die harte Tour:
Quellen
- Kudelski Security, Dissecting and detecting Babuk ransomware cryptography
- Picus Security, Is Babuk Back? Uncovering the Truth Behind Babuk Locker 2.0