Sysmon som forensisk datakilde

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

Sysmon er Microsofts gratis systemtjeneste fra Sysinternals, der logger proceskørsel med fuld kommandolinje, netværksforbindelser, filoprettelser, ændringer i registreringsdatabasen og meget mere til en særskilt hændelseslog. Hvor den er installeret, er den ofte den mest detaljerede lokale kilde til, hvad der faktisk kørte på en Windows-maskine. Men den logger kun det, konfigurationen beder om, og kun fra det tidspunkt, den blev installeret. Den første opgave i en undersøgelse er derfor at fastslå, hvilken konfiguration der var aktiv i den relevante periode.

De indbyggede Windows-logs og deres event-id’er er beskrevet i Windows-hændelseslogs. Her handler det om Sysmon.

Hvor loggen ligger

Sysmon skriver til kanalen Microsoft-Windows-Sysmon/Operational under Programmer og tjenester i Logbog. Microsoft angiver, at hændelsernes tidsstempler er i UTC. På tidspunktet for gennemgangen (oktober 2026) kører den aktuelle version på Windows 11 og Windows Server 2019 og nyere, og Microsoft har desuden gjort Sysmon tilgængelig som en valgfri, indbygget funktion i nyere Windows 11-versioner. Den indbyggede variant er slået fra, til den aktiveres, så det skal kontrolleres på hver maskine, om Sysmon overhovedet var i drift.

Mange organisationer sender Sysmon-hændelser videre til en SIEM-løsning. Så kan der findes en længere historik centralt end lokalt, hvor kanalen overskrives, når den er fuld.

De vigtigste event-id’er i en undersøgelse

1 · Proces oprettet, med kommandolinje, forælderproces, hash og bruger
3 · Netværksforbindelse, med proces, adresser og porte
5 · Proces afsluttet
6 og 7 · Driver og modul (DLL) indlæst, med signatur
11 · Fil oprettet eller overskrevet
12, 13 og 14 · Registreringsdatabasen: nøgler oprettet, værdier sat, omdøbt
15 · Navngiven datastrøm oprettet, fx Zone.Identifier ved download
22 · DNS-opslag fra en proces
23 og 26 · Fil slettet, med eller uden arkivering af den slettede fil

Hertil kommer hændelser for fjerntråde i andre processer, rå disklæsning, procesadgang, navngivne pipes, WMI-abonnementer, ændringer i udklipsholderen og forsøg på at skjule processer. Hvilke af dem der er relevante, afhænger af sagen.

Event 1 er den mest brugte. Den svarer til Windows’ egen 4688, men indeholder altid kommandolinjen, hashværdien efter konfigurationen og et unikt ProcessGuid, som gør det muligt at følge en proces på tværs af hændelser, selv om Windows genbruger proces-id’er. Feltet LogonGuid kobler processen til en bestemt logonsession.

Hændelser om Sysmon selv

Tre hændelser er afgørende for at vurdere loggens fuldstændighed:

Event 4: Sysmon-tjenesten er startet eller stoppet.
Event 16: konfigurationen er ændret. Hændelsen viser, at filtrene blev opdateret, men ikke nødvendigvis det fulde indhold.
Event 255: fejl i Sysmon, fx ved høj belastning, hvor ikke alle hændelser kunne behandles.

Et hul i loggen omkring et kritisk tidspunkt, eventuelt kombineret med event 4 eller 16, skal undersøges, før fravær af hændelser fortolkes. Sammenhold med Windows’ System-log for tjenestestop og med eventuel SIEM-modtagelse.

Konfigurationen afgør alt

Sysmon filtrerer hændelser efter en XML-konfiguration med regler for, hvad der skal med, og hvad der skal udelades. Netværksforbindelser og modulindlæsning er som udgangspunkt slået fra. Mange organisationer bruger offentligt tilgængelige konfigurationer som udgangspunkt og udelader støjende processer. Det har to konsekvenser for en undersøgelse:

Fravær er ikke bevis for fravær. Hvis en proces eller sti er udeladt i konfigurationen, logges den ikke. En angriber, der bruger et udeladt program, efterlader ingen Sysmon-spor.
Konfigurationen skal sikres. Den aktuelle konfiguration kan læses fra tjenestens indstillinger i registreringsdatabasen, eller vises med Sysmon selv. Den versionsstyrede konfigurationsfil hos IT-afdelingen eller MSP’en viser, hvad der var gældende tidligere.

Rapporten bør angive, hvilken konfiguration der var aktiv i perioden, og hvilke relevante hændelsestyper den udelukkede.

Sikring

Kanalen eksporteres som EVTX sammen med de øvrige hændelseslogs, helst fra en forensisk kopi eller med en metode, der bevarer filen uændret. Se eksport af Windows-hændelseslogs. Hvis hændelserne også findes i en SIEM-løsning, eksporteres de derfra med de originale felter, og det noteres, hvordan SIEM-løsningen har normaliseret dem. Forskellen mellem rå hændelser og SIEM-data er beskrevet i SIEM-data som bevis.

Notér også:

Sysmon-version og driverens navn, hvis standardnavnet er ændret.
Konfigurationens hashværdi og indhold.
Kanalens maksimale størrelse og ældste hændelse.
Om indstillingen for arkivering af slettede filer var aktiv, og hvor arkivmappen ligger. Mappen er beskyttet, men kan indeholde kopier af slettede filer, der er relevante for sagen.

Fortolkning

Sysmon er stærk til at vise, hvad der kørte, og hvordan processer hænger sammen. Typiske faldgruber:

Forælderprocessen er ikke altid den, der startede handlingen. Programmer kan starte processer via tjenester, planlagte opgaver eller WMI, så kæden ser anderledes ud end brugerens oplevelse.
Brugerfeltet viser den konto, processen kørte under, ikke nødvendigvis personen ved tastaturet.
Netværkshændelser logger forbindelsen, ikke indholdet, og værtsnavnet kan være et omvendt DNS-opslag på logtidspunktet.
Event 2, ændret oprettelsestid, opstår også ved helt legitime programmer, fx installationsprogrammer og synkroniseringsklienter.
Tidsstempler er i UTC i hændelsens eget felt, men kan blive vist i lokal tid af Logbog eller en SIEM-løsning.

Sammenhold Sysmon med andre kilder: Windows’ egne logs, programkørselsspor som Prefetch og Amcache og EDR-telemetri, hvis den findes. Når kilderne stemmer overens, er konklusionen stærk. Når de ikke gør, er forskellen i sig selv et fund, der skal forklares.

Sysmon, EDR og Windows’ egne logs

Sysmon overlapper med både Windows’ revisionspolitik og en EDR-løsning, men de har forskellige styrker. Windows’ 4688 kræver, at proceskørsel og kommandolinje er slået til i revisionspolitikken, og den har ingen hashværdi. PowerShell-scriptblokke logges kun af PowerShell selv, se PowerShell-historik og scriptlogning. En EDR-løsning registrerer ofte mere end Sysmon, men data ligger hos leverandøren med en opbevaringstid, kunden ikke styrer, som beskrevet i EDR-telemetri som bevis. Sysmon har den fordel, at data ligger lokalt i et dokumenteret format, som enhver kan læse. Den har den ulempe, at loggen er lige så sårbar som resten af maskinen: en administrator kan afinstallere tjenesten, ændre konfigurationen eller rydde kanalen. Derfor er en central kopi i en SIEM-løsning eller på en logserver langt stærkere som bevis end den lokale kanal alene, og rydning af kanalen efterlader selv spor i Windows’ egne logs.

Hvad Sysmon kan og ikke kan bevise

Sysmon kan med høj sikkerhed vise, at en bestemt proces med en bestemt kommandolinje og hashværdi blev startet på et bestemt tidspunkt under en bestemt konto, forudsat at loggen er sikret korrekt, og at tjenesten kørte. Den kan ikke vise, hvad brugeren havde til hensigt, hvad der blev vist på skærmen, eller hvad der skete i perioder og processer, konfigurationen udelukkede.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: Hiberfil, pagefile og swap: hukommelsesrester på disken · Kerberos og NTLM: autentificeringsspor ud over 4624

→ 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