Timestomping, Protokolllöschung und verborgene Daten

Lektion 7.1 behandelte die Vernichtung von Daten. Diese Lektion behandelt stattdessen drei Möglichkeiten, einen Prüfer in die Irre zu führen: Zeitstempel ändern, Protokolle löschen oder bearbeiten und Daten verbergen. Jede dieser Methoden hinterlässt eine Unstimmigkeit zwischen Quellen, die dasselbe Ereignis unabhängig voneinander aufzeichnen; die Aufgabe des Prüfers besteht darin, diese zu finden, ihr Ausmaß zu bestimmen und anzugeben, wie stark sie eine Manipulation belegt.

Timestomping

Timestomping bedeutet, die Zeitstempel einer Datei so zu ändern, dass sie unauffällig wirkt oder älter erscheint. Die meisten Werkzeuge ändern nur die Werte von $STANDARD_INFORMATION ($SI), entweder über SetFileTime (Erstellung, Zugriff, Änderung) oder über NtSetInformationFile mit der Klasse FileBasicInformation (alle vier, einschließlich des Änderungszeitpunkts des MFT-Eintrags). Beide benötigen keine Administratorrechte, und $FILE_NAME ($FN) lässt sich schwerer fälschen (Lektion 3.2). Einige veröffentlichte Techniken gleichen auch $FN an, indem sie $SI-Änderungen mit einer Umbenennung oder Verschiebung innerhalb des Volumes kombinieren, bei der NTFS die $SI-Werte in das neue $FN kopiert. Dadurch können übereinstimmende $SI- und $FN-Werte entstehen, doch werden dabei Umbenennungsdatensätze zum Journal hinzugefügt.

Mehrstufige Erkennung

Keine einzelne Prüfung ist eindeutig, da auch Archivierungsprogramme, Installationsprogramme und Synchronisierungsclients Zeitstempel setzen. Wenden Sie die Prüfungen schrittweise an und geben Sie an, wie viele übereinstimmende Ergebnisse liefern.

1. $SI im Vergleich zu $FN. Ein $SI B, das vor $FN B liegt, oder ein $SI C, das zu keinem Vorgang passt, ist ein erster Anhaltspunkt.
2. Sekundenbruchteile gleich null. Ein FILETIME zählt Intervalle von 100 Nanosekunden; daher fällt ein echter Zeitpunkt nur etwa einmal in zehn Millionen Fällen auf eine volle Sekunde. Mehrere Werkzeuge schreiben volle Sekunden. Neuere Werkzeuge wählen den Bruchteil zufällig, sodass ein Bruchteil ungleich null nichts beweist.
3. Benachbarte MFT-Einträge. Eintragsnummern geben eine grobe Erstellungsreihenfolge wieder, da die $MFT wächst, wenn Dateien hinzugefügt werden. Ein Eintrag, dessen Nachbarn alle an einem Tag erstellt wurden, dessen $SI jedoch Jahre früher angibt, ist verdächtig. Freigegebene Einträge werden wiederverwendet, daher kann dies nur andere Befunde stützen.
4. Älter als das System. Vergleichen Sie $SI B mit InstallDate (wird durch Funktionsupgrades zurückgesetzt) und mit $SI B der Metadatendateien des Volumes selbst, etwa $MFT (Eintrag 0) und $Volume (Eintrag 3), die normalerweise den Formatierungszeitpunkt des Volumes festhalten. Kopierte oder extrahierte Dateien können ältere Zeitstempel mitbringen, doch ihre $SI C- und $FN-Werte zeigen dann den Zeitpunkt ihres Eintreffens.
5. $UsnJrnl. Das Setzen von Zeitstempeln schreibt einen Datensatz mit BASIC_INFO_CHANGE (0x00008000) für die Referenznummer der Datei, dessen Zeitstempel von der Uhr zum tatsächlichen Änderungszeitpunkt stammt. Das Flag erfasst auch Attributänderungen, werten Sie es daher zusammen mit den $SI-Werten aus. Kopier- und Extraktionswerkzeuge setzen Zeitstempel üblicherweise, während die Datei noch geöffnet ist, in derselben Vorgangsgruppe wie FILE_CREATE; eine separate spätere Vorgangsgruppe ist aussagekräftiger. Danebenliegende Umbenennungsdatensätze weisen auf die $FN-Technik hin.
6. $LogFile. Ein UpdateResidentValue am $SI-Attribut enthält die alten Zeitstempel in seinen Undo-Daten und die neuen in seinen Redo-Daten, sofern das Protokoll diesen Zeitpunkt noch abdeckt (Minuten bis Stunden).
7. Andere Artefakte, die die Datei erfasst haben. Eine LNK-Datei bewahrt die $SI-Zeitstempel für Erstellung, Zugriff und Änderung des Ziels in dem Zustand auf, den sie beim Schreiben der Verknüpfung hatten, an den Header-Offsets 0x1C, 0x24 und 0x2C (Lektion 2.4). Prefetch, Amcache und Sprunglisten zeigen, wann die Datei verwendet wurde. Wenn alle Verweise aus 2026 stammen, steht ein Erstellungszeitpunkt aus 2019 allein da.
8. Interne Zeitstempel. Der TimeDateStamp einer PE-Datei (Unix-Sekunden im COFF-Header, am Offset e_lfanew + 8; von Amcache-Parsern als LinkDate angezeigt) kann logisch nicht später als die Erstellung der Datei liegen. Dokumentmetadaten wie dcterms:created in Office-Dateien (Registerkarte „Details“ im Explorer) funktionieren nach demselben Prinzip. Beide lassen sich fälschen, und deterministische Builds tragen in TimeDateStamp einen Hash statt eines Zeitpunkts ein.

Manipulation der Systemuhr ist etwas anderes

Stattdessen kann jemand die Systemuhr zurückstellen, die Datei erstellen und die Uhr wiederherstellen. Dann tragen $SI, $FN, USN-Datensätze und Ereignisprotokolle gemeinsam die falsche Zeit, mit normalen Sekundenbruchteilen. Die Anzeichen entsprechen denen aus Lektion 3.5: Kernel-General-Ereignis 1 im Systemprotokoll (OldTime, NewTime) und Security-Ereignis 4616 (PreviousTime, NewTime) sowie Sequenznummern (USN, EventRecordID), die ansteigen, während die Zeiten rückwärts springen. Timestomping verschiebt ein Attribut; Änderungen der Systemuhr verschieben alles, was in diesem Zeitfenster geschrieben wird.

Protokolllöschung

Windows

Beim Löschen des Security-Protokolls wird Security-Ereignis 1102 („Das Überwachungsprotokoll wurde gelöscht“) als erster Datensatz des neuen Protokolls geschrieben; beim Löschen jedes anderen Protokolls wird System-Ereignis 104 geschrieben, das den Kanal nennt. Beide stammen vom Anbieter Microsoft-Windows-Eventlog und erfassen SubjectUserName, SubjectDomainName sowie bei 1102 auch SubjectUserSid und SubjectLogonId. Das Löschen des Security-Protokolls erfordert das Recht „Verwalten von Überwachungs- und Sicherheitsprotokollen“, über das Administratoren standardmäßig verfügen.

Ermitteln Sie auch das verwendete Mittel: wevtutil cl <log> hinterlässt auf Clienteditionen eine Prefetch-Datei für WEVTUTIL.EXE sowie 4688, wenn die Prozesserstellung überwacht wird (mit der Befehlszeile nur dann, wenn auch die Befehlszeilenprotokollierung aktiviert ist); Clear-EventLog erscheint in PowerShell/Operational 4104, wenn die Skriptblockprotokollierung aktiviert ist, und in ConsoleHost_history.txt.

Weitere Anzeichen für Manipulation:

• EventRecordID. Ein gelöschtes Protokoll beginnt wieder bei 1. Ein Protokoll, dessen älteste Einträge regulär überschrieben wurden, beginnt mit einem höheren Wert und weist keine internen Lücken auf; ein Sprung innerhalb einer Datei bedarf daher einer Erklärung.
• Zeitliche Abdeckung und Größe. Ein Security-Protokoll, das auf einem seit Monaten genutzten System erst Minuten vor dem Vorfall beginnt, oder eine Datei weit unter ihrer MaxSize passt zu einer kürzlich erfolgten Löschung. Auch Zeiträume ohne Einträge sind relevant, wenn andere Quellen Aktivität zeigen.
• Selektive Löschung. Einige Werkzeuge entfernen oder verbergen einzelne Datensätze, indem sie die Datei neu schreiben. Achten Sie auf ID-Lücken, CRC32-Prüfsummenfehler in den Datei- oder Chunk-Headern sowie auf Datensätze, die Parser als verborgen oder beschädigt melden. Behandeln Sie diese als Anhaltspunkte.
• Manipulation von Diensten und Richtlinien. Security 1100 („Der Ereignisprotokollierungsdienst wurde heruntergefahren“) und System 6006 (Ereignisprotokolldienst beendet) sind beim Herunterfahren normal; ohne nachfolgenden Systemstart (6005) deuten sie darauf hin, dass der Dienst beendet wurde. Security 4719 erfasst eine Änderung der Überwachungsrichtlinie. Techniken, die die Protokollierung im Arbeitsspeicher aussetzen, schreiben nichts; nur Lücken im Vergleich mit anderen Quellen machen sie sichtbar.

Gelöschte Datensätze lassen sich häufig wiederherstellen: aus älteren Kopien in Volumenschattenkopien (Lektion 2.9), durch Carving von 64 KB großen ElfChnk-Chunks aus nicht zugeordnetem Speicherplatz, pagefile.sys oder hiberfil.sys (beispielsweise mit EVTXtract) sowie aus Kopien, die an einen Kollektor oder ein SIEM weitergeleitet wurden.

Linux

Vergleichen Sie Quellen, die dieselben Ereignisse protokollieren (Lektion 6.4). Eine gekürzte /var/log/auth.log oder eine solche Datei, in der Sitzungszeilen fehlen, die journalctl für sshd noch anzeigt, deutet auf eine Bearbeitung hin. Jeder wtmp-Datensatz ist unter x86-64-Linux 384 Bytes groß; utmpdump /var/log/wtmp zeigt einen mit Nullen überschriebenen Datensatz als Typ 0 mit einem Zeitpunkt aus 1970 an (auf Systemen, die stattdessen wtmpdb verwenden, untersuchen Sie /var/lib/wtmpdb/wtmp.db, Lektion 6.4), einen entfernten Datensatz dagegen als Anmeldung ohne zugehörige Abmeldung oder als Lücke in der Abfolge der Systemstarts. journalctl --verify meldet beschädigte Journaldateien; Meldungen wie „beschädigt oder nicht ordnungsgemäß geschlossen“ und .journal~-Dateien haben häufig harmlose Ursachen. Die Namen archivierter Journaldateien enthalten die Sequenznummer ihres ersten Eintrags, sodass eine fehlende Datei mitten in der Reihe als Lücke erkennbar ist; die reguläre Bereinigung entfernt nur die ältesten Dateien. Lektion 6.3 behandelt Tricks mit dem Shell-Verlauf, etwa das Entfernen der Variablen HISTFILE.

Verborgene Daten

• Alternative Datenströme (Lektion 1.4). Jeder Datenstrom außer Zone.Identifier und bekannten Systemdatenströmen verdient eine nähere Betrachtung. MFTECmd (HasAds, IsAds), istat und dir /r listen sie auf; beim Hinzufügen eines Datenstroms wird STREAM_CHANGE geschrieben.
• Dateierweiterung im Vergleich zur Signatur. Vergleichen Sie die ersten Bytes mit der Erweiterung: 4D 5A (MZ) kennzeichnet eine PE-Datei, 50 4B 03 04 einen ZIP-Container (einschließlich .docx), 25 50 44 46 (%PDF) eine PDF-Datei, FF D8 FF eine JPEG-Datei. Das Modul von Autopsy für abweichende Dateierweiterungen und file automatisieren dies.
• Slack und nicht zugeordneter Speicherplatz (Lektion 1.2). RAM-Slack mit Werten ungleich null auf einem modernen NTFS-Volume oder strukturierte Daten über viele Slack-Bereiche hinweg deuten auf eine absichtliche Platzierung hin.
• Verborgene Partitionen und Lücken (Lektion 1.1). Vergleichen Sie die Partitionstabelle mit der Datenträgergröße und suchen Sie nach unpartitioniertem Speicherplatz, der über die normale Ausrichtung an 1 MiB hinausgeht. Bei GPT verbergen die Attributbits 62 (verborgen) und 63 (kein Laufwerkbuchstabe) Basisdatenpartitionen vor dem Explorer.
• Steganografie. Statistische Tests (Chi-Quadrat- oder RS-Analyse der niederwertigsten Bits) in Werkzeugen wie StegExpose oder zsteg kennzeichnen auffällige Bilder, liefern aber auch falsch positive Ergebnisse. Daten, die nach FF D9 einer JPEG-Datei oder IEND einer PNG-Datei angehängt wurden, oder Steganografiesoftware in Ausführungsartefakten sind oft bessere Anhaltspunkte.
• Als Dateien getarnte verschlüsselte Container. Eine Shannon-Entropie nahe 8,0 Bits pro Byte, kein erkennbarer Header und eine Größe, die ein exaktes Vielfaches von 512 Bytes ist, passen zu einem Container (Lektion 7.3). Komprimierte Formate erreichen ebenfalls hohe Werte, beginnen jedoch mit einer Signatur.
• Attribute und Namen. Die Attribute „Versteckt“ und „System“, Unix-Namen mit einem Punkt am Anfang, Namen, die Systemdateien im falschen Ordner nachahmen, das Zeichen zur Erzwingung der Rechts-nach-links-Schreibrichtung U+202E sowie $Recycle.Bin-Unterordner, die nach SIDs benannt sind, die im Schlüssel ProfileList nicht existieren.

Durchgearbeitetes Beispiel: svc.dll und ein gelöschtes Security-Protokoll

Die Triage-Erfassung von anas Laptop zeigt diesen MFT-Eintrag:

Prüfung der Sekundenbruchteile. Der $SI-Wert beträgt 132.073.632.000.000.000 (Bytes 00 40 8E BF 44 38 D5 01). Geteilt durch 10.000.000 ergibt das 13.207.363.200 Sekunden, Rest 0. Der $FN-Wert 134.179.718.913.301.447 ÷ 10.000.000 = 13.417.971.891 Rest 3.301.447, also 0,3301447 s. Die Differenz von 2.106.086.913.301.447 Intervallen oder 210.608.691,33 s entspricht 2.437 Tagen 14 h 24 min 51,33 s.

Begründung. $SI B liegt 6 Jahre und 8 Monate vor $FN B und vor der Formatierung des Volumes; seine Sekundenbruchteile sind null; die benachbarten Einträge wurden vier Sekunden vor und 35 Sekunden nach dem $FN-Zeitpunkt erstellt; und das Journal erfasst eine Zeitstempeländerung in einer separaten Vorgangsgruppe 12 Sekunden nach der Erstellung, ohne Umbenennung. $LogFile war bereits zyklisch überschrieben worden und deckte 14:25 nicht mehr ab. Die belastbare Aussage lautet, dass der Name svc.dll auf diesem Volume um 2026-03-14T14:24:51Z erstellt wurde und seine $SI-Zeitstempel gegen 14:25:03Z auf 2019-07-12T00:00:00Z gesetzt wurden, was mit Timestomping vereinbar ist. Das Journal zeigt nicht, wer dies getan hat.

Das Protokoll. Security.evtx beginnt mit EventRecordID 1, einem Ereignis 1102 um 2026-03-14T14:38:55Z mit SubjectUserName ana und SubjectUserSid S-1-5-21-…-1001. Das Security-Protokoll wurde 13 min 52 s nach der Zeitstempeländerung durch anas Konto gelöscht, und dieses Konto verfügte über das erforderliche Recht. Ein etwaiges Ereignis 4616 zur Zeitänderung ging dabei ebenfalls verloren; prüfen Sie daher Kernel-General 1 im Systemprotokoll, bevor Sie dem Journalzeitpunkt 14:25:03Z vertrauen; ein solches Ereignis ist nicht vorhanden. Als Nächstes: Prefetch für WEVTUTIL.EXE, 4104, Schattenkopien und durch Carving gewonnene Chunks.

Technik, Erkennung und Aussagekraft

Die Aussagekraft bezieht sich auf die Manipulation; wer sie vorgenommen hat, erfordert separate Belege wie Anmeldungen und Ausführungsartefakte.

Prüfungsschwerpunkt: Rechnen Sie damit, den tatsächlichen Zeitpunkt des Eintreffens einer Datei anhand von $FN oder dem Journal angeben zu müssen, wenn $SI gefälscht ist, sowie den Änderungszeitpunkt anhand eines BASIC_INFO_CHANGE-Datensatzes. Sie sollten die Sekundenbruchteile eines rohen FILETIME prüfen und aus 1102 oder 104 ablesen können, wer welches Protokoll wann gelöscht hat. Fragen können verlangen, Timestomping von einer Änderung der Systemuhr zu unterscheiden oder anzugeben, wo gelöschte Datensätze wiederhergestellt werden können.

Kernpunkte

• Timestomping ändert normalerweise nur $SI; vergleichen Sie mit $FN, Sekundenbruchteilen, benachbarten MFT-Einträgen, Volume-Erstellung, $UsnJrnl, $LogFile, LNK und internen Zeitstempeln und zählen Sie, wie viele übereinstimmende Ergebnisse liefern.
• BASIC_INFO_CHANGE erfasst den tatsächlichen Zeitpunkt, zu dem Zeitstempel oder Attribute gesetzt wurden; eine separate Vorgangsgruppe nach der Erstellung ist aussagekräftiger als eine innerhalb der Erstellung.
• Eine Änderung der Systemuhr verschiebt alle Artefakte gemeinsam und hinterlässt Kernel-General 1 oder 4616; Timestomping verschiebt ein Attribut.
• 1102 (Security) und 104 (System) nennen das Konto, das ein Protokoll gelöscht hat; Datensatz-IDs beginnen wieder bei 1, und alte Datensätze können in Schattenkopien, durch Carving gewonnenen Chunks und weitergeleiteten Kopien erhalten bleiben.
• Vergleichen Sie unter Linux Textprotokolle mit dem Journal, lesen Sie wtmp mit utmpdump und prüfen Sie die Journal-Sequenznummern.
• Verborgene Daten werden durch ihre Struktur sichtbar: zusätzliche $DATA-Attribute, abweichende Signaturen, ungewöhnlicher Slack, unpartitionierter Speicherplatz und Dateien mit hoher Entropie ohne Header.