Windows‑hændelseslogs: de vigtigste kanaler og event‑id’er

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

Windows’ hændelseslogs er ofte den eneste kilde, der binder en konto, et tidspunkt og en handling sammen på selve computeren eller serveren. De vigtigste poster ligger i kanalerne Security og System og i en håndfuld Operational-kanaler, men hvad der faktisk er registreret, afhænger af revisionspolitikken, logstørrelsen og Windows-versionen. Et event-id viser, at systemet har registreret en bestemt type hændelse, ikke nødvendigvis hvem der sad ved maskinen, og et manglende id beviser intet, før det er kontrolleret, om logningen var slået til.

Haster det? Hændelseslogs har en fast maksimal størrelse, og når den er nået, overskrives de ældste poster, på en travl maskine efter ganske kort tid. Ved akut behov: akut forensisk sikring; hastesager koster ekstra.

Den grundlæggende sikring af en Windows-computer er beskrevet på hubben i Bevissikring af Windows-computere. Her gennemgås kanalerne og id’erne teknisk.

Hvordan logningen er bygget op

Hændelser skrives af Windows’ logtjeneste til binære filer i EVTX-format, én fil pr. kanal. Hver post har et event-id, en kilde (provider), et tidsstempel i UTC, et fortløbende nummer (EventRecordID), computernavn og en struktureret datadel med felter som kontonavn, SID, logon-id og procesnavn. Den tekst, som Logbog viser, sammensættes først ved visning ud fra beskedfiler på den maskine, der viser loggen. Derfor kan en log vist på en anden maskine mangle beskrivelser, selvom data er intakte.

Kanalerne falder i to grupper:

Windows-logs · Security, System, Application, Setup, Forwarded Events
Applikations- og tjenestelogs · TerminalServices, PowerShell, TaskScheduler, Defender, WinRM, SMB

Security-kanalen fyldes efter revisionspolitikken, som kan være sat lokalt eller via gruppepolitik. Mange hændelsestyper er ikke slået til som standard. Revision af procesoprettelse står fx som ikke konfigureret, og kommandolinjen kommer kun med i 4688, hvis en separat politik også er slået til. Den effektive politik skal derfor aflæses på systemet, fx med auditpol, eller i en kopi af registreringsdatabasen, før et fravær tolkes.

Opslagsliste: de mest brugte event-id’er

Listen dækker de id’er, der oftest indgår i civile sager og interne undersøgelser. Om et id overhovedet skrives, afhænger af den underkategori i revisionspolitikken, det hører til.

Logon og sessioner (Security)

4624: vellykket logon, med logontype, kilde-IP og logon-id.
4625: mislykket logon, med fejlkode.
4634 og 4647: logoff og brugerinitieret logoff.
4648: logon med eksplicit angivne legitimationsoplysninger.
4672: særlige rettigheder tildelt ved logon, typisk administratorkonti.
4778 og 4779: genoptagelse og afbrydelse af en session, fx fjernskrivebord.
4800 og 4801: arbejdsstation låst og låst op, hvis revision af andre logonhændelser er slået til.

Fortolkningen af logontyper er beskrevet i Event 4624 og 4625.

Konti og grupper (Security)

4720, 4722, 4725 og 4726: konto oprettet, aktiveret, deaktiveret og slettet.
4723 og 4724: forsøg på at skifte og nulstille adgangskode.
4728, 4732 og 4756: medlem tilføjet til en sikkerhedsgruppe.
4740: konto låst.
4768, 4769 og 4776: Kerberos- og NTLM-godkendelse, primært på domænecontrollere.

På domæneniveau ligger de fleste af disse hændelser på domænecontrolleren, ikke på klienten; se Active Directory og domænecontroller-logs.

Programmer, tjenester og opgaver

4688: ny proces oprettet, kun hvis revision af procesoprettelse er slået til.
4697 (Security) og 7045 (System): tjeneste installeret.
4698: planlagt opgave oprettet; TaskScheduler/Operational har flere detaljer.

System og integritet

1102 (Security) og 104 (System): log ryddet.
4616: systemtid ændret.
6005 og 6006: logtjenesten startet og stoppet, en praktisk markør for opstart og nedlukning.
6008: uventet nedlukning.
1074: nedlukning eller genstart startet af en proces eller bruger.

Operational-kanalerne

Flere spørgsmål besvares bedre i de applikationsspecifikke kanaler. TerminalServices-LocalSessionManager og RemoteConnectionManager viser fjernskrivebordssessioner med kilde-IP. PowerShell/Operational kan indeholde scriptblokke, hvis logningen er slået til. TaskScheduler/Operational viser oprettelse og kørsel af opgaver. Defenders Operational-kanal viser detektioner og ændrede indstillinger. Er Sysmon installeret, giver dens kanal langt mere detaljeret proces- og netværksaktivitet, men kun fra installationstidspunktet og med den konfiguration, der var valgt.

Overskrivning og logstørrelse

Hver kanal har en maksimal størrelse og en handling, når den er fuld. Hvor længe det i praksis rækker, er beskrevet i Hvor længe gemmes Windows’ event log?. Typisk overskrives de ældste poster. Security-kanalen på en travl server eller domænecontroller kan derfor dække ned til timer eller dage, mens en sjældent brugt Operational-kanal kan gå måneder tilbage. Den generelle mekanik er gennemgået i Logfiler og logrotation. For hændelseslogs betyder det konkret:

Notér den konfigurerede maksimale størrelse og opbevaringsmetode for hver relevant kanal.
Notér tidspunktet for den ældste post i hver kanal på sikringstidspunktet.
Videresendes logs til et SIEM eller en logsamler, sikres de der også, fordi den kopi typisk rækker længere tilbage og er uafhængig af den undersøgte maskine.

Selve udtrækket og hashberegningen er beskrevet i Eksport af Windows-hændelseslogs.

Sikring og verifikation

Den stærkeste kilde er EVTX-filerne fra en forensisk kopi, fordi de indeholder alle felter, også poster, der er markeret som overskrevne, men stadig fysisk findes i filen. Visse værktøjer kan genfinde poster i ledig plads i filen eller i ikke-allokeret plads (unallocated) på disken. Sådanne genfundne poster skal markeres særskilt i rapporten, fordi de ikke er en del af den aktive log.

Verificér analysen ved at:

kontrollere, at EventRecordID er fortløbende, og forklare eventuelle huller,
sammenholde tidsstempler med en kendt hændelse, fx sikringstidspunktet,
parse de afgørende poster med to uafhængige værktøjer og sammenligne felterne.

Fejlkilder i fortolkningen

Konto er ikke person. En logonhændelse viser en konto og en session, ikke hvem der sad ved tastaturet.
Tjenester og systemkonti skaber mange logons af type 3 og 5, som let forveksles med brugeraktivitet.
Beskrivelsestekst kan variere mellem Windows-versioner og sprog; brug felterne i datadelen.
Tidszone: Logbog viser lokal tid, mens posten er gemt i UTC. Eksporter til CSV kan arve visningens tidszone.
Fravær: Ingen 4688-poster betyder oftest, at revisionen ikke var slået til.
Ryddet log: 1102 viser, at loggen er ryddet, og af hvilken konto, men ikke hvad der stod i den. Det er behandlet i Anti-forensics.

Når id’erne kombineres

Enkeltposter siger sjældent meget. Værdien opstår, når posterne kædes sammen via felter, der går igen. Logon-id’et i 4624 går igen i 4634, 4672 og i 4688 for processer startet i samme session, så en session kan følges fra start til slut. Kilde-IP’en i en fjernlogon kan kobles til VPN- eller firewalllogs. Et kontonavn i 4720 kan kobles til den konto, der efterfølgende logger på i 4624. På den måde kan en række af hændelser beskrives som ét forløb: en session åbnes, rettigheder tildeles, en tjeneste installeres, og loggen ryddes.

Kædningen skal dog gøres med omtanke. Logon-id’er genbruges efter genstart, og samme kontonavn kan findes lokalt og i domænet. Brug derfor altid både SID, logon-id og tidsvindue, når poster kobles, og angiv i rapporten, hvilke felter koblingen hviler på.

Hvad loggen kan og ikke kan bevise

Hændelseslogs kan vise, at en konto loggede på et bestemt tidspunkt, fra en bestemt adresse, med en bestemt metode, og at bestemte systemændringer fandt sted. De kan sjældent alene vise, hvilken fil der blev åbnet, eller hvad der blev kopieret; det kræver artefakter i filsystemet og registreringsdatabasen. Loggens værdi stiger markant, når samme hændelse findes i en uafhængig kilde, fx domænecontrollerens log eller en central logsamler.

Dokumentation

For hver kanal, der indgår, bør rapporten angive kildefil og sti, maskinens navn og Windows-version, revisionspolitik og logstørrelse på sikringstidspunktet, ældste og nyeste post, værktøj og version til parsing samt hashværdi af den sikrede fil. Ved hver afgørende post angives EventRecordID, så en anden sagkyndig kan finde præcis samme post og efterprøve fortolkningen.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: Windows-artefakter: LNK, jump lists, shellbags og USB-spor · Event 4624 og 4625: logontyper og fortolkning

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