Ein Kunde nutzt Veeam B&R als Backuplösung und speichert Backups innerhalb dieser Umgebung passwortgeschützt auf ein ReFS-Repository. Die Umgebung umfasst über 200 virtuelle Server auf Linux- und Windows-Basis und betreibt unter anderem eine 24/7-Produktion.
Der Kunde war Opfer eines erfolgreichen Ransomware-Angriffes und nach anschließender Analyse ist der Angreifer folgendermaßen vorgegangen (stark vereinfacht dargestellt!):
- Sammeln von Informationen (ein Standard) – oft per Social Engineering
- Sammeln von technischen Informationen über die Umgebung
- Sammeln von Informationen über die verschiedenen Hard- und Softwarehersteller des Kunden
- Infiltration des Netzwerkes über offene RDP-Ports („Altlasten“ aus der Corona-Zeit)
- Verweilen im System mit sehr seltenem Call-Home für etwa 7 Monate
- Infiltration des Veeam Backup Servers (Simple Deployment – also nur ein physikalischer Server vorhanden)
- Änderung des Verschlüsselungspasswortes der Veeam Backups
- Verweilen im System für weitere 4 Wochen
- Angriff der Systeme in umgekehrter Priorität (erst „unwichtige“ Applikationsserver, dann Angriff auf kritische Systeme wie Exchange und Domain Controller)
- Lösegeldforderung
Der Kunde nutzte bereits verschlüsselte Backups, somit war er gegenüber Datendiebstahl grundsätzlich gut aufgestellt, auch war der Backupserver kein Mitglied der Domäne. Soweit bekannt, ist der Angreifer über eine Sicherheitslücke im Windows oder im iDRAC des Servers zu erhöhten Rechten gekommen und hat dann den nicht in der Domäne befindlichen Server übernehmen können.
Dem Kunden fiel die Änderung des Passwortes nicht auf. Warum? Veeam wirft hier natürlich keinerlei Fehlermeldung, da die Backups trotzdem sauber durchlaufen. Was man auf den ersten Blick nur schwer sieht, ist dass Veeam mit Änderung des Passwortes keine Fehlermeldung auswirft, jedoch eine neue Backup-Chain anfängt und somit ein neues Full-Backup schreibt.
Wie hätte der Kunde dieses Szenario umgehen können? Hier einige Beispiele:
- zusätzliches Hardening der Umgebung (Deaktivieren von Internetzugriff, Separieren der Netze etc.)
- Deaktivierung von RDP
- Monitoren der lokalen und entfernten Anmeldungen per PRTG o.ä.
- Nutzung von Veeam ONE o.ä. zur Anomalieerkennung
Eine Anomalie hätte hier z.B. erkannt werden können, da ja die benötige Zeit für das Schreiben der Backups durch das zu schreibende Full-Backup auf einmal mehr als doppelt so lange gebraucht hat. Das kann natürlich legitim sein, sofern der Kunde aktiv ein Full-Backup getriggert hat oder sogar selbst das Passwort geändert hat, jedoch würde beispielsweise Veeam ONE dies erkennen und zur Prüfung auffordern.
Sofern bekannt, musste der Kunde ein sechsstelliges Lösegeld zahlen, wurde jedoch dann wieder handlungsfähig, da der Angreifer den Key zur Entschlüsselung bereitgestellt hat.
Als Folge des Angriffes hat der Kunde seine gesamte Infrastruktur parallel neu aufgebaut und auch alle Clients sauber neu aufgesetzt und lediglich die alte Datenbasis (Datenbanken etc.) in das neue System nach vorheriger Prüfung importiert. Dem Kunden sind dadurch massive Kosten in ebenfalls sechsstelliger Höhe entstanden, zumal das Projekt erst nach rund 2 Jahren vollständig abgeschlossen war.