Pivotierung und Bestätigung über mehrere Quellen hinweg

Modul 2 behandelte jedes Windows-Artefakt einzeln; Lektion 3.3 führte sie zu einer Super-Timeline zusammen. Diese Lektion behandelt die Methode, mit der aus Zeilen Feststellungen werden: über gemeinsame Identifikatoren pivotieren, Ereignisse in zeitlicher Nähe zu einem Anker untersuchen, jede wesentliche Tatsache anhand einer unabhängigen Quelle bestätigen sowie Widersprüche und Vertrauensgrad offen darlegen. Genau dies prüfen CFX-Prüfungsfragen zur Korrelation.

Pivotpunkte

Ein Pivotpunkt ist ein Wert, der in mehr als einem Artefakt vorkommt und diese dadurch miteinander verknüpft.

Die Pivotierungstechnik

1. Anker setzen. Beginnen Sie mit etwas Bekanntem und Konkretem: einer Warnmeldung, einer im Fall genannten Datei, einem Gerät, einem Konto.
2. Extrahieren Sie alle Identifikatoren, die der Anker enthält: Seriennummern, GUIDs, Pfade, SIDs, Hashwerte, Zeitangaben.
3. Durchsuchen Sie jede Quelle nach jedem Identifikator, nicht nur dort, wo Sie ihn erwarten: die Super-Timeline, geparste CSV-Dateien und mittels Stichwortsuche die Rohabbilder.
4. Ergänzen Sie jeden neuen Identifikator in einer Arbeitsliste und vermerken Sie seine Herkunft.
5. Wiederholen Sie dies, bis neue Suchläufe nichts mehr ergeben, das für die Fragestellung relevant ist.

Die Arbeitsliste ist Ihr Prüfpfad. Bevorzugen Sie spezifische Identifikatoren (eine Seriennummer, eine VSN, einen Hashwert) gegenüber allgemeinen wie report.docx oder dem Buchstaben E:.

Zeitliche Nähe

Wenn keine weiteren Identifikatoren verfügbar sind, pivotieren Sie anhand der Zeit: Listen Sie alles innerhalb eines Zeitfensters um den Anker auf, beispielsweise ±10 Minuten um den letzten Anschluss eines Geräts. Passen Sie das Zeitfenster an die gröbste beteiligte Quelle an: Sekunden für FILETIME-Quellen, 2 Sekunden für FAT-Schreibzeiten, etwa eine Stunde für SRUM.

Nähe legt einen Zusammenhang nahe, beweist ihn aber nicht: Windows schreibt jede Minute viele Hintergrundereignisse, und jedes davon kann zufällig in der Nähe des Ankers liegen. Ein Programm, das zwei Minuten nach einem USB-Anschluss ausgeführt wurde, ist ein Ermittlungsansatz; daraus wird eine Feststellung, wenn ein gemeinsamer Identifikator beide verknüpft, etwa eine Prefetch-Referenz auf einen Pfad auf dem Volume mit dieser VSN. Berichten Sie Nähe als Nähe ("6 Minuten nach dem Anschluss des Geräts"), niemals als Ursache.

Bestätigung und Unabhängigkeit

Eine Feststellung ist belastbar, wenn zwei unabhängige Quellen sie aufzeichnen. Unabhängig bedeutet, dass unterschiedliche Mechanismen unterschiedliche Datensätze schreiben, sodass ein Fehler, eine Lücke oder eine Manipulation in einer Quelle die andere nicht gleichermaßen betrifft. Zwei Parser für eine Datei sind eine zweimal geprüfte Quelle: Das validiert Ihr Werkzeug, nicht das Ereignis.

Das erste Paar ist das schwächste: Eine einzige Bereinigungsaktion oder Datenschutzeinstellung entfernt beide. Ergänzen Sie daher einen dritten Mechanismus, etwa die eigene MRU-Liste der Anwendung. Zwei Werte stimmen überein, wenn ihre Abweichung kleiner ist als die Auflösung der gröberen Quelle zuzüglich ihrer bekannten Schreibverzögerung.

Wenn Quellen voneinander abweichen

Widersprüche sind meist technisch bedingt:

• Auflösung. Eine DOS-Schreibzeit hat Schritte von 2 Sekunden; eine SRUM-Zeile deckt ein Intervall von etwa einer Stunde ab. Eine DOS-Zeit und eine FILETIME, die weniger als 2 Sekunden auseinanderliegen, stellen keinen Widerspruch dar.
• Ortszeit gegenüber UTC. FAT-DOS-Zeiten und setupapi.dev.log verwenden Ortszeit; FILETIMEs in Registry, EVTX, LNK und Prefetch verwenden UTC. Eine Differenz von exakt dem Zeitzonenversatz ist das typische Kennzeichen.
• Schreibverzögerungen. Shimcache wird beim Herunterfahren geschrieben, SRUM wird etwa einmal pro Stunde auf den Datenträger geschrieben, eine Prefetch-Datei wird etwa 10 Sekunden nach Programmstart geschrieben, und LastWrite eines Schlüssels gibt dessen letzte Änderung wieder, die nach dem für Sie relevanten Ereignis liegen kann.
• Uhrzeitänderungen. Ein Sprung der Systemuhr (Kernel-General-Ereignis 1, Security 4616) verschiebt alles, was davor geschrieben wurde. Lektion 3.5 zeigt, wie Sie dies messen und korrigieren.

Legen Sie jeden Widerspruch offen dar: beide Werte und Quellen, die Erklärung sowie den Wert, auf den Sie sich stützen, und die Begründung dafür. Lassen Sie niemals einen Wert weg, der nicht passt; wenn Sie ihn nicht erklären können, sagen Sie dies und senken Sie Ihren Vertrauensgrad.

Den Vertrauensgrad formulieren

ISO/IEC 27042 gibt Hinweise zur Analyse und Interpretation digitaler Beweismittel. In der Praxis gilt: Trennen Sie das, was ein Artefakt aufzeichnet, von Ihren Schlussfolgerungen, berücksichtigen Sie Alternativen und wählen Sie Formulierungen, die der Beweislage entsprechen.

Artefakte zeichnen Konten und Prozesse auf, nicht Personen: Schreiben Sie "das Konto von ana", nicht "ana", sofern nicht andere Beweismittel die Person an der Tastatur verorten.

Fall-Timeline gegenüber Super-Timeline

Die Super-Timeline (Lektion 3.3) enthält Millionen von Zeilen. Die Fall-Timeline listet nur die Ereignisse auf, die die Fragestellung beantworten, gewöhnlich einige Dutzend Zeilen. Jede enthält die UTC-Zeit mit der Genauigkeit der Quelle, das Ereignis in verständlichen Worten, die Quelle (Datei plus Datensatz, Offset oder Schlüsselpfad), die bestätigende Quelle und gegebenenfalls einen Hinweis auf Widersprüche. Nehmen Sie auch Ereignisse auf, die Ihre Hypothese schwächen. Sie durchsuchen die Super-Timeline; Sie berichten anhand der Fall-Timeline.

Durchgearbeitetes Beispiel: Datendiebstahl am 2026-03-14

Eine Budgetdatei ist außerhalb des Unternehmens aufgetaucht. Das Paket enthält eine Windows-11-Triage-Erfassung (ActiveTimeBias 180, also UTC = Ortszeit + 3 h) und ein E01-Abbild eines FAT32-USB-Laufwerks. Der Anker ist die Seriennummer des Laufwerks, 4C530001230411109384.

Die Schritte 1 und 2 stimmen innerhalb einer Sekunde überein, ebenso die DestList- und LNK-Zeiten in Schritt 5; die Prefetch- und BAM-Zeiten in Schritt 6 liegen 8 Sekunden auseinander und damit innerhalb der normalen Schwankungsbreite.

Der Widerspruch in Schritt 7. Das Schreibzeit-Wort am Offset 0x16 des Verzeichniseintrags lautet 66 57, gelesen als 0x5766, und das Datumswort bei 0x18 lautet 6E 5C, gelesen als 0x5C6E. Datum: 0x5C6E >> 9 = 46, also 1980 + 46 = 2026; (0x5C6E >> 5) & 0xF = 3; 0x5C6E & 0x1F = 14. Zeit: 0x5766 >> 11 = 10; (0x5766 >> 5) & 0x3F = 59; (0x5766 & 0x1F) × 2 = 6 × 2 = 12 s. Ein Werkzeug, das diesen Wert als UTC kennzeichnet, zeigt 2026-03-14T10:59:12Z an, fast drei Stunden vor dem letzten Anschluss des Laufwerks und nicht mit Schritt 6 vereinbar. FAT speichert Ortszeit, daher ist die fehlende Korrektur der Zeitzonenversatz: 10:59:12 + 3 h = 13:59:12Z, 31 Sekunden nach dem Start von 7zG.exe. Die Fall-Timeline behält beide Werte mit dieser Erklärung bei.

Schritt 8. BytesSent übersteigt die Archivgröße um 66.912.404 − 64.108.233 = 2.804.171 Bytes (etwa 4,4 %), was für Protokoll-Overhead und sonstiges Browsen plausibel ist. SRUM kann nicht angeben, welche Datei gesendet wurde oder wann.

Schritt 9. Chromes visit_time zählt Mikrosekunden seit 1601 (Lektion 3.1). Der Wert 13.417.970.987.412.318 ÷ 1.000.000 = 13.417.970.987,412318 s; − 11.644.473.600 = Unix 1.773.497.387,412. Nach Abzug von 1.773.446.400 (2026-03-14T00:00:00Z) verbleiben 50.987 s = 14 h 09 min 47 s, also 2026-03-14T14:09:47.412Z.

Formulierte Feststellung. "Das Gerät mit der Seriennummer 4C530001230411109384 wurde zuletzt am 2026-03-14T13:52:05Z angeschlossen (USBSTOR, bestätigt durch Partition/Diagnostic 1006). Sein Volume, VSN 1A2B-3C4D, wurde in der Sitzung des Kontos ana (SID S-1-5-21-…-1001) eingebunden. Die LNK-Datei und die Sprungliste deuten darauf hin, dass dieses Konto E:\Clients\budget-q3.xlsx um 13:54:29Z von diesem Volume geöffnet hat. Prefetch und BAM belegen, dass 7zG.exe um 13:58:41Z ausgeführt wurde, laut BAM unter diesem Konto; q3-files.7z auf dem abgebildeten Volume wurde zuletzt um 13:59:12Z geschrieben. SRUM und der Browserverlauf sind mit einem Upload des Archivs über chrome.exe zwischen 14:09:47Z und 14:31:09Z vereinbar, identifizieren jedoch nicht die gesendete Datei." Prefetch zeigt, dass 7zG.exe beide Dateien referenziert hat; erst der aus dem Abbild aufgelistete Archivinhalt zeigt, dass budget-q3.xlsx in q3-files.7z enthalten ist.

Prüfungsaufgaben präzise beantworten

• Unterscheiden Sie genau, welcher Wert gefragt ist: Eine Seriennummer ohne &0 ist nicht die Instanz-ID, ein Pfad ohne Laufwerksbuchstaben ist unvollständig, und eine gekürzte SID oder ein gekürzter Hashwert ist ein anderer Wert.
• Geben Sie Zeiten in ISO 8601 UTC mit Z an, beispielsweise 2026-03-14T13:52:05Z, auf Sekunden abgeschnitten, sofern keine höhere Genauigkeit verlangt wird.
• Achten Sie auf das Verb: "erstmals angeschlossen" (0065, setupapi) ist nicht "zuletzt angeschlossen" (0066); "geöffnet", "ausgeführt" und "kopiert" verweisen auf unterschiedliche Artefakte.
• Prüfen Sie den Wert vor der Abgabe anhand eines zweiten Artefakts; eine Abweichung von exakt dem Zeitzonenversatz bedeutet, dass ein Wert nicht umgerechnet wurde.

Prüfungsschwerpunkt: Rechnen Sie mit szenariobasierten Fragen, die zwei oder drei Schritte erfordern, etwa von einer Geräteseriennummer zu einer Benutzer-SID oder von einer Datei auf dem USB-Laufwerk zu dem Programm, das darauf zugegriffen hat. Fragen können prüfen, welche Quellen als unabhängig gelten, wie eine FAT-Zeit zu erklären ist, die um exakt einen Zeitzonenversatz von einer FILETIME abweicht, und welche Formulierung eine Feststellung rechtfertigt.

Kernpunkte

• Pivotpunkte sind Werte, die Artefakte gemeinsam haben, etwa Pfade, VSNs, Geräteseriennummern, SIDs, Hashwerte und Zeitfenster.
• Pivotieren Sie, indem Sie jede Quelle nach den Identifikatoren des Ankers durchsuchen und dies wiederholen; zeitliche Nähe liefert Ermittlungsansätze, und ein gemeinsamer Identifikator macht aus einem Ermittlungsansatz eine Feststellung.
• Unabhängige Bestätigung bedeutet unterschiedliche Mechanismen, nicht unterschiedliche Parser derselben Datei; erklären Sie Widersprüche anhand von Auflösung, Zeitzone, Schreibverzögerung oder Uhrzeitänderung.
• Passen Sie die Formulierung an die Beweislage an ("verzeichnet", "ist vereinbar mit", "deutet darauf hin", "belegt") und berichten Sie anhand einer gezielt zusammengestellten Fall-Timeline, nicht anhand der Super-Timeline.