Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen
Om et dokument er skrevet senere end den dato, det bærer, kan sjældent afgøres ud fra dokumentet alene. Datoen i teksten og datoerne i filens metadata kan ændres af den, der laver dokumentet. Det, der gør en vurdering mulig, er sammenligningen med spor, som brugeren ikke styrer på samme måde: filsystemets tidsstempler og journal, programmernes egne spor, versionshistorik i cloudtjenester, mails og backup. Peger flere uafhængige kilder på en senere tilblivelse, er det et stærkt fund. Peger de i hver sin retning, skal det forklares.
Den juridiske problemstilling er beskrevet på Antedaterede dokumenter. De tekniske tegn inde i Office- og PDF-filer, fx rsid, fonte og inkrementelle opdateringer, står i Dokumentforfalskning i Office og PDF. Denne artikel handler om metoden til at sammenholde dem med alt det, der ligger uden for filen.
Tre lag af tid
Et dokument har typisk tidsangivelser i tre lag:
- Indhold · Eksempler: Dato i brevhoved, underskriftsdato, dato i filnavn · Hvem styrer det: Forfatteren, frit
- Dokumentmetadata · Eksempler: Oprettet, senest gemt, udskrevet, redigeringstid, revisionsnummer · Hvem styrer det: Programmet, men kan ændres
- Systemspor · Eksempler: Filsystemets tidsstempler, journal, programspor, serverlogs, cloudversioner · Hvem styrer det: Styresystem og tjenester
Jo længere ned i tabellen, jo sværere er det at ændre tiden uden at efterlade andre spor. Dokumentmetadata er gennemgået i Office-metadata.
Spørgsmålene, der skal besvares
En undersøgelse af en påstået tilbagedatering kan bygges op om fire spørgsmål:
- Kunne dokumentet være lavet på den påståede dato? Fandtes programversionen, skabelonen, fonten og de oplysninger, dokumentet indeholder, på det tidspunkt?
- Hvornår optræder filen første gang i et uafhængigt system? Første upload, første mail, første backup, første indeksering.
- Hvornår er den senest ændret, og af hvem? Filsystem, journal, versionshistorik.
- Er der tegn på, at tiden er manipuleret? Ændret systemur, ændrede tidsstempler eller indbyrdes modstridende spor.
Filsystemet
På NTFS har hver fil to sæt tidsstempler i MFT-posten: $STANDARD_INFORMATION, som almindelige programmer og brugerværktøjer kan ændre, og $FILE_NAME, som opdateres i færre situationer. En fil, hvis $SI-oprettelsestid ligger måneder før $FN-oprettelsestiden, kan have fået sin oprettelsestid ændret, men der er også almindelige forklaringer. Detaljerne står i NTFS i dybden, og hvad oprettet, ændret og åbnet hver især betyder, i Oprettet, ændret, åbnet.
Ændringsjournalen $UsnJrnl kan vise oprettelse, omdøbning og skrivning med tidspunkt, så længe posterne ikke er overskrevet. En journalpost om oprettelse af filen i en periode, der ligger langt efter den påståede dato, er et af de stærkeste lokale spor. MFT-postens sekvensnummer og placering kan også give en grov indikation af, hvornår posten blev taget i brug, men det skal fortolkes forsigtigt.
Programspor som LNK-filer, jump lists og seneste filer i Office viser, hvornår dokumentet blev åbnet, og fra hvilken sti. Se Windows-artefakter.
Cloud, mail og backup
Uafhængige systemer er ofte afgørende:
- Versionshistorik i SharePoint, OneDrive og Google Drive registreres af tjenesten med serverens tid og med brugerkonto. Den første version viser, hvornår filen kom ind i tjenesten. Se Versioner og deling i SharePoint og OneDrive.
- Mails med dokumentet vedhæftet har serverens modtagelsestidspunkter i headerne. Et dokument, der påstås at være sendt i marts, men kun findes i en mail fra september, skal forklares.
- Backup fra perioden omkring den påståede dato kan vise, om filen fandtes, og i hvilken version.
- Auditlogs i Microsoft 365 og Google Workspace viser filhandlinger med tidspunkt og konto.
Hvis dokumentet påstås at være lavet før en bestemt dato, men ikke findes i nogen backup eller tjeneste fra før den dato, er det ikke i sig selv bevis for tilbagedatering. Det kan være lavet lokalt og aldrig synkroniseret. Men det fjerner den støtte, som et tidligt uafhængigt spor ellers ville give.
Anakronismer
Indholdet og strukturen kan indeholde ting, der ikke fandtes på den påståede dato:
- en skabelon, et logo eller en standardtekst, der først blev indført senere i virksomheden,
- en programversion eller et filformat, der først blev udgivet senere,
- henvisninger til begivenheder, personer eller priser, der ligger efter datoen,
- indlejrede billeder med egne metadata, der er nyere end dokumentet.
En anakronisme er ofte stærkere end et tidsstempel, fordi den ikke afhænger af noget ur. Den kræver til gengæld, at tidspunktet for det nye element dokumenteres uafhængigt.
Manipuleret tid
Et ændret systemur giver tidsstempler, der stemmer indbyrdes, men er forkerte. Windows logger ændringer af systemtiden i sikkerhedsloggen som hændelse 4616 med tidligere og ny tid samt den konto og proces, der ændrede den. Mange af disse hændelser er almindelige korrektioner fra tidstjenesten, så det er ændringer foretaget af andre processer, der er interessante. Spring i ellers fortløbende logs kan også afsløre det. Sammenlign også computerens tid med tidspunkter, der stammer fra servere, fx mails og cloudsynkronisering. Afvigelser mellem klientens og serverens ur skal måles og dokumenteres, før de bruges som argument.
Fremgangsmåde
En undersøgelse kan med fordel følge samme rækkefølge hver gang, så intet springes over:
- Sikr alle eksemplarer af dokumentet, som de findes: på computeren, i mails, i cloudtjenester og hos modparten. Beregn hashværdi for hvert eksemplar, og notér, hvor det kommer fra.
- Sammenlign eksemplarerne. Identiske hashværdier betyder samme fil. Forskellige hashværdier kræver en strukturel sammenligning af indhold og metadata.
- Sikr systemsporene fra de enheder og konti, hvor dokumentet påstås at være lavet og sendt: diskkopi eller målrettet sikring med MFT og journal, auditlogs, versionshistorik og relevante backupsæt.
- Byg tidslinjen i én tidszone med kilde for hver hændelse.
- Formulér hypoteserne før konklusionen: dokumentet er lavet på den påståede dato, eller det er lavet senere. Gennemgå hvert spor for, hvilken hypotese det passer bedst med.
- Afprøv adfærd, der er afgørende for konklusionen, på et testsystem med samme programversion, fx hvad der sker med tidsstemplerne ved kopiering eller ved Gem som.
Det er vigtigt at arbejde med begge hypoteser fra starten. Ellers er der risiko for kun at lede efter spor, der bekræfter mistanken, og overse dem, der taler imod.
Typiske fejlkilder
- Kopiering og download giver ny oprettelsestid i filsystemet, mens ændringstiden ofte bevares. Det kan se ud, som om filen er ændret før den blev oprettet.
- Skabeloner fører gamle oprettelsestider og forfattere med ind i nye dokumenter.
- Gemt som opretter en ny fil med ny tid, selvom indholdet er gammelt.
- Tidszoner. Lokal tid og UTC blandes, når kilderne lægges sammen.
- Manglende spor. Overskrevne journaler og slettede versioner betyder, at fravær af et spor ikke er et bevis.
Hvad metoden kan og ikke kan bevise
Sammenholdes flere uafhængige kilder, kan metoden ofte fastlægge et tidligste og et seneste tidspunkt for, hvornår dokumentet fik sin nuværende form. Den kan understøtte eller afkræfte en påstået dato. Den kan sjældent sige, hvem der har ændret datoen, eller med hvilken hensigt, og den kan ikke udelukke, at et ældre udkast har eksisteret et sted, der ikke er undersøgt.
I rapporten
Opstil en tidslinje med hvert spor, dets kilde, rå værdi og tidszone. Angiv for hver kilde, hvor let den kan påvirkes af brugeren. Skriv de alternative forklaringer, der er overvejet, og hvorfor de er fravalgt. Se Tidslinjeanalyse.
Kilder og versioner
- Microsoft Learn: Hændelse 4616, systemtiden blev ændret
- Microsoft Learn: Filtider i Windows
- Ecma International: ECMA-376 Office Open XML
Senest gennemgået: oktober 2026.
Næste skridt
- Metadata, der forsvinder ved upload og deling
- Falske chatbilleder: verifikation mod kildeenheden og appens database
- Audit trail i e-signaturløsninger
Del af: Analyse og fortolkning
Læs også: Filsignaturer og forkerte filendelser · Falske chatbilleder: verifikation mod kildeenheden og appens database
→ Teknisk undersøgelse af dokumenter og metadata · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
