Zeitzonen- und Uhrenfehler

Ein Zeitstempel kann vollkommen korrekt dekodiert und dennoch falsch sein: Er wurde in Ortszeit gespeichert und als UTC ausgegeben, mit den heutigen Regeln statt den am Ereignistag geltenden umgerechnet, durch das Werkzeug des Analysten verschoben oder von einer Uhr aufgezeichnet, die um Minuten oder Jahre falsch ging. Diese Lektion zeigt, welche Quellen UTC und welche Ortszeit speichern, wie Sie Ortszeitwerte umrechnen und wie Sie einen Fehler der Geräteuhr messen, dokumentieren und korrigieren. Modul 7 behandelt absichtliche Uhrenmanipulationen; hier geht es darum, nicht manipulierte Zeitstempel richtig einzuordnen.

Drei Uhren in jedem Fall

Halten Sie in Ihren Notizen drei Uhren auseinander:

1. Tatsächliche Zeit (UTC): wann das Ereignis wirklich stattfand. Diese Zeit muss Ihr Bericht angeben.
2. Die Systemuhr des Geräts: welche Zeit der Computer für richtig hielt. Artefakte zeichnen diese Uhrzeit auf, niemals die tatsächliche Zeit. Ging die Uhr 7 Minuten vor, liegt jeder von ihr geschriebene Zeitstempel 7 Minuten zu spät.
3. Die Anzeigeuhr: wie ein Werkzeug einen Wert auf der Arbeitsstation des Analysten anzeigt. Die Ereignisanzeige zeigt beispielsweise in UTC gespeicherte EVTX-Zeiten in der Zeitzone des Computers an, auf dem sie betrachtet werden.

Fehler entstehen, wenn diese Uhren verwechselt werden.

UTC-Quellen und Ortszeitquellen

Zwei Formate liegen dazwischen. exFAT speichert Ortszeit zusammen mit einem Byte für den UTC-Offset jedes Zeitstempels, das nur verwendbar ist, wenn sein Gültigkeitsbit gesetzt ist (Lektion 1.5). EXIF ab Version 2.31 kann OffsetTimeOriginal ergänzen, etwa -03:00. Ein Textprotokoll, das einen Offset schreibt, wie Apaches [14/Mar/2026:09:21:07 -0300], ist ebenfalls eindeutig. Ohne eine solche Kennzeichnung gehen Sie von Ortszeit aus und ermitteln Sie, wessen Ortszeit gemeint ist: die des Hosts oder die einer Kamera, deren Uhr nie eingestellt wurde.

Die Hardware-Echtzeituhr (RTC) birgt eine weitere Falle: Windows führt sie standardmäßig in Ortszeit, die meisten Linux-Distributionen in UTC. Daher kann die Uhr eines Dual-Boot-Rechners bis zur erneuten Synchronisierung um den Zeitzonenoffset falsch gehen.

Ortszeit in UTC umrechnen

Windows speichert Offsets als Bias in Minuten, mit dem umgekehrten Vorzeichen der üblichen Schreibweise „UTC−3“: Bias = −(UTC-Offset), und UTC = Ortszeit + Bias. UTC−3 hat einen Bias von +180; UTC+1 hat −60. Während der Sommerzeit (DST) ist der wirksame Bias Bias + DaylightBias (üblicherweise −60), sodass sich für die mitteleuropäische Sommerzeit −60 + (−60) = −120 ergibt. Lektion 2.2 zeigt, wo diese Werte unter TimeZoneInformation liegen.

Fehlende und wiederholte Stunden

Bei einer Sommerzeitumstellung springt die Ortszeit. In Mitteleuropa sprangen die Uhren am 2026-03-29 von 01:59:59 CET auf 03:00:00 CEST, sodass die Ortszeiten von 02:00 bis 02:59 an diesem Tag nicht existieren. Am 2026-10-25 sprangen sie von 02:59:59 CEST auf 02:00:00 CET zurück, sodass jede Ortszeit von 02:00 bis 02:59 zweimal auftrat, einmal bei UTC+2 und einmal bei UTC+1. Eine Protokollzeile mit der Ortszeit 02:30 an diesem Tag ist um eine Stunde mehrdeutig. Klären Sie dies anhand benachbarter Einträge oder einer UTC-Quelle und geben Sie an, wie Sie dabei vorgegangen sind.

Die am Ereignistag geltende Regel verwenden

ActiveTimeBias beschreibt den Zeitpunkt, zu dem der Schlüssel zuletzt geschrieben wurde, nicht das Datum Ihres Ereignisses. Zeitzonenregeln ändern sich auch durch Gesetze. Brasilien schaffte die Sommerzeit 2019 ab; seine letzte Sommerzeitperiode endete am 2019-02-17. Ein 2026 gesicherter Host aus Brasília zeigt ActiveTimeBias 180, aber eine lokale Protokollzeile vom 2018-12-10 10:00 wurde bei UTC−2 geschrieben und entspricht 12:00Z, nicht 13:00Z. Rechnen Sie jeden Wert mit den Regeln für sein jeweiliges Datum um. Verwenden Sie dazu eine aktuelle Zeitzonendatenbank (die IANA-tz-Datenbank) oder die jahresspezifischen Regeln, die Windows unter SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\<zone>\Dynamic DST speichert.

Überlassen Sie die Wahl Ihrer Zeitzone niemals einem Werkzeug

Viele Werkzeuge wenden stillschweigend die Zeitzone der Analystenarbeitsstation an:

• Stellen Sie die Analysearbeitsstation auf UTC ein, damit ein Rückgriff auf „lokal“ harmlos bleibt.
• Geben Sie in Plaso die Ausgabezeitzone ausdrücklich an: psort.py --output_time_zone UTC. Wenn Ortszeitquellen wie FAT-Volumes geparst werden, übergeben Sie die Zeitzone des Geräts mit log2timeline.py --timezone (Lektion 3.3).
• Prüfen Sie bei GUI-Werkzeugen die Anzeigeeinstellungen. In den Ansichtsoptionen von Autopsy wird die für die Anzeige verwendete Zeitzone ausgewählt. Timeline Explorer zeigt die Zeitstempel der geöffneten CSV-Datei an. Erzeugen Sie diese CSV-Datei daher in UTC und stellen Sie ihr Datumsformat so ein, dass Sekunden und Sekundenbruchteile angezeigt werden. Prüfen Sie anschließend eine Zeile anhand eines manuell dekodierten Werts.
• Tabellenkalkulationen sind gefährlich. Excel wandelt datumsähnlichen Text in serielle Zahlen ohne Zeitzone um, blendet in seinem Standardanzeigeformat Sekunden und Sekundenbruchteile aus und kann bei manchen Regionseinstellungen Tag und Monat vertauscht einlesen. Importieren Sie Zeitstempelspalten als Text.

Uhrenabweichung und Uhrendrift

Die Uhrenabweichung ist die Differenz zwischen der Geräteuhr und der tatsächlichen Zeit zu einem bestimmten Zeitpunkt. Die Uhrendrift gibt an, wie schnell sich diese Differenz ändert. Eine frei laufende Quarzuhr mit einem Fehler von 20 Millionsteln geht pro Tag etwa 1,7 Sekunden vor oder nach (20 × 10⁻⁶ × 86.400 s), sodass ein nicht synchronisiertes Gerät nach einigen Monaten um Minuten falsch gehen kann. Bei der Synchronisierung wird die Uhr durch Slewing (vorübergehend etwas schnellerer oder langsamerer Lauf bis zur Übereinstimmung) oder durch Stepping (sprunghaftes Verstellen) korrigiert. Nur sprunghafte Korrekturen hinterlassen einen Eintrag „Uhrzeit geändert“.

Die Abweichung messen

Vergleichen Sie die Geräteuhr mit einer vertrauenswürdigen Referenz:

• NTP-Synchronisierungsaufzeichnungen. Ereignisse des Anbieters Microsoft-Windows-Time-Service im Systemprotokoll zeigen die Synchronisierung an: Ereignis 35 nennt die Zeitquelle, mit der sich der Dienst synchronisiert, und Ereignis 37 besagt, dass der NtpClient-Anbieter gültige Zeitdaten empfängt. Sie zeigen, dass die Synchronisierung funktionierte, nicht den Umfang einer Korrektur.
• Kernel-General-Ereignis 1 (Anbieter Microsoft-Windows-Kernel-General, Systemprotokoll) zeichnet eine Änderung der Systemzeit mit OldTime und NewTime auf, beide in UTC. Die Differenz ist der Umfang der sprunghaften Korrektur.
• Sicherheitsereignis 4616, „Die Systemzeit wurde geändert“, wird protokolliert, wenn die Überwachungsunterkategorie „Änderung des Sicherheitsstatus“ aktiviert ist. Es ergänzt PreviousTime, NewTime, das Konto und den Prozess. Routinemäßige Korrekturen durch den Windows-Zeitdienst zeigen üblicherweise das Konto LOCAL SERVICE; eine Änderung durch einen Benutzerprozess verdient Aufmerksamkeit.
• Serverseitige Zeitstempel, die eine synchronisierte Uhr zur selben Aktion schreibt: die von Mailservern hinzugefügten Received:-Header, das Zugriffsprotokoll eines Webservers oder der HTTP-Antwortheader Date:, der in einem Browser-Cache-Eintrag gespeichert ist. Der Last-Modified:-Header eines Servers liefert eine Untergrenze: Ein Download kann lokal nicht erstellt worden sein, bevor der Inhalt zuletzt auf dem Server geändert wurde.
• Bei der Sicherung zeichnen Sie die Geräteuhr zusammen mit einer vertrauenswürdigen Referenz auf. Damit messen Sie die Uhrenabweichung zum Sicherungszeitpunkt, nicht unbedingt zu früheren Zeitpunkten.

Eine Korrektur dokumentieren und anwenden

Notieren Sie die Referenz, wie Sie die Abweichung ermittelt haben, das Intervall, für das sie gilt, und die verbleibende Unsicherheit. Wenden Sie die Korrektur nur zwischen bekannten Uhrenereignissen an: Eine nach einer sprunghaften Korrektur gemessene Abweichung gilt nicht für die Zeit davor. Bewahren Sie in Ihrem Bericht den ursprünglichen Wert neben dem korrigierten auf.

Ereignisse außerhalb der zeitlichen Reihenfolge

Ein Rücksprung lässt einen Bereich von Uhrzeiten zweimal auftreten, sodass eine Sortierung nach Zeit nicht zusammengehörige Ereignisse ineinander verschachtelt; ein Vorwärtssprung hinterlässt eine Lücke. Nach dem Ausfall der RTC-Batterie oder dem Zurücksetzen der Firmware (BIOS/CMOS) kann die Uhr mit einem Firmware-Standarddatum neu beginnen und Ereignisse „im Jahr 2001“ oder einem anderen frühen Jahr erzeugen, bis sie erneut eingestellt wird; eine zu weit vorgestellte Uhr erzeugt Dateien „in der Zukunft“. Solche Muster sind normale Folgen von Hardwareproblemen und manuellen Änderungen, kein Beweis für Manipulation. Suchen Sie nach dem Kernel-General-Ereignis 1 oder dem Ereignis 4616, das sie erklärt, und stellen Sie die tatsächliche Reihenfolge anhand uhrenunabhängiger Sequenznummern wieder her: EVTX EventRecordID, Aktualisierungssequenznummern des USN-Journals, Sequenznummern von $LogFile.

Sicherungszeiten sind keine Beweiszeiten

Zeiten, die durch die Sicherung selbst entstehen, etwa die Dateisystemzeiten kopierter Dateien in einem Triage-Ordner und der Erfassungszeitpunkt, beschreiben Ihre Arbeit, nicht die des Benutzers (Lektion 3.3). Schließen Sie sie aus der Ereigniszeitleiste aus und verwenden Sie das Sicherungsprotokoll, um die Uhrenabweichung zu messen und die Beweismittelkette zu dokumentieren.

Präzision und Abgleich

Ein DOS-Wert kennzeichnet einen Zwei-Sekunden-Schritt. Je nach schreibender Software wurde die tatsächliche Zeit auf die vorherige gerade Sekunde abgeschnitten oder auf die nächste aufgerundet. Sie kann daher bis zu 2 Sekunden vor oder nach dem gespeicherten Wert liegen. Berücksichtigen Sie dieses Fenster beim Vergleich eines DOS-Werts mit einem FILETIME-Wert; eine Differenz von 1 Sekunde bedeutet nicht zwei Ereignisse. CFX-Prüfungsfragen geben Zeitstempel in ISO 8601 UTC mit Z an, etwa 2026-03-16T09:20:14Z, auf ganze Sekunden abgeschnitten, sofern nicht anders angegeben. Geben Sie den exakt umgerechneten Wert des in der Aufgabe genannten Artefakts an und runden Sie ihn nicht in Richtung einer anderen Quelle.

Durchgerechnetes Beispiel 1: eine FAT32-Datei und die $MFT des Hosts

Ein FAT32-USB-Abbild enthält plan.docx (Kurzname PLAN~1.DOC). In ihrem Verzeichniseintrag lautet das Zeitwort am Offset 0x16 87 32 und das Datumswort bei 0x18 70 5C:

• Zeit 0x3287: Stunde = 0x3287 >> 11 = 6; Minute = (0x3287 >> 5) & 0x3F = 20; Sekunden = (0x3287 & 0x1F) × 2 = 7 × 2 = 14, also 06:20:14.
• Datum 0x5C70: Jahr = (0x5C70 >> 9) + 1980 = 46 + 1980 = 2026; Monat = (0x5C70 >> 5) & 0x0F = 3; Tag = 0x5C70 & 0x1F = 16, also 2026-03-16.

Der TimeZoneKeyName des Hosts lautet E. South America Standard Time und ActiveTimeBias ist 180. Brasilien hatte 2026 keine Sommerzeit, daher gilt an diesem Datum 180: 06:20:14 + 180 Minuten = 2026-03-16T09:20:14Z.

Die $MFT des Hosts enthält C:\Users\ana\Desktop\plan.docx mit einer $SI-Änderungszeit von 2026-03-16T09:20:12.7Z. Die Differenz beträgt 1,3 Sekunden und liegt damit unter der DOS-Auflösung von 2 Sekunden. Die Werte sind daher mit einer einzigen Änderung vereinbar: Beim Kopieren bleibt die Änderungszeit der Datei erhalten, und Windows rundet sie auf FAT auf die nächste gerade Sekunde auf. Für das USB-Laufwerk lautet die anzugebende Antwort 2026-03-16T09:20:14Z.

Durchgerechnetes Beispiel 2: eine um 7 Minuten vorgehende Uhr

Auf einem anderen Host enthält das Systemprotokoll das Kernel-General-Ereignis 1 mit OldTime 2026-03-18T13:47:31.5Z und NewTime 2026-03-18T13:40:31.5Z. Die sprunghafte Korrektur beträgt 13:47:31.5 − 13:40:31.5 = −7 min 00 s: Die Uhr ging vor 13:47:31.5 Gerätezeit um 7 Minuten vor. Seit dem Systemstart ist keine frühere Zeitänderung zu erkennen, daher gilt die Abweichung für den gesamten Vormittag.

Bestätigen Sie dies mit einer unabhängigen Uhr: Der Browser-Cache-Eintrag für den Download speichert den Date:-Header des Servers, 13:22:03Z. Gerätezeit 13:29:05 − 13:22:03 = 7 min 02 s, vereinbar mit einer Abweichung von 7 Minuten plus 2 Sekunden Übertragungszeit. Dokumentieren Sie die Datensatz-ID des Ereignisses, die Abweichung, ihr Intervall und beide Werte für jede Zeile.

Prüfungsschwerpunkt: Rechnen Sie damit, Ortszeitartefakte wie FAT-Zeitstempel, Zeilen aus setupapi.dev.log oder EXIF-Datumswerte anhand des Bias und der am Ereignistag geltenden Regeln in UTC umzurechnen. Sie sollten OldTime und NewTime aus dem Kernel-General-Ereignis 1 beziehungsweise PreviousTime und NewTime aus Ereignis 4616 lesen und frühere Zeitstempel um den Betrag der sprunghaften Korrektur berichtigen können. Zuordnungsfragen können einen DOS-Wert mit 2-Sekunden-Auflösung einem FILETIME-Wert gegenüberstellen; eine Differenz unter 2 Sekunden bedeutet kein anderes Ereignis.

Kernpunkte

• Trennen Sie tatsächliche UTC, Geräteuhr und Werkzeuganzeige; Artefakte zeichnen nur die Geräteuhr auf.
• FILETIME-, Unix- und APFS-Zeiten sind UTC; FAT/DOS, viele Textprotokolle, einige SYSTEMTIME-Werte und EXIF DateTimeOriginal sind Ortszeit; exFAT kann einen gültigen UTC-Offset enthalten.
• UTC = Ortszeit + Bias, mit Bias = −(UTC-Offset) und den Sommerzeit- und gesetzlichen Regeln des Ereignisdatums, nicht dem heutigen ActiveTimeBias.
• Erzwingen Sie UTC in jedem Werkzeug und verhindern Sie, dass Tabellenkalkulationen Zeitstempel neu interpretieren.
• Messen Sie die Uhrenabweichung anhand vertrauenswürdiger Referenzen (Kernel-General 1, 4616, Serverheader, Sicherungsnotizen) und wenden Sie Korrekturen nur innerhalb des Intervalls an, das sie abdecken.
• Berücksichtigen Sie die Auflösung: DOS-Änderungszeiten sind Werte mit 2-Sekunden-Auflösung, daher bedeutet eine Differenz unter 2 Sekunden gegenüber einem FILETIME-Wert kein anderes Ereignis.