Digital Forensics nach dem Einbruch: Was sichern und wie dokumentieren

Key Takeaways

• Die ersten 60 Minuten nach Entdeckung eines Einbruchs sind forensisch kritisch — flüchtige Beweise verschwinden mit jedem Neustart.
• Beweissicherung folgt einer festen Reihenfolge: erst RAM und Netzwerkzustand, dann Logs, zuletzt Disk-Images.
• Eine lückenlose Chain of Custody ist Voraussetzung für strafrechtliche Verwertbarkeit und NIS-2-Nachweispflichten.
• Microsoft 365 Unified Audit Log und Wazuh-Alerts sind bei KMU häufig die wertvollsten Beweisquellen — sofern die Aufbewahrung korrekt konfiguriert ist.
• Dokumentation und Zeitleiste beginnen vom ersten Moment an, nicht nach der Bereinigung.

Warum Forensik kein Luxus für Konzerne ist

Ein Ransomware-Vorfall, ein kompromittiertes Administrator-Konto, ein unbekannter Prozess mit ausgehendem Traffic in der Nacht — Sicherheitsvorfälle treffen KMU genauso wie Großunternehmen. Der Unterschied: Großunternehmen haben IR-Teams, die sofort mit Arbeit beginnen. KMU improvisieren oft. Das kostet Zeit, vernichtet Beweise und macht es nahezu unmöglich, den Angriffsweg zu rekonstruieren.

Digitale Forensik ist dabei kein akademisches Thema, sondern eine operative Notwendigkeit. Sie beantwortet drei Fragen, ohne die keine sinnvolle Reaktion möglich ist:

1. Was ist genau passiert? Welche Systeme wurden kompromittiert, welche Daten abgeflossen, welche Mechanismen genutzt?
2. Seit wann? Der Zeitpunkt des initialen Zugriffs unterscheidet sich oft um Tage oder Wochen vom Zeitpunkt der Entdeckung.
3. Wie kam der Angreifer rein? Nur wer den initialen Angriffsvektor kennt, kann ihn schließen — und Folgeeinbrüche verhindern.

Daneben gibt es regulatorische Realitäten: NIS-2 verlangt Nachweise über Vorfallsreaktion, die DSGVO schreibt Meldepflichten und Dokumentation vor. Wer keine forensischen Artefakte gesichert hat, kann diese Nachweise nicht erbringen.

Die ersten 60 Minuten: Prioritäten setzen

Nach der Entdeckung eines Einbruchs beginnt eine Art Wettlauf. Flüchtige Daten — RAM-Inhalte, aktive Netzwerkverbindungen, laufende Prozesse — existieren nur so lange, wie ein System eingeschaltet und nicht neu gestartet wurde. Gleichzeitig gibt es den verständlichen Reflex, befallene Systeme sofort vom Netz zu trennen oder neu aufzusetzen. Beides kann forensisch katastrophal sein, wenn es in der falschen Reihenfolge passiert.

Grundsatz: Nie ein kompromittiertes System neu starten oder Disk-Inhalte ohne vorherige Sicherung löschen.

Die empfohlene Reihenfolge:

1. Betroffene Systeme isolieren (Netzwerktrennung), aber eingeschaltet lassen
2. Flüchtige Daten erfassen (RAM, Prozesse, Netzwerkverbindungen)
3. Logs und Audit-Trails exportieren
4. Forensische Disk-Images erstellen
5. Erst dann: Bereinigung und Wiederherstellung

Was sichern: Beweismittel und ihre Priorität

1. Flüchtige Daten — die vergänglichsten Beweise

Flüchtige Daten existieren nur im laufenden System. Dazu gehören:

• RAM-Inhalt: Verschlüsselungsschlüssel von Ransomware, entpackte Malware-Payloads, Credentials im Speicher, laufende Shellcode-Fragmente
• Aktive Netzwerkverbindungen: C2-Server-IP-Adressen, offene Ports, unbekannte Prozesse mit Netzwerkzugang
• Laufende Prozesse: Injizierte Prozesse, verdächtige Parent-Child-Beziehungen, unbekannte ausführbare Dateien
• Angemeldete Benutzer und Sessions: Aktive RDP-Verbindungen, lokale und Remote-Logins

Unter Windows lassen sich diese Daten mit eingebauten Tools oder spezialisierten Forensik-Tools sichern. Für eine schnelle Ersterfassung auf der Kommandozeile:

# Aktive Netzwerkverbindungen mit zugehörigen Prozessen
netstat -ano | Out-File C:\Forensics\netstat_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt

# Laufende Prozesse mit Pfaden
Get-Process | Select-Object Id, ProcessName, Path, StartTime | 
  Export-Csv C:\Forensics\processes_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv -NoTypeInformation

# Angemeldete Benutzer
query user | Out-File C:\Forensics\sessions_$(Get-Date -Format 'yyyyMMdd_HHmmss').txt

# Geplante Tasks (häufiges Persistenzmittel)
Get-ScheduledTask | Where-Object {$_.State -ne 'Disabled'} |
  Select-Object TaskName, TaskPath, State, @{N='Actions';E={$_.Actions.Execute}} |
  Export-Csv C:\Forensics\scheduled_tasks_$(Get-Date -Format 'yyyyMMdd_HHmmss').csv -NoTypeInformation

Für RAM-Dumps ist spezialisierte Software nötig. Tools wie WinPmem (open source) oder Magnet RAM Capture ermöglichen vollständige Arbeitsspeicher-Abbilder, die später mit Volatility 3 analysiert werden können.

2. Event Logs und SIEM-Daten

Windows Event Logs sind bei KMU oft die primäre forensische Datenquelle — vorausgesetzt, sie wurden nicht überschrieben. Standardmäßig ist die maximale Log-Größe in Windows auf 20 MB eingestellt, was bei aktiven Systemen wenige Stunden abdeckt. Für forensische Zwecke sollten Event Logs deutlich größer konfiguriert sein.

Die wichtigsten Log-Quellen:

Log	Event-IDs	Relevanz
Security	4624, 4625, 4648	Anmeldungen und Fehlversuche
Security	4688	Prozesserstellung (mit CommandLine)
Security	4698, 4702	Geplante Tasks erstellt/geändert
Security	4720, 4732	Benutzer erstellt, Gruppe geändert
System	7045	Neuer Dienst installiert
PowerShell/Operational	4103, 4104	Script Block Logging

# Alle Security-Events der letzten 72 Stunden sichern
$start = (Get-Date).AddHours(-72)
Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  StartTime = $start
} | Export-Csv C:\Forensics\security_events_72h.csv -NoTypeInformation

# Kritische Event-IDs gezielt extrahieren
$criticalIDs = @(4624, 4625, 4648, 4688, 4698, 4720, 4732, 7045)
Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id = $criticalIDs
  StartTime = $start
} | Select-Object TimeCreated, Id, Message |
  Export-Csv C:\Forensics\critical_events.csv -NoTypeInformation

3. Microsoft 365 Unified Audit Log

Für KMU, die Microsoft 365 nutzen, ist das Unified Audit Log (UAL) oft wichtiger als lokale Logs — insbesondere bei Business Email Compromise, kompromittierten Konten oder Dateiexfiltration via SharePoint/OneDrive.

Wichtig: Das UAL muss explizit aktiviert sein und ist standardmäßig für 90 Tage verfügbar (mit E5-Lizenz bis zu einem Jahr). Es sollte vor einer Untersuchung exportiert werden.

# Exchange Online PowerShell Modul vorausgesetzt
Connect-ExchangeOnline

# UAL-Export für einen Benutzer in einem Zeitraum
Search-UnifiedAuditLog \
  -StartDate "2026-06-18" \
  -EndDate "2026-06-25" \
  -UserIds "benutzer@firma.de" \
  -ResultSize 5000 |
  Select-Object CreationDate, UserIds, Operations, AuditData |
  Export-Csv C:\Forensics\UAL_export.csv -NoTypeInformation

# Speziell: Mailweiterleitung und Postfachregeln
Search-UnifiedAuditLog \
  -StartDate "2026-06-18" \
  -EndDate "2026-06-25" \
  -Operations "New-InboxRule","Set-InboxRule","UpdateInboxRules" \
  -ResultSize 1000 |
  Export-Csv C:\Forensics\inbox_rules.csv -NoTypeInformation

4. Wazuh-Alerts und SIEM-Korrelationen

Wenn Wazuh als SIEM im Einsatz ist, sind die historischen Alerts eine hochwertige, bereits korrelierte Beweisquelle. Wazuh speichert Alerts in Elasticsearch/OpenSearch — der direkte Export über die Wazuh-API oder die OpenSearch-Abfrage sichert die Rohdaten:

# Wazuh Alerts via API für einen Zeitraum exportieren
curl -k -u admin:PASSWORT \
  "https://wazuh-manager:55000/alerts?pretty=true&limit=10000&offset=0"\
  "&q=timestamp>2026-06-18T00:00:00" \
  -o /forensics/wazuh_alerts_export.json

# Alternativ: OpenSearch-Direktabfrage
curl -X GET "https://opensearch-node:9200/wazuh-alerts-*/_search?pretty" \
  -H 'Content-Type: application/json' \
  -d '{
    "query": {
      "range": {
        "timestamp": {
          "gte": "2026-06-18T00:00:00",
          "lte": "2026-06-25T23:59:59"
        }
      }
    },
    "size": 10000
  }' \
  -o /forensics/opensearch_alerts.json

5. Forensische Disk-Images

Ein forensisches Image ist eine bitgenaue Kopie eines Datenträgers, die im Gegensatz zu einer normalen Datensicherung auch gelöschte Dateien, Slack Space und Metadaten enthält. Das Standardformat ist dd (Linux) oder das forensische E01-Format (FTK Imager, Arsenal Image Mounter).

Für Windows-Systeme im laufenden Betrieb eignet sich FTK Imager Lite (läuft ohne Installation vom USB-Stick):

FTK Imager -> File -> Create Disk Image
-> Ziel: USB-Festplatte mit ausreichend Speicherplatz
-> Format: E01 mit Komprimierung und MD5/SHA1-Hashing
-> Verify after creation: aktivieren

Der erzeugte Hash-Wert ist entscheidend: Er beweist die Integrität des Images und ist Voraussetzung für die gerichtliche Verwertbarkeit.

Chain of Custody: Beweissicherung rechtssicher dokumentieren

Digitale Beweise sind nur verwertbar, wenn ihre Herkunft und Unversehrtheit lückenlos nachweisbar sind. Die Chain of Custody (Beweismittelkette) dokumentiert:

• Wer hat das Beweismittel wann und wo gesichert
• Welche Werkzeuge und Methoden wurden verwendet
• Wer hatte seitdem Zugriff auf das Beweismittel
• Wo wird es aufbewahrt (physisch und digital)

Ein minimales Chain-of-Custody-Formular enthält:

Beweismittel-ID: [eindeutige ID, z.B. INC-2026-001-001]
Beschreibung: [RAM-Dump, Festplatten-Image, Log-Export, ...]
System/Hostname: [srv-dc01.firma.local]
Sicherungsdatum/-zeit: [2026-06-25 14:32 UTC]
Sicherung durch: [Vorname Nachname, Position]
Verwendetes Tool: [WinPmem 4.0.0, Hash: SHA256 des Tools]
Hash des Beweismittels: [MD5: ..., SHA256: ...]
Speicherort: [Externer USB "Forensics-USB-001", in Safe Raum 204]
Zugriffe:
  - [Datum, Uhrzeit, Person, Zweck]

Jede Übertragung, jede Analyse, jede Kopie wird eingetragen. Das Formular selbst wird ausgedruckt und physisch aufbewahrt — nicht nur digital.

Zeitleiste und Vorfallsdokumentation

Parallel zur technischen Sicherung beginnt die narrative Dokumentation. Sie hält fest, was wann bekannt wurde, welche Entscheidungen getroffen wurden und warum. Diese Zeitleiste hat mehrere Funktionen: Sie unterstützt die forensische Rekonstruktion, dient als Nachweis gegenüber Behörden und Versicherungen, und hilft bei der Nachbesprechung (Lessons Learned).

Mindestinhalt einer Incident-Zeitleiste:

• T0: Erste Entdeckung oder erster Alarm (Timestamp, Quelle)
• Alle Folgeentdeckungen mit Zeitstempel und Quelle
• Jede Maßnahme mit Zeitpunkt und ausführender Person
• Externe Kommunikation (intern, BSI, Datenschutzbehörde, Versicherung, Strafverfolgung)
• Systemzustände zu jedem Zeitpunkt (online/offline/isoliert)

Ein einfaches, aber wirksames Format ist eine chronologische Tabelle in einem getrennt gespeicherten Dokument (nicht auf den betroffenen Systemen), das von Beginn an gepflegt wird.

NIS-2 und DSGVO: Regulatorische Pflichten im Vorfall

Für Unternehmen, die unter NIS-2 fallen (wesentliche und wichtige Einrichtungen gemäß BSI-Gesetz), gelten konkrete Meldepflichten:

• Innerhalb von 24 Stunden: Erstmeldung an das BSI bei erheblichem Vorfall
• Innerhalb von 72 Stunden: Detailliertere Folgemeldung
• Innerhalb von 1 Monat: Abschlussbericht mit Ursache, Auswirkung und Gegenmaßnahmen

Unter der DSGVO gilt: Sobald personenbezogene Daten betroffen sein könnten, besteht eine 72-Stunden-Meldepflicht an die zuständige Datenschutzaufsichtsbehörde — auch wenn die Betroffenheit noch nicht abschließend geklärt ist. Bei hohem Risiko für Betroffene kommt die Benachrichtigungspflicht der betroffenen Personen hinzu.

Für beide Pflichten gilt: Ohne forensische Dokumentation können die geforderten Nachweise nicht erbracht werden. Das BSI erwartet in Abschlussberichten konkrete Angaben zu Angriffsvektor, Zeitpunkt und Umfang des Vorfalls — alles Informationen, die nur aus einer strukturierten Beweissicherung stammen können.

Typische Fehler und wie man sie vermeidet

Systeme sofort neu aufsetzen: Verständlicher Reflex, forensisch fatal. Immer erst sichern, dann bereinigen.

Logs nicht aufbewahren: Windows-Event-Logs mit Standardkonfiguration überschreiben sich nach Stunden. Log-Größen erhöhen, zentrales SIEM nutzen.

Keine Hash-Werte bilden: Ohne kryptografische Hash-Werte ist die Integrität von Beweismitteln nicht nachweisbar. SHA256 für alle gesicherten Artefakte.

Beweise auf betroffenen Systemen speichern: Forensische Daten gehören auf externe, write-protected Medien oder in ein isoliertes Forensik-System.

Ohne Zeitplan kommunizieren: Interne und externe Kommunikation ohne Koordination erzeugt Widersprüche, die später als Zeuge oder gegenüber Behörden problematisch werden.

Azure/M365-Audit-Logs zu spät exportieren: Das UAL hat eine begrenzte Aufbewahrungszeit. Export muss frühzeitig erfolgen, bevor Logs altern und gelöscht werden.

Vorbereitung: Was vor dem Vorfall passieren muss

Digitale Forensik beginnt nicht im Vorfall. Sie beginnt mit der richtigen Konfiguration und Vorbereitung:

• Unified Audit Log in M365 aktivieren und Aufbewahrung auf Maximum setzen
• Windows Event Log-Größen auf mindestens 128 MB pro Log erhöhen (GPO)
• Script Block Logging und Process Creation Auditing aktivieren (Event 4688 mit CommandLine)
• Zentrales SIEM (z.B. Wazuh) mit ausreichender Datenvorhaltezeit konfigurieren
• Forensik-USB-Set vorbereiten: FTK Imager Lite, WinPmem, Volatility-Portable, Chain-of-Custody-Formulare
• IR-Plan dokumentieren und mindestens einmal im Jahr tabellarisch üben
• Externe IR-Unterstützung vorab identifizieren — im Ernstfall ist keine Zeit für Anbieterauswahl

---

Wer nach einem Einbruch strukturiert vorgeht, bewahrt nicht nur Beweise — er verschafft sich die Informationen, um den eigentlichen Angriffsweg zu verstehen und dauerhaft zu schließen. Genau das ist der Unterschied zwischen einem bewältigten Vorfall und einem, der sich sechs Monate später wiederholt.

Das Vyrex Security Operations Center unterstützt KMU dabei, diese Forensik-Grundlagen nicht erst im Ernstfall aufzubauen. Über das managed SIEM auf Basis von Wazuh sind kritische Log-Quellen kontinuierlich erfasst und aufbewahrt — sodass im Vorfall die Daten bereits vorliegen und das SOC-Team sofort mit der Analyse beginnen kann, anstatt zuerst Infrastruktur einzurichten. Weitere Informationen unter vyrex.cloud.