Kerberos RC4-hardening: de KDCSVC-events lezen en de accounts vinden die in april breken

21-01-2026 · Samantha Kloos-Kilkens

Sinds de updates van januari 2026 loggen domain controllers KDCSVC-events 201 tot en met 209 zodra een service ticket op een manier van RC4 afhankelijk is die de update van april 2026 niet meer toestaat. De fasering rond CVE-2026-20833 is elders al goed beschreven, dus die houd ik kort en ik ga in deze blog in op het deel waar het echte werk zit: wat elk event je vertelt, welke accounts erin terechtkomen (en welke er nooit in verschijnen), en hoe je die accounts vóór april met PowerShell vindt.

Een stapel papieren kaartjes in pasteltinten

Foto: Planet Volumes via Unsplash

Wat de januari-update verandert en wat niet

Windows-updates van 13 januari 2026 en later pakken CVE-2026-20833 aan: een aanvaller haalt service tickets op die met RC4 versleuteld zijn en probeert offline het wachtwoord van het service account te achterhalen. De januari-update is vooral instrumentatie: de audit-events en een tijdelijke REG_DWORD, RC4DefaultDisablementPhase onder HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters (1 is de huidige default en logt alleen, 2 laat de KDC aannemen dat RC4 standaard niet aanstaat, herstart nodig). Met de update van april 2026 wordt de aangenomen default voor accounts zonder msDS-SupportedEncryptionTypes alleen AES-SHA1 (0x18), met fase 1 nog als handmatige terugvaloptie. In juli 2026 wordt de registerwaarde niet meer gelezen. De januari-update alleen mitigeert de CVE dus niet; je bent pas beschermd zodra een DC in fase 2 draait.

Veel omgevingen leunen op het gedrag dat in april verandert, zonder dat iemand dat doorheeft. Een service account zonder msDS-SupportedEncryptionTypes valt terug op DefaultDomainSupportedEncTypes op de KDC, en als die niet gezet is, gaat de KDC sinds de wijzigingen van november 2022 uit van RC4 met AES-session keys. Daarom krijgt een Windows 11-client die keurig AES aanbiedt voor het gemiddelde SQL- of IIS-service account (een user-object) toch een met RC4 versleuteld ticket.

De events 201 tot en met 209 lezen

De events komen in de System-log van elke DC (bron Kdcsvc) en bevatten de service, de msDS-SupportedEncryptionTypes en beschikbare keys van die service, hetzelfde voor de DC, de waarde van DefaultDomainSupportedEncTypes, het clientadres en de encryptietypes die de client aanbood. De meeste komen in paren: een audit-event zolang de DC in fase 1 staat, en het bijbehorende blokkeer-event zodra hij afdwingt (de KB noemt die laatste errors, maar de eigen tabel geeft bij elk event type Warning, dus filter niet op level).

201 (audit) en 203 (geblokkeerd): de client bood alleen RC4 aan, de service heeft geen msDS-SupportedEncryptionTypes en de DC geen expliciete DefaultDomainSupportedEncTypes. Het account is in orde, de client is het probleem.
202 en 204: geen attribuut op de service, geen expliciete waarde op de DC, en het service account heeft alleen onveilige keys. Zonder AES-keys is het wachtwoord gezet voordat het domein ze kon genereren. Een fix aan de clientkant helpt hier niet; het account heeft een nieuw wachtwoord nodig.
205: DefaultDomainSupportedEncTypes is expliciet gezet op meer dan alleen AES-SHA1. Wordt bij elke start van de KDC-service gelogd en leidt nooit tot een blokkade.
206 en 208: de service (via het eigen attribuut) of de DC (via DefaultDomainSupportedEncTypes) staat al op alleen AES-SHA1, en de client bood alleen RC4 aan.
207 en 209: alleen AES-SHA1 is geconfigureerd, maar het service account heeft geen AES-keys.

201 en 206 wijzen dus naar de client, 202 en 207 naar het account, en het verschil tussen de paren is of de AES-eis uit de nieuwe default komt of uit configuratie die iemand eerder al heeft neergezet. Twee details uit de KB bepalen hoe je de log leest. 201 en 202 worden helemaal niet gelogd als DefaultDomainSupportedEncTypes handmatig gezet is, dus een DC met een expliciete waarde waar RC4 nog in zit, laat je bij het opstarten een 205 zien en daarna niets meer, terwijl een DC waar een eerdere hardeningpoging expliciet 0x18 heeft gezet 206 en 207 logt in plaats van 201 en 202. En de KDC blijft een expliciete waarde ook na april respecteren.

Daarnaast hebben de events een blinde vlek, en daar zit wat mij betreft het grootste risico. Ze verschijnen alleen als de KDC niet kan leveren wat de nieuwe default vraagt. Een service account zonder attribuut maar met AES-keys, benaderd door een Windows-client die AES aanbiedt, levert geen enkel event op: in april schakelen de tickets van RC4 naar AES zonder dat er iets gelogd wordt. Een Windows-service leidt zijn keys af van het wachtwoord en merkt daar niets van. Het gaat mis waar de servicekant een eigen kopie van de key heeft die alleen RC4 is, zoals een keytab die jaren geleden met ktpass /crypto RC4-HMAC-NT is geëxporteerd, of een appliance die ooit is gejoind en daarna nooit meer is aangeraakt. De KDC geeft een geldig AES-ticket uit, de service kan het niet ontsleutelen, en de fout verschijnt bij de service in plaats van op de DC. Deze vind je via de 4769-events (Ticket Encryption Type 0x17 naar accounts zonder attribuut), of met Get-KerbEncryptionUsage.ps1 -Encryption RC4 uit Microsofts Kerberos-Crypto-repository.

Welke accounts echt risico lopen

User-accounts met een service principal name vormen de hoofdgroep: ze hebben zelden msDS-SupportedEncryptionTypes, en de oudere missen AES-keys. Windows-computeraccounts schrijven hun eigen attribuut en roteren hun wachtwoord, dus een computerobject zonder attribuut is meestal een Linux-host, een NAS, een appliance of iets dat al jaren niet meer bestaat. gMSA's krijgen hun wachtwoord van de DC's en hebben AES-keys. De KDC versleutelt TGT's met AES zodra krbtgt een AES-key heeft, dus kijk wanneer het krbtgt-wachtwoord voor het laatst is gezet; ligt dat vóór AES in het domein, dan was een (dubbele, 10 uur uit elkaar) reset sowieso al aan de beurt. Trusts vallen erbuiten: volgens de KB blijven trust- en referral-flows naar andere Windows-DC's of KDC's van derden ongewijzigd.

Ze vooraf vinden met PowerShell

Kijk eerst waar elke DC werkelijk mee draait, want een expliciete DefaultDomainSupportedEncTypes verandert hoe je al het andere interpreteert.

Get-ADDomainController -Filter * | ForEach-Object {
    Invoke-Command -ComputerName $_.HostName -ScriptBlock {
        [pscustomobject]@{
            DC    = $env:COMPUTERNAME
            DDSET = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\KDC' -ErrorAction SilentlyContinue).DefaultDomainSupportedEncTypes
            Phase = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters' -ErrorAction SilentlyContinue).RC4DefaultDisablementPhase
        }
    }
}

Haal daarna de events van alle DC's op en groepeer ze per event, service en client, zodat je een werklijst hebt in plaats van een log.

Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{ LogName = 'System'; Id = 201..209 } -ErrorAction SilentlyContinue |
        Where-Object ProviderName -match 'Kdc|Key-Distribution'
} | ForEach-Object {
    [pscustomobject]@{
        Id      = $_.Id
        Service = if ($_.Message -match 'Service Name:\s+(\S+)')   { $Matches[1] }
        Client  = if ($_.Message -match 'Client Address:\s+(\S+)') { $Matches[1] }
    }
} | Group-Object Id, Service, Client | Sort-Object Count -Descending | Select-Object Count, Name

Om accounts zonder AES-keys te vinden voordat ze een ticket aanvragen, is de gebruikelijke shortcut de aanmaakdatum van de groep Read-only Domain Controllers (RID 521), die meekwam met de Windows Server 2008-generatie die ook AES naar Kerberos bracht. Die truc werkt maar in één richting: een wachtwoord dat vóór die datum voor het laatst is gezet, kan geen AES-keys hebben. Daarna zijn AES-keys waarschijnlijk maar niet zeker, want tools die alleen de NT-hash wegschrijven (wachtwoordmigratie met ADMT is het klassieke voorbeeld) geven je een recente pwdLastSet zonder AES-keys. In een domein dat op Windows Server 2008 of later is aangemaakt, is de datum gewoon de aanmaakdatum van het domein. Het andere advies, de datum waarop het domain functional level is verhoogd, is lastiger dan het lijkt: de replicatiemetadata van msDS-Behavior-Version laat alleen de laatste verhoging zien.

$domain  = Get-ADDomain
$aesHint = (Get-ADGroup -Identity "$($domain.DomainSID)-521" -Properties whenCreated).whenCreated

Get-ADUser -LDAPFilter '(servicePrincipalName=*)' -Properties msDS-SupportedEncryptionTypes, pwdLastSet |
    Where-Object SamAccountName -ne 'krbtgt' |
    Select-Object SamAccountName,
        @{ n = 'EncTypes';      e = { $_.'msDS-SupportedEncryptionTypes' } },
        @{ n = 'PwdLastSet';    e = { [datetime]::FromFileTime($_.pwdLastSet) } },
        @{ n = 'BeforeAesHint'; e = { [datetime]::FromFileTime($_.pwdLastSet) -lt $aesHint } } |
    Sort-Object PwdLastSet

Zie die uitvoer als triagelijst. Het echte antwoord staat in het veld Available Keys van de 4768- en 4769-events (Microsofts List-AccountKeys.ps1 leest die uit) en in de events 202 en 207. Dat veld bestaat alleen op DC's met Windows Server 2019 of later, en op 2016 sinds de cumulatieve update van januari 2025; een DC met Windows Server 2012 R2 logt het niet, dus daar vindt List-AccountKeys.ps1 niets.

RC4-service tickets en Kerberoasting

Elke geauthenticeerde gebruiker kan een service ticket aanvragen voor elk account met een SPN, en een deel van dat ticket is versleuteld met de key van het service account. Bij RC4-HMAC is die key de NT-hash, een ongezouten MD4 van het wachtwoord, dus elke kraakpoging is goedkoop. AES-keys worden afgeleid met PBKDF2 (standaard 4096 iteraties) en gezouten met realm en principal name, waardoor elke poging veel duurder wordt. AES vertraagt roasting maar houdt het niet tegen: een zwak wachtwoord blijft kraakbaar, dus de structurele oplossing is een lang willekeurig wachtwoord of een gMSA. Windows-clients bieden standaard niet alleen RC4 aan, terwijl je roasting-tools wel specifiek RC4 kunt laten vragen (Rubeus heeft daar opties voor), dus een 201 vanaf een gewone werkplek verdient ook een blik van je SOC.

Wat je vóór april oplost

Patch elke DC en draai de registercheck hierboven. Een expliciete DefaultDomainSupportedEncTypes met RC4 erin houdt die DC ook na april kwetsbaar, dus haal hem weg of houd hem aan als bewuste keuze.
Verzamel 201 tot en met 209 van alle DC's gedurende een paar weken, lang genoeg om maandafsluitingen en kwartaaljobs mee te nemen.
Geef accounts uit 202 en 207 een nieuw lang willekeurig wachtwoord en werk alles bij wat het account gebruikt, of zet de service over op een gMSA.
Los voor clients uit 201 en 206 het probleem aan de clientkant op: zet AES aan in krb5.conf of de Java-configuratie, en exporteer keytabs opnieuw met ktpass /crypto AES256-SHA1 (of All). Let op: ktpass zet bij het exporteren het wachtwoord van het account, dus al het andere dat dat account gebruikt, heeft het nieuwe wachtwoord ook nodig.
Kan een niet-Windows-service echt geen AES, zet dan msDS-SupportedEncryptionTypes op dat ene service account op 0x24 (RC4 met AES-session keys), geef het een lang willekeurig wachtwoord en leg het vast als uitzondering. DefaultDomainSupportedEncTypes op 0x24 zetten is het laatste redmiddel en laat elk account in het domein kwetsbaar.
Maak voor de stille groep een lijst van RC4-service tickets naar accounts zonder attribuut, en controleer bij elke niet-Windows-service daarin vóór april of de keytab AES-keys bevat (klist -k -e op MIT-systemen).
Zet daarna RC4DefaultDisablementPhase op 2 op één DC, herstart hem, en let op 203, 204, 208 en 209 voordat je de rest volgt.

Begin deze week met stap 1: de registercheck en een eerste ophaalronde van de events kosten minder dan een uur en laten zien hoe lang de rest van de lijst wordt.

Update maart 2026: Microsoft heeft de blinde vlek hierboven inmiddels bevestigd: het ontbreken van audit-events is geen bewijs dat niet-Windows-services blijven werken, en Azure Files-shares met on-premises AD DS-authenticatie (inclusief FSLogix-profielshares) vallen expliciet onder de wijziging. Storage accounts die nog op RC4 staan, moeten naar AES-256 (Update-AzStorageAccountAuthForAES256 in AzFilesHybrid), uiterlijk in juli bij standaard-SPN's en al in april als je custom SPN's of een custom DNS-suffix gebruikt; de stappen staan in Microsofts Azure Files-troubleshootingartikel. Shares op Entra Kerberos krijgen hun tickets van Entra ID, niet van je DC's.

De scripts uit deze blog staan ook op GitHub, in entra-scripts.

Kerberos RC4-hardening: de KDCSVC-events lezen en de accounts vinden die in april breken

Wat de januari-update verandert en wat niet

De events 201 tot en met 209 lezen

Welke accounts echt risico lopen

Ze vooraf vinden met PowerShell

RC4-service tickets en Kerberoasting

Wat je vóór april oplost

Bronnen

Samantha Kloos-Kilkens

Blijf op de hoogte

Lees ook:

Conditional Access op All resources: de uitzondering voor baseline scopes vervalt op 15 juni

Van Entra Connect Sync naar Cloud Sync: wat de begeleide migratie meeneemt en wat achterblijft