Cybervorfall: Die ersten Stunden richtig handeln – Spuren forensisch sichern statt vernichten

Ist ein Cybervorfall erkannt, schalten viele das betroffene System sofort ab. Damit gehen alle Inhalte des Arbeitsspeichers verloren: laufende Schadsoftware, aktive Verbindungen zum Command-and-Control-Server, Anmeldedaten und bei manchen Ransomware-Varianten sogar Schlüssel. Diese Anleitung zeigt die Reihenfolge der Beweissicherung, die Dokumentation als Beweiskette (Chain of Custody) und eine Checkliste zum Ausdrucken. Den organisatorischen Ablauf der ersten Stunde mit Krisenstab, Backups und Meldungen beschreibt Ransomware-Notfallplan: Die ersten 60 Minuten; beide Anleitungen ergänzen sich.

Voraussetzungen

• Vorbereiteter, schreibgeschützter USB-Stick mit Forensik-Werkzeugen, etwa WinPmem, FTK Imager, KAPE und dcfldd; laden Sie während eines Vorfalls keine Werkzeuge auf das betroffene System
• Externe Datenträger mit ausreichend Platz: für das RAM-Abbild mindestens die Größe des Arbeitsspeichers, für das Disk-Image die Kapazität des Datenträgers
• Hardware-Write-Blocker oder eine Software mit Schreibschutz-Modus für das Einbinden von Datenträgern
• Formulare für die Beweiskette auf Papier oder ein Fallverwaltungswerkzeug wie TheHive
• Ausgedruckte Kontaktliste: Hotline des Cyber-Versicherers, Forensik-Dienstleister, BSI-Service-Center (0800 274 1000), zuständige Datenschutzaufsicht, Datenschutzbeauftragter, Geschäftsleitung, Rechtsberatung
• Bei NIS2-Pflicht: Registrierung beim BSI und Zugang zum Meldeportal (mip.bsi.bund.de) vor dem Vorfall
• Ein schriftlicher Incident-Response-Plan

Schritt 1: Ruhe bewahren und Umfang einschätzen

Klären Sie vor jeder Aktion, welche Systeme betroffen sind und ob der Angriff noch läuft. Aktivieren Sie das Incident-Response-Team und informieren Sie die Geschäftsleitung; sie entscheidet über Meldungen und externe Unterstützung. Notieren Sie den Zeitpunkt der Entdeckung, denn ab ihm laufen die Meldefristen.

Halten Sie jede Aktion minutengenau fest, auf Papier und nicht auf dem betroffenen System. Die Beweiskette belegt später für jedes Beweisstück: wann gesichert, von wem, wie gelagert, wer Zugriff hatte. Ohne sie lässt sich die Unverfälschtheit der Beweise kaum nachweisen.

Verifizieren: Das Protokoll enthält Entdeckungszeit, betroffene Systeme, informierte Personen und die Uhrzeit jeder Information.

Schritt 2: RAM-Abbild erstellen, noch vor allem anderen

Der Arbeitsspeicher geht beim Ausschalten verloren. RFC 3227 legt deshalb die Reihenfolge nach Flüchtigkeit fest: zuerst Arbeitsspeicher, Netzwerk- und Prozessstatus, dann Datenträger. Starten Sie das Werkzeug vom schreibgeschützten USB-Stick und schreiben Sie die Ausgabe auf einen externen Datenträger.

Windows mit WinPmem (als Administrator):

# Werkzeug vom USB-Stick (E:), Ausgabe auf externes Laufwerk (F:)
E:\tools\winpmem_mini_x64.exe F:\evidence\memory.raw

# Sofort danach Hash erstellen und ablegen
Get-FileHash F:\evidence\memory.raw -Algorithm SHA256 | Out-File F:\evidence\memory.raw.sha256.txt

Unter Linux erfüllt das Kernelmodul LiME denselben Zweck; es muss zum laufenden Kernel passen und vorab gebaut sein.

Verifizieren: Die Datei memory.raw ist etwa so groß wie der installierte Arbeitsspeicher. Dateiname, Größe, SHA-256, Uhrzeit und Ersteller stehen in der Beweiskette.

Schritt 3: Netzwerkstatus dokumentieren, dann isolieren

Aktive Verbindungen, ARP- und DNS-Cache enthalten wichtige Kompromittierungsindikatoren (IOCs). Sichern Sie sie, bevor Sie das System vom Netz trennen.

Windows (als Administrator):

netstat -anob > F:\evidence\netstat.txt
arp -a > F:\evidence\arp.txt
ipconfig /all > F:\evidence\ipconfig.txt
ipconfig /displaydns > F:\evidence\dnscache.txt
route print > F:\evidence\route.txt

Linux (als root):

ss -antup > /mnt/evidence/sockets.txt
ip neigh > /mnt/evidence/arp.txt
ip addr > /mnt/evidence/ip_addr.txt
ip route > /mnt/evidence/routes.txt
cat /etc/resolv.conf > /mnt/evidence/dns.txt

Dann isolieren, nicht abschalten: Netzwerkkabel ziehen, WLAN deaktivieren oder den Switch-Port in ein Quarantäne-VLAN legen. Das System läuft weiter, kann sich aber nicht mehr ausbreiten oder mit dem Angreifer kommunizieren.

Verifizieren: Die Textdateien liegen auf dem externen Datenträger und sind nicht leer. Ein ping auf das Gateway vom betroffenen System schlägt fehl.

Schritt 4: Laufende Prozesse sichern

Die Prozessliste zeigt Schadprozesse, auffällige Eltern-Kind-Beziehungen und ungewöhnliche Pfade.

tasklist /v > F:\evidence\processes.txt
Get-CimInstance Win32_Process |
  Select-Object Name,ProcessId,ParentProcessId,ExecutablePath,CommandLine |
  Export-Csv F:\evidence\processes.csv -NoTypeInformation

Verifizieren: processes.csv enthält für jeden Prozess die Befehlszeile und die ID des Elternprozesses.

Schritt 5: Disk-Image forensisch korrekt erstellen

Arbeiten Sie nie auf dem Originaldatenträger und binden Sie ihn nie beschreibbar ein; das verändert Zeitstempel und Protokolle. Bauen Sie den Datenträger aus und schließen Sie ihn über einen Write-Blocker an ein Analysesystem an, oder erstellen Sie das Image mit einem Werkzeug wie FTK Imager im Format E01.

Linux mit dcfldd (Datenträger über Write-Blocker als /dev/sdX):

dcfldd if=/dev/sdX of=/mnt/evidence/disk.img hash=sha256 hashlog=/mnt/evidence/disk.hash bs=4M conv=noerror,sync
sha256sum /mnt/evidence/disk.img

Ohne dcfldd:

dd if=/dev/sdX bs=4M conv=noerror,sync status=progress | tee /mnt/evidence/disk.raw | sha256sum > /mnt/evidence/disk.sha256

Verifizieren: Der Hash in disk.hash bzw. disk.sha256 stimmt mit einer erneuten Berechnung über das Image überein. Ein zusätzlicher MD5-Hash hilft beim Abgleich mit Werkzeugen, die nur MD5 anzeigen; als Integritätsnachweis dient SHA-256.

Schritt 6: Windows-Ereignisprotokolle und weitere Logs exportieren

Die Ereignisprotokolle sind die Grundlage, um den Angriffsweg zu rekonstruieren. Wichtige Ereignis-IDs: 4624 (Anmeldung), 4625 (fehlgeschlagene Anmeldung), 4648 (Anmeldung mit expliziten Anmeldedaten), 4688 (Prozessstart), 4698 (geplante Aufgabe erstellt).

wevtutil epl Security F:\evidence\Security.evtx
wevtutil epl System F:\evidence\System.evtx
wevtutil epl Application F:\evidence\Application.evtx
# nur falls Sysmon installiert ist:
wevtutil epl "Microsoft-Windows-Sysmon/Operational" F:\evidence\Sysmon.evtx

Ergänzend oder wenn kein vollständiges Image möglich ist, sammelt KAPE die wichtigsten Artefakte:

E:\tools\kape\kape.exe --tsource C: --tdest F:\evidence\kape --target !SANS_Triage

Sichern Sie auch Firewall-, VPN-, Proxy- und Active-Directory-Protokolle. Diese Quellen werden oft nach wenigen Tagen überschrieben.

Verifizieren: Die .evtx-Dateien lassen sich auf dem Analysesystem in der Ereignisanzeige öffnen, jede Datei hat einen Hash-Eintrag in der Beweiskette.

Schritt 7: Meldungen auslösen, drei Stränge parallel

Die Meldepflichten laufen unabhängig voneinander; keine Meldung ersetzt eine andere. Den Ablauf mit Zuständigkeiten und Vorlagen beschreibt Ransomware-Notfallplan: Die ersten 60 Minuten. Kurzüberblick:

Meldung	Frist	Empfänger	Grundlage
Frühe Erstmeldung (NIS2)	spätestens 24 Stunden nach Kenntnis eines erheblichen Sicherheitsvorfalls	Meldestelle von BSI und BBK (mip.bsi.bund.de)	§ 32 Abs. 1 Nr. 1 BSIG
Meldung mit erster Bewertung und IOCs (NIS2)	spätestens 72 Stunden nach Kenntnis	Meldestelle	§ 32 Abs. 1 Nr. 2 BSIG
Abschlussmeldung (NIS2)	spätestens 1 Monat nach der 72-Stunden-Meldung; dauert der Vorfall an, zunächst Fortschrittsmeldung	Meldestelle	§ 32 Abs. 1 Nr. 4, Abs. 2 BSIG
Datenschutzverletzung	unverzüglich, möglichst binnen 72 Stunden nach Bekanntwerden, außer bei voraussichtlich keinem Risiko für Betroffene	zuständige Datenschutzaufsicht	Art. 33 DSGVO
Versicherungsfall	unverzüglich; Einzelheiten im Vertrag	Hotline des Cyber-Versicherers	§ 30 VVG, Folgen verletzter Obliegenheiten § 28 VVG

Die NIS2-Meldungen gelten für besonders wichtige und wichtige Einrichtungen. Unvollständige Angaben sind in der Erstmeldung zulässig und werden mit den Folgemeldungen ergänzt; auch Art. 33 Abs. 4 DSGVO erlaubt eine schrittweise Meldung. Verspätete oder fehlende NIS2-Meldungen sind bußgeldbewehrt, für besonders wichtige Einrichtungen bis 10 Mio. Euro, für wichtige Einrichtungen bis 7 Mio. Euro oder einen Anteil am Jahresumsatz (§ 65 BSIG).

Rufen Sie den Versicherer an, bevor Sie Dienstleister ohne seine Zustimmung beauftragen. Viele Policen schreiben vor, welche Dienstleister eingesetzt werden; eine vorsätzliche oder grob fahrlässige Verletzung solcher Obliegenheiten kann die Leistung mindern oder ausschließen.

Verifizieren: Jede abgegebene Meldung ist mit Uhrzeit, Empfänger und Aktenzeichen bzw. Eingangsbestätigung in der Vorfalldokumentation vermerkt.

Schritt 8: RAM-Abbild analysieren (optional)

Mit eigenem Forensik-Wissen werten Sie das RAM-Abbild auf einem separaten Analysesystem mit Volatility 3 aus, immer an einer Kopie:

vol -f memory.raw windows.info
vol -f memory.raw windows.pslist
vol -f memory.raw windows.netscan
vol -f memory.raw windows.malfind
vol -f memory.raw windows.cmdline

Verifizieren: windows.info gibt Betriebssystemversion und Aufnahmezeitpunkt aus; stimmt beides, ist das Abbild lesbar.

Wann externen IR-Dienstleister einschalten?

Holen Sie einen Forensik-Dienstleister (DFIR) hinzu bei:

• Ransomware oder Verdacht auf Datenabfluss
• Infrastruktur, die das interne Wissen übersteigt
• Vorfällen, deren Dokumentation vor Gericht oder gegenüber Behörden bestehen muss
• Verdacht auf Innentäter
• fehlender Erfahrung mit Beweissicherung

Vereinbaren Sie einen Rahmenvertrag (Retainer) im Voraus und stimmen Sie die Auswahl mit Ihrem Versicherer ab; viele Versicherer führen Listen zugelassener Dienstleister.

Sofortmaßnahmen-Checkliste (ausdruckbar)

• Umfang einschätzen, Geschäftsleitung informieren, Entdeckungszeit notieren
• Jede Aktion minutengenau in der Beweiskette dokumentieren
• RAM-Abbild vom USB-Stick erstellen, Ausgabe auf externes Laufwerk, SHA-256 dokumentieren
• Netzwerkstatus sichern: netstat, arp, ipconfig, DNS-Cache, route
• System vom Netz isolieren, nicht abschalten
• Prozessliste sichern
• Disk-Image über Write-Blocker erstellen, SHA-256 dokumentieren
• Ereignisprotokolle sowie Firewall-, VPN- und AD-Protokolle sichern
• Cyber-Versicherer anrufen
• Bei NIS2-Pflicht: frühe Erstmeldung binnen 24 Stunden
• Bei Personendaten: Meldung an die Datenschutzaufsicht möglichst binnen 72 Stunden
• Forensik-Dienstleister nach Abstimmung mit dem Versicherer einschalten
• Kein System bereinigen oder neu aufsetzen, bevor das Disk-Image gesichert ist

Troubleshooting / Typische Fehler

• System bereits abgeschaltet: Der Arbeitsspeicher ist verloren. Starten Sie das System nicht neu, sondern sichern Sie den Datenträger über einen Write-Blocker und ziehen Sie einen Dienstleister hinzu.
• Originaldatenträger beschreibbar eingebunden: Zeitstempel und Protokolle sind verändert. Dokumentieren Sie genau, was wann geschah, und arbeiten Sie ab sofort nur mit Write-Blocker.
• NIS2-Meldung wegen fehlender Informationen verzögert: Die Erstmeldung darf unvollständig sein. Melden Sie fristgerecht und ergänzen Sie später.
• Nur eine Meldung abgegeben: BSI-Meldung und Meldung an die Datenschutzaufsicht sind getrennte Pflichten. Prüfen Sie immer beide.
• Versicherer zu spät oder erst nach Beauftragung informiert: Das kann den Versicherungsschutz gefährden. Rufen Sie zuerst die Hotline an.
• Hash erst nach der Analyse erstellt: Die Unverfälschtheit lässt sich dann nicht belegen. Hashen Sie direkt nach der Sicherung.
• Werkzeug auf dem betroffenen System gespeichert: Das verändert Dateisystem-Artefakte. Starten Sie Werkzeuge nur vom schreibgeschützten USB-Stick.
• Netzwerkgeräte vergessen: Firewall-, VPN- und Switch-Protokolle werden oft nach wenigen Tagen überschrieben. Sichern Sie sie am ersten Tag.

Häufige Fragen

Muss ich das System abschalten, um Ransomware zu stoppen?

Nein. Die Trennung vom Netz stoppt die Ausbreitung, ohne den Arbeitsspeicher zu löschen. Fahren Sie das System erst nach RAM-Abbild und Disk-Image herunter. Verschlüsselt die Schadsoftware erkennbar noch lokale Daten und ist kein RAM-Abbild möglich, wägen Sie mit Ihrem Dienstleister ab, ob sofortiges Ausschalten den größeren Schaden verhindert.

Bin ich als KMU von NIS2 betroffen?

Betroffen sind Unternehmen der Sektoren in Anlage 1 und 2 zum BSIG, die mindestens 50 Beschäftigte haben oder mehr als 10 Mio. Euro Jahresumsatz und mehr als 10 Mio. Euro Jahresbilanzsumme erreichen (§ 28 BSIG), sowie einige Einrichtungen unabhängig von der Größe. Prüfen Sie das mit der Betroffenheitsprüfung des BSI. Als Zulieferer können Sie vertraglich zu NIS2-Maßnahmen verpflichtet sein, ohne selbst meldepflichtig zu sein.

Wann muss der Cyber-Versicherer informiert werden?

Unverzüglich nach Kenntnis (§ 30 VVG); die genaue Frist und Form regelt Ihr Vertrag. Rufen Sie sofort an und reichen Sie die schriftliche Meldung nach.

Gilt die 72-Stunden-Frist der DSGVO auch, wenn noch unklar ist, ob Personendaten betroffen sind?

Die Frist beginnt, sobald Sie mit hinreichender Sicherheit wissen, dass personenbezogene Daten betroffen sind. Klären Sie das zügig. Ist es wahrscheinlich, melden Sie vorsorglich und ergänzen Sie die Angaben schrittweise (Art. 33 Abs. 4 DSGVO); dokumentieren Sie jede Verletzung auch dann, wenn Sie nicht melden (Art. 33 Abs. 5 DSGVO).

Reicht ein MD5-Hash für forensische Beweissicherung?

Nein. MD5 ist nicht kollisionsresistent. Verwenden Sie SHA-256; einen zusätzlichen MD5-Hash können Sie zum Abgleich mit älteren Werkzeugen mitführen. Erstellen Sie die Hashes direkt nach der Sicherung und tragen Sie sie mit Uhrzeit und Ersteller in die Beweiskette ein.

Wann brauche ich einen externen IR-Dienstleister?

Bei Ransomware, Verdacht auf Datenabfluss, komplexer Infrastruktur, Insider-Verdacht oder fehlender eigener Erfahrung, siehe Abschnitt oben. Ein vorher vereinbarter Rahmenvertrag spart im Ernstfall Zeit.

Fazit

Die ersten Stunden nach einem Cybervorfall entscheiden darüber, ob Beweise erhalten bleiben. Die Reihenfolge lautet: nicht abschalten, RAM-Abbild erstellen, Netzwerkstatus sichern, isolieren, Datenträger und Protokolle sichern, jeden Schritt mit Hash dokumentieren. Parallel lösen Sie die Meldungen an BSI, Datenschutzaufsicht und Versicherer aus. Bereiten Sie USB-Stick, Kontaktliste und Incident-Response-Plan vor dem Ernstfall vor. Die organisatorischen Datenschutzmaßnahmen beschreibt DSGVO TOMs und Auftragsverarbeitung in der Praxis.

Weiterführende Anleitungen und Quellen

• Ransomware-Notfallplan: Die ersten 60 Minuten
• DSGVO TOMs und Auftragsverarbeitung in der Praxis
• Linux-Server härten: CIS Benchmark Debian/Ubuntu
• Logs lesen: journalctl und /var/log unter Linux

Quellen: § 32 BSIG · § 65 BSIG · Art. 33 DSGVO · § 30 VVG · RFC 3227