Forside › Windows-forensik · Gennemgået oktober 2026 · Af John Nielsen
Kort svar: Hvornår computeren var tændt, kan som regel læses i Windows’ hændelseslogs. System-loggen registrerer opstart og nedlukning (Event 12, 13, 6005, 6006, 1074 og 41) samt dvale og opvågning. Security-loggen viser logon, logoff og, hvis det er slået til, lås og oplåsning (4800 og 4801). De viser, hvornår maskinen var i brug, ikke hvem der arbejdede.
Haster det? Security-loggen kan overskrive sig selv på dage på en travl maskine, og SleepStudy-rapporten dækker som standard kun de seneste tre døgn. Se akut forensisk sikring; hastesager koster ekstra.
Spørgsmålet opstår typisk i tvister om arbejdstid, fravær og hjemmearbejde. Den juridiske side er beskrevet på digital-bevissikring.dk. Her er fokus på kilderne og fortolkningen.
De vigtigste hændelser
12· Log og kilde: System, Kernel-General · Hvad den viser: Styresystemet startede, med starttidspunkt13· Log og kilde: System, Kernel-General · Hvad den viser: Styresystemet lukkede ned6005· Log og kilde: System, EventLog · Hvad den viser: Hændelseslogtjenesten startede (følger af opstart)6006· Log og kilde: System, EventLog · Hvad den viser: Hændelseslogtjenesten stoppede ved en ren nedlukning6008· Log og kilde: System, EventLog · Hvad den viser: Forrige nedlukning var uventet1074· Log og kilde: System, User32 · Hvad den viser: En bruger eller et program startede nedlukning eller genstart, ofte med konto og årsag41· Log og kilde: System, Kernel-Power · Hvad den viser: Windows startede igen uden en ren nedlukning42· Log og kilde: System, Kernel-Power · Hvad den viser: Systemet går i dvale eller slumretilstand107· Log og kilde: System, Kernel-Power · Hvad den viser: Systemet genoptog fra slumre1· Log og kilde: System, Power-Troubleshooter · Hvad den viser: Systemet vågnede, med tidspunkt for dvale og opvågning4624,4634,4647· Log og kilde: Security · Hvad den viser: Logon og logoff4800,4801· Log og kilde: Security · Hvad den viser: Arbejdsstationen blev låst og låst op4802,4803· Log og kilde: Security · Hvad den viser: Pauseskærm startet og afsluttet4778,4779· Log og kilde: Security · Hvad den viser: Fjernskrivebordssession genoptaget og afbrudt
Hændelsernes tekst og datafelter kan variere mellem Windows-versioner, så betydningen bør altid læses i den konkrete hændelses detaljer. En samlet oversigt over hændelses-id’er findes i event-id-opslaget.
Opstart og nedlukning
En normal opstart giver typisk 12 og 6005 inden for få sekunder af hinanden. En normal nedlukning giver 1074, efterfulgt af 6006 og 13. Event 1074 er særligt nyttig, fordi den ofte angiver, hvilken proces der startede nedlukningen, og under hvilken konto. Det skelner mellem en bruger, der lukker ned fra startmenuen, og en opdatering, der genstarter maskinen om natten.
Event 41 skrives ved næste opstart, når Windows ikke blev lukket rent ned. Hændelsesdata kan indeholde en fejlkode (bugcheck) eller et tidsstempel for, at tænd/sluk-knappen blev holdt inde. Står begge felter til nul, kan årsagen være strømsvigt, et tømt batteri eller en maskine, der hang. Event 41 siger altså, at noget gik galt, ikke præcist hvornår maskinen gik ud. Det tidspunkt må findes ved at se på de sidste hændelser før afbrydelsen, eller i Event 6008, som angiver forrige nedlukningstidspunkt.
Hurtig opstart narrer tidslinjen
Hurtig opstart (Fast Startup) er slået til på mange Windows-klienter. Når brugeren vælger “Luk computeren”, logges brugeren af, men kernen gemmes i en dvalefil i stedet for at blive lukket helt ned. Ved næste tænd genoptages kernen. Konsekvensen er, at hændelserne ikke altid ligner en klassisk opstart, og at oppetidstællere og visse opstartshændelser kan pege på et langt tidligere tidspunkt. Genstart giver derimod en fuld opstart. Hvilke af de klassiske hændelser der skrives ved en nedlukning med hurtig opstart, er ikke dokumenteret entydigt og kan variere. Et mere direkte spor er Event 27 fra Kernel-Boot, hvis datafelt for opstartstype skelner mellem fuld opstart (0x0), hurtig opstart (0x1) og genoptagelse fra dvale (0x2).
Kontrollér derfor indstillingen for hurtig opstart på den konkrete maskine, og beskriv i rapporten, hvordan den påvirker fortolkningen.
Dvale, slumre og Modern Standby
Bærbare computere lukkes sjældent ned. De går i slumre, når låget lukkes, og vågner, når det åbnes. Power-Troubleshooter-hændelsen ved opvågning angiver både, hvornår systemet gik i dvale, og hvornår det vågnede, og er ofte den mest præcise kilde til “låget var lukket fra 17.12 til 07.48”.
Maskiner med Modern Standby (S0) opfører sig anderledes. De kan vågne kortvarigt for at hente mail og opdateringer uden brugerens medvirken, og skærmen kan være slukket, mens systemet teknisk set kører. Sådanne korte opvågninger kan fejltolkes som aktivitet. Her giver Windows’ indbyggede SleepStudy-rapport (powercfg /sleepstudy) et bedre billede end System-loggen alene. Den viser hver standby-periode med start, varighed og årsag til opvågning, som standard for de seneste tre døgn og med tilvalg op til 28 døgn. Rapporten bør dannes tidligt og gemmes som bilag.
Lås og oplåsning
Event 4800 og 4801 er de mest direkte spor efter, at en bruger forlod og vendte tilbage til maskinen. De skrives kun, hvis underkategorien “Audit Other Logon/Logoff Events” er slået til i auditpolitikken, og det er den ikke altid. Mangler hændelserne, skyldes det oftest konfigurationen, ikke at skærmen aldrig blev låst. Se Windows audit policy.
Automatisk lås efter inaktivitet registreres på samme måde som manuel lås. En låsning siger derfor ikke, om brugeren aktivt forlod pladsen eller blot holdt op med at bruge tastaturet. Logon og oplåsning hænger sammen via logon-id og logontype. Se Event 4624 og 4625: logontyper.
Andre kilder, der supplerer
- SRUM registrerer program- og netværksforbrug pr. bruger i timeintervaller og kan vise, om der var aktivitet, også når hændelseslogs er kortere. Se SRUM.
- Programspor som jump lists, LNK-filer og Office-metadata viser konkrete handlinger, der kan sættes ind mellem tænd og sluk.
- Serverside-logs i Microsoft 365, VPN og fagsystemer viser aktivitet, brugeren ikke kan påvirke lokalt.
Sådan bygges en dagsoversigt
- Udtræk alle relevante hændelser fra System og Security for perioden, og normalisér til én tidszone.
- Par hændelserne: opstart med nedlukning, dvale med opvågning, lås med oplåsning og logon med logoff via logon-id.
- Markér intervaller som tændt, i dvale, låst, logget på eller ukendt.
- Læg serverside-aktivitet og programspor ind som uafhængige kontrolpunkter.
- Kontrollér stikprøver direkte i de rå EVTX-poster, og notér afvigelser mellem kilderne.
Et interval uden afsluttende hændelse, fx en opstart uden efterfølgende nedlukning, skal stå som uafklaret. Det er fristende at udfylde hullet med den mest sandsynlige forklaring, men det svækker hele oversigten, hvis modparten kan vise, at forklaringen ikke holder.
Fejlkilder
- Logstørrelse: Security-loggen kan overskrive sig selv på dage eller uger på en travl maskine. Huller er ofte et spørgsmål om rotation.
- Tidszone og sommertid: EVTX-tidsstempler er i UTC, men vises i lokal tid af Logbog. Eksportér og normalisér konsekvent.
- Systemaktivitet: opdateringer, backup og planlagte opgaver kan vække eller genstarte maskinen. Se systemet eller brugeren?.
- Fjernadgang: en tændt og ulåst maskine kan bruges via fjernskrivebord eller fjernsupport uden fysisk tilstedeværelse.
- Delte maskiner: flere konti på samme maskine kræver, at hændelser kobles til den rigtige konto.
Hvad sporene kan og ikke kan vise
Hændelseslogs kan vise, hvornår maskinen var tændt, i dvale, låst og logget på, med en præcision på sekunder. De kan ikke vise, om brugeren sad foran skærmen, eller om arbejdet var arbejdsrelateret. En maskine kan være tændt og ulåst i timevis uden brug, og en bruger kan arbejde i cloudtjenester fra en anden enhed, mens computeren er slukket. Konklusioner om arbejdstid bør derfor bygge på flere kilder, hvor lokale hændelser kun er én.
Dokumentation
Eksportér hele EVTX-filerne fra en forensisk kopi frem for skærmbilleder fra Logbog, og hash dem. Angiv Windows-version, revisionspolitik, indstilling for hurtig opstart, logstørrelser og den periode, loggene faktisk dækker. Præsentér resultatet som en tidslinje pr. dag med kilde for hver post, og markér huller tydeligt som “ingen data” frem for “slukket”.
Hvis oversigten skal bruges af ikke-teknikere, bør den ledsages af en kort forklaring af hver hændelsestype og af de vigtigste forbehold: hurtig opstart, dvale, automatisk lås og loggenes begrænsede rækkevidde. Det forebygger, at tal fra oversigten senere bruges til mere, end de kan bære.
Kilder og versioner
- Microsoft Learn: Event ID 41, The system has rebooted without cleanly shutting down first
- Microsoft Learn: Modern standby SleepStudy
- Microsoft Learn: Audit Other Logon/Logoff Events
- Microsoft Learn: 4624(S) An account was successfully logged on
Senest gennemgået: oktober 2026.
Næste skridt
- Registreringsdatabasen i en undersøgelse: hives, NTUSER.DAT og transaktionslogs
- Prefetch, Amcache og Shimcache: bevis for programkørsel og grænserne
- NTFS i dybden: MFT, $UsnJrnl, $LogFile og tidsstemplerne $SI og $FN
Del af: Windows-forensik
Læs også: Filserverrevision: hvem åbnede filen? · Windows audit policy: de indstillinger en undersøgelse har brug for
→ Forensisk undersøgelse af en computer · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT