Maandelijkse vulnerability scanning: Eerste maand kosteloos! Meer informatie →
Hero

WIJ ZIJN

HACKIFY

Kerberos

Kerberos

30 juni 2026 · 9 min leestijd · begrippen

active-directory credentials network

Wat is Kerberos?

Kerberos is een netwerkauthenticatieprotocol dat de identiteit van gebruikers en computers controleert met tickets en symmetrische versleuteling. In plaats van bij elke service opnieuw je wachtwoord te sturen, haal je één keer een ticket op bij een centrale, vertrouwde partij, en dat ticket bewijst daarna wie je bent. Die centrale partij heet de Key Distribution Center (KDC).

Het protocol komt van MIT, uit Project Athena, en is genoemd naar Kerberos, de driekoppige hond uit de Griekse mythologie die de onderwereld bewaakt. De drie koppen passen bij de drie partijen in elke uitwisseling: de client, de KDC en de service. De huidige versie is Kerberos versie 5, vastgelegd in RFC 4120. In Active Directory is Kerberos sinds Windows 2000 het standaard authenticatieprotocol, met NTLM als oudere terugval.

Hoe werkt Kerberos?

In het kort bewijs je bij Kerberos één keer wie je bent, en krijg je daarvoor een soort digitaal pasje terug. Met dat pasje haal je daarna voor elke service een apart toegangsbewijs op, zonder telkens opnieuw je wachtwoord in te voeren. Onder water gebeurt dat in drie stappen tussen de client, de KDC en de service.

  1. In de eerste stap (de AS-exchange) logt de client in bij de Authentication Service (AS) van de KDC. De client bewijst dat hij het wachtwoord kent door er een timestamp mee te versleutelen die de KDC controleert. Dat heet pre-authenticatie. Klopt het, dan krijgt de client het digitale pasje terug, een TGT (Ticket Granting Ticket). Dat TGT is versleuteld met de sleutel van het krbtgt-account, zodat de client het zelf niet kan aanpassen.
  2. In de tweede stap (de TGS-exchange) gebruikt de client dat TGT om bij de Ticket Granting Service (TGS) van de KDC een service ticket aan te vragen voor één specifieke service. De client noemt die service bij zijn SPN (Service Principal Name), de unieke naam waaronder de service in het domein bekendstaat. De KDC controleert het TGT en geeft een service ticket terug dat versleuteld is met de sleutel van die service.
  3. In de derde stap (de AP-exchange) stuurt de client het service ticket naar de service zelf. Die ontsleutelt het met zijn eigen sleutel en weet daarmee wie de client is, zonder de KDC nog te hoeven raadplegen.

Omdat het TGT met de krbtgt-sleutel is versleuteld, kan de client het zelf niet lezen of aanpassen, en omdat een service ticket met de sleutel van de service zelf is versleuteld, kan alleen die ene service het openen. Daar bovenop controleert Kerberos ook de server, niet alleen de client. De service kan zich op zijn beurt aan de client bewijzen (mutual authentication), iets wat NTLM niet kan.

Kerberos in Active Directory

In een domein draait de KDC op elke domain controller, met de AD-database als accountopslag. Het belangrijkste account daarin is het krbtgt-account, een speciaal, uitgeschakeld account waarvan de wachtwoord-hash elk TGT in het domein versleutelt. Die hash is daarmee de belangrijkste sleutel in de hele AD.

In elk ticket zit een PAC (Privilege Attribute Certificate). Daarin staan de SID (Security Identifier) van de gebruiker en de SID’s van alle groepen waar hij in zit. Dat is de autorisatie-informatie waarmee een service bepaalt wat je mag, zonder voor elke vraag terug te “bellen” naar een domain controller. De noPac-aanval uit 2021 misbruikte een fout in de PAC-afhandeling. Microsoft heeft die met beveiligingsupdates gedicht.

De SPN uit stap 2 is de unieke naam van een service, gekoppeld aan het account waaronder die service draait. Aan de hand van die naam bepaalt de KDC met welke accountsleutel hij het service ticket versleutelt. Daarom mag een SPN maar op één account staan. Staat dezelfde SPN op twee accounts, dan weet de KDC niet welke hij moet hebben en mislukt de authenticatie.

Windows kiest tussen Kerberos en NTLM via het Negotiate-mechanisme, dat Kerberos gebruikt waar het kan en anders terugvalt op NTLM. Of Kerberos kan, hangt om te beginnen af van hoe je verbindt. Via een hostnaam stelt de client een SPN samen en gebruikt hij Kerberos, via een IP-adres bestaat er geen SPN voor en valt Windows terug op NTLM. Daarnaast kun je het sturen met beleid, bijvoorbeeld door NTLM in een domein te beperken of helemaal uit te schakelen, zodat alleen Kerberos overblijft.

Een client en een domain controller mogen standaard maximaal 5 minuten uit elkaar lopen, anders mislukt de authenticatie. Daarom synchroniseren domeincomputers hun tijd met de domain controller.

Aanvallen op Kerberos

Veel Active Directory-aanvallen raken Kerberos ergens. De bekendste vallen grofweg in vier groepen uiteen.

Hashes offline kraken

Bij Kerberoasting vraag je met een gewoon domein-account service tickets op voor accounts met een SPN. Dat ticket is versleuteld met de wachtwoord-hash van het service-account, dus een zwak service-wachtwoord kraak je offline. AS-REP roasting werkt op accounts waarbij pre-authenticatie uitstaat. Bij die accounts geeft de KDC al versleutelde data terug zonder dat je het wachtwoord hoeft te bewijzen, en ook die data kraak je offline.

Tickets stelen en hergebruiken

Bij pass-the-ticket trek je, als je lokaal beheerder bent op een machine waar iemand is ingelogd, zijn TGT of service tickets uit het geheugen met Mimikatz of Rubeus, en injecteer je die in je eigen sessie. Bij overpass-the-hash zet je een gestolen NT-hash of AES-sleutel om in een echt TGT, en zo breng je Pass-the-Hash over naar de Kerberos-wereld.

Tickets vervalsen

Wie de juiste sleutel steelt, kan zelf geldige tickets maken. Een golden ticket is een zelfgemaakt TGT, ondertekend met de hash van het krbtgt-account. Omdat elk TGT met die hash wordt ondertekend, accepteert het domein zo’n vervalst ticket voor elke gebruiker en elke groep, tot Domain Admin aan toe. Je hebt de krbtgt-hash er wel voor nodig, en die heb je pas als je het domein al volledig hebt overgenomen. Een golden ticket gebruik je dus om toegang te behouden, niet om binnen te komen.

Een silver ticket is kleiner van bereik. Dat maak je met de hash van één service-account, en het geeft alleen toegang tot die ene service. Het voordeel voor de aanvaller is dat de domain controller er niets van ziet, want die komt er niet aan te pas. Diamond- en sapphire-tickets zijn varianten die een echt, door de domain controller uitgegeven ticket aanpassen in plaats van er één helemaal zelf op te bouwen, waardoor ze moeilijker te detecteren zijn.

Delegatie misbruiken

Kerberos-delegatie laat een service namens jou bij een andere service inloggen, bijvoorbeeld een webserver die namens jou gegevens uit een database ophaalt. Krijgt een aanvaller zo’n delegatie in handen, dan vraagt hij een service ticket op voor elke gewenste gebruiker, ook domain admins, en logt daarmee bij die service in. Er zijn drie varianten, die verschillen in waar de delegatie staat ingesteld.

  • Bij unconstrained delegation mag de service namens de gebruiker bij elke andere service inloggen. Een host met deze instelling bewaart de TGT van iedereen die ermee verbindt. Wie die host overneemt, verzamelt dus de TGT’s van anderen, en met de printer bug dwing je zelfs een domain controller om langs te komen.
  • Bij constrained delegation (msDS-AllowedToDelegateTo) is de delegatie beperkt tot een paar vaste services. Wie dat account beheert, vraagt met S4U een service ticket voor elke gebruiker aan en logt zo bij die services in.
  • Bij resource-based constrained delegation (RBCD) staat op de service zelf ingesteld wie namens anderen mag inloggen, in het attribuut msDS-AllowedToActOnBehalfOfOtherIdentity. Met schrijfrechten op een computerobject zet je daar een eigen account in, en log je op die machine in als elke gewenste gebruiker.

Met BloodHound brengen wij dit soort delegatiepaden in kaart.

Kerberos en relay

Relay betekent dat een aanvaller een inlogpoging die voor de ene server bedoeld is, opvangt en doorstuurt naar een andere server, om daar als het slachtoffer binnen te komen. Bij NTLM is dit een bekend en groot probleem, bekend als NTLM-relay. Bij Kerberos werkt het niet zomaar, omdat een ticket maar voor één service geldig is en op een andere server wordt geweigerd.

De route die wel werkt loopt via coercion. Je dwingt een server om naar jouw machine te authenticeren, vangt die Kerberos-authenticatie op en stuurt hem door naar bijvoorbeeld LDAP, om daar een aanvaller-account meer rechten te geven. De tool krbrelayx is hier speciaal voor gemaakt.

Kerberos in een pentest

Zodra wij in een Active Directory pentest een geldig domein-account hebben, is Kerberos een vroege bron van bevindingen. Met NetExec halen wij in twee commando’s de hashes op voor Kerberoasting en AS-REP roasting, en kijken meteen of RC4 nog is toegestaan. Met BloodHound brengen wij onveilige delegatie en aanvalspaden naar geprivilegieerde accounts in kaart.

# AS-REP roasting: hashes van accounts zonder pre-authenticatie
nxc ldap 10.0.0.1 -u jdoe -p Password --asreproast asreproast.txt

# Kerberoasting: hashes van accounts met een SPN
nxc ldap 10.0.0.1 -u jdoe -p Password --kerberoasting kerberoast.txt

De opgehaalde hashes kraken wij daarna offline. Wat een gekraakt service-account of een delegatiepad oplevert, hangt af van de rechten erachter. In onze rapportage benoemen wij niet alleen wat wij hebben gekraakt, maar ook de onderliggende oorzaak: een service-account in een privileged group, RC4 dat nog aanstaat, of een host met unconstrained delegation. Dat is voor de meeste klanten de duurzaamste fix. Voer dit soort tests alleen uit op systemen waarvoor je expliciete, schriftelijke toestemming hebt. Zonder die toestemming is het strafbaar.

Kerberos veilig houden

Bijna alle aanvallen hierboven misbruiken een verkeerde instelling, niet een zwakte in Kerberos zelf. Het volgende houdt ze tegen.

  • Geef service-accounts lange, willekeurige wachtwoorden, of beter nog een gMSA. Windows roteert dat wachtwoord automatisch elke 30 dagen, met een lengte van 240 bytes, waardoor Kerberoasting en silver tickets onhaalbaar worden.
  • Zet RC4 uit en forceer AES. RC4-tickets kraak je veel sneller en ze zijn het kenmerk van meerdere aanvallen. Microsoft bouwt RC4 sowieso af. Sinds november 2022 is AES de standaard, en in Windows Server 2025 geven domain controllers geen RC4-TGT’s meer uit.
  • Bescherm en roteer het krbtgt-account. AD bewaart altijd de huidige én de vorige sleutel, dus na één reset blijft een golden ticket gewoon werken. Daarom reset je het wachtwoord twee keer. Tussen de twee resets wacht je minstens 10 uur, de maximale levensduur van een TGT, zodat alle nog geldige tickets in die tijd vanzelf worden vervangen door tickets met de nieuwe sleutel. Reset je sneller, dan verbreek je in één klap de lopende sessies in het hele domein.
  • Ruim unconstrained delegation op. Markeer geprivilegieerde accounts als “Account is sensitive and cannot be delegated” en zet ze in de groep Protected Users, zodat hun TGT niet kan worden opgevangen of doorgegeven.
  • Laat pre-authenticatie op elk account aanstaan. AS-REP roasting werkt alleen op accounts waar de optie “Do not require Kerberos preauthentication” aanstaat, dus controleer regelmatig of geen enkel account die optie heeft.
  • Monitor de Kerberos-events 4768 (TGT-aanvraag), 4769 (service ticket) en 4771 (pre-authenticatie mislukt). Een piek aan 4769’s met RC4 voor veel verschillende SPN’s wijst op Kerberoasting, en een TGT met een extreem lange levensduur op een golden ticket.

Veelgestelde vragen over Kerberos

Wat is het verschil tussen Kerberos en NTLM?

Kerberos werkt met tickets en een centrale KDC, en kan ook de server controleren (mutual authentication). NTLM is ouder, doet een challenge-response zonder de server te verifiëren, en is gevoelig voor relay en Pass-the-Hash. In een domein gebruikt Windows standaard Kerberos zodra je via een hostnaam of SPN verbindt. Verbind je via een IP-adres, dan valt Windows terug op NTLM, omdat er voor een kaal IP geen SPN bestaat.

Wat is een TGT?

Een TGT (Ticket Granting Ticket) is het eerste ticket dat je na het inloggen van de KDC krijgt. Het is versleuteld met de sleutel van het krbtgt-account, dus alleen de KDC kan het lezen. Met dat TGT vraag je daarna service tickets op voor losse services, zonder telkens je wachtwoord opnieuw te sturen. In Windows is een TGT standaard 10 uur geldig en maximaal 7 dagen verlengbaar.

Wat gebeurt er als de krbtgt-hash wordt gestolen?

Dan kan een aanvaller golden tickets maken, oftewel vervalste TGT’s voor elke gebruiker met elke groep, inclusief Domain Admins. Een krbtgt-compromis staat gelijk aan een volledig gecompromitteerd domein. Herstellen kan alleen door het krbtgt-wachtwoord twee keer te resetten, met minstens 10 uur ertussen, want AD bewaart ook de vorige sleutel.

Waarom moet de tijd kloppen voor Kerberos?

Kerberos stopt timestamps in zijn berichten om replay-aanvallen tegen te gaan. Daarom mag de klok van een client maar beperkt afwijken van die van de domain controller. De standaardtolerantie is 5 minuten. Wijkt de tijd verder af, dan mislukt de authenticatie met de fout KRB_AP_ERR_SKEW. Daarom synchroniseren domeincomputers hun tijd met de domain controller.

Is Kerberos veiliger dan NTLM?

Over het algemeen wel. Kerberos stuurt geen wachtwoord over de lijn, controleert ook de server en is van zichzelf niet te relayen. Maar verkeerde configuratie haalt dat voordeel onderuit: RC4 dat nog aanstaat, service-accounts met zwakke wachtwoorden, en onveilige delegatie maken Kerberos alsnog goed aanvalbaar. Veilig is het pas als die punten op orde zijn.

Gerelateerde artikelen