True IT Stories

Ein SMB-Repository ist für Ransomware ein Netzlaufwerk

TL;DR

  1. Drei Backup-Ablagen, alle per SMB oder Mount am Backup-Server, alle in einer Dreiviertelstunde verschlüsselt.
  2. Ransomware braucht dafür keine Lücke in Veeam, nur die Schreibrechte, die der Server ohnehin hat. Babuk beendet vorher sogar die Veeam-Dienste.
  3. Die entscheidende Frage an jedes Ziel: Kann der Backup-Server dort Vorhandenes löschen? Wenn ja, fehlt ein gehärtetes Repository oder Object Lock.

Ein kleiner Betrieb hatte drei Ablagen für seine Sicherungen: einen externen Cloud-Speicher, ein NAS und eine weitere. Auf dem Papier ist das mehr als genug. Nach einem Ransomware-Angriff waren alle drei verschlüsselt, innerhalb derselben Dreiviertelstunde. Die ganze Geschichte steht in Der Decryptor läuft, und die großen VMs bleiben zu .

Der Grund ist schnell erzählt: Alle drei hingen per SMB oder Mount am Backup-Server.

Was der Angreifer sieht

Für Veeam ist eine SMB-Freigabe ein Repository. Für eine Ransomware, die auf dem Backup-Server läuft, ist sie ein Netzlaufwerk wie jedes andere. Sie braucht keinen Exploit und keine Lücke in Veeam. Sie braucht nur die Rechte, die der Server ohnehin hat, um seine Sicherungen zu schreiben. Mit denselben Rechten kann sie sie überschreiben.

Und sie räumt vorher auf. Babuk beendet laut Acronis gezielt die Dienste von Backup-Programmen, bei Veeam unter anderem VeeamTransportSvc, VeeamDeploymentService und VeeamNFSSvc, und löscht die Schattenkopien. Laut Picus schließt es außerdem offene Dateien über die Restart-Manager-Schnittstelle von Windows. Ein laufender Sicherungsjob hält die Dateien also nicht fest.

Was ein Backup-Ziel aushalten muss

Die Frage an jedes Backup-Ziel lautet nicht „Ist es woanders?“, sondern: Was kann der Backup-Server dort kaputt machen, wenn jemand anderes ihn steuert?

Bei einer SMB-Freigabe mit Schreibrechten ist die Antwort: alles. Dasselbe gilt für jedes andere Laufwerk, das am Backup-Server eingehängt ist, und für einen Cloud-Speicher, der als Netzlaufwerk erscheint.

Die Antwort muss lauten: Er kann neue Sicherungen schreiben, aber keine vorhandene ändern oder löschen. Bei Veeam leisten das ein gehärtetes Linux-Repository oder Objektspeicher mit Object Lock. Was das gehärtete Repository anders macht als eine Freigabe, steht in Die Freigabe, die jeder löschen darf .

Eine SMB-Freigabe kann man absichern, aber nicht unveränderlich machen. In diesem Fall hätte eine einzige unveränderliche Kopie gereicht, und der Hauptserver wäre mit dem Stand der Nacht vor dem Angriff zurückgekommen.

Was wir prüfen würden

  • Wie hängt jedes Backup-Ziel am Server? Alles, was als Laufwerk, Freigabe oder Mount erscheint, ist für Ransomware erreichbar.
  • Gibt es eine Kopie, die der Backup-Server nicht löschen kann? Wenn nein, ist das die erste Baustelle.
  • Steht der Backup-Server in der Domäne? Dann reicht ein Domänen-Admin für alles. Dazu unsere Reihe ab Der Backup-Server gehört nicht in die Domäne .

Warum mehrere Ziele allein nicht helfen, steht in Zwei Backup-Ziele sind kein zweites Backup .

Quellen