Ransomware Emulation – Den Ernstfall proben, bevor er eintritt

Fast jede Organisation, die ein SOC betreibt, hat einen Plan für den Ernstfall. Es gibt Detektionsregeln, Eskalationsketten und Runbooks, die genau festlegen, wer bei welchem Alarm was zu tun hat. Was es deutlich seltener gibt, ist ein Beleg dafür, dass dieser Plan funktioniert, wenn tatsächlich jemand im Netz ist. Genau diese Lücke adressiert Ransomware Emulation. Dieser Beitrag erklärt, was hinter dem Begriff steckt, wie sich Emulation von Pentests und Red Teaming unterscheidet und wo ihre Grenzen liegen.

Was Ransomware Emulation eigentlich ist

Bei einer Ransomware Emulation wird das Verhalten einer realen Ransomware-Gruppe kontrolliert in der eigenen Umgebung nachgestellt. Nicht irgendein generischer Angriff, sondern die dokumentierten Taktiken, Techniken und Abläufe, die eine bestimmte Gruppe tatsächlich einsetzt. Die eingesetzte Software verhält sich dabei wie echte Schadsoftware, sie scannt das Netz, versucht sich festzusetzen, sammelt Daten und leitet sie aus. Der entscheidende Unterschied ist, dass die Software keinen Schaden anrichtet. Wo Verschlüsselung Teil des Szenarios ist, trifft sie nur eigens dafür platzierte Demo-Dateien.

Die meisten Emulationen folgen dem Prinzip Assumed Breach. Man geht also davon aus, dass der erste Einbruch bereits gelungen ist, etwa über eine Phishing-Mail oder gestohlene Zugangsdaten, und beginnt die Übung auf einem bereits kompromittierten System. Das ist keine Abkürzung, sondern eine bewusste Entscheidung. Die Frage lautet nicht, ob ein Angreifer hineinkommt, sondern ob er bemerkt wird, sobald er drin ist.

Warum gerade die Erkennung entscheidet

Moderne Ransomware-Angriffe sind selten ein einzelner Moment. Zwischen dem ersten Zugriff und der Lösegeldforderung liegt meist eine ganze Kette von Schritten. Die Umgebung erkunden, Rechte ausweiten, sich seitwärts im Netz bewegen, Daten ausleiten und erst am Ende verschlüsseln. Viele Gruppen setzen dabei auf doppelte Erpressung, sie drohen also nicht nur mit verschlüsselten Systemen, sondern auch mit der Veröffentlichung gestohlener Daten.

Jeder dieser Schritte hinterlässt Spuren und ist damit eine Chance für die Verteidigung. Laut Mandiant bleiben Angreifer im Median rund zwei Wochen unentdeckt im Netz, und ein Teil der Betroffenen bemerkt den Angriff erst durch die Lösegeldforderung selbst. Zu diesem Zeitpunkt ist das Zeitfenster für eine wirksame Reaktion längst geschlossen.

Das Problem ist dabei selten, dass gar keine Erkennung existiert. Häufiger geht ein kritischer Alarm in der Masse der Fehlalarme unter, eine Regel greift bei einer leicht abgewandelten Technik nicht, oder im entscheidenden Moment weiß niemand genau, wie der eigene Prozess weitergeht. Solange kein echter Angriff kommt, fällt das nicht auf. Die Dashboards sind grün, und genau das erzeugt eine Sicherheit, die nie überprüft wurde.

Emulation, Pentest, Red Teaming

Im Bereich offensiver Sicherheitstests überschneiden sich die Begriffe, und nicht jeder meint dasselbe damit. Grob lassen sich die Ansätze nach ihrer Leitfrage unterscheiden.

Wie eine Emulation in der Praxis abläuft

Die Details unterscheiden sich je nach Anbieter und Umgebung, der grundsätzliche Ablauf ist aber meist vergleichbar.

Als gemeinsame Sprache dient dabei meist das MITRE ATT&CK Framework. Es katalogisiert Angreifertechniken systematisch und macht so nachvollziehbar, welche Techniken nachgestellt wurden und an welcher Stelle der Kette die Erkennung gegriffen hat oder eben nicht.

Blackbox oder Purple Teaming?

Eine grundlegende Weichenstellung ist die Frage, ob das SOC-Team von der Übung weiß. In der Blackbox-Variante ist es nicht eingeweiht und reagiert so, wie es auch bei einem echten Angriff reagieren würde. Das liefert die ehrlichste Messung. Im Purple Teaming dagegen arbeiten Angreifer- und Verteidigerseite gemeinsam, halten nach jeder Phase inne und besprechen, was gesehen wurde und was nicht. Das misst weniger streng, ist aber als Training deutlich wertvoller. Welche Variante sinnvoll ist, hängt davon ab, ob man vor allem wissen oder vor allem lernen will.

Was eine Emulation nicht leistet

So nützlich eine Emulation ist, sie ist kein Allheilmittel. Wer sie einsetzt, sollte ihre Grenzen kennen.

• Kein Test des Einstiegs: Wer mit Assumed Breach startet, prüft nicht, wie ein Angreifer initial hineinkommt. Dafür sind Penetrationstests das richtige Werkzeug.
• Kein Recovery-Test: Ob Backups im Ernstfall tatsächlich tragen und wie schnell der Betrieb wieder läuft, ist eine eigene Frage.
• Kein Ersatz für ein SOC: Eine Emulation fordert eine bestehende Erkennung heraus. Wo es noch kein SOC oder SIEM gibt, gibt es auch nichts herauszufordern.

Für wen sich eine Emulation lohnt

Sinnvoll ist Ransomware Emulation vor allem für Organisationen, die bereits in Erkennung und Reaktion investiert haben, sei es mit eigenem SOC oder über einen Dienstleister. Gerade bei ausgelagerten SOCs ist die Frage relevant, ob der vertraglich zugesicherte Schutz auch tatsächlich geliefert wird.

Hinzu kommt der regulatorische Druck. NIS2, ISO 27001 und der BSI-Grundschutz verlangen wirksame Prozesse zur Erkennung und Behandlung von Sicherheitsvorfällen. Eine dokumentierte Emulation ist ein belastbarer Nachweis, dass diese Wirksamkeit geprüft und nicht nur behauptet wurde, etwa gegenüber Geschäftsführung, Auditoren oder der Cyberversicherung.

Wie Mint Secure euch dabei unterstützt

Mit unserer Ransomware Emulation stellen wir einen realen Angriff kontrolliert in eurer Umgebung nach und fordern damit euer SOC und SIEM heraus. Ihr stellt ein internes Testsystem und einen unprivilegierten Account bereit, wir übernehmen den Rest.