Kerberos og NTLM: autentificeringsspor ud over 4624

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

Event 4624 på en klient eller server viser, at en logonsession blev oprettet. Domænecontrolleren viser noget andet: at en konto blev godkendt, med hvilken protokol, fra hvilken adresse og til hvilken tjeneste. Kerberos-hændelserne 4768, 4769 og 4771 og NTLM-hændelsen 4776 er derfor den anden halvdel af ethvert spørgsmål om, hvem der loggede ind hvor. De ligger centralt, de er svære for en almindelig bruger at påvirke, og de dækker også de maskiner, der ikke selv blev sikret.

Felterne i 4624 og logontyperne er beskrevet i Event 4624 og 4625, og en oversigt over domænecontrollerens øvrige logs i Active Directory og domænecontroller-logs. Her går vi i dybden med godkendelsen.

Kerberos i grove træk

Når en domænebruger logger på, beder klienten domænecontrolleren om en billet, der beviser identiteten (TGT). Med den beder klienten derefter om tjenestebilletter til hver tjeneste, den skal bruge, fx en filserver, en SQL-server eller en anden computer via fjernskrivebord. Hver af de to trin giver sin egen hændelse på den domænecontroller, der svarede:

4768 · Betydning: Billet til kontoen (TGT) anmodet · Revisionsunderkategori: Audit Kerberos Authentication Service
4771 · Betydning: Forhåndsgodkendelse mislykkedes · Revisionsunderkategori: Audit Kerberos Authentication Service
4769 · Betydning: Tjenestebillet anmodet · Revisionsunderkategori: Audit Kerberos Service Ticket Operations
4770 · Betydning: Tjenestebillet fornyet · Revisionsunderkategori: Audit Kerberos Service Ticket Operations

Microsoft angiver, at 4769 kun dannes på domænecontrollere. Underkategorierne skal være slået til i revisionspolitikken, ellers findes hændelserne ikke. Se Windows audit policy.

Felterne, der betyder noget

I 4768 og 4769 er de vigtigste felter:

Kontonavn og domæne: hvem der blev godkendt. Computerkonti ender på $.
Tjenestenavn: i 4769 den tjeneste eller computer, billetten gælder. Det viser, hvad kontoen tilgik efter logon.
Klientadresse og port: den IP-adresse, anmodningen kom fra. ::1 betyder, at anmodningen kom fra domænecontrolleren selv.
Fejlkode: 0x0 ved succes. I 4771 betyder 0x18 forkert adgangskode, og 0x25 betyder for stor tidsforskel mellem klient og domænecontroller.
Krypteringstype: fx 0x12 for AES256 og 0x17 for RC4.
Logon-GUID: i 4769 et id, der ifølge Microsoft kan bruges til at koble hændelsen til 4624 på den computer, billetten blev udstedt til.

Microsoft har fra opdateringerne i januar 2025 udvidet 4769 på Windows Server 2016 og nyere med flere felter om understøttede krypteringstyper og nøgler. Ældre og nyere hændelser kan derfor have forskellig struktur i samme eksport.

Krypteringstypen som indikator

På et domæne, hvor alle systemer understøtter AES, forventes 4769 med 0x11 eller 0x12. Microsofts egne overvågningsanbefalinger peger på, at andre værdier bør undersøges. En tjenestebillet med RC4 kan skyldes et gammelt system eller en tjenestekonto, der aldrig har fået ny adgangskode, men et pludseligt mønster af RC4-anmodninger til mange tjenester fra én konto er et kendt tegn på, at nogen har forsøgt at hente billetter til senere angreb på tjenestekontoernes adgangskoder. Det er et fund, der skal sammenholdes med andre spor, ikke en konklusion i sig selv.

NTLM

NTLM bruges, når Kerberos ikke kan: ved adgang via IP-adresse i stedet for navn, ved lokale konti, mellem systemer uden for domænet og i ældre programmer. Ved NTLM-godkendelse af en domænekonto validerer domænecontrolleren legitimationsoplysningerne og logger 4776. For lokale konti logges 4776 på den maskine, kontoen ligger på.

4776 er tyndere end Kerberos-hændelserne. Den viser konto, fejlkode og et felt for kildearbejdsstation, men ikke en IP-adresse. Arbejdsstationsnavnet er det navn, klienten selv har oplyst, og det kan være tomt eller misvisende. IP-adressen skal derfor findes i 4624 på den server, der blev logget på, hvor feltet for godkendelsespakke også viser, om det var NTLM, og i givet fald version 1 eller 2.

Microsoft har udvidet NTLM-logningen i Windows 11 24H2 og nyere serverversioner med hændelser i kanalen Microsoft-Windows-NTLM/Operational. De viser blandt andet proces, bruger, målmaskine og NTLM-version på klienten, serveren og domænecontrolleren. Findes de i miljøet, giver de et langt bedre grundlag for at følge NTLM-trafik end 4776 alene.

Sådan rekonstrueres et logon

Et typisk forløb for en domænebruger, der logger på en filserver fra en klient, giver:

4768 på en domænecontroller, med klientens IP-adresse.
4769 på en domænecontroller, med filserveren som tjeneste.
4624 på filserveren med logontype 3, godkendelsespakke Kerberos og samme logon-GUID som i 4769.

Ved fjernskrivebord ser kæden lidt anderledes ud og suppleres af RDP-specifikke spor, se RDP-spor. Mangler et af leddene, er det et spørgsmål i sig selv: blev der brugt NTLM, var revisionen slået fra, eller er loggen roteret?

Flere domænecontrollere

Hver domænecontroller logger de godkendelser, den selv behandlede. Klienter vælger domænecontroller efter site og tilgængelighed, så en brugers hændelser er typisk spredt. Sikr derfor Security-loggen fra alle domænecontrollere for samme periode, og kontrollér, hvor langt hver log går tilbage. Security-loggen på en domænecontroller kan rotere hurtigt i et travlt miljø.

IP-adresser og navne

Klientadressen i 4768 og 4769 er den adresse, domænecontrolleren så. Bag NAT, VPN eller en terminalserver kan mange brugere dele adresse, og med DHCP skifter adresser over tid. Kobl derfor adressen til en enhed via DHCP-logs eller VPN-logs for det konkrete tidspunkt, som beskrevet i DHCP- og Wi-Fi-logs.

Tid på tværs af maskiner

Kerberos kræver, at klientens og domænecontrollerens ure stemmer nogenlunde overens, og Microsoft beskriver fejlkoden 0x25, når forskellen er større end den tilladte tolerance i Kerberos-politikken. Det betyder, at domænemedlemmer normalt har ure, der ligger tæt på domænecontrollerens. Det gælder dog ikke for maskiner uden for domænet, for NTLM-forbindelser eller for systemer, der har været slukket længe. Når hændelser fra domænecontrolleren og fra klienter lægges i samme tidslinje, bør afvigelsen kontrolleres, fx ved at sammenligne tidspunktet for 4769 med den tilsvarende 4624 på målmaskinen. Metoden er beskrevet i urafvigelse. Alle tider i Security-loggen gemmes i UTC, men vises ofte i lokal tid.

Mønstre i fejlede godkendelser

Mange 4771 med fejlkode 0x18 eller 4776 med fejlkoder for forkert adgangskode, spredt over mange konti fra få adresser, ligner password spray. Mange fejl på én konto fra én adresse ligner snarere en gemt, forældet adgangskode på en enhed. Mønstrene er gennemgået i password spray og brute force.

Hvad sporene kan og ikke kan bevise

Domænecontrollerens hændelser kan vise, at en konto blev godkendt fra en bestemt adresse til en bestemt tjeneste på et bestemt tidspunkt. De kan ikke vise, hvem der kendte adgangskoden, eller hvem der sad ved den enhed, adressen tilhørte. Sammen med 4624, DHCP-data og spor på klienten kan de dog ofte indsnævre det til én enhed og én session.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Windows-forensik

Læs også: Sysmon som forensisk datakilde · Kan man se, om en fil er blevet åbnet? Spor i Windows og Microsoft 365

→ 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