Når enhedens ur går forkert: urafvigelse og korrektion

Forside › Sikring: metoderne samlet · Gennemgået oktober 2026 · Af John Nielsen

Alle lokale tidsstempler på en computer eller telefon er skrevet efter enhedens eget ur. Går uret forkert, er alle tidsstempler forskudt tilsvarende, og en tidslinje, der blander enhedens tider med serverlogs, kan vise en forkert rækkefølge. Urafvigelse (clock skew) skal derfor måles ved sikringen, spores bagud i tid og, hvis den er væsentlig, korrigeres åbent i analysen uden at ændre de rå data.

Metoden til at samle tider fra mange kilder er beskrevet i Tidslinjeanalyse. Her handler det om selve uret. Tidszoner og sommertid i rapporten er behandlet i UTC og sommertid i forensiske rapporter.

Hvorfor ure går forkert

Drift: Hardwareuret (RTC) i en computer driver typisk nogle sekunder om dagen. Uden tidssynkronisering bliver afvigelsen stor over måneder.
Manglende synkronisering: En computer uden for domænet, uden netværk eller med blokeret tidssynkronisering korrigeres ikke.
Forkert tidszone: Uret står rigtigt i UTC, men tidszonen er forkert indstillet, eller omvendt. Det giver typisk forskydninger på hele timer.
Tømt batteri: Når batteriet til hardwareuret er tomt, kan uret starte forfra fra en standarddato, hver gang strømmen afbrydes.
Manuel ændring: En bruger eller et program stiller uret, enten af praktiske grunde eller for at få filer til at se ud, som om de er lavet på et andet tidspunkt. Det sidste er behandlet i Anti-forensics.
Virtuelle maskiner: En gendannet eller pauset virtuel maskine kan starte med en gammel tid, indtil den synkroniseres.
Isolerede anlæg: Styringer og logenheder i OT-net kører ofte uden tidssynkronisering, så deres ure kan afvige meget fra IT-systemernes; se OT og PLC: logs og hændelsesdata.

Måling ved sikringen

Afvigelsen måles bedst, mens enheden er under kontrol:

Tændt computer eller server: Notér systemets tid og tidszone og sammenlign med en pålidelig reference, fx et ur synkroniseret mod en officiel tidskilde. Notér begge tider og forskellen i arbejdsnoterne.
Slukket computer: Hardwareurets tid kan aflæses i firmwareopsætningen, uden at styresystemet startes. Det skal ske kontrolleret, efter at disken er frakoblet eller kopien er taget, så opstarten ikke skriver til disken.
Telefon: Notér den viste tid og om automatisk tid er slået til. Et fotografi af skærmen ved siden af referenceuret er enkelt og overbevisende.
Servere og netværksudstyr: Notér tid og tidskilde i konfigurationen.

Hvordan målingen indgår i sikringsforløbet, er beskrevet i Forensisk image trin for trin.

En måling ved sikringen viser kun afvigelsen på det tidspunkt. Den kan have været en anden på de tidspunkter, sagen drejer sig om.

Spor efter tidligere afvigelser og ændringer

Windows

Windows registrerer ændringer af systemtiden. Sikkerhedsloggen har en hændelse for ændring af systemtid (Event ID 4616), som hører under auditunderkategorien Security State Change og derfor kun findes, hvis den er slået til i politikken. Systemloggen har hændelser fra kernen om tidsændringer (kilden Kernel-General) samt hændelser fra tidstjenesten (Time-Service) om synkronisering og fejl, og tidstjenesten har desuden sin egen driftslog. Hændelserne om ændring af tiden indeholder typisk den gamle og den nye tid, så afvigelsens størrelse kan aflæses. Hvilke hændelses-id’er der bruges, bør kontrolleres for den konkrete Windows-version. Se Windows-hændelseslogs.

Tidstjenesten justerer ofte uret gradvist, når afvigelsen er lille, og i ét spring, når den er stor. Små korrektioner efterlader derfor ikke altid en hændelse.

macOS, Linux og telefoner

macOS og Linux logger tidssynkronisering i systemloggen, fx fra tidsdæmonen. På Linux kan logs fra chrony eller ntpd vise korrektioner og deres størrelse. Telefoner synkroniserer typisk via mobilnetværket eller internettet, og systemlogs kan vise ændringer af tid og tidszone. Hvad der findes, afhænger meget af version og logniveau.

Indirekte spor

Når enheden selv ikke har logget noget, kan afvigelsen udledes ved at sammenligne lokale tidsstempler med tidsstempler fra en uafhængig server for den samme hændelse:

Mail: Date-headeren sættes af afsenderens klient efter dens ur, mens den første Received-header sættes af serveren. En konstant forskel mellem de to over mange mails viser klientens afvigelse. Se Mail-headere: SPF, DKIM og DMARC.
Cloudsynkronisering: Tidspunktet for lokal ændring sammenlignet med tjenestens registrerede uploadtid.
Webtrafik: Lokale browsertider sammenlignet med serverlogs, hvor de findes.
Kendte hændelser: Installation af en opdatering, hvis udgivelsesdato kendes, eller et login, der også står i en serverlog.

Flere uafhængige målepunkter over tid kan vise, om afvigelsen er konstant, voksende eller springende. Et pludseligt spring, der senere springer tilbage, er et mønster, der kræver forklaring.

Hvilken tid servere og apps faktisk viser, er uddybet i Server-tid og klient-tid.

Når enheden ikke kan måles

Ofte er enheden ikke til rådighed, fordi sagen kun har en kopi, en eksport eller en mængde filer. Så kan afvigelsen ikke måles direkte, og de indirekte spor bliver det eneste grundlag. Det har to konsekvenser.

For det første skal usikkerheden angives. Et målepunkt fra en mailheader har sekunders opløsning, men afhænger også af, hvor hurtigt mailen blev afsendt efter at være skrevet. Et målepunkt fra en cloudsynkronisering afhænger af, hvornår klienten fik forbindelse. Hvert målepunkt bør beskrives med sin forventede usikkerhed, og afvigelsen angives som et interval frem for en præcis værdi.

For det andet skal det overvejes, om afvigelsen overhovedet har betydning. Hvis spørgsmålet er, om en fil blev ændret før eller efter en opsigelse, der ligger flere dage væk, er en afvigelse på et par minutter uden betydning. Hvis spørgsmålet er, om en besked blev sendt før eller efter et telefonopkald samme eftermiddag, kan selv få minutter være afgørende, og så skal grundlaget være tilsvarende stærkt.

Korrektion

Korrektion sker i analysen, aldrig i kildedata:

Fastlæg afvigelsen for de relevante perioder med målepunkter og deres usikkerhed.
Vælg model: en fast forskydning, hvis afvigelsen var konstant, eller en tidsafhængig korrektion, hvis den drev. Ved spring opdeles perioden.
Anvend korrektionen i en separat kolonne, så rå tid og korrigeret tid står side om side.
Kontrollér korrektionen mod mindst ét målepunkt, der ikke er brugt til at fastlægge den.
Overvej om korrektion er nødvendig: Er afvigelsen få sekunder, og drejer spørgsmålet sig om timer eller dage, er det ofte nok at beskrive den.

Korrektion til hele timer bør ses i sammenhæng med tidszoner og sommertid, før den antages at være urafvigelse. Se Sommertid og tidszoner i rapporten.

Typiske fejlkilder

At antage, at afvigelsen ved sikringen også gjaldt måneder tidligere.
At blande urafvigelse og tidszonefejl.
At korrigere filsystemtider, der er overført fra en anden enhed, med denne enheds afvigelse. En kopieret fil bærer den oprindelige enheds tid med sig.
At rette tider i en eksport, så de rå værdier går tabt.

Hvad det kan og ikke kan bevise

En målt og dokumenteret afvigelse gør det muligt at placere lokale hændelser korrekt i forhold til uafhængige kilder. En registreret manuel tidsændring viser, at uret blev ændret, men ikke i sig selv hvorfor. Den skal ses sammen med, hvad der skete på enheden i perioden med den ændrede tid.

Dokumentation

Angiv i rapporten måling ved sikringen med referencekilde, sporene efter tidligere afvigelser og ændringer, den valgte korrektionsmodel, dens usikkerhed og hvilke tider i rapporten der er korrigerede, og hvilke der er rå.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Sommertid og tidszoner i rapporten: UTC og den dobbelte time · Server-tid og klient-tid i cloud og apps

→ Forensisk sikring · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik