Während der Incident Response finden Sie eine verdächtige Lücke in den Authentifizierungsprotokollen. Was schließen Sie daraus und was tun Sie?
Kurzantwort
Eine Lücke in lokalen Protokollen während eines Vorfalls kann gelöschte oder manipulierte Protokolle bedeuten, ein verbreiteter Anti-Forensik-Schritt, behandeln Sie die Abwesenheit von Protokollen also nicht als Abwesenheit von Aktivität. Gleichen Sie mit zentralen/weitergeleiteten Protokollen, EDR und Netzwerkdaten ab, die der Angreifer wahrscheinlich nicht ändern konnte, und halten Sie die Integritätslücke als Befund fest. Anzunehmen, der Server sei untätig gewesen, vertraut Beweisen, die der Angreifer möglicherweise kontrolliert, die Lücke als Beweis dafür zu nehmen, dass nichts geschah, ist genau die Schlussfolgerung, die er will, und weitere Protokolle zu löschen zerstört, was übrig ist. Bestätigen Sie stattdessen mit unabhängiger Telemetrie.
Eine saubere, unerklärte Lücke in den Authentifizierungsprotokollen während eines aktiven Vorfalls ist selbst ein Beweisstück — und der gefährlichste Fehler ist, sie als „nichts ist geschehen" zu lesen. Das Löschen oder selektive Bearbeiten von Protokollen ist eine dokumentierte Anti-Forensik-Technik (MITRE ATT&CK T1070, Indicator Removal). Angreifer tun dies gerade deshalb, damit ein weniger erfahrener Responder schließt, das Zeitfenster sei ruhig gewesen.
Die richtige Schlussfolgerung und Maßnahme
Behandeln Sie die Lücke als mögliches Integritätsereignis, nicht als Tatsache über die Aktivität. Dann:
- Gleichen Sie mit Quellen ab, die der Angreifer wahrscheinlich nicht erreichen konnte. Zentrale/weitergeleitete Protokolle (bereits außerhalb des Hosts), EDR-Telemetrie, Netzwerkflussdaten und Protokolle vorgelagerter Geräte (Firewall, VPN, Identitätsanbieter) zeigen häufig noch, was lokale Protokolle nicht mehr zeigen.
- Jagen Sie nach Manipulationsartefakten. Unter Linux können Anomalien bei der Journal-Rotation, Lücken, die mit Angreiferaktivität anderswo zusammenfallen, oder Inode-/Zeitstempel-Inkonsistenzen ein Löschen verraten, selbst wenn die Einträge verschwunden sind.
- Dokumentieren Sie die Integritätslücke als ausdrücklichen Befund, mit dem Zeitfenster und dem, was bestätigende Beweise füllen oder nicht. Das ist sowohl für die Umfangsbestimmung als auch für die Zulässigkeit wichtig.
Warum die Ablenker scheitern
- „Der Server war untätig" nimmt an, dass das fehlende Protokoll die Realität getreu widerspiegelt — aber der Angreifer kontrolliert möglicherweise genau diese Quelle. Abwesenheit von Beweisen ist kein Beweis für Abwesenheit.
- „Der Lücke als Beweis vertrauen, dass nichts geschah" ist die Schlussfolgerung, die der Angreifer herbeiführt; es ist die Falle, nicht die Antwort.
- „Den Rest der Protokolle zum Aufräumen löschen" zerstört die verbleibenden Beweise und könnte eine Beweisvernichtung darstellen — katastrophal für eine Untersuchung und jedes Gerichtsverfahren.
Was der Interviewer prüft
Ob Sie bequemen Lücken instinktiv misstrauen, zu unabhängiger, manipulationssicherer Telemetrie greifen und Beweise bewahren statt zerstören — das Senior-Urteilsvermögen, das „die Protokolle sagen, dass nichts geschah" von „man hat die Protokolle dazu gebracht zu sagen, dass nichts geschah" unterscheidet.
Wahrscheinliche Anschlussfragen
- Welche Artefakte unter Linux verraten, dass Protokolle gelöscht wurden, selbst wenn die Einträge selbst verschwunden sind?
- Wie verändert die zentrale Protokollweiterleitung die Fähigkeit eines Angreifers, sich zu verbergen, und wo liegen ihre Grenzen?
- Wie würden Sie eine Beweismittel-Integritätslücke so dokumentieren, dass sie einer rechtlichen Prüfung standhält?