Am Montagmorgen waren die zentralen Dateifreigaben nicht mehr erreichbar, mehrere virtuelle Server zeigten Erpressernotizen, und die Buchhaltung konnte keine Belege bearbeiten. Dieses Praxisbeispiel zur Ransomware-Recovery mit Backup zeigt einen typischen Vorfall im Mittelstand: Ein Angriff trifft nicht nur die IT, sondern unterbricht Lieferprozesse, Kommunikation und Finanzabläufe zugleich. Entscheidend ist dann nicht, ob Sicherungen existieren, sondern ob sie isoliert, vollständig und innerhalb der benötigten Zeit wiederherstellbar sind.
Das hier beschriebene Szenario basiert auf wiederkehrenden Mustern aus der Praxis. Unternehmensnamen, Größenordnungen und einzelne technische Details sind angepasst. Die Vorgehensweise ist jedoch auf viele kleine und mittlere Unternehmen übertragbar.
Ausgangslage: Ein Angriff legt den Betrieb lahm
Das Unternehmen beschäftigt rund 85 Mitarbeitende und betreibt einen Standort mit Lager, Verwaltung und Außendienst. Die tägliche Arbeit stützt sich auf einen zentralen Verzeichnisdienst, einen Dateiserver, eine ERP-Anwendung, Microsoft 365 sowie mehrere virtuelle Maschinen für Fachanwendungen. Die Datensicherung lief nachts auf ein lokales Backup-System; zusätzlich wurden Sicherungskopien in einen externen Speicher übertragen.
Der Angreifer verschaffte sich vermutlich über kompromittierte Zugangsdaten Zugang zum Netzwerk. Nach einer Phase unauffälliger Aktivitäten wurden innerhalb weniger Stunden Dateifreigaben verschlüsselt. Auch zwei Server und Teile der Sicherungsumgebung waren betroffen. Der Betrieb entschied sich gegen eine Kommunikation mit den Erpressern und konzentrierte sich auf die Eindämmung sowie eine kontrollierte Wiederherstellung.
Diese Entscheidung ist nachvollziehbar, aber keineswegs automatisch richtig oder einfach. Ob eine Wiederherstellung möglich ist, hängt unter anderem von der Qualität der Sicherung, dem Befallsumfang, den Abhängigkeiten der Systeme und den verfügbaren personellen Ressourcen ab. Gerade bei eigenständig betriebenen Umgebungen wird häufig unterschätzt, wie viele Einzelschritte zwischen einem vorhandenen Backup und einem arbeitsfähigen Geschäftsbetrieb liegen.
Ransomware-Recovery mit Backup: Die ersten 24 Stunden
Der erste Fehler wäre gewesen, Server sofort zurückzusetzen oder Sicherungen ohne Prüfung einzuspielen. Dadurch können Spuren verloren gehen, Schadsoftware erneut aktiviert werden oder saubere Wiederherstellungspunkte überschrieben werden. Deshalb stand zunächst die Trennung betroffener Systeme vom Netzwerk im Vordergrund.
Das IT-Team deaktivierte verdächtige Benutzerkonten, trennte Server und Arbeitsplätze logisch vom Netz und stoppte automatisierte Synchronisationen. Besonders wichtig war die Prüfung von Schnittstellen: Ein kompromittierter Server kann über angebundene Speicher, Cloud-Synchronisationen oder administrative Konten weitere Bereiche erreichen. Parallel wurde dokumentiert, welche Systeme auffällig waren, welche Dienste noch liefen und welche Geschäftsfunktionen priorisiert werden mussten.
Anschließend erfolgte eine Bestandsaufnahme nach drei Kategorien: sicher betroffen, möglicherweise betroffen und nach aktuellem Stand unauffällig. Diese Einteilung verhindert, dass die Wiederherstellung auf falschen Annahmen basiert. Sie hilft auch der Geschäftsführung, Entscheidungen nach Geschäftsauswirkung zu treffen. In diesem Fall hatten die ERP-Datenbank, die Dateifreigaben für Aufträge und die Identitätsverwaltung Vorrang vor weniger kritischen Archivsystemen.
Ein externer IT-Dienstleister unterstützte bei der forensisch orientierten Erstbewertung und beim Aufbau einer sauberen Wiederherstellungsumgebung. Viele Unternehmen greifen in dieser Phase auf Spezialisten zurück, weil der eigene IT-Betrieb zwar die Landschaft kennt, aber nicht dauerhaft auf Incident Response, Backup-Analyse und Sicherheitsbereinigung ausgelegt ist. Die Zusammenarbeit funktioniert am besten, wenn Zuständigkeiten, Freigaben und Kommunikationswege vorab geregelt sind.
Das Backup prüfen, bevor es eingesetzt wird
Die Sicherung war vorhanden, aber nicht jeder Sicherungspunkt war automatisch vertrauenswürdig. Die IT prüfte zunächst, wann die Verschlüsselung wahrscheinlich begann und welche Backups davor liegen. Danach wurden mehrere Wiederherstellungspunkte in einer isolierten Testumgebung eingespielt. Dort prüfte das Team Dateistrukturen, Datenbanken, Ereignisprotokolle und die Funktionsfähigkeit der Anwendungen.
Besondere Aufmerksamkeit galt dem Verzeichnisdienst. Werden dort manipulierte Konten, Gruppenrichtlinien oder administrative Berechtigungen aus einem kompromittierten Stand übernommen, kann der Angriff erneut Fuß fassen. Im konkreten Fall wurde die Identitätsverwaltung daher nicht einfach restauriert, sondern nach einer Sicherheitsprüfung neu aufgebaut und anschließend schrittweise mit den erforderlichen Daten abgeglichen.
Auch beim Dateiserver genügt es nicht, auf die Anzahl wiederhergestellter Dateien zu schauen. Fachbereiche mussten bestätigen, ob aktuelle Auftragsunterlagen, Kalkulationen und Produktionsdaten tatsächlich verfügbar und lesbar waren. Diese fachliche Abnahme wird in Notfallplänen oft zu wenig berücksichtigt. IT kann die technische Wiederherstellung bestätigen, nicht aber die inhaltliche Vollständigkeit geschäftskritischer Informationen.
Wiederherstellung nach Geschäftspriorität statt nach Serverliste
Nach zwei Tagen stand eine bereinigte Basisumgebung bereit. Der Wiederanlauf erfolgte nicht nach dem Prinzip „ein Server nach dem anderen“, sondern anhand eines abgestimmten Geschäftsprozesses. Zuerst wurden Netzwerkgrunddienste, Identitäten und Sicherheitsmechanismen aktiviert. Danach folgten Datenbank, ERP-Anwendung und die für Auftragsbearbeitung erforderlichen Dateibereiche. Erst im nächsten Schritt kamen weitere Abteilungen und Komfortfunktionen hinzu.
Diese Reihenfolge verkürzt die Zeit bis zur eingeschränkten Arbeitsfähigkeit. In dem Beispiel konnte die Auftragsabwicklung am dritten Arbeitstag wieder beginnen, zunächst mit klar definierten Einschränkungen. Einzelne historische Datenbestände und Archivbereiche wurden nachgelagert wiederhergestellt. Das war ein bewusster Zielkonflikt: Eine vollständige Rückkehr aller Systeme hätte länger gedauert, während das Unternehmen kurzfristig vor allem Lieferfähigkeit und Rechnungsstellung sichern musste.
Parallel wurden sämtliche administrativen Kennwörter zurückgesetzt, Mehrfaktor-Authentifizierung ausgeweitet und Berechtigungen überprüft. Arbeitsplätze erhielten neue Sicherheitsrichtlinien, bevor sie erneut auf zentrale Ressourcen zugreifen durften. Auch Cloud-Dienste wurden kontrolliert: Synchronisierte Dateien, Freigaben und Benutzeranmeldungen können sonst den Erfolg der lokalen Bereinigung gefährden.
Was das Beispiel über Backup-Konzepte zeigt
Ein Backup ist kein einzelnes Produkt, sondern ein überprüfbarer Betriebsprozess. Die oft genannte 3-2-1-Regel ist ein sinnvoller Ausgangspunkt: drei Kopien der Daten, auf zwei unterschiedlichen Speichermedien, davon eine Kopie außerhalb der primären Umgebung. Gegen moderne Ransomware reicht das allein jedoch nicht immer aus. Angreifer suchen gezielt nach erreichbaren Sicherungszielen und nach Konten mit weitreichenden Rechten.
Daher benötigen Unternehmen zusätzlich eine unveränderbare oder logisch getrennte Sicherung, eigene Backup-Zugangsdaten und eine klare Trennung zwischen Produktiv- und Sicherungsumgebung. Welche technische Ausgestaltung passt, hängt von Datenmenge, Wiederherstellungszeit, regulatorischen Anforderungen und vorhandener Infrastruktur ab. Für ein kleines Büro gelten andere Maßstäbe als für einen Betrieb mit Schichtarbeit, Lagerlogistik und mehreren Standorten.
Mindestens ebenso relevant sind die Zielwerte. Die Recovery Time Objective beschreibt, wie schnell ein Prozess wieder laufen muss. Die Recovery Point Objective legt fest, wie viel Datenverlust zeitlich akzeptabel ist. Wer für die Fakturierung maximal vier Stunden Ausfall und höchstens eine Stunde Datenverlust toleriert, braucht eine andere Sicherungsfrequenz und Wiederherstellungsarchitektur als ein Unternehmen, das Daten erst am Folgetag benötigt.
Ein häufiger Projektfehler besteht darin, diese Werte nur für Server zu definieren. Entscheidend sind jedoch Prozesse: Kann ein Auftrag ohne die aktuelle Datenbank, ohne Dateifreigabe oder ohne bestimmte Benutzerrechte bearbeitet werden? Erst wenn Fachbereiche und IT diese Abhängigkeiten gemeinsam erfassen, entsteht ein Notfallkonzept, das im Ernstfall Orientierung gibt.
Regelmäßige Tests machen Sicherungen belastbar
Im Praxisfall zeigte sich ein weiterer Punkt: Die Wiederherstellung dauerte länger als zunächst kalkuliert, weil Abhängigkeiten zwischen Anwendungen nicht ausreichend dokumentiert waren. Die Sicherungen selbst waren nutzbar. Dennoch kostete die Reihenfolge der Wiederanläufe Zeit. Genau hier helfen geplante Recovery-Tests.
Ein sinnvoller Test umfasst nicht nur das Zurückspielen einer Datei. Er sollte mindestens einmal jährlich die Wiederherstellung eines kritischen Systems in einer isolierten Umgebung einschließen. Dabei werden Wiederherstellungsdauer, Datenstand, Anwendungsfunktion, Berechtigungen und fachliche Freigabe dokumentiert. Nach technischen Änderungen, etwa einer neuen ERP-Version, einer Servermigration oder erweiterten Cloud-Nutzung, sind zusätzliche Tests ratsam.
Erfahrene Berater vermeiden in solchen Projekten typische Fallen: unklare Verantwortlichkeiten, fehlende Notfallkontakte, Sicherungen mit denselben Administratorrechten wie die Produktion oder Tests ohne Beteiligung der Fachbereiche. LTmemory begleitet Unternehmen dabei häufig nicht nur bei der technischen Auslegung, sondern auch bei der Übersetzung von Geschäftsanforderungen in prüfbare Wiederanlaufpläne.
Fazit: Wiederherstellbarkeit ist eine Führungsaufgabe
Der Angriff wurde ohne Lösegeldzahlung bewältigt, weil eine extern getrennte Sicherung vorhanden war und die Wiederherstellung strukturiert erfolgte. Dennoch entstanden Ausfallzeiten, Zusatzaufwand und Verzögerungen, die ein regelmäßiger Test teilweise hätte reduzieren können. Die entscheidende Erkenntnis lautet: Datensicherung ist nicht abgeschlossen, wenn ein Job erfolgreich durchgelaufen ist. Sie ist erst dann belastbar, wenn kritische Prozesse aus ihr unter realistischen Bedingungen wieder arbeiten können.
Nächster sinnvoller Schritt: Die eigene Ausgangslage prüfen
Viele mittelständische Unternehmen kennen ihre Sicherungsberichte, aber nicht ihre tatsächliche Wiederanlaufzeit. Typische Herausforderungen sind gewachsene Serverlandschaften, unklare Anwendungsabhängigkeiten, begrenzte interne IT-Kapazitäten und fehlende Zeitfenster für Tests. Bei einer Eigenimplementierung besteht das Risiko, dass technische Sicherungen zwar vorhanden sind, im Angriff jedoch keine saubere Reihenfolge, keine isolierte Umgebung oder keine belastbare Verantwortungsstruktur existiert.
Ein erfahrener Partner kann den Aufwand realistisch einordnen, kritische Prozesse priorisieren und Tests so planen, dass sie den Betrieb nicht unnötig beeinträchtigen. Sinnvoll ist eine sachliche Bestandsaufnahme: Welche Daten und Systeme sind geschäftskritisch, welche Wiederanlaufzeiten sind akzeptabel, und wann wurde die Wiederherstellung zuletzt vollständig erprobt? Diese drei Fragen schaffen eine belastbare Grundlage, bevor der nächste Vorfall Entscheidungen unter Zeitdruck erzwingt.