Windows audit policy: de indstillinger en undersøgelse har brug for

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

Når et event-id mangler i en undersøgelse, er forklaringen oftest ikke, at hændelsen aldrig skete, men at Windows ikke var sat op til at logge den. Mange af de hændelser, der bruges i sager om fratræden, misbrug af adgang og hackerangreb, skrives kun, hvis den relevante underkategori i den avancerede auditpolitik er slået til, og hvis loggen er stor nok til at gemme dem. Artiklen beskriver de indstillinger, der bør være på plads, før noget sker.

Den er skrevet til IT-afdelinger og MSP’er, der vil gøre klienter og servere klar til en undersøgelse, og til sagkyndige, der skal forklare, hvorfor et spor mangler. Et samlet overblik over baseline for logning, opbevaring og tidssynkronisering findes i forensic readiness teknisk.

Basis eller avanceret auditpolitik

Windows har to sæt indstillinger. Den grundlæggende auditpolitik har ni brede kategorier. Den avancerede auditpolitik (Advanced Audit Policy Configuration) har omkring 60 underkategorier og giver mulighed for at slå netop de hændelser til, der er brug for, uden at drukne loggen. De to sæt bør ikke blandes. Brug den avancerede, og slå indstillingen til, der tvinger underkategorierne til at have forrang. Ellers kan en grundlæggende indstilling overskrive de avancerede, og hændelse 4719 registrerer, at auditpolitikken er ændret.

Den aktuelle tilstand på en maskine kan dokumenteres med kommandoen auditpol /get /category:* kørt som administrator. Resultatet bør gemmes som en del af sikringen.

Underkategorier, der typisk er brug for

Logon og Logoff · Eksempler på hændelser: 4624, 4625, 4634, 4647 · Anvendelse i undersøgelser: Hvem loggede på, hvornår og hvordan
Special Logon · Eksempler på hændelser: 4672 · Anvendelse i undersøgelser: Logon med administratorrettigheder
Other Logon/Logoff Events · Eksempler på hændelser: 4800, 4801, 4778, 4779 · Anvendelse i undersøgelser: Lås, oplåsning og fjernskrivebord
Credential Validation · Eksempler på hændelser: 4776 · Anvendelse i undersøgelser: Godkendelse mod lokale konti eller domæne
Kerberos Authentication Service · Eksempler på hændelser: 4768, 4771 · Anvendelse i undersøgelser: Domænelogin på domænecontrolleren
User Account Management · Eksempler på hændelser: 4720, 4722, 4724, 4738 · Anvendelse i undersøgelser: Oprettelse og ændring af konti
Security Group Management · Eksempler på hændelser: 4728, 4732, 4756 · Anvendelse i undersøgelser: Tilføjelse til grupper
Process Creation · Eksempler på hændelser: 4688 · Anvendelse i undersøgelser: Hvilke programmer blev startet
File System · Eksempler på hændelser: 4663 · Anvendelse i undersøgelser: Adgang til filer med auditering (SACL)
Removable Storage · Eksempler på hændelser: 4663 · Anvendelse i undersøgelser: Adgang til filer på USB-medier
Detailed File Share · Eksempler på hændelser: 5145 · Anvendelse i undersøgelser: Adgang til filer på netværksshares
Audit Policy Change · Eksempler på hændelser: 4719 · Anvendelse i undersøgelser: Ændring af selve auditpolitikken
Security State Change, System Integrity · Eksempler på hændelser: 4608, 1102 (fra Eventlog) · Anvendelse i undersøgelser: Opstart og rydning af loggen

Tabellen følger Microsofts beskrivelse af de avancerede auditindstillinger. Hvad de enkelte hændelser viser, er beskrevet i Windows-hændelseslogs og Event 4624 og 4625. Hurtigt opslag pr. id findes i event-id-opslaget.

Kommandolinje i 4688

Event 4688 viser, at en proces blev startet, men som udgangspunkt ikke med hvilke argumenter. En særskilt indstilling under administrative skabeloner tilføjer kommandolinjen til hændelsen. Det gør 4688 langt mere nyttig, fordi forskellen mellem en harmløs og en mistænkelig kørsel ofte ligger i argumenterne. Microsoft gør opmærksom på, at kommandolinjer kan indeholde følsomme oplysninger, og at alle, der kan læse Security-loggen, også kan læse dem. Adgangen til loggen bør derfor begrænses. Hvordan hændelsen læses, er beskrevet i Event 4688: proceskørsel og kommandolinje.

Filrevision kræver to ting

Hændelse 4663 for filadgang skrives kun, når både underkategorien File System er slået til og den konkrete mappe har en revisionsliste (SACL), der angiver, hvilke handlinger og hvilke brugere der skal revideres. Uden SACL’en sker intet, selvom politikken er slået til. Det er en af de hyppigste årsager til, at spørgsmålet “hvem slettede filen?” ikke kan besvares. Se hvem slettede filen?.

PowerShell-logning

PowerShell er både et administrationsværktøj og et hyppigt angrebsværktøj. To indstillinger giver spor:

Script block logging skriver indholdet af kørte scriptblokke til PowerShell-Operational-loggen som hændelse 4104.
Module logging registrerer kald til bestemte moduler.

Begge slås til via gruppepolitik. Transskription kan derudover gemme hele sessioner som tekstfiler. Se PowerShell-historik og scriptlogning.

Logstørrelse og opbevaring

Selv med den rigtige politik er loggen ubrugelig, hvis den overskriver sig selv på få dage. Security-loggens standardstørrelse er lille i forhold til, hvad en travl server eller en klient med procesrevision producerer. På en Windows 11-klient er Security- og System-loggen ved gennemgangen (oktober 2026) typisk sat til 20 MB og PowerShell-loggen til 15 MB, medmindre en politik har ændret det. Den faktiske værdi aflæses med wevtutil gl efterfulgt af loggens navn. Øg størrelsen på klienter og servere, og send hændelserne videre til en central opsamling, fx via Windows Event Forwarding eller en SIEM, så de overlever, hvis den lokale maskine nulstilles eller loggen ryddes. Se logfiler og logrotation.

Tid

Hændelser er kun nyttige, hvis tiden er rigtig. Klienter og servere bør synkronisere tid fra en fælles, pålidelig kilde, og afvigelser bør kunne dokumenteres. Domænemedlemmer får normalt tiden fra domænecontrolleren, som selv skal have en pålidelig ekstern kilde. Ved sikring bør maskinens ur sammenlignes med en kendt kilde, og afvigelsen noteres, så hændelser fra flere maskiner kan lægges på samme tidslinje uden at blive forskudt.

Balancen mellem spor og støj

Mere logning er ikke altid bedre. Revision af alt filsystemet eller alle objekter på en domænecontroller kan give millioner af hændelser om dagen og fylde loggen, før den kan bruges. Microsoft anbefaler, at hver organisation selv vurderer sine trusler og vælger niveau ud fra det. En praktisk tilgang er at slå de brede kategorier for logon, kontoadministration, procesoprettelse og politikændringer til overalt, og at bruge filrevision målrettet på mapper med følsomme data.

Indsamling og overvågning af medarbejderes aktivitet skal have et lovligt grundlag, og medarbejderne bør være orienteret om logningen.

Domænecontrollere og filservere

Nogle spor findes kun på servere. Domænelogin via Kerberos registreres på domænecontrolleren, ikke på klienten (se Kerberos og NTLM: autentificeringsspor), og ændringer af konti og grupper i Active Directory skrives i domænecontrollerens Security-log. Adgang til filer på netværksdrev registreres på filserveren. En undersøgelse, der kun ser på medarbejderens computer, overser derfor ofte de vigtigste hændelser. Auditpolitikken bør sættes særskilt for domænecontrollere og filservere, og deres logs bør have høj prioritet i den centrale opsamling.

Tjekliste før sagen

☐ Avanceret auditpolitik bruges, og underkategorierne har forrang for de grundlæggende indstillinger.
☐ Logon, Logoff, Special Logon og Other Logon/Logoff Events er slået til for succes og fejl, hvor det giver mening.
☐ Kontoadministration og gruppeadministration revideres.
☐ Procesoprettelse revideres med kommandolinje, og adgangen til Security-loggen er begrænset.
☐ Mapper med følsomme data har SACL, og File System eller Detailed File Share er slået til på filservere.
☐ PowerShell script block logging er slået til.
☐ Logstørrelser er øget, og hændelser sendes til central opsamling.
☐ Tidssynkronisering er konfigureret og overvåget.
☐ Den gældende politik er dokumenteret med dato.

Når politikken manglede

Rapporten skal sige det, hvis en hændelse ikke kunne findes, fordi politikken ikke var slået til. Den aktuelle politik på sikringstidspunktet, hændelse 4719 og gruppepolitikkens historik kan vise, hvordan konfigurationen så ud i den relevante periode. Andre kilder, fx Prefetch, Amcache, LNK-filer og serverside-logs, kan ofte delvist erstatte de manglende hændelser, men med andre styrker og svagheder. En manglende hændelse skal derfor beskrives som en begrænsning i kildegrundlaget, ikke som et tegn på, at handlingen ikke fandt sted. Det er en skelnen, der har stor betydning, når modparten senere stiller spørgsmål til, hvorfor et bestemt spor ikke er med i rapporten.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: Opstart, nedlukning, lås og dvale: Windows-events · Hiberfil, pagefile og swap: hukommelsesrester på disken

→ 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