Registreringsdatabasen i en undersøgelse: hives, NTUSER.DAT og transaktionslogs

Forside › Windows-forensik · Gennemgået oktober 2026 · Af John Nielsen

Registreringsdatabasen er Windows’ centrale konfigurationslager og en af de rigeste kilder i en undersøgelse: systemets opsætning, brugerkonti, installerede programmer, netværk, tilsluttede enheder og den enkelte brugers seneste handlinger. Den består af en håndfuld filer, kaldet hives, og hver hive har transaktionslogs, der kan indeholde nyere data end selve filen. Sikres registreringsdatabasen ved at eksportere den fra et kørende system, går netop de oplysninger tabt, der gør den værdifuld som bevis: tidsstempler, slettede nøgler og de ændringer, der kun ligger i transaktionsloggen.

De brugerrelaterede artefakter som shellbags og USB-spor er beskrevet i Windows-artefakter. Her gennemgås selve databasen: struktur, tid og korrekt sikring.

Hives og deres placering

SYSTEM · Placering: System32\config · Indhold i hovedtræk: Hardware, tjenester, drevbogstaver, tidszone, computernavn
SOFTWARE · Placering: System32\config · Indhold i hovedtræk: Installerede programmer, Windows-version, netværksprofiler
SAM · Placering: System32\config · Indhold i hovedtræk: Lokale konti, seneste logon, antal logons, skift af adgangskode
SECURITY · Placering: System32\config · Indhold i hovedtræk: Sikkerhedspolitik og gemte hemmeligheder
NTUSER.DAT · Placering: Brugerens profilmappe · Indhold i hovedtræk: Brugerens indstillinger, seneste filer, kørte programmer
UsrClass.dat · Placering: Brugerens lokale AppData · Indhold i hovedtræk: Shellbags og filtilknytninger for brugeren
Amcache.hve · Placering: Windows’ AppCompat-mappe · Indhold i hovedtræk: Programfiler, der har været på systemet

Hver bruger med en profil på computeren har sin egen NTUSER.DAT og UsrClass.dat. Det gør det muligt at skelne mellem aktivitet under forskellige konti på samme maskine, hvilket ofte er afgørende.

Struktur og LastWrite-tid

En hive er bygget op af nøgler og værdier, lagret i celler i blokke på 4 KB. Hver nøgle har et LastWrite-tidsstempel i UTC, der angiver, hvornår nøglen eller en af dens værdier sidst blev ændret. Værdierne har ingen egne tidsstempler.

Det har to konsekvenser for fortolkningen:

Når en nøgle indeholder mange værdier, viser LastWrite kun den seneste ændring af en af dem, ikke hvilken.
LastWrite opdateres også, når Windows eller et program skriver til nøglen uden brugerens medvirken, fx ved en opdatering eller vedligeholdelse.

Visse artefakter gemmer deres egne tidsstempler inde i værdiens data, fx UserAssist og BAM. De er ofte mere præcise end nøglens LastWrite, men formatet skal kendes og afkodes korrekt. Se UserAssist, RecentDocs og MRU-lister.

Transaktionslogs og beskidte hives

Windows skriver ændringer til registreringsdatabasen i to trin. Ændringen skrives først til en transaktionslog ved siden af hiven, med filendelserne LOG1 og LOG2, og flettes først senere ind i den primære fil. Er computeren slukket hårdt, eller tages kopien, mens systemet kører, kan den primære fil være “beskidt”: dens sekvensnumre stemmer ikke overens, og de nyeste ændringer ligger kun i loggen.

For undersøgelsen betyder det:

Transaktionslogs skal altid sikres sammen med hiven.
Analyseværktøjet skal kunne genafspille logs på en kopi af hiven, og det skal fremgå af dokumentationen, om det er sket.
En analyse af en beskidt hive uden logs kan overse de seneste timers eller dages ændringer, netop den periode, en sag ofte handler om.

Tidligere versioner af Windows lagde desuden automatiske sikkerhedskopier af hives i en RegBack-mappe. Fra Windows 10 version 1803 sker det ikke længere automatisk. Filerne i RegBack står typisk med størrelsen 0 KB, medmindre en administrator har genaktiveret funktionen i registreringsdatabasen. Ældre tilstande af registreringsdatabasen findes oftere i skyggekopier; se Volume Shadow Copies.

Slettede nøgler og værdier

Når en nøgle slettes, markeres cellen som fri, men indholdet bliver ofte liggende, indtil cellen genbruges. Specialiserede værktøjer kan genfinde slettede nøgler og værdier i hivens ledige plads. Det kan være relevant, hvis et program er afinstalleret, eller en liste over seneste filer er ryddet. Genfundne data skal markeres som genfundne, fordi de ikke indgår i den aktive database og ikke kan dateres lige så sikkert.

Hvorfor live-kopiering er forkert

En eksport med registreringseditoren giver en tekstfil med nøgler og værdier, men uden LastWrite-tid, uden slettede data og uden transaktionslogs. Hives kan ikke kopieres direkte, mens systemet kører, fordi de er låst. Værktøjer, der gemmer en hive fra et kørende system, laver en ny fil, hvor intern struktur og ledig plads ikke svarer til originalen.

Den korrekte kilde er en forensisk kopi af disken, hvor hives og logs udtrækkes fra et filsystem, der ikke længere ændres. Er en live-sikring nødvendig, fx fordi disken er krypteret og maskinen ikke må slukkes, bør filerne udtrækkes via en skyggekopi eller med et værktøj, der læser filsystemet direkte, så de rå filer med logs bevares. Fremgangsmåden og begrundelsen skal dokumenteres.

Nyttige kategorier af oplysninger

Uden at gentage artefaktartiklerne kan registreringsdatabasen typisk bidrage med:

Systemets grundoplysninger: computernavn, Windows-version, installationsdato, tidszone og seneste nedlukning. Tidszonen er en forudsætning for at tolke andre tidsstempler korrekt.
Konti: lokale konti med oprettelse, seneste logon og antal logons i SAM, og hvilke profiler der findes.
Programmer: installerede programmer, programkørsel og autostart; se Autostart, planlagte opgaver og tjenester.
Netværk: kendte netværk med første og seneste forbindelse, og tilknyttede netværksdrev.

Sammenligning over tid

Én hive viser kun tilstanden på sikringstidspunktet. Ændringer over tid kan ofte rekonstrueres ved at sammenligne samme hive fra flere kilder: den aktuelle kopi, hives i skyggekopier, hives i en backup og eventuelt en hive i en mappe fra en tidligere Windows-installation. Forskellene mellem versionerne viser, hvad der er tilføjet, ændret eller fjernet i mellemtiden, fx at et program er afinstalleret, eller at en liste over seneste filer er tømt.

Sammenligningen skal gøres med et værktøj, der arbejder på nøgle- og værdiniveau, ikke ved at sammenligne hashværdier af hele filer. To hives med forskellig hashværdi kan have identisk indhold, fordi intern placering og ledig plads ændrer sig, når Windows skriver til filen.

Flere brugere på samme maskine

Er flere konti brugt på computeren, skal hver profils NTUSER.DAT og UsrClass.dat analyseres for sig. Notér profilens SID, og kontrollér i SOFTWARE-hiven, hvilken profilsti der hører til hvilket SID. Et omdøbt brugernavn eller en genoprettet profil kan ellers føre til, at aktivitet tilskrives den forkerte konto.

Fejlkilder

LastWrite tolkes som brugerens handling, selvom systemet har opdateret nøglen.
Hives analyseres uden transaktionslogs, så de nyeste ændringer mangler.
Tidszonen fra SYSTEM overses, og lokale tidsstempler i værdidata tolkes som UTC eller omvendt.
Værktøjer afkoder samme værdi forskelligt. Afgørende værdier bør kontrolleres med et andet værktøj eller manuelt i rå data; se Verifikation af værktøjer.

Hvad registreringsdatabasen kan og ikke kan bevise

Registreringsdatabasen viser systemets og brugerens tilstand på bestemte tidspunkter, og med LastWrite og indlejrede tidsstempler kan den ofte placere handlinger i tid. Den viser sjældent alene, hvad der skete med en fil eller hvem der sad ved maskinen. Oplysningerne får deres styrke, når de sammenholdes med filsystem, hændelseslogs og andre artefakter i en tidslinje; se Tidslinjeanalyse.

Dokumentation

Angiv for hver hive: sti i kopien, tilhørende bruger, om transaktionslogs var til stede og er genafspillet, værktøj og version samt hashværdi. For hver afgørende værdi angives nøglesti, værdinavn, rå data, LastWrite-tid og fortolkningen, og om oplysningen stammer fra den aktive database, fra en transaktionslog eller fra ledig plads.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: Eksport af Windows-hændelseslogs (EVTX) til en sag · Prefetch, Amcache og Shimcache: bevis for programkørsel og grænserne

→ Forensisk undersøgelse af en computer · For IT-sikkerhed og SOC · 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