Forside › Windows-forensik · Gennemgået oktober 2026 · Af John Nielsen
Windows-hændelseslogs bør sikres i det oprindelige EVTX-format, enten som kopi af filerne fra en forensisk kopi eller som eksport med Windows’ eget eksportværktøj, og der skal beregnes en hashværdi med det samme. En CSV-fil eller et skærmbillede fra Logbog mister felter, tidszoneoplysninger og muligheden for efterprøvning. Det haster, fordi logs overskrives løbende, og fordi den mest oplagte knap i Logbog, “Ryd log”, sletter netop det, der skulle sikres.
Haster det? Logs overskrives løbende, når de når deres maksimale størrelse, og en forkert ryddet log kan ikke genskabes fra den kørende maskine. Se akut forensisk sikring, og bemærk, at hastesager koster ekstra.
Den generelle mekanik bag rotation og overskrivning er beskrevet i Logfiler og logrotation. Her gennemgås, hvordan Windows-logs konkret tages ud, så resultatet kan bruges i en sag.
Hvor filerne ligger
Hver kanal er en fil i mappen System32\winevt\Logs under Windows-mappen, fx Security.evtx, System.evtx og en lang række filer for Operational-kanalerne med kanalens navn i filnavnet. Placeringen kan være ændret pr. kanal, via gruppepolitik eller med wevtutil, og stien står i kanalens konfiguration i registreringsdatabasen. Kontrollér derfor den konfigurerede sti for hver kanal, før der kopieres.
Mens logtjenesten kører, er filerne låst. En almindelig filkopi i Stifinder mislykkes derfor eller giver en fejl, og det er en god ting: Det forhindrer en halv kopi.
Tre måder at sikre logs på
- EVTX-filer fra en forensisk kopi af disken · Fordele: Komplet, inklusive data i ledig plads i filen; ingen ændring af systemet · Ulemper: Kræver fuld eller målrettet forensisk sikring
- Eksport med Windows’ eget værktøj (Logbog eller kommandolinjen) · Fordele: Hurtig, kan gøres på et kørende system og fjernt · Ulemper: Kun aktive poster; handlingen ændrer systemet en smule
- Indsamling via en logsamler eller et SIEM · Fordele: Uafhængig af maskinen, ofte længere historik · Ulemper: Ofte omformede felter og filtrering ved indsamlingen
I en civil sag med en enkelt computer, der kan tages ud af drift, er den forensiske kopi at foretrække. På en server eller domænecontroller, der skal køre videre, er eksport ofte det realistiske valg. Bliver der tvivl om, hvorvidt maskinen skal slukkes, så se Sluk eller lad køre.
Eksport på et kørende system
Logbog kan gemme en kanal som EVTX via “Gem alle hændelser som”. Kommandolinjeværktøjet wevtutil har en tilsvarende funktion til at eksportere en kanal til en fil og kan bruges i et script, så samme fremgangsmåde gentages på flere maskiner. Det kan også ske via et fjernadministrationsværktøj; se RMM-værktøjet som sikringsværktøj. PowerShell kan læse logs, men cmdlet’erne er primært beregnet til at vise og filtrere; til selve sikringen bør den rå EVTX-eksport bruges.
Vær opmærksom på:
- Ikke “Gem og ryd”. Logbog tilbyder at gemme og rydde loggen i ét trin. Det skaber en
1102– eller104-hændelse og fjerner loggen fra systemet. Vælg altid kun eksport. - Ikke kun en filtreret visning. En gemt filtreret visning indeholder kun de poster, filtret viste. Eksportér hele kanalen, og filtrér bagefter på en kopi.
- Visningsoplysninger. Når Logbog spørger om at gemme visningsoplysninger, oprettes en mappe med sprog- og beskedfiler ved siden af EVTX-filen. Den gør det lettere at læse loggen på en anden maskine og bør gemmes sammen med eksporten.
- Rettigheder. Security-kanalen kræver administratorrettigheder. Notér, hvilken konto eksporten er udført med, fordi det vil fremgå af systemets egne logs.
Som hovedregel bør eksporten skrives til et eksternt, forberedt medie eller et netværksdrev, ikke til den undersøgte maskines egen disk. Skrivning til den lokale disk kan overskrive ikke-allokeret plads (unallocated), hvor slettede data ellers kunne genfindes.
Logstørrelse og overskrivning
Før eksporten aflæses kanalens egenskaber: maksimal størrelse, aktuel størrelse og handling ved fuld log. Notér også tidspunktet for den ældste post. Er loggen tæt på at være fuld og sat til overskrivning, er eksporten det første, der skal ske.
Det kan være relevant at øge den maksimale størrelse for at standse yderligere tab, mens sagen afklares. Det er en ændring af systemet og skal dokumenteres med tidspunkt, konto, gammel og ny værdi. Selve ændringen sletter ikke data, men en modpart kan spørge til den, og den skal kunne forklares. På mange servere vil det være mere robust at sikre logs løbende ved at slå videresendelse til en central logsamler til, hvis det ikke allerede er gjort.
Hashværdi og verifikation
Beregn en SHA-256-værdi af hver eksporteret EVTX-fil straks efter eksporten, og registrér den i en hashlog. Valget af algoritme er begrundet i Hashalgoritmer i forensic, og en skabelon findes på Hash-log over sikrede filer.
Bemærk, at to eksporter af samme kanal med kort mellemrum ikke giver samme hashværdi, fordi der i mellemtiden er skrevet nye poster. Hashværdien låser eksporten, ikke den levende log. Til kontrol af indholdet kan antallet af poster samt første og sidste EventRecordID noteres, så en senere læsning kan sammenlignes med det, der blev vist ved eksporten.
Flere maskiner og fjerneksport
I sager med mange maskiner eksporteres ofte via et script eller et administrationsværktøj. Det er acceptabelt, når:
- scriptet gemmes og versioneres sammen med sagen,
- outputtet indeholder maskinnavn, kanal, tidspunkt for eksport og konto,
- hver fil hashes ved modtagelse,
- fejl og maskiner, der ikke svarede, logges, så huller i indsamlingen er kendte.
Fjernindsamling som metode er nærmere beskrevet i Fjernindsamling via agent eller netværk.
Læsning på en anden maskine
En EVTX-fil kan åbnes i Logbog på en analysemaskine, men beskrivelsesteksten sammensættes ud fra beskedfiler på den maskine, der viser loggen. Mangler analysemaskinen de samme programmer eller sprogpakker, vises poster med teksten om, at beskrivelsen ikke kan findes. Data er stadig intakte i postens datadel, og det er dem, der skal bruges i analysen. Forensiske parsere læser datadelen direkte og afhænger ikke af beskedfilerne.
Åbn altid en arbejdskopi, ikke den hashede original. Nogle programmer skriver til filen eller opretter hjælpefiler ved åbning, og selvom indholdet ikke ændres, er det enklere at kunne vise, at originalen aldrig har været åbnet. Kontrollér hashværdien af originalen, før og efter analysen er afsluttet.
Typiske fejl
- Eksport til CSV eller tekst i stedet for EVTX. Felter går tabt, og tidspunkter vises i den lokale tidszone på eksportmaskinen.
- Kun Security-kanalen sikres, mens de Operational-kanaler, der faktisk viser fjernskrivebord, opgaver eller PowerShell, glemmes.
- Logs eksporteres efter en geninstallation eller oprydning, hvor indholdet allerede er væk.
- Ingen notering af logstørrelse og ældste post, så det senere ikke kan vises, at en periode aldrig var dækket.
Hvad eksporten kan og ikke kan
En korrekt EVTX-eksport bevarer de aktive poster i kanalen med alle felter og giver mulighed for at parse dem med flere værktøjer. Den indeholder ikke poster, der allerede er overskrevet, og normalt heller ikke rester i filens ledige plads, som kan findes i en forensisk kopi. Hvis spørgsmålet går på, om loggen er ryddet eller manipuleret, er den forensiske kopi derfor stærkere. Hvad de enkelte id’er betyder, står i Windows-hændelseslogs.
Dokumentation
Notér for hver eksport: maskinnavn og Windows-version, kanal, metode og værktøj, konto, tidspunkt med tidszone, logstørrelse og handling ved fuld log, ældste og nyeste post, antal poster, filnavn, hashværdi og lagringssted. Beskriv eventuelle ændringer af logindstillingerne. Med de oplysninger kan en anden sagkyndig følge eksporten fra maskinen til rapporten.
Kilder og versioner
Senest gennemgået: oktober 2026.
Næste skridt
- Prefetch, Amcache og Shimcache: bevis for programkørsel og grænserne
- NTFS i dybden: MFT, $UsnJrnl, $LogFile og tidsstemplerne $SI og $FN
- Volume Shadow Copies: tidligere versioner som bevis
Del af: Windows-forensik
Læs også: Event 4624 og 4625: logontyper og fortolkning · Registreringsdatabasen i en undersøgelse: hives, NTUSER.DAT og transaktionslogs
→ Forensisk undersøgelse af en computer · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
