Ein anonymisierter Incident-Response-Fall von Argos Security
Nach einem Ransomware-Angriff richten sich viele Hoffnungen auf das Backup. Wenn Systeme wiederhergestellt werden können, scheint der schwerste Teil überstanden: Anwendungen laufen, Prozesse starten erneut, der Betrieb kommt zurück. Doch ein erfolgreicher Restore bedeutet nicht automatisch, dass der Vorfall beendet ist. Solange die Ursache des Angriffs nicht geklärt, kompromittierte Konten nicht abgesichert und mögliche Persistenzmechanismen nicht ausgeschlossen sind, kann der Wiederanlauf zum Risiko werden.
Ein anonymisierter Incident-Response-Fall von Argos Security zeigt, warum Wiederherstellung und Bereinigung nicht verwechselt werden dürfen – und weshalb ein sicherer Wiederanlauf mehr braucht als ein funktionierendes Backup.
Der Fall: Wiederhergestellt, aber nicht bereinigt
Als Argos Security in diesen Vorfall eingebunden wurde, war der erste Wiederanlauf bereits erfolgt. Das betroffene Industrieunternehmen hatte seine Systeme nach einem Ransomware-Angriff aus vorhandenen Backups wiederhergestellt. Auf den ersten Blick schien die Maßnahme erfolgreich: Zentrale Anwendungen liefen wieder, erste Geschäftsprozesse konnten aufgenommen werden, die Organisation atmete auf. Doch wenige Tage später kam es erneut zur Verschlüsselung.
Was zunächst wie ein zweiter Angriff wirkte, stellte sich in der Analyse als Fortsetzung desselben Vorfalls heraus. Die ursprüngliche Ursache war nicht beseitigt worden. Ein kompromittiertes Administratorkonto war weiterhin aktiv und ermöglichte den Angreifern erneut Zugriff auf die Umgebung. Die Fehlannahme war ebenso verbreitet wie gefährlich: Restore eingespielt, Problem gelöst.
Der Wiederanlauf war erfolgreich – aber nicht sicher
Das Unternehmen beschäftigte rund 2.000 Mitarbeitende. Aufgrund von Größe, Branche und Datenverarbeitung spielten neben der operativen Wiederherstellung auch DSGVO-Aspekte, Nachweispflichten und perspektivisch NIS2-relevante Anforderungen eine Rolle. Der Druck auf die IT war erheblich: Produktion, Logistik, kaufmännische Prozesse und Kommunikation sollten möglichst schnell wieder funktionieren. Deshalb wurde die Backup-Wiederherstellung priorisiert. Systeme wurden aus vorhandenen Sicherungen zurückgespielt, Anwendungen geprüft und schrittweise wieder freigegeben.
Aus betrieblicher Sicht war das nachvollziehbar. Aus Incident-Response-Sicht fehlte jedoch ein entscheidender Schritt: die Klärung, wie die Angreifer ursprünglich in die Umgebung gelangt waren und ob ihr Zugriff tatsächlich beendet wurde. Der Restore brachte die Systeme zurück. Aber er entfernte nicht automatisch den Angreifer.
Die zweite Verschlüsselung veränderte die Lage
Nach der erneuten Verschlüsselung war klar: Der erste Wiederanlauf hatte den Vorfall nicht beendet, sondern verlängert. Ein kompromittiertes Administratorkonto war weiterhin aktiv, Zugangsdaten waren nicht vollständig rotiert und ursprüngliche Zugriffsmöglichkeiten nicht konsequent geschlossen worden. Damit stand das Unternehmen ein zweites Mal vor denselben Fragen, nur unter deutlich schlechteren Bedingungen:
• Welche Systeme sind erneut betroffen?
• Welche Daten wurden beim zweiten Zugriff verändert oder verschlüsselt?
• Welche administrativen Konten sind noch vertrauenswürdig?
• Welche Backups sind sauber?
• Welche Aussagen können gegenüber Geschäftsleitung, Kunden, Versicherer und Behörden belastbar getroffen werden?
Der zweite Stillstand hatte nicht nur technische Folgen. Er führte zu zusätzlichem Vertrauensverlust innerhalb der Organisation, erhöhtem Abstimmungsaufwand mit der Cyberversicherung und deutlich höheren Gesamtkosten. Wiederherstellungsarbeiten mussten erneut begonnen, bereits erreichte Fortschritte überprüft und Kommunikationslinien angepasst werden.
Der kritische Punkt: die Freigabe des Wiederanlaufs
In der Nachbetrachtung wurde deutlich, dass der entscheidende Punkt nicht allein in der Technik lag. Entscheidend war die Frage, wer den Wiederanlauf unter welchen Voraussetzungen freigibt. War der schnelle Restore eine bewusste Managemententscheidung, um den Betrieb trotz unvollständigem Lagebild wieder aufzunehmen? Oder fehlte ein Prozess, der eine Root-Cause-Analyse und Sicherheitsfreigabe vor dem Wiederanlauf verbindlich vorschreibt? Genau diese Frage ist in realen Incident-Response-Fällen zentral.
Nach einem Cyberangriff reicht es nicht, Systeme wiederherzustellen. Es muss geklärt werden, ob die Umgebung wieder vertrauenswürdig ist. Dazu gehören die Prüfung kompromittierter Konten, möglicher Persistenzmechanismen, manipulierter Gruppenrichtlinien, verdächtiger Remote-Zugänge, lateraler Bewegungen und potenzieller Backdoors. Ohne diese Prüfung besteht das Risiko, dass die Organisation technisch wieder startet, während Angreifer weiterhin Zugriff auf die Umgebung haben.
Die Analyse von Argos Security: Erst verstehen, dann freigeben
Argos Security übernahm im weiteren Verlauf die strukturierte Incident Response und forensische Analyse. Im Fokus stand zunächst nicht der nächste Restore, sondern die Ursache des Angriffs. Das Team untersuchte Authentifizierungsereignisse, administrative Aktivitäten, betroffene Systeme, vorhandene Logs, Backup-Zeitpunkte und mögliche Persistenzspuren. Dabei zeigte sich, dass das kompromittierte Administratorkonto eine zentrale Rolle spielte. Der Zugriff war nicht konsequent beendet worden. Damit hatten die Angreifer nach der Wiederherstellung weiterhin eine Tür in die Umgebung.
Im nächsten Schritt wurden administrative Konten überprüft, Passwörter und Schlüsselmaterial rotiert, privilegierte Zugriffe eingeschränkt, verdächtige Systeme isoliert und Wiederherstellungen erst nach technischer Bewertung freigegeben. Parallel unterstützte Argos Security bei der Aufbereitung des Lagebilds für Management, Rechtsberatung, Datenschutzverantwortliche und Versicherer. Die wichtigste Veränderung: Der Wiederanlauf wurde nicht mehr nur als IT-Aufgabe betrachtet, sondern als kontrollierter Sicherheitsprozess.
Die Konsequenzen: doppelter Aufwand, doppelte Unsicherheit
Die erneute Verschlüsselung hatte erhebliche Folgen. Der Geschäftsbetrieb wurde ein zweites Mal unterbrochen. Die Kosten für externe Unterstützung, interne Aufwände, Wiederherstellung und Kommunikation stiegen deutlich. Auch die versicherungsseitige Bewertung wurde komplexer, weil nachvollzogen werden musste, welche Maßnahmen nach dem ersten Angriff ergriffen wurden und warum es dennoch zu einer erneuten Verschlüsselung kommen konnte. Hinzu kam die regulatorische Dimension. Unter DSGVO-Gesichtspunkten musste bewertet werden, ob personenbezogene Daten betroffen waren oder abgeflossen sein könnten.
Mit Blick auf NIS2 wurde zusätzlich deutlich, wie wichtig dokumentierte Entscheidungswege, angemessene Sicherheitsmaßnahmen und ein belastbares Incident Management sind. Ein Satz aus der Aufarbeitung brachte den Kern des Vorfalls auf den Punkt: „Sie haben den Angreifer mit dem Restore gleich wieder eingeladen.“
Wiederherstellung ist nicht gleich Bereinigung
Der Fall verdeutlicht eine Erfahrung, die Argos Security in Incident-Response-Einsätzen immer wieder macht: Ein Backup kann Systeme zurückbringen. Es beantwortet aber nicht automatisch die Frage, wie der Angriff funktioniert hat. Es entfernt keine kompromittierten Konten, schließt keine Schwachstellen, löscht keine Persistenzmechanismen und garantiert nicht, dass Angreifer keinen Zugriff mehr haben. Professionelle Incident Response beginnt deshalb nicht mit der Frage, welches Backup verfügbar ist. Sie beginnt mit der Frage, ob die Umgebung noch kompromittiert ist. Erst wenn der Angriffsweg verstanden, die Ursache beseitigt, privilegierte Zugänge abgesichert und die Wiederinbetriebnahme kontrolliert freigegeben wurde, entsteht eine belastbare Grundlage für den Betrieb.
Was Unternehmen daraus lernen sollten
Ein schneller Restore ist wichtig. Er darf aber nicht isoliert betrachtet werden. Unternehmen benötigen klare Kriterien für die Wiederinbetriebnahme nach einem Cyberangriff. Dazu gehören eine Root-Cause-Analyse, die Prüfung privilegierter Konten, die Rotation kritischer Zugangsdaten, die Bewertung möglicher Persistenzmechanismen und eine dokumentierte Freigabe durch definierte Verantwortliche. Ebenso wichtig ist die Vorbereitung vor dem Ernstfall: ein getesteter Incident-Response-Plan, belastbare Backup- und Recovery-Prozesse, klare Entscheidungsrollen, externe Unterstützung über Retainer-Modelle und regelmäßige Übungen mit Management, IT, Datenschutz und Kommunikation. Denn im Ernstfall entscheidet nicht nur die Geschwindigkeit des Restores über den Ausgang. Entscheidend ist, ob der Wiederanlauf sicher ist.
Fazit: Restore ist nicht gleich Recovery
In diesem Fall war das Backup nicht das Problem, denn die Wiederherstellung funktionierte. Das eigentliche Problem war, dass der Angreifer weiterhin Zugriff hatte. Für Argos Security zeigt dieser Vorfall sehr deutlich: Ein erfolgreicher Restore ist nur ein Teil der Wiederherstellung. Maßgeblich ist die kontrollierte Rückkehr in einen vertrauenswürdigen Zustand.
Argos Security unterstützt Unternehmen dabei, Wiederherstellung, forensische Analyse und Entscheidungsprozesse so vorzubereiten, dass der Wiederanlauf nach einem Cyberangriff nicht nur schnell, sondern sicher erfolgt.
