Strukturiertes Incident Response Management nach NIST-Framework — von der Detektion über forensische Beweissicherung und Containment bis zur vollständigen Wiederherstellung und nachhaltigen Härtung der Infrastruktur.
Die ersten 24 Stunden — Schritt für Schritt durch den Ernstfall
Die ersten Stunden nach der Erkennung eines Sicherheitsvorfalls sind entscheidend — und genau hier werden die meisten Fehler gemacht. Der häufigste und folgenschwerste: Systeme sofort herunterfahren. Damit vernichten Sie flüchtige Beweise im RAM — laufende Prozesse, aktive Netzwerkverbindungen, entschlüsselte Malware-Payloads und Angreiferaktivitäten, die nirgendwo auf der Festplatte sichtbar sind. Stattdessen gilt: Ruhe bewahren, klassifizieren, Incident Commander aktivieren. Handelt es sich um einen Datenverlust, Ransomware, einen Advanced Persistent Threat (APT) oder eine Insider-Bedrohung? Die Klassifizierung bestimmt die gesamte weitere Vorgehensweise, die benötigten Ressourcen und die gesetzlichen Meldepflichten.
In den Stunden 1 bis 4 steht die forensische Beweissicherung im Vordergrund. Die goldene Regel lautet: Memory Dump zuerst, dann Festplattenimage. Unter Windows erstellt winpmem einen vollständigen RAM-Dump, unter Linux avml (Acquire Volatile Memory for Linux). Erst danach folgt das Disk-Image mit FTK Imager oder dd. Parallel dazu wird eine Netzwerkerfassung gestartet, um laufende Command-and-Control-Kommunikation (C2) zu dokumentieren. Jeder Schritt wird in einer Chain-of-Custody-Dokumentation lückenlos protokolliert: Wer hat wann was an welchem System getan? Screenshots von allem. Diese Dokumentation ist nicht nur für die interne Analyse essenziell, sondern auch für eine eventuelle Strafverfolgung und die Cyber-Versicherung.
Ab Stunde 4 beginnt das Containment — die Eindämmung des Vorfalls ohne Beweisvernichtung. Betroffene Systeme werden nicht ausgeschaltet, sondern netzwerkseitig isoliert: VLAN-Wechsel, Firewall-Regeln oder Switch-Port-Deaktivierung. Bekannte Indicators of Compromise (IOCs) — IP-Adressen, Domains, Datei-Hashes — werden sofort auf Firewall und Proxy blockiert. Kompromittierte Benutzerkonten werden deaktiviert. Wenn ein Active-Directory-Kompromiss vermutet wird, muss das KRBTGT-Passwort zurückgesetzt werden — ein Schritt, der sorgfältig geplant werden muss, da er alle Kerberos-Tickets invalidiert. Ab Stunde 8 beginnt die eigentliche Investigation: Timeline-Analyse mit Velociraptor oder KAPE, Auswertung der Windows Event Logs (insbesondere Event-IDs 4624, 4625, 4672, 4688 und 7045) und die Suche nach Lateral Movement und Persistenzmechanismen.
- Stunde 0–1 — Detektion & Erstbewertung: Nicht in Panik verfallen. Vorfall klassifizieren (Datenverlust, Ransomware, APT, Insider). Incident Commander benennen, der alle Entscheidungen koordiniert. Systeme NICHT herunterfahren — flüchtige Beweise im RAM sind oft wertvoller als alles auf der Festplatte. Incident-Ticket anlegen und Zeitleiste beginnen.
- Stunde 1–4 — Beweissicherung: Memory Dump zuerst (
winpmemfür Windows,avmlfür Linux), dann Disk-Image (FTK Imager,dd). Netzwerkerfassung starten. Chain-of-Custody-Dokumentation für jeden Beweisgegenstand. Screenshots aller relevanten Bildschirme. Hash-Werte (SHA256) aller gesicherten Images dokumentieren. - Stunde 4–8 — Containment: Betroffene Systeme netzwerkseitig isolieren (VLAN-Wechsel, Firewall-Block — nicht ausschalten!). IOCs auf Firewall/Proxy blockieren. Kompromittierte Accounts deaktivieren. Bei AD-Kompromiss: KRBTGT-Reset vorbereiten. VPN-Zugänge betroffener Benutzer sperren.
- Stunde 8–24 — Investigation: Timeline-Analyse mit Velociraptor oder KAPE. Windows Event Logs auswerten: 4624/4625 (Anmeldung/fehlgeschlagen), 4672 (Privilegien), 4688 (neue Prozesse), 7045 (neue Services). Lateral Movement suchen: PsExec, WMI, WinRM, RDP-Spuren. Scheduled Tasks, Services und Registry-Run-Keys auf Persistenzmechanismen prüfen.
- NIS2-Meldepflicht: Erstmeldung an das BSI innerhalb von 24 Stunden, detaillierter Bericht innerhalb von 72 Stunden, Abschlussbericht innerhalb von 1 Monat. Zusätzlich DSGVO Art. 33: Meldung an die Datenschutzaufsichtsbehörde innerhalb von 72 Stunden bei personenbezogenen Daten. Versäumnis kann zu erheblichen Bußgeldern führen.
- Kommunikation: Information an Management, Rechtsabteilung, PR-Abteilung — in dieser Reihenfolge. Keine Details über potenziell kompromittierte Kanäle kommunizieren (E-Mail könnte mitgelesen werden!). Out-of-Band-Kommunikation nutzen: Signal, persönliche Mobiltelefone, physische Meetings. Kein öffentliches Statement ohne Abstimmung mit Rechtsabteilung.
IOC-Hunting & Log-Analyse — Den Angreifer finden
Die Suche nach Indicators of Compromise (IOCs) ist der Kern jeder forensischen Untersuchung. IOCs sind die digitalen Spuren, die ein Angreifer hinterlässt: Datei-Hashes von Malware, IP-Adressen von Command-and-Control-Servern, verdächtige Domänennamen, Registry-Schlüssel, Mutex-Namen und charakteristische User-Agent-Strings. Die Kunst besteht darin, diese Spuren in den riesigen Mengen an Log-Daten zu finden. Windows Event Logs sind dabei die wichtigste Quelle: Event-ID 4624 mit Logon-Type 10 zeigt RDP-Anmeldungen, Event-ID 4688 zeigt neu gestartete Prozesse — allerdings nur, wenn Command Line Auditing aktiviert ist (standardmäßig deaktiviert!). Event-ID 1102 — das Löschen des Security-Audit-Logs — ist fast immer ein Red Flag und sollte sofortige Alarmierung auslösen.
Für die Memory-Forensik ist Volatility das Standardwerkzeug. Der Befehl vol.py -f memdump.raw windows.pslist listet alle laufenden Prozesse auf, windows.netscan zeigt Netzwerkverbindungen aus dem Speicher (auch solche, die netstat nicht mehr anzeigt), und windows.malfind sucht nach injiziertem Code in Prozessspeicherbereichen — ein typisches Merkmal von Fileless Malware, die ausschließlich im RAM lebt und keine Dateien auf der Festplatte hinterlässt. Memory-Forensik enthüllt oft, was Disk-Forensik übersieht: laufende Backdoors, entschlüsselte Payloads und aktive C2-Verbindungen.
Das MITRE ATT&CK Framework ist unverzichtbar, um die beobachteten Taktiken, Techniken und Prozeduren (TTPs) des Angreifers systematisch zu kartieren. Durch das Mapping auf ATT&CK können Sie nicht nur dokumentieren, was der Angreifer getan hat, sondern auch vorhersagen, was er als Nächstes tun wird. Häufig beobachtete Techniken: T1059 (Command & Scripting Interpreter — PowerShell, cmd), T1053 (Scheduled Task/Job — Persistenz), T1021 (Remote Services — Lateral Movement), T1078 (Valid Accounts — gestohlene Zugangsdaten). Sigma-Regeln — ein offenes Format für SIEM-Detektionsregeln — können automatisch in Splunk-, Elastic- oder QRadar-Queries konvertiert werden und liefern sofort einsetzbare Detektionen für Mimikatz, PsExec, verdächtige PowerShell-Aktivitäten und DCSync-Angriffe.
- Windows Event Logs — Kritische IDs: 4624 Type 10 (RDP-Anmeldung), 4688 (neuer Prozess — Command Line Auditing muss aktiviert sein!), 7045 (neuer Service installiert), 4697 (Service installiert via SCM), 1102 (Audit-Log gelöscht = Red Flag!), Sysmon Event 1 (Prozesserstellung mit Hash), Sysmon Event 3 (Netzwerkverbindung mit Ziel-IP).
- Linux-Forensik:
/var/log/auth.log(SSH-Anmeldungen und sudo-Nutzung),last -f /var/log/wtmp(Login-Historie),find / -mtime -7 -type f(kürzlich geänderte Dateien),cat /etc/crontabundls /etc/cron.d/(Persistenzmechanismen),/proc/PID/exe(Binary eines laufenden Prozesses),ss -tlnp(lauschende Ports mit Prozessname). - IOC-Typen und Austausch: Datei-Hashes (MD5/SHA256), IP-Adressen, Domänennamen, YARA-Regeln, Registry-Schlüssel, Mutex-Namen, User-Agent-Strings. Austausch im STIX/TAXII-Format über Plattformen wie MISP (Malware Information Sharing Platform). Abgleich gegen VirusTotal, AbuseIPDB und OTX AlienVault für Threat Intelligence.
- MITRE ATT&CK-Mapping: Beobachtete TTPs auf das ATT&CK-Framework mappen, um nächste Angreiferschritte vorherzusagen. Häufig: T1059 (Command & Scripting Interpreter), T1053 (Scheduled Task), T1021 (Remote Services), T1078 (Valid Accounts), T1003 (OS Credential Dumping). ATT&CK Navigator für visuelle Darstellung nutzen.
- Memory-Forensik mit Volatility:
vol.py -f memdump.raw windows.pslist(laufende Prozesse),windows.netscan(Netzwerkverbindungen aus dem Speicher),windows.malfind(injizierter Code — Fileless Malware). Memory-Forensik enthüllt, was Disk-Forensik übersieht: entschlüsselte Payloads, aktive Backdoors, C2-Verbindungen. - Sigma-Regeln für SIEM-Detektion: Open-Source-Detektionsregeln im universellen Format, konvertierbar nach Splunk, Elastic, QRadar, Microsoft Sentinel. Wichtige Regeln: Mimikatz-Erkennung (Zugriff auf lsass.exe), PsExec-Nutzung (Named Pipes), verdächtige PowerShell (Base64-kodierte Befehle,
-enc-Parameter), DCSync-Angriff (Directory Replication Service).
Recovery & Lessons Learned — Nach dem Vorfall
Die Eradication-Phase ist der kritischste Schritt vor der Wiederherstellung: Alle Persistenzmechanismen des Angreifers müssen entfernt werden, bevor Systeme wieder ans Netzwerk angeschlossen werden. Dazu gehören Scheduled Tasks, Windows-Services, Registry-Run-Keys, WMI-Event-Subscriptions, DLL-Hijacking und manipulierte Group Policy Objects (GPOs). Die sicherste Variante ist der vollständige Neuaufbau kompromittierter Systeme aus bekannten sauberen Images — ein bloßes „Bereinigen“ reicht nicht, da Rootkits und Bootkits eine Erkennung zuverlässig umgehen können. Bei einem bestätigten Domänen-Kompromiss müssen sämtliche Passwörter zurückgesetzt werden — nicht nur die der kompromittierten Konten.
Die Wiederherstellungsreihenfolge ist entscheidend und muss strikt eingehalten werden: Zuerst DNS/DHCP (ohne Namensauflösung funktioniert nichts), dann die Domain Controller (aus einem Backup vor dem Kompromittierungszeitpunkt!), dann kritische Server und zuletzt Workstations. Jedes System muss einzeln getestet werden, bevor es in die Produktionsumgebung zurückkehrt. Besonders bei einem AD-Kompromiss ist der KRBTGT-Doppelreset erforderlich: Das KRBTGT-Passwort wird zweimal zurückgesetzt, mit einem Mindestabstand von 12 Stunden. Der erste Reset invalidiert alle aktuellen Kerberos-Tickets (Lebensdauer: 10 Stunden), der zweite stellt sicher, dass keine zwischengespeicherten alten Tickets übrig bleiben. Dieser Schritt verursacht zwangsläufig Service-Unterbrechungen und muss sorgfältig geplant werden.
Innerhalb von zwei Wochen nach dem Vorfall sollte ein Lessons-Learned-Meeting stattfinden — keine Schuldzuweisung, sondern systematische Analyse: Was ist passiert? Wann wurde der Vorfall erkannt? Was hat funktioniert, was nicht? Die Ergebnisse fließen in eine aktualisierte Incident-Response-Dokumentation ein. Darüber hinaus müssen konkrete Härtungsmaßnahmen umgesetzt werden: Detektionsregeln für die beobachteten TTPs implementieren, Netzwerksegmentierung verbessern, fehlende Log-Quellen anbinden und regelmäßige Tabletop-Exercises (quartalsweise) etablieren, um die Reaktionsfähigkeit des Teams kontinuierlich zu verbessern. Wenn die interne CSIRT-Kapazität nicht ausreicht, sollte ein MDR-Dienst (Managed Detection & Response) in Betracht gezogen werden.
- Eradication — Persistenz vollständig entfernen: Alle Persistenzmechanismen identifizieren und entfernen: Scheduled Tasks, Services, Registry Run-Keys, WMI-Subscriptions, manipulierte GPOs. Kompromittierte Systeme vollständig neu aufbauen aus sauberen Images — nicht bloß „bereinigen“. Rootkits und Bootkits überleben Standard-Bereinigungen.
- Recovery-Reihenfolge: DNS/DHCP → Domain Controller (aus Pre-Compromise-Backup!) → Kritische Server → Workstations. Jedes System einzeln testen vor Produktions-Anbindung. Parallel: Netzwerk-Monitoring verschärfen, um eine erneute Kompromittierung sofort zu erkennen.
- KRBTGT-Doppelreset bei AD-Kompromiss: KRBTGT-Passwort zweimal zurücksetzen mit mindestens 12 Stunden Abstand. Erster Reset invalidiert aktuelle Tickets (10h Lebensdauer), zweiter Reset beseitigt zwischengespeicherte alte Tickets. Alle Kerberos-Tickets brechen — Service-Unterbrechungen einplanen. Vorher: Alle Service-Accounts dokumentieren.
- Lessons-Learned-Meeting: Innerhalb von 2 Wochen durchführen. Keine Schuldzuweisungen. Fragen: Was ist passiert? Wann wurde detektiert? Was hat funktioniert? Was nicht? Vollständige Timeline und Root-Cause-Analyse dokumentieren. Incident Response Plan (IRP) auf Basis der Erkenntnisse aktualisieren.
- Härtung nach dem Vorfall: Detektionsregeln für beobachtete TTPs implementieren. Netzwerksegmentierung verbessern. Fehlende Log-Quellen anbinden (Sysmon, PowerShell Script Block Logging, DNS Query Logging). MDR (Managed Detection & Response) evaluieren, wenn CSIRT-Kapazität nicht ausreicht. Quartalsweise Tabletop-Exercises etablieren.
- Recht & Versicherung: Beweise für potenzielle Strafverfolgung sichern (Chain of Custody!). Cyber-Versicherung informieren und Schadensdokumentation erstellen. Ggf. externe Forensik-Firma für Legal Hold beauftragen. Bei personenbezogenen Daten: Betroffene gemäß DSGVO Art. 34 informieren, wenn hohes Risiko besteht.
Sie benötigen Unterstützung?
Von der Incident-Response-Planung über forensische Untersuchungen bis zum Aufbau eines CSIRT — unsere Sicherheitsexperten unterstützen Sie bei der Vorbereitung auf und Bewältigung von Sicherheitsvorfällen. Ob NIS2-Compliance, SIEM-Implementierung oder regelmäßige Tabletop-Exercises: Schützen Sie Ihre Infrastruktur proaktiv.
Security & Firewall ansehen →
