Ransomware: Ist unser Unternehmen auf einen Angriff wirklich vorbereitet?

Moderne Ransomware-Angriffe zielen nicht in erster Linie darauf ab, Dateien zu verschlüsseln. Angreifer suchen privilegierte Zugänge, greifen Management- und Backup-Systeme an und stehlen Daten. Die Verschlüsselung ist häufig nur der sichtbare Abschluss eines Angriffs, der bereits deutlich früher begonnen hat.

Deshalb lässt sich „Ransomware-Readiness“ nicht daran messen, wie viele Sicherheitsprodukte ein Unternehmen besitzt.

Entscheidend sind drei andere Fragen:

1. Wie schnell erkennen wir einen Angriff?
2. Wie weit kann sich ein Angreifer ausbreiten?
3. Wie schnell können wir kritische Geschäftsprozesse kontrolliert wiederherstellen?

Nehmen wir an, Angreifer verschaffen sich einen Zugang ins Netzwerk. Jetzt entscheidet die Geschwindigkeit der Erkennung darüber, ob ein Angreifer Stunden, Tage oder möglicherweise länger ungestört handeln kann.

Ein mittelständisches Unternehmen sollte deshalb erkennen und nachvollziehen können, wenn beispielsweise:

• ungewöhnliche Anmeldungen stattfinden,
• privilegierte Konten plötzlich auf zahlreichen Systemen verwendet werden,
• neue Administratorrechte vergeben werden,
• Security-Dienste deaktiviert werden,
• verdächtige Skript- oder PowerShell-Aktivitäten auftreten,
• ungewöhnlich viele Dateien verändert werden,
• sich ein System auffällig zu zahlreichen anderen Systemen verbindet,
• große oder ungewöhnliche Datenübertragungen stattfinden.

Für diese Art der Überwachung kommen „Detection and Response“-Systeme zum Einsatz, die in unterschiedlichen Ausprägungen zur Verfügung stehen. EDR erkennt verdächtige Aktivitäten auf Endpoints. XDR führt Informationen aus mehreren Security-Quellen zusammen. MDR ergänzt Technologie um Menschen, die Alarme bewerten und bei Vorfällen reagieren können. Doch unabhängig von der eingesetzten Lösung kommt es vor allem darauf an, diese Frage zu beantworten: Wer erkennt bei uns Freitag um 23:40 Uhr einen Angriff – und wer darf anschließend handeln? 

Der klassische Ransomware-Angriff beginnt aus Sicht des Opfers häufig erst dann, wenn Dateien verschlüsselt sind und eine Lösegeldforderung auftaucht. Aus Sicht des Angreifers ist dieser Moment jedoch das letzte Glied einer deutlich längeren Angriffskette. Am Anfang steht zunächst der Zugang zum Unternehmen, beispielsweise über Phishing, gestohlene Zugangsdaten, kompromittierte Remote-Zugänge oder ungepatchte öffentlich erreichbare Systeme.

Ist dieser erste Zugang geschaffen, beginnt die Vorbereitung des eigentlichen Angriffs. Die Täter versuchen, sich ein möglichst genaues Bild der Infrastruktur zu verschaffen: Welche Systeme sind vorhanden, wo liegen wichtige Daten, welche Benutzerkonten verfügen über weitreichende Berechtigungen und wo befinden sich besonders interessante Ziele wie Domain Controller, Virtualisierungsplattformen, Management-Systeme oder die Backup-Infrastruktur? Gleichzeitig prüfen sie, welche weiteren Systeme sie aus dem bereits kompromittierten Bereich erreichen können und wie sie ihre eigenen Rechte innerhalb der Umgebung ausweiten können.

Besonders wertvoll sind dabei privilegierte Identitäten. Gelingt es beispielsweise, ein Administrationskonto zu übernehmen, kann aus einem einzelnen kompromittierten Arbeitsplatz schnell ein unternehmensweiter Sicherheitsvorfall werden. Für die Ransomware-Abwehr entsteht dadurch eine neue Fragestellung: Es geht nicht nur darum, wie sich die Kompromittierung eines Arbeitsplatzes verhindern lässt, sondern ebenso darum, was ein Angreifer mit einem bereits kompromittierten Arbeitsplatz oder Benutzerkonto anschließend erreichen kann.

Besonders kritisch sind deshalb:

• Domain- und lokale Administratoren,
• Microsoft-365- und Cloud-Administratoren,
• VPN- und Remote-Access-Konten,
• Service Accounts,
• Backup-Administratoren,  
• Virtualisierungsadministratoren,  
• RMM- und Management-Zugänge. 

Ein einzelner kompromittierter Arbeitsplatz muss noch keine Katastrophe sein. Entscheidend ist vielmehr, ob ein Angreifer von dort aus auf weitere kritische Systeme zugreifen kann. Genau hier wird Netzwerksegmentierung relevant. Sie soll nicht nur unterschiedliche Bereiche technisch voneinander trennen, sondern vor allem die mögliche Reichweite eines Angriffs begrenzen.

Ein sinnvoller Praxistest besteht deshalb darin, einen vollständig kompromittierten Standard-Arbeitsplatz anzunehmen und zu prüfen, welche Systeme von dort tatsächlich erreichbar sind. Entscheidend ist die Art des Zugriffs.

Ein sinnvolles Zielbild sieht beispielsweise so aus:

• Arbeitsplatz → benötigter Anwendungs- oder Fileserver:
  Erlaubt, aber nur über die tatsächlich benötigten Dienste.
• Arbeitsplatz → Domain Controller:
  Nur die für Authentifizierung und Verzeichnisdienste erforderliche Kommunikation.
• Arbeitsplatz → Hypervisor oder Virtualisierungsmanagement:
  Kein direkter administrativer Zugriff.
• Arbeitsplatz → Backup-Management:
  Kein direkter Zugriff.
• Arbeitsplatz → Firewall-, Netzwerk- oder RMM-Management:
  Kein direkter administrativer Zugriff.
• Benutzernetz → besonders kritische Serverbereiche:
  Nur explizit notwendige Verbindungen.

Das Ziel lautet also nicht „keine Verbindung“, sondern „nur die für den Geschäftsprozess erforderliche Verbindung“. Damit lässt sich ein Testergebnis deutlich besser einordnen. Wenn ein Standard-Arbeitsplatz den Fileserver erreicht, ist das zunächst normal. Wenn derselbe Arbeitsplatz aber Management-Oberflächen des Hypervisors, Backup-Servers und der Firewall erreichen kann, besteht ein wesentlich größeres Problem.

Die Frage. „Haben wir ein Backup?“ sagt wenig darüber aus, ob ein Unternehmen nach einem Angriff tatsächlich wieder arbeitsfähig wird.

Interessanter sind folgende Punkte:

• Kann ein Angreifer aus dem Produktivnetz die Sicherungen erreichen?
• Können kompromittierte Administratoren Backups löschen?
• Existieren unveränderbare oder ausreichend getrennte Sicherungskopien?
• Sind Backup-Administrationskonten vom normalen Administrationsumfeld getrennt?
• Wann wurde zuletzt eine vollständige Wiederherstellung getestet?
• Wie lange hat sie tatsächlich gedauert?

Ein erfolgreicher Backup-Job ist kein Nachweis für Wiederherstellbarkeit. Ein erfolgreicher Restore ist wesentlich aussagekräftiger.

Ebenso wichtig ist die Definition, in welcher Reihenfolge Systeme nach einem größeren Ransomware-Vorfall wiederhergestellt werden müssen. Ein Unternehmen kann in einer solchen Situation nicht einfach alle Server gleichzeitig zurückspielen. Entscheidend ist, welche Geschäftsprozesse für den Betrieb besonders kritisch sind, welche Systeme dafür benötigt werden und welche technischen Abhängigkeiten zwischen diesen Systemen bestehen. Ein ERP-System hilft beispielsweise wenig, wenn dafür notwendige Identitäts-, Netzwerk-, Datenbank- oder Virtualisierungsdienste noch nicht verfügbar sind.

Deshalb sollte für kritische Systeme nicht nur ein Backup vorhanden sein, sondern auch eine klar definierte Recovery-Reihenfolge. Erst wenn bekannt ist, welche Komponenten zuerst in einen vertrauenswürdigen Zustand zurückgeführt werden müssen und welche Systeme darauf aufbauen, wird aus einer reinen Datensicherung ein belastbares Wiederanlaufkonzept.

Der entscheidende Unterschied liegt damit zwischen „Wir können Daten wiederherstellen“ und „Wir können den Geschäftsbetrieb kontrolliert wieder aufnehmen.“

Eine der besten Methoden zur Bewertung der eigenen Ransomware-Readiness ist ein realistisches Szenario. Stellen wir uns vor, es ist Montagmorgen um 7:10 Uhr. Mehrere Mitarbeiter melden plötzlich, dass sich Dateien nicht mehr öffnen lassen. Kurz darauf schlägt die Endpoint-Security auf mehreren Systemen an. Gleichzeitig fällt auf, dass sich ein privilegiertes Konto bereits in der Nacht an mehreren Servern angemeldet hat und es gibt Hinweise auf ungewöhnliche Datenübertragungen. 

In einer solchen Situation muss klar sein, wer betroffene Systeme isolieren oder kompromittierte Konten sperren darf, wer die Geschäftsführung informiert und wann externe Forensik oder Incident Response hinzugezogen wird. Ebenso sollten Verantwortlichkeiten für Datenschutz und mögliche Meldepflichten feststehen. Auch die Kommunikation muss vorbereitet sein, falls E-Mail, Collaboration-Plattformen oder Teile der Identitätsinfrastruktur nicht mehr verfügbar oder nicht mehr vertrauenswürdig sind. Und es braucht eine klare Vorstellung davon, welche Systeme für den Wiederanlauf Priorität besitzen.

Besonders wichtig für Unternehmen mit IT-Dienstleister

Auch ein guter Dienstleister kann im Ernstfall nur schnell handeln, wenn seine Befugnisse geklärt sind.

Unternehmen und Systemhaus sollten deshalb vorab festlegen:

• Wer darf einen kompromittierten Server abschalten?
• Wer darf VPN-Zugänge deaktivieren oder privilegierte Konten sperren?
• Wer entscheidet über die Isolation ganzer Netzwerkbereiche?
• Wer informiert Geschäftsführung, Datenschutz oder Cyberversicherung?
• Wann wird ein externer Forensiker hinzugezogen?
• Wer gibt bereinigte Systeme wieder für den Betrieb frei?

Fazit: Die Bewältigung der ersten Stunden eines Ransomware-Angriffs sind vor allem eine Entscheidungs- und Organisationsaufgabe, bei der vorbereitete Rollen, Befugnisse und Kommunikationswege darüber entscheiden können, wie schnell sich der Vorfall eindämmen lässt.

Für eine erste Bewertung müssen Unternehmen keine hundert Kontrollpunkte abarbeiten.

Zwölf Fragen reichen aus, um erhebliche Lücken sichtbar zu machen.

Identitäten

1) Sind externe und privilegierte Zugänge konsequent mit MFA abgesichert?

2) Nutzen Administratoren getrennte Konten für Büroarbeit und Administration?

3) Wissen wir, welche hochprivilegierten und technischen Konten existieren und welche Rechte sie besitzen?

Ausbreitung

4) Haben wir praktisch getestet, welche kritischen Systeme ein kompromittierter Standard-Arbeitsplatz erreichen kann?

5) Sind Backup-, Virtualisierungs-, Netzwerk- und andere Management-Systeme besonders vom normalen Benutzerbereich abgeschottet?

Erkennung

6) Können wir ungewöhnliche Anmeldungen, Rechteänderungen und verdächtige Aktivitäten auf Endpoints erkennen?

7) Können wir auffällige Netzwerkaktivitäten und einen möglichen größeren Datenabfluss erkennen oder nachvollziehen?

8) Ist rund um kritische Alarme geklärt, wer sie bewertet und wer anschließend handeln darf?

Recovery

9) Existieren Sicherungen, die nicht einfach aus dem kompromittierten Produktivumfeld gelöscht werden können?

10) Wurde die vollständige Wiederherstellung geschäftskritischer Systeme tatsächlich getestet?

11) Erreichen die gemessenen Wiederherstellungszeiten die definierten RTO- und RPO-Anforderungen?

Organisation

12) Gibt es einen dokumentierten und bekannten Incident-Response-Ablauf mit Verantwortlichkeiten, Notfallkontakten und einer definierten Recovery-Reihenfolge?

„Ja“ ist nicht immer ein belastbarer Nachweis

Auch die Checkliste braucht eine Bewertungslogik. Deshalb kann jeder Punkt mit drei Stufen bewertet werden:

• Grün: Die Maßnahme existiert, wurde getestet und das Ergebnis ist nachvollziehbar dokumentiert.
• Gelb: Die Maßnahme ist geplant oder technisch vorhanden, wurde aber nicht ausreichend getestet.
• Rot: Die Antwort ist unbekannt oder die Fähigkeit existiert nicht.

Besonders wichtig: „Das müsste funktionieren“ ist kein grünes Ergebnis.

• Für Ransomware-Readiness zählen nachgewiesene Fähigkeiten.
• Ein Restore, der nie getestet wurde, ist gelb.
• Eine Segmentierung, deren tatsächliche Kommunikationswege niemand geprüft hat, ist gelb.
• Eine Security-Warnung, für die außerhalb der Geschäftszeiten niemand zuständig ist, ist ebenfalls gelb.

Und „Das weiß ich gerade nicht“ sollte bei kritischen Punkten wie ein rotes Ergebnis behandelt werden.

Wer nach dem Check mehrere Lücken findet, muss nicht sofort die gesamte Sicherheitsarchitektur umbauen.

Eine sinnvolle Reihenfolge ist:

1. Kritische Identitäten absichern.
Privilegierte und extern erreichbare Zugänge haben besonders hohen Hebel.

2. Recovery praktisch testen.
So wird schnell sichtbar, ob vorhandene Backups tatsächlich ausreichen.

3. Reichweite eines kompromittierten Arbeitsplatzes prüfen.
Besonders Management-, Backup- und Virtualisierungsumgebungen verdienen Aufmerksamkeit.

4. Kritische Detection-Szenarien definieren.
Nicht jeden denkbaren Angriff erkennen wollen, sondern zunächst die für Ransomware wichtigen Signale zuverlässig abdecken.

5. Einen Ransomware-Fall als Tabletop-Übung durchspielen.
Dabei werden organisatorische Schwächen oft schneller sichtbar als in technischen Audits.