Fra artefakt til konklusion: hvad et spor faktisk viser

Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen

Et artefakt viser næsten altid mindre, end det ser ud til. At en fil findes på en disk, at filen er blevet åbnet, og at en bestemt person åbnede den, er tre forskellige påstande, og hver af dem kræver mere dokumentation end den foregående. Den mest almindelige fejl i forensiske rapporter er ikke forkerte data, men et spring mellem disse niveauer, som ikke er begrundet.

Artiklen beskriver en trinvis måde at bevæge sig fra rå data til en konklusion, der kan efterprøves, og hvor springene typisk sker. Analysemetoderne samlet står i Analyse og fortolkning.

Fire niveauer af påstande

Det er nyttigt at skelne mellem fire niveauer, når et spor skal beskrives:

Tilstedeværelse: Data findes på et bestemt sted i det sikrede materiale. Eksempel: en fil med et bestemt navn og en bestemt hashværdi ligger i en brugers profilmappe.
Systemhændelse: Systemet har registreret en handling. Eksempel: der findes en LNK-fil, en jump list-post eller en Prefetch-fil, som peger på filen eller programmet.
Brugerhandling: Handlingen er sket i en interaktiv brugersession, ikke af en automatisk proces. Eksempel: posten ligger i en brugers NTUSER.DAT og er skrevet, mens kontoen var logget interaktivt på.
Person: En bestemt person udførte handlingen. Det kræver spor uden for selve computeren eller kontoen.

Mange tvister handler reelt om niveau 3 og 4, mens de fleste artefakter kun dokumenterer niveau 1 og 2. ISO/IEC 27042 beskriver netop analyse og fortolkning som et selvstændigt trin, der skal kunne efterprøves, og hvor den, der analyserer, skal kunne redegøre for hvert skridt fra data til konklusion.

Hvad typiske artefakter faktisk registrerer

Fil i filsystemet · Hvad det registrerer: At data findes, med tidsstempler · Hvad det ikke viser: Hvordan filen kom dertil
LNK-fil og jump list · Hvad det registrerer: At en fil blev åbnet via skallen eller et program (se spor efter åbnede filer) · Hvad det ikke viser: At indholdet blev læst
Prefetch · Hvad det registrerer: At et program blev startet · Hvad det ikke viser: Hvilken bruger der startede det
Shellbags · Hvad det registrerer: At en mappe er vist i Stifinder for en bruger · Hvad det ikke viser: At filer i mappen blev åbnet
Browserhistorik · Hvad det registrerer: At en adresse blev indlæst · Hvad det ikke viser: At siden blev læst af en person
Auditlog i cloud · Hvad det registrerer: At en konto udførte en handling · Hvad det ikke viser: Hvem der brugte kontoen

Hvert artefakt har en kendt oprindelse og en kendt adfærd, men adfærden varierer med version, konfiguration og program. Prefetch er typisk slået til på Windows-klienter, men er ofte slået fra på servere og kan slås fra via konfiguration, og jump lists afhænger af, om programmet understøtter dem. Om et artefakt overhovedet blev dannet på det konkrete system, skal derfor kontrolleres, før dets fravær tillægges betydning. → Windows-artefakter: LNK, jump lists, shellbags og USB

Springene, der skal begrundes

Fra tilstedeværelse til handling

En fil i Overførsler-mappen er ikke nødvendigvis hentet bevidst. Den kan være synkroniseret fra en anden enhed, gendannet fra backup, kopieret ved en migrering eller lagt der af et program. Før man skriver “filen blev downloadet”, skal man se efter de spor, en download normalt efterlader: browserens downloadhistorik, en Zone.Identifier-strøm og tidsstempler, der passer sammen.

Fra systemhændelse til brugerhandling

En LNK-fil oprettes, når en fil åbnes via skallen, men også i visse andre situationer, fx ved nogle programmers forhåndsvisning eller ved gendannelse af en brugerprofil. En Prefetch-post kan stamme fra en planlagt opgave eller en opdatering. Spørgsmålet er derfor altid: Kunne en automatisk proces have skrevet dette? Svaret findes ved at se på konteksten, fx om der var en interaktiv logon på tidspunktet, og om andre artefakter viser brugerinput samtidig. → Systemet eller brugeren?

Fra brugerkonto til person

En konto er ikke en person. Delte adgangskoder, ulåste skærme, fjernadgang og overtagne sessioner betyder, at selv en sikker brugerhandling kun peger på kontoen. Koblingen til en person kræver uafhængige spor som adgangskort, MFA-godkendelser på en bestemt telefon, kalenderdata eller vidneudsagn. → Hvem sad ved tastaturet?

En arbejdsmetode, der holder

Beskriv observationen præcist. Angiv artefakt, sti eller post, værdien og tidsstemplet med tidszone. Ingen fortolkning endnu.
Beskriv artefaktets mekanisme. Hvad får systemet til at skrive denne post, og under hvilke betingelser? Henvis til dokumentation eller egen afprøvning.
Opstil de mulige forklaringer. Mindst én alternativ forklaring bør overvejes for hver vigtig observation.
Afprøv forklaringerne mod andre spor. Hvilke artefakter burde findes, hvis forklaring A er rigtig, og hvilke, hvis forklaring B er rigtig?
Formulér konklusionen på det niveau, sporene bærer. Brug en konsistent skala for sikkerhed, og skriv, hvad der ikke kan konkluderes.

Punkt 4 er det, der adskiller analyse fra beskrivelse. Hvis brugeren har åbnet et dokument fra et USB-drev, forventes typisk både en LNK-fil, en shellbag-post for drevet, registreringer af USB-enheden og en logon-session på tidspunktet. Mangler en af dem, skal fraværet forklares, ikke ignoreres.

Sprog, der skiller observation og slutning

Formuleringen i rapporten afgør, om læseren kan se, hvor observationen slutter. Sammenlign:

“Brugeren åbnede kontrakten den 3. marts.” Her er tre spring skjult i én sætning.
“Der findes en LNK-fil i profilen for kontoen X, som peger på kontrakt.docx på drev E:. Målfilens tidsstempler i LNK-filen og LNK-filens egen oprettelsestid ligger den 3. marts kl. 14.02 (UTC+1). Det er forenetligt med, at filen blev åbnet via Stifinder fra drevet på dette tidspunkt i en session for kontoen X.”

Den anden version er længere, men den kan efterprøves, og den lader det juridiske spørgsmål om, hvem der sad ved computeren, stå åbent, indtil andre spor er vurderet. → Rapportskrivning: struktur, sprog og efterprøvelighed

Sikkerhedsgrader

En konklusion bør ledsages af en angivelse af, hvor sikker den er, og på hvilket grundlag. Mange bruger en verbal skala fra “udelukket” over “forenelig med” til “sikker”. Det vigtige er, at skalaen er defineret i rapporten, bruges ensartet, og at hver grad er knyttet til de konkrete spor. → Konklusionsgrader: verbale skalaer og likelihood ratio

Pas på med “forenelig med”. Det er en svag påstand, som mange læsere opfatter som stærk. Hvis observationen er lige så forenelig med en uskyldig forklaring, skal det stå der.

Typiske faldgruber

Værktøjets etiket som konklusion. Et analyseværktøj kalder måske en post “File Opened” eller “User Activity”. Etiketten er en fortolkning foretaget af værktøjets udvikler, ikke en observation. Kontrollér den rå post.
Ét artefakt bærer hele konklusionen. Uafhængige kilder, der peger samme vej, er stærkere end mange poster fra samme mekanisme.
Tidsstempler læses som handlingstidspunkter. Et ændringstidspunkt viser, at metadata blev skrevet, ikke nødvendigvis, at en person redigerede indholdet.
Alternative forklaringer afvises uden test. Hvis en alternativ forklaring er afvist, skal det fremgå, hvilket spor der afviste den.

Flere af disse fejlkilder er samlet i en oversigt. → Fejlkilder i digital forensics

Hvad det betyder for læseren af rapporten

Advokater og dommere læser rapporten for konklusionen. Derfor skal vejen dertil være synlig: observation, mekanisme, alternative forklaringer og grad af sikkerhed. En rapport, der springer fra “filen findes” til “medarbejderen tog filen”, er sårbar ved en gennemgang fra modpartens sagkyndige, også selv om konklusionen i sidste ende er rigtig. Hvordan rapporten læses fra den juridiske side, er beskrevet her: → Sådan læser du en IT-sagkyndig rapport

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Analyse og fortolkning

Læs også: Fejlkilder i digital forensics: oversigt · Hvem sad ved tastaturet? Attribution af brugerhandlinger · Teknisk ordbog

→ Digital forensics-undersøgelse · 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