True IT Stories

Verschlüsselt oder nur umbenannt?

TL;DR

  1. Die Endung .babyk beweist nichts. Manche Sicherungen sind nur umbenannt, manche entschlüsselbar, manche verloren.
  2. Kopf und Dateiende entscheiden in Sekunden: intakter Kopf heißt heil, 72 Bytes Anhang heißt entschlüsselbar, verschlüsselter Kopf ohne Anhang heißt Schlüssel verloren.
  3. Erst messen, dann entschlüsseln. Nur auf Kopien, an einer sauberen Referenz geeicht, und nur umbenannte Dateien nie durch den Decryptor.

Nach einem Ransomware-Angriff hat jede Datei die neue Endung, hier .babyk. Die naheliegende Annahme ist: alles verschlüsselt, Decryptor drüber, fertig. In unserem Fall stimmte das für keine der großen Sicherungen. Manche waren nur umbenannt, manche ließen sich entschlüsseln, manche waren endgültig verloren. Von außen sahen alle gleich aus.

Diese Anleitung ist aus dem Fall entstanden, den wir in Der Decryptor läuft, und die großen VMs bleiben zu erzählen. Die Werte unten gelten für Babuk. Bei einer anderen Ransomware ist das Prinzip dasselbe, die Zahlen muss man an einer Referenz neu bestimmen.

Drei Sorten Dateien

SorteKopfDateiendeWas tun
HEIL, nur umbenanntintaktkein AnhangNicht entschlüsseln. Auf einer Kopie die Endung abschneiden, mit dem Veeam Backup Validator prüfen
FERTIG verschlüsseltverschlüsseltAnhang vorhandenDecryptor, auf einer Kopie
KAPUTT, angefangen und abgebrochenverschlüsseltkein AnhangSchlüssel verloren, der Decryptor ändert nichts. Original aufheben, Veeam-Support oder Datenrettung

Der Anhang ist das entscheidende Merkmal. Babuk hängt an jede Datei, die es fertig verschlüsselt hat, genau 72 Bytes an: Schlüsselmaterial und eine Kennung. Fehlt der Anhang bei verschlüsseltem Kopf, ist der Lauf abgebrochen, und der Schlüssel für diese Datei existiert nicht mehr.

Die Endung beweist nichts

In unserem Fall trugen Sicherungen von vor Jahren die Endung .babyk, waren aber nie angefasst: Kopf intakt, Änderungsdatum lange vor dem Angriff. Babuk hatte sie umbenannt und ist dann nicht mehr dazu gekommen. Umgekehrt kann eine Datei ohne Endung verschlüsselt sein. Nur der Inhalt sagt, was los ist.

Ein guter erster Hinweis ist das Änderungsdatum. Liegt es vor dem Angriff, hat niemand die Datei beschrieben. Haben viele Dateien auf einer Ablage exakt dieselbe letzte Schreibsekunde, wurde dort etwas abgebrochen.

Der Kopf in Sekunden

Eine intakte Veeam-Datei beginnt mit einer kleinen Versionsnummer, und in den ersten 4 KB stehen Tausende Nullbytes. Ist der Kopf verschlüsselt, steht dort eine riesige Zahl und nur noch eine Handvoll Nullen.

$p  = 'D:\Analyse\Server.vbk.babyk'
$fs = [IO.File]::OpenRead($p); $b = New-Object byte[] 4096
$null = $fs.Read($b, 0, 4096); $fs.Close()
[BitConverter]::ToUInt32($b, 0)            # kleine Zahl = intakter Kopf
($b | Where-Object { $_ -eq 0 }).Count     # Tausende = intakt, etwa 16 = verschlüsselt

Veeam meldete bei uns Storage version [2102807789] is not supported. Das ist keine Version, sondern die ersten vier Bytes eines verschlüsselten Kopfs.

Das Ende in Sekunden

Die Veeam-Dateien waren bei uns auf 4 KB ausgerichtet. Ist eine Datei 72 Bytes größer als ein Vielfaches von 4096, hängt der Babuk-Anhang dran:

(Get-Item $p).Length % 4096                # 72 = Anhang vorhanden, 0 = kein Anhang

Darauf allein nicht verlassen. Ob die eigenen Sicherungen ausgerichtet sind, zeigt erst eine saubere Referenz, siehe unten. Dazu die letzten 64 Bytes ansehen: Am Ende eines Anhangs steht die Kennung der Täter als lesbarer Text.

Die Falle: komprimiert sieht aus wie verschlüsselt

Veeam komprimiert die Datenblöcke. Komprimierte Daten sehen fast so zufällig aus wie verschlüsselte. Ein Stück aus der Mitte einer VBK, das nach Rauschen aussieht, beweist nichts. Tragfähig sind nur Kopf, Ende und Bereiche mit vielen Nullen, die eine Stromchiffre nicht übrig lassen würde.

Bei uns war in allen verschlüsselten großen Dateien genau das erste MiB verschlüsselt. Dahinter sah die Datei aus wie eine gesunde Sicherung.

Erst messen, dann entschlüsseln

  1. Originale nicht anfassen. Alles auf Kopien. Auf einer KAPUTT-Datei ändert der Decryptor nichts, eine HEIL-Datei kann er aber zerstören.
  2. Prüfen, ob die Kopie fertig ist. Eine Datei, die noch kopiert wird, liefert beim Lesen Nullen und damit ein falsches „sauber“. Ist uns passiert.
  3. Prüfsummen bilden. Get-FileHash über alle Originale, Ergebnis wegspeichern.
  4. An einer Referenz eichen. Eine kleine VM, die sich nach dem Entschlüsseln sauber wiederherstellen ließ: Ihre .babyk-Datei ist sicher FERTIG, die entschlüsselte Fassung sicher heil. Bei uns war die verschlüsselte genau 72 Bytes größer, und die entschlüsselte hatte wieder einen intakten Kopf.
  5. Jede Datei einsortieren: HEIL, FERTIG oder KAPUTT.
  6. Decryptor nur auf FERTIG-Dateien, nur auf Kopien, danach die Ausgabe erneut prüfen. Wie man ihn dabei von den Originalen fernhält, steht in Den Decryptor an die Leine legen .
  7. Die VBM mitprüfen. Die Metadatei war bei uns überall fertig verschlüsselt. Eine heile VBK lässt sich trotzdem einzeln importieren.
  8. Ketten zusammensetzen. Eine HEIL-Vollsicherung plus FERTIG-Inkremente ergibt einen vollständigen Stand. So kam bei uns ein Server zurück.

Quellen