Forside › Windows-forensik · Gennemgået oktober 2026 · Af John Nielsen
NTFS gemmer langt mere end filernes indhold. Master File Table ($MFT) har en post for hver fil med navn, størrelse og to sæt tidsstempler, ændringsjournalen ($UsnJrnl) registrerer oprettelse, ændring, omdøbning og sletning, og transaktionsloggen ($LogFile) rummer de seneste metadataændringer på et meget detaljeret niveau. Tilsammen kan de ofte vise, hvad der skete med en fil, i hvilken rækkefølge, også når filen selv er væk. Men de dækker forskellige perioder, og de findes kun i en kopi, der omfatter hele filsystemet. Hvordan andre filsystemer håndterer tid og sletning, er sammenlignet i Filsystemer sammenlignet.
Tidsstemplernes rolle i en samlet tidslinje er beskrevet i Tidslinjeanalyse, og mønstre efter sletteværktøjer og ændrede tidsstempler i Anti-forensics. Her gennemgås strukturerne.
Master File Table
$MFT er selv en fil og består af poster, typisk på 1.024 byte hver. Hver post starter med signaturen FILE og indeholder en række attributter:
$STANDARD_INFORMATION($SI): fire tidsstempler, filattributter og ejer-id.$FILE_NAME($FN): filnavn, reference til forældremappen og et eget sæt med fire tidsstempler. En fil kan have flere$FN-attributter, fx et langt navn og et kort 8.3-navn.$DATA: filens indhold eller en liste over de klynger på disken, hvor indholdet ligger. Meget små filer kan ligge helt inde i MFT-posten (resident data).
Hver post identificeres af et postnummer og et sekvensnummer. Sekvensnummeret tælles op, hver gang posten genbruges. Kombinationen, filreferencen, gør det muligt at skelne mellem en fil og en senere fil, der har fået samme post.
Når en fil slettes, markeres posten som ikke i brug, men indholdet bliver liggende, indtil posten genbruges. Det er derfor ofte muligt at finde navn, sti, størrelse og tidsstempler for slettede filer, og for små filer endda indholdet, selv på SSD’er, hvor de klynger, filen optog, er ryddet af TRIM. Se SSD, TRIM og gendannelse.
Mappernes indeks ($I30) kan desuden indeholde rester af poster for filer, der er slettet fra mappen, i indeksets ledige plads.
MACB: de fire tidsstempler
Både $SI og $FN har fire tidsstempler i FILETIME-format med 100 nanosekunders opløsning, gemt i UTC:
- M · Indhold ændret
- A · Sidst tilgået
- C · MFT-posten ændret
- B · Oprettet (born)
$SI opdateres ved de fleste handlinger og kan ændres af programmer via almindelige systemkald. $FN opdateres primært, når filen oprettes, flyttes eller omdøbes, og er sværere at påvirke. Derfor bruges forholdet mellem de to sæt til at vurdere, om $SI er ændret kunstigt.
Senest tilgået kan være slået fra af ydelseshensyn, og indstillingen kan aflæses med fsutil eller i registreringsdatabasen. Selv når den er slået til, kan NTFS udskyde skrivningen til disken i op til en time. Den bør derfor ikke bære en konklusion uden afprøvning på et tilsvarende system. Konvertering af FILETIME og andre formater er beskrevet i Tidsstempelformater.
$UsnJrnl: ændringsjournalen
Ændringsjournalen ligger som datastrømmen $J i filen $UsnJrnl i systemmappen $Extend. Hver post indeholder:
- et fortløbende USN-nummer, der også er en position i journalen,
- filreference og forældremappens reference,
- tidsstempel,
- filnavn på tidspunktet for posten,
- en eller flere årsagskoder, fx oprettelse, dataændring, omdøbning (gammelt og nyt navn), sletning og lukning.
Journalen gør det muligt at rekonstruere en fils livsforløb: oprettet i en mappe, ændret, omdøbt, flyttet til en anden mappe og slettet. Da forældrereferencen er med, kan stien ofte genskabes, også for mapper, der ikke findes længere.
Journalen har en maksimal størrelse, og de ældste poster frigives løbende. Den konfigurerede maksimale størrelse kan aflæses med fsutil usn queryjournal, men hvor lang tid den dækker, afhænger af aktiviteten: på en klient ofte dage til uger, på en travl server kortere. Frigivne poster kan dog ofte stadig findes i ledig plads på volumen og genfindes med carving.
Bemærk, at journalens tidsstempel er tidspunktet for posten, ikke nødvendigvis tidspunktet for brugerens handling, og at én handling i et program kan give mange poster.
$LogFile: transaktionsloggen
$LogFile er NTFS’ egen journal over metadataændringer, beregnet til at kunne gendanne filsystemets konsistens efter et nedbrud. Den indeholder gentagelses- og fortrydelsesposter for ændringer i MFT-poster, indekser og andre strukturer. Den er relativt lille og cirkulær og dækker derfor typisk kun timer eller få dage.
Til gengæld kan den indeholde detaljer, som hverken MFT eller journalen har, fx de tidligere værdier af tidsstempler før en ændring. Formatet er komplekst, og få værktøjer parser det fuldt ud. Fund fra $LogFile bør derfor verificeres med særlig omhu og beskrives forsigtigt.
Hvad de tre tilsammen kan vise
- At en fil fandtes, hvor den lå, og hvornår den blev oprettet, også efter sletning.
- Rækkefølgen af omdøbninger, flytninger og sletninger.
- Om tidsstempler er sat tilbage, ved at sammenholde
$SI,$FN, journalens tidsstempler og USN-numrenes rækkefølge. - At mange filer blev slettet eller omdøbt inden for et kort tidsrum.
De kan ikke vise filens indhold, når klyngerne er overskrevet, og de kan ikke vise, hvem der udførte handlingen. Det sidste kræver kobling til logon, programkørsel og andre artefakter. Spørgsmålet om, hvem der slettede en bestemt fil, er gennemgået i Hvem slettede filen?.
Sådan læses en fils forløb
Et typisk spørgsmål er, om et dokument blev omdøbt og slettet kort før en bestemt dato. Fremgangsmåden er:
- Find filens MFT-post via navn eller sti, eller find den i journalen, hvis posten allerede er genbrugt.
- Notér filreferencen, og filtrér journalen på den, så alle poster for netop den fil vises.
- Læs årsagskoderne i rækkefølge efter USN-nummer, ikke kun efter tidsstempel. USN-rækkefølgen er journalens egen og påvirkes ikke af ændringer af systemuret.
- Sammenhold med
$SI– og$FN-tiderne i MFT-posten og med eventuelle ældre versioner i skyggekopier. - Kontrollér, om andre filer i samme mappe har lignende hændelser på samme tid, fordi det kan pege på en automatisk proces frem for en enkelt brugerhandling.
Verifikation
Strukturerne er dokumenteret uofficielt, og værktøjerne fortolker dem forskelligt, særligt ved beskadigede poster og carvede data. Afgørende fund bør derfor parses med to uafhængige værktøjer, og de vigtigste værdier kontrolleres i rå hex på det angivne offset. Beskriv kontrollen kort i rapporten.
Sikring
Strukturerne er systemfiler, der ikke kommer med i en almindelig filkopi. De kræver en fysisk kopi af disken eller en logisk kopi af hele volumen. En målrettet kopi af udvalgte mapper mister dem helt. Valget af metode er beskrevet i Fysisk, logisk eller målrettet sikring. Skyggekopier kan indeholde ældre versioner af MFT og journal og bør inddrages.
Fejlkilder
- Kopiering, udpakning og synkronisering sætter tidsstempler, der ligner manipulation.
- En genbrugt MFT-post forveksles med den oprindelige fil, hvis sekvensnummeret ikke kontrolleres.
- Journalens dækningsperiode overses, så fravær af poster tolkes som fravær af handlinger.
- Værktøjer viser tider i lokal tid uden at sige det. Fastlås tidszonen i værktøjet, og notér den.
- Carvede journalposter blandes med aktive poster uden markering.
Dokumentation
Angiv for hvert fund: volumen, MFT-postnummer og sekvensnummer, USN-nummer for journalposter, alle relevante tidsstempler fra både $SI og $FN, kilde (aktiv struktur, skyggekopi eller carving), værktøj og version. Beskriv journalens dækningsperiode, så læseren kan se, hvilken periode fraværet af poster faktisk siger noget om.
Kilder og versioner
- Microsoft Learn: fsutil behavior (Last Access Time)
- Microsoft Learn: fsutil usn
- Microsoft Learn: Change journals
Senest gennemgået: oktober 2026.
Næste skridt
- Volume Shadow Copies: tidligere versioner som bevis
- RDP-spor: fjernskrivebord i logs, register og bitmap-cache
- Active Directory og domænecontroller-logs: konti, grupper og nulstillinger
Del af: Windows-forensik
Læs også: Prefetch, Amcache og Shimcache: bevis for programkørsel og grænserne · Volume Shadow Copies: tidligere versioner som bevis
→ Forensisk undersøgelse af en computer · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
