Ein Cybervorfall ist erkannt – und genau jetzt passiert der häufigste und kostspieligste Fehler: Das betroffene System wird sofort abgeschaltet. Damit vernichtest du unwiederbringlich alle RAM-Inhalte: laufende Malware, Encryption Keys (bei Ransomware mitunter noch im Speicher), aktive Verbindungen zum Command-and-Control-Server, Passwort-Hashes. Parallel laufen drei unabhängige Meldefristen an, die gleichzeitig bedient werden müssen. Diese Anleitung zeigt dir die korrekte Reihenfolge der Beweissicherung, die vollständige Meldekette und eine ausdruckbare Sofortmaßnahmen-Checkliste – damit du weder forensische Beweise noch Versicherungsschutz vernichtest.

Voraussetzungen

Vorbereiteter USB-Stick (schreibgeschützt) mit forensischen Tools: WinPmem, DumpIt, FTK Imager, KAPE, dcfldd – niemals Tools während eines Vorfalls vom Internet herunterladen
Externes Speichermedium mit ausreichend Kapazität: RAM-Dump (= physischer RAM-Größe), Disk-Image (= Festplattenkapazität), separate Laufwerke empfohlen
Hardware-Write-Blocker (z. B. Tableau T35u, Logicube Forensic Dossier) oder Software-Write-Blocker (Arsenal Image Mounter mit Read-Only-Flag)
Papierbasierte Chain-of-Custody-Formulare oder Case-Management-Tool (TheHive) für Beweisketten-Dokumentation
Kontaktliste ausgedruckt (oder offline verfügbar): Cyber-Versicherer-Hotline, externer IR-Dienstleister, BSI-Notfallnummer +49 228 99 9582-444, zuständige Datenschutzbehörde, interner Datenschutzbeauftragter, Geschäftsführung, Rechtsanwalt
BSI-Meldeportal-Zugangsdaten: Registrierung unter mip.bsi.bund.de idealerweise vor dem Vorfall erledigt (Pflicht für NIS2-Betroffene)
NIS2-Selbsteinschätzung abgeschlossen: Betrifft dein Unternehmen die NIS2-Pflichten (Sektor, Größe ab 50 Mitarbeiter oder 10 Mio. Euro Jahresumsatz in definierten Sektoren)?
Schriftlich dokumentierter Incident Response Plan (IRP) – ohne vorbereiteten Plan verlierst du in den ersten Minuten wertvolle Zeit

Schritt 1: Ruhe bewahren und Scope einschätzen

Bevor du irgendetwas anklickst, drückst oder abschaltest: Atme durch. Die nächste Entscheidung kostet dich entweder Beweise oder Ausbreitung. Stelle zunächst fest, wie viele Systeme betroffen sind und ob der Angriff noch aktiv läuft. Aktiviere sofort dein Incident-Response-Team und informiere die Geschäftsführung – die rechtliche Verantwortung für Meldefristen liegt bei ihr und kann nicht delegiert werden.

Halte alle Aktionen mit Zeitstempel auf die Minute genau fest – auf Papier, nicht auf dem betroffenen System. Diese Chain of Custody muss später belegen: wann gesammelt, durch wen, wie gelagert, wer hatte Zugang. Ohne korrekte Chain of Custody sind Beweise vor Gericht nicht verwertbar.

Schritt 2: RAM-Dump erstellen – noch vor allem anderen

RAM ist flüchtig: Mit dem Stromverlust verschwinden Encryption Keys, laufende Malware, Netzwerkverbindungen und Passwort-Hashes für immer. Die Order of Volatility (RFC 3227) schreibt vor, was zuerst gesichert wird: RAM, dann Netzwerkstatus, dann laufende Prozesse, dann Disk-Artefakte.

Führe den RAM-Dump von einem schreibgeschützten USB-Stick aus – niemals das Tool auf dem betroffenen System speichern. Leite die Ausgabe auf ein externes Laufwerk um.

Windows – WinPmem (empfohlen, kostenlos):

# Als Administrator ausfuehren – Tool vom USB-Stick, Ausgabe auf externes Laufwerk
E:\tools\winpmem_mini_x64.exe F:\evidence\memory.raw

# Sofort anschliessend SHA-256 Hash erstellen und dokumentieren:
Get-FileHash F:\evidence\memory.raw -Algorithm SHA256 | Out-File F:\evidence\memory.raw.sha256.txt
certutil -hashfile F:\evidence\memory.raw SHA256 >> F:\evidence\memory.raw.sha256.txt

Windows – DumpIt (Magnet Forensics, Alternative):

# Stilles Dump-Kommando, Ausgabe auf externes Laufwerk:
E:\tools\DumpIt.exe /output F:\evidence\memory.raw /quiet

# Hash-Verifikation (MD5 + SHA256 parallel):
certutil -hashfile F:\evidence\memory.raw MD5
certutil -hashfile F:\evidence\memory.raw SHA256

Unmittelbar nach dem Dump: Dateiname, Dateigröße, SHA-256, Zeitstempel und Ersteller in die Chain-of-Custody-Dokumentation eintragen. Ohne diesen Schritt ist das Image anfechtbar.

Schritt 3: Netzwerkstatus dokumentieren, dann isolieren

Bevor du das Netzwerkkabel ziehst: Aktiven Netzwerkstatus sichern. Aktive Verbindungen zum C2-Server, ARP-Cache und DNS-Konfiguration sind wichtige IOCs (Indicators of Compromise). Erst danach isolieren.

Netzwerkstatus sichern (Windows, als Admin):

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

Netzwerkstatus sichern (Linux):

ss -antp > /evidence/netstat.txt
arp -n > /evidence/arp.txt
ip addr > /evidence/ip_addr.txt
ip route > /evidence/routes.txt
cat /etc/resolv.conf > /evidence/dns.txt

Jetzt isolieren – aber nicht abschalten: Netzwerkkabel physisch trennen, WLAN deaktivieren, VLAN-Isolation am Switch konfigurieren. Das System läuft weiter – Isolation verhindert weiteres Lateral Movement und Command-and-Control-Kommunikation, ohne RAM-Inhalte zu vernichten.

Schritt 4: Laufende Prozesse sichern

Nach RAM-Dump und Netzwerk-Dokumentation: Prozessliste des laufenden Systems sichern. Malware-Prozesse, verdächtige Eltern-Kind-Beziehungen und ungewöhnliche Pfade werden hier sichtbar.

# Windows – vollstaendige Prozessliste mit Pfaden:
tasklist /v > F:\evidence\processes.txt
Get-Process | Select-Object Name,Id,Path,CommandLine | Export-Csv F:\evidence\processes.csv
wmic process get Name,ProcessId,ExecutablePath,CommandLine /format:csv > F:\evidence\wmic_processes.csv

Schritt 5: Disk-Image forensisch korrekt erstellen

Nur mit Hardware-Write-Blocker oder Write-Blocking-Software – niemals den Originaldatenträger im Read-Write-Modus mounten oder darauf arbeiten. Das verändert Zeitstempel (atime), Swap-Dateien und Logeinträge und macht das Image vor Gericht anfechtbar.

Linux – dcfldd (forensisches dd mit integriertem Hashing):

# Disk-Image mit automatischem SHA-256 Hash-Log:
dcfldd if=/dev/sda of=/mnt/evidence/disk.img hash=sha256 hashlog=/mnt/evidence/disk.hash bs=512 conv=noerror,sync

# Verifikation nach Abschluss:
sha256sum /mnt/evidence/disk.img

Linux – dd + Hash (Fallback ohne dcfldd):

# Image erstellen und gleichzeitig hashen:
dd if=/dev/sda conv=noerror,sync bs=64K | tee /mnt/evidence/disk.raw | sha256sum > /mnt/evidence/disk.sha256

# Groesse pruefen:
ls -lh /mnt/evidence/disk.raw

Zielformat: E01 (Expert Witness Format) oder raw/dd. Immer MD5 plus SHA-256 parallel erstellen – MD5 allein gilt als kollisionsanfällig und wird vor deutschen Gerichten zunehmend kritisch gesehen.

Schritt 6: Windows Event Logs und System-Logs exportieren

Windows Event Logs sind entscheidend für die Angriffspfad-Rekonstruktion. Schlüssel-Event-IDs: 4624 (erfolgreicher Login), 4625 (fehlgeschlagener Login), 4688 (Prozessstart), 4648 (Logon mit expliziten Credentials), 4698 (geplanter Task erstellt).

# Windows Event Logs exportieren (als Admin):
wevtutil epl Security F:\evidence\Security.evtx
wevtutil epl System F:\evidence\System.evtx
wevtutil epl Application F:\evidence\Application.evtx
wevtutil epl "Microsoft-Windows-Sysmon/Operational" F:\evidence\Sysmon.evtx

Schnelle Artefaktsammlung mit KAPE (wenn kein vollständiges Disk-Image möglich oder als Ergänzung):

# KAPE Basissammlung (Prefetch, Registry-Hives, EventLogs, Browser-History):
kape.exe --tsource C: --tdest F:\evidence --target !BasicCollection,EventLogs,RegistryHives,Prefetch

# Compound-Target fuer Ransomware-Vorfaelle (SANS Triage):
kape.exe --tsource C: --tdest F:\evidence --target !SANS_Triage

Wichtig: Nicht nur System-Logs sichern – auch Firewall-Logs, VPN-Concentrator-Logs, Switch-Port-Logs und Active-Directory-Security-Logs. Viele dieser Quellen haben kurze Rotation (Standard: 7–30 Tage) und werden überschrieben, bevor jemand daran denkt.

Schritt 7: Meldekette auslösen – drei parallele Fristen

Nach der Beweissicherung startet die Meldekette. Drei unabhängige Meldepflichten laufen gleichzeitig – keine ersetzt die andere, und jede versäumte Meldung zieht ein separates Bußgeld nach sich.

Meldepflicht	Frist	Empfänger	Besonderheit
NIS2-Frühwarnung	24 Stunden	BSI (mip.bsi.bund.de)	Unvollständig ist erlaubt, nicht melden ist bußgeldbewehrt
NIS2-Erstmeldung mit IOCs	72 Stunden	BSI (mip.bsi.bund.de)	Indicators of Compromise dokumentieren
NIS2-Abschlussbericht	1 Monat	BSI	Vollständige Aufarbeitung
DSGVO Art. 33 Meldung	72 Stunden	Landesdatenschutzbehörde	Nur wenn Personendaten betroffen; läuft parallel zur NIS2-Meldung
Cyber-Versicherer	Unverzüglich (24–48 h)	Versicherer-Hotline	Verspätung kann Deckung verwirken (§ 28 VVG)

BSI-Meldeprinzip „Schnelligkeit vor Vollständigkeit": Die 24h-Frühwarnung ist kein vollständiger Incident-Report. Unvollständige Erstmeldungen können durch Folgemeldungen korrigiert werden. Nichts zu melden ist schlimmer als unvollständig zu melden. Fristbeginn ist die Kenntniserlangung durch Mitarbeiter – nicht der Zeitpunkt der Bestätigung oder des abgeschlossenen Scope.

Cyber-Versicherer sofort anrufen – telefonisch, noch bevor externe Dienstleister ohne Zustimmung des Versicherers beauftragt werden. Viele Policen enthalten Obliegenheitsklauseln, die bei verspäteter Meldung oder unautorisierter Beauftragung die Deckung kürzen oder komplett verweigern. Viele Versicherer stellen seit 2025 NIS2-Compliance als Deckungsvoraussetzung.

Das NIS2UmsuCG gilt seit 6. Dezember 2025 ohne Übergangsfrist. Bußgelder nach NIS2: bis zu 10 Mio. Euro für wesentliche Einrichtungen, bis zu 7 Mio. Euro für wichtige Einrichtungen. Die persönliche Haftung liegt bei der Geschäftsführung und kann nicht delegiert werden.

Tipp für eine verwandte Vorbereitung: Der Artikel Ransomware-Notfallplan: Die ersten 60 Minuten ergänzt diese Anleitung um spezifische Ransomware-Reaktionsschritte.

Schritt 8: RAM-Dump analysieren (optional, nach Sicherung)

Nach der Beweissicherung und wenn internes DFIR-Know-how vorhanden ist, ermöglicht Volatility 3 die Analyse des RAM-Dumps ohne das Originalsystem zu beeinflussen:

# Volatility 3 - Basisanalyse (Python, plattformuebergreifend):
python3 vol.py -f memory.raw windows.info
python3 vol.py -f memory.raw windows.pslist
python3 vol.py -f memory.raw windows.netscan
python3 vol.py -f memory.raw windows.malfind
python3 vol.py -f memory.raw windows.cmdline

Wann externen IR-Dienstleister einschalten?

Nicht jeder Vorfall muss intern abgearbeitet werden. Externe DFIR-Dienstleister sind Pflicht bei:

Ransomware mit Datenleak-Verdacht oder Nation-State-Verdacht
Komplexer Infrastruktur, die internes Know-how übersteigt
Regulatorischen Implikationen, die gerichtsfeste Dokumentation erfordern
Insider-Verdacht (internes Team potenziell befangen)
Fehlendem internem DFIR-Know-how für saubere Chain-of-Custody-Dokumentation

Empfehlung: IR-Retainer im Voraus vereinbaren. Ein Kaltanruf im Ernstfall kostet oft 2–4 Stunden Verzögerung. Viele Versicherer haben Partnerlisten zugelassener IR-Dienstleister – Abstimmung mit dem Versicherer vor der Beauftragung ist obligatorisch.

Sofortmaßnahmen-Checkliste (ausdruckbar)

Ruhe bewahren, Scope einschätzen, Geschäftsführung informieren
Alle Aktionen mit Zeitstempel (Minute) in Chain-of-Custody-Formular dokumentieren
RAM-Dump vom USB-Stick erstellen (WinPmem / DumpIt / LiME), Ausgabe auf externes Laufwerk
SHA-256 Hash des RAM-Dumps erstellen und dokumentieren
Netzwerkstatus sichern: netstat, arp, ipconfig, route, dns
System vom Netzwerk isolieren (Kabel, WLAN, VLAN) – nicht abschalten
Laufende Prozesse sichern (tasklist, Get-Process, wmic)
Disk-Image mit Write-Blocker erstellen (E01 oder raw), MD5 + SHA-256 dokumentieren
Windows Event Logs exportieren (Security, System, Application, Sysmon)
Firewall-Logs, VPN-Logs, AD-Security-Logs sichern (Rotation beachten)
Cyber-Versicherer anrufen (Hotline, telefonisch, unverzüglich)
NIS2-Frühwarnung ans BSI binnen 24 Stunden (mip.bsi.bund.de) – falls NIS2-pflichtig
DSGVO-Meldung an Datenschutzbehörde binnen 72 Stunden – falls Personendaten betroffen
Externen IR-Dienstleister einschalten (falls erforderlich, nach Versicherer-Abstimmung)
Kein System bereinigen oder neu aufsetzen vor vollständigem Disk-Image

Troubleshooting / Typische Fehler

System sofort abgeschalten: RAM-Inhalte unwiederbringlich verloren. Wenn bereits geschehen: Disk-Image sofort sichern, keine weiteren Änderungen, externen IR-Dienstleister einschalten. Für zukünftige Vorfälle: USB-Stick mit Tools und diese Checkliste griffbereit halten.
Originaldatenträger im Read-Write-Modus gemountet: Verändert Zeitstempel (atime), Swap-Dateien, Log-Einträge. Image vor Gericht anfechtbar. Immer Hardware-Write-Blocker (Tableau T35u) oder Arsenal Image Mounter mit Read-Only-Flag verwenden.
NIS2-Meldung wegen „unvollständiger Information" verzögert: Das BSI-Prinzip „Schnelligkeit vor Vollständigkeit" erlaubt ausdrücklich unvollständige Erstmeldungen. Korrektur via Folgemeldung möglich. Keine Meldung bei Kenntnis ist eine Ordnungswidrigkeit.
DSGVO-Meldung nach NIS2-Meldung vergessen: Beide Regime laufen vollständig unabhängig. Jede versäumte Meldung zieht ein separates Bußgeld nach sich. BSI = technische Meldung, Datenschutzbehörde = Personendaten-Meldung – immer beide prüfen.
Cyber-Versicherer zu spät oder nach Beauftragung externer Dienstleister informiert: Obliegenheitsklauseln können Deckung kürzen oder verweigern. Versicherer-Hotline vor Beauftragung externer Dienstleister anrufen.
Hash-Wert erst nach der Analyse erstellt: Ohne dokumentierten Hash unmittelbar nach Erfassung kann die Integrität des Beweismittels nicht bewiesen werden. Hash muss in Chain-of-Custody-Dokumentation mit Zeitstempel und Ersteller vermerkt sein.
RAM-Dump-Tool auf dem Zielsystem gespeichert: Schreibzugriff verändert Filesystem-Artefakte (Zeitstempel, MFT-Einträge). Tools immer von schreibgeschütztem USB-Stick ausführen.
Nur System-Logs gesichert, Netzwerkgeräte vergessen: Firewall-Logs, VPN-Logs, Switch-Port-Logs haben oft kurze Rotation (7–30 Tage). Sofort sichern, bevor sie überschrieben werden.

Häufige Fragen

Muss ich das System abschalten, um Ransomware zu stoppen?

Nein. Netzwerk-Isolation (Kabel ziehen, WLAN deaktivieren) stoppt die Ausbreitung sofort, ohne den RAM zu löschen. Viele Ransomware-Varianten halten Encryption Keys kurzzeitig im RAM – ein RAM-Dump direkt nach Entdeckung kann diese sichern. Erst nach RAM-Dump und Disk-Image darf das System heruntergefahren werden.

Bin ich als KMU von NIS2 betroffen?

NIS2 erfasst seit Dezember 2025 wesentliche und wichtige Einrichtungen ab 50 Mitarbeitern oder 10 Mio. Euro Jahresumsatz in definierten Sektoren (Energie, Wasser, Digitale Infrastruktur, Gesundheit, Post, Transport u. a.) sowie deren kritische Lieferanten. Als Lieferant kritischer Infrastruktur kannst du auch ohne eigene Betroffenheit vertraglich zur NIS2-Compliance verpflichtet sein. Selbsteinschätzung unter bsi.bund.de prüfen.

Wann muss der Cyber-Versicherer informiert werden?

Unverzüglich nach Kenntnisnahme – die genaue Frist steht im Versicherungsvertrag (häufig 24–72 Stunden, manche Policen verlangen sofortige telefonische Meldung). Verspätete oder unterlassene Meldung kann zur Leistungsverweigerung führen (§ 28 VVG). Im Zweifel: Sofort anrufen, schriftliche Meldung nachreichen.

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

Ja. Die Frist beginnt mit Kenntniserlangung des Vorfalls, nicht mit Sicherheit über den Umfang. Bei Unsicherheit sollte vorsorglich gemeldet werden („vorläufige Meldung") und später präzisiert werden. Zu spät melden ist bußgeldbewehrt, zu früh melden ist korrigierbar.

Reicht ein MD5-Hash für forensische Beweissicherung?

Nein. MD5 gilt als kollisionsanfällig und wird vor deutschen Gerichten zunehmend kritisch gesehen. Standard ist MD5 plus SHA-256 parallel. Manche Labors verwenden zusätzlich SHA-512. Beide Hashes müssen unmittelbar nach Erfassung erstellt und in der Chain-of-Custody-Dokumentation mit Zeitstempel und Ersteller vermerkt werden.

Wann brauche ich einen externen IR-Dienstleister?

Bei kritischen Vorfällen (Ransomware mit Datenleak, Nation-State-Verdacht, komplexe Infrastruktur), fehlendem internem DFIR-Know-how, bei regulatorischen Implikationen, die gerichtsfeste Dokumentation erfordern, oder wenn das interne Team befangen ist (z. B. Insider-Verdacht). IR-Retainer im Voraus abschließen – Kaltanruf im Ernstfall kostet oft 2–4 Stunden Verzögerung.

Fazit

Die ersten Minuten nach einem Cybervorfall sind forensisch die wichtigsten – und gleichzeitig die, in denen die meisten Fehler passieren. Die Regel ist einfach: Nie sofort abschalten, immer erst RAM-Dump, dann isolieren, dann dokumentieren und melden. Wer das beherzigt, sichert nicht nur Beweise für Strafverfolgung und Versicherungserstattung, sondern erfüllt auch die drei parallelen Meldefristen, die ab dem Moment der Kenntnisnahme laufen – unabhängig davon, ob das interne Team noch mitten in der Analyse steckt. Ein vorbereiteter USB-Stick mit forensischen Tools, eine ausgedruckte Kontaktliste und ein schriftlicher Incident Response Plan kosten wenig Zeit im Voraus und sparen im Ernstfall Stunden, die über den Versicherungsschutz entscheiden können. Lies ergänzend dazu auch DSGVO TOMs und Auftragsverarbeitung in der Praxis, um die organisatorischen Maßnahmen rund um Datenschutz und Meldepflichten vollständig zu verankern.

Weiterführende Anleitungen und Quellen

Quellen: BSI NIS-2-Meldepflicht (bsi.bund.de) · NIS2Compass Meldepflichten · Transferstelle Cybersicherheit Meldepflichten im IT-Notfall · CyberDirekt Cyberversicherung Obliegenheiten · Secjur NIS2 Meldepflicht Fristen 2026 · Cyber Forensics Academy Disk Imaging Tools