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

WIJ ZIJN

HACKIFY

Kerberoasting

Kerberoasting

22 mei 2026 · 5 min leestijd · begrippen

active-directory credentials

Wat is Kerberoasting?

Kerberoasting is een Active Directory-aanval waarbij een aanvaller met een geldig domain-account willekeurige service-account-wachtwoorden offline kan kraken. De techniek maakt gebruik van een basisprincipe van Kerberos. Elke geauthenticeerde gebruiker mag een ticket aanvragen voor elke service. Dat ticket wordt versleuteld met de wachtwoord-hash van het service-account. Een aanvaller die het ticket opvangt heeft daarmee een offline crack-target, zonder dat een enkele login op het account nodig is.

De aanval werd in 2014 voor het eerst gedemonstreerd door Tim Medin op DerbyCon. MITRE ATT&CK categoriseert hem onder T1558.003 Steal or Forge Kerberos Tickets: Kerberoasting.

Hoe werkt Kerberoasting?

De aanval doorloopt vier stappen.

  1. De aanvaller heeft een geldig domain-gebruikersaccount, hoe weinig privileges ook. Zelfs een standaard user-account werkt.
  2. Vanuit dat account vraagt hij in LDAP een lijst op van alle accounts met een Service Principal Name (SPN). SPN’s zijn typisch toegekend aan service-accounts (SQL-server, IIS, scheduled task).
  3. Voor elk SPN vraagt hij een Ticket Granting Service-ticket (TGS) aan bij de domain controller. Dat is een normale Kerberos-flow en triggert geen alarm.
  4. De domain controller stuurt een TGS terug die versleuteld is met de wachtwoord-hash van het service-account. De aanvaller extraheert het encrypted blob en kraakt het offline met hashcat.

Het encryption type maakt verschil voor de cracking-snelheid. Een RC4-HMAC TGS (etype 23) is een SHA1-HMAC over de NT-hash van het wachtwoord, en gaat in hashcat naar mode 13100. Op een moderne GPU kraakt dat een 8-character lowercase wachtwoord in seconden tot minuten. AES-versleutelde tickets (etype 17 voor AES128, etype 18 voor AES256) zijn zwaarder; hashcat mode 19600 of 19700 handelt die af.

Wat de aanval mogelijk maakt is dat het verkrijgen van de TGS geen authenticatie tegen het service-account zelf vereist. De domain controller geeft hem aan iedere geauthenticeerde domain-user. Een zwak service-account-wachtwoord wordt zo offline en stiltjes te kraken.

Wat kan een aanvaller met Kerberoasting bereiken?

Kerberoasting levert wachtwoorden van service-accounts. De waarde daarvan hangt direct af van welke rechten die accounts hebben.

In een AD-omgeving die least privilege correct toepast heeft een service-account alleen de rechten die zijn service technisch nodig heeft, niets meer. Een gekraakte hash uit zo’n omgeving levert toegang tot de bijbehorende service en niet veel verder. Met een sterk wachtwoord en periodieke rotatie blijft de aanval grotendeels theoretisch.

In de praktijk zijn service-accounts vaak slordiger ingericht. Veel zitten in privileged groups zoals Domain Admins of Backup Operators, of hebben een delegated rol op een hele OU, omdat het bij het aanmaken simpel leek. Het komt regelmatig voor dat een gekraakt SQL-service-account direct Domain Admin-rechten oplevert. De pijn zit niet in Kerberoasting zelf, maar in service-accounts die veel meer rechten hebben dan hun service ooit nodig had. Met BloodHound brengen wij die verkeerde rechten-verdeling in kaart.

Een laatste eigenschap is dat de aanval nauwelijks sporen achterlaat. Een TGS-request hoort tot het normale verkeer in een AD-domein. Alleen door specifiek op RC4-HMAC tickets te alerteren komt het in beeld.

Kerberoasting in een pentest

In een Active Directory pentest is Kerberoasting een vroege standaard-stap zodra wij over een geldig domain-account beschikken. Wij draaien Impacket’s GetUserSPNs.py of Rubeus, schrijven de TGS-hashes naar een bestand, en zetten dat in hashcat tegen onze GPU-rig.

# Linux: alle SPN's enumereren en TGS's aanvragen
GetUserSPNs.py -dc-ip 10.0.0.1 -request acme.local/jdoe -outputfile tgs.hashes

# Hashcat: RC4-tickets (mode 13100) tegen een woordenboek
hashcat -m 13100 tgs.hashes /usr/share/wordlists/rockyou.txt

Zwakke service-account-wachtwoorden vallen binnen het uur, soms binnen minuten. Lukt het cracken niet, dan combineren wij de SPN-lijst met andere bevindingen. In welke groups zitten deze accounts, welke services draaien op welke hosts, en welke daarvan kunnen wij verder uitbuiten?

In onze rapportage benoemen wij niet alleen welke wachtwoorden wij gekraakt hebben, maar ook welke service-accounts onnodig in privileged groups zaten. Dat is voor de meeste klanten de duurzaamste fix.

Hoe voorkomt u Kerberoasting?

De aanval volledig blokkeren kan niet zonder Kerberos af te schaffen, maar de impact kan goed worden ingeperkt. Least privilege en lange random wachtwoorden zijn de twee fundamentele maatregelen.

Geef een service-account alleen de rechten die zijn service technisch nodig heeft, niets meer. Geen Domain Admin, geen wildcard-delegations, geen “voor de zekerheid”. Een gekraakte hash uit een least-privilege account heeft beperkte waarde, terwijl hetzelfde compromis op een service-account met Domain Admin-rechten direct catastrofaal is.

Lengte en willekeur zijn de criteria voor het wachtwoord. Niemand hoeft een service-wachtwoord te onthouden, dus wij adviseren 64 bytes random. Dat maakt offline cracking onhaalbaar, ook met moderne GPU’s of dedicated rigs. Gebruik een wachtwoord-generator in plaats van een herkenbaar patroon.

Group Managed Service Accounts (gMSA) zijn de moderne vervanger van traditionele service-accounts. Windows roteert het wachtwoord automatisch elke 30 dagen, met een lengte van 240 bytes. Een gekraakte gMSA-hash is binnen een maand alweer veranderd, en de kans dat een aanvaller hem in die tijd kraakt is verwaarloosbaar.

Schakel RC4-HMAC uit in uw domein. Met de groepsbeleid-instelling “Network security: Configure encryption types allowed for Kerberos” forceert u AES als enige toegestane etype. Dat verzwaart cracking aanzienlijk, al biedt het geen volledige bescherming.

Schoon overbodige SPN’s op. Veel domain-accounts hebben jaren geleden een SPN gekregen voor een service die niet meer draait. Een onnodige SPN is een gratis crack-target voor een aanvaller. Audit periodiek welke accounts daadwerkelijk SPN’s nodig hebben en verwijder de rest.

Honeypot SPN’s en logging vangen Kerberoasting-pogingen op. Maak een service-account aan met een lokkende naam zoals svc_db_admin, zonder dat daar daadwerkelijk een service achter zit. Configureer een alert op iedere TGS-aanvraag voor dat account. Daarnaast helpt Windows Event ID 4769 met een RC4-HMAC-encryption-flag om reguliere Kerberoasting-pogingen op te merken.

Veelgestelde vragen over Kerberoasting

Heb ik admin-rechten nodig voor Kerberoasting?

Nee. Elke gewone domain-gebruiker kan TGS-tickets aanvragen voor elk service-account. Dat is de hele kracht en het hele probleem van de aanval. Een aanvaller die via phishing één enkele werknemers-credential bemachtigt, kan onmiddellijk beginnen met enumereren en kraken.

Werkt Kerberoasting ook met AES-Kerberos?

Ja, maar het is zwaarder. Hashcat mode 19600 (etype 17, AES128) en 19700 (etype 18, AES256) handelen AES-tickets af. AES-Kerberos gebruikt PBKDF2 met 4096 iteraties, dus cracken duurt langer dan bij RC4. Zwakke wachtwoorden (8 tot 12 tekens, dictionary-woorden) vallen alsnog binnen redelijke tijd. Het uitschakelen van RC4 verzwaart de aanval; een random wachtwoord van 64 bytes of een gMSA stopt hem volledig.

Wat is het verschil tussen Kerberoasting en AS-REP roasting?

AS-REP roasting werkt op accounts met de optie ‘Do not require Kerberos preauthentication’ aan. Bij die accounts kan een aanvaller een AS-REP-bericht aanvragen zonder ooit een geldig domain-account te hebben, en het bericht offline kraken. Kerberoasting werkt op accounts met een SPN, maar de aanvaller heeft daarvoor wel een geldig domain-account nodig. Beide leveren offline-crackbare hashes, het type vereiste account-configuratie verschilt.

Hoe vaak slaagt Kerberoasting in jullie pentests?

In een grote meerderheid van de AD-pentests die wij uitvoeren slaagt Kerberoasting. Veel organisaties hebben minstens één service-account met een verouderd of zwak wachtwoord dat binnen een woordenboek-aanval valt. Pas op omgevingen die gMSA gestandaardiseerd hebben, of waar service-account-wachtwoorden centraal en strikt beheerd worden, slaagt de aanval doorgaans niet meer.

Gerelateerde artikelen