Over the last 6 months, I have been researching forged Kerberos tickets, specifically Golden Tickets, Silver Tickets, and TGTs generated by MS14-068 exploit code (a type of Golden Ticket). I generated forged Kerberos tickets using Mimikatz (Mimikatz Command Reference) and MS14-068 exploits and logged the results. Over the course of several weeks, I identified anomalies in the event logs that are clear indication of forged ticket use in an Active Directory environment.
Update1/5/2016:
Around this time last year (early January 2015), I shared with customers these indicators for detecting forged Kerberos tickets and subsequently presented this information at BSides Charm 2015. Soon after, Mimikatz was updated with a domain field that was set to static values, usually containing the string “eo.oe”. As of the Mimikatz update dated 1/5/2016, forged Kerberos tickets no longer include a domain anomaly since the netbios domain name is placed in the domain component of the Kerberos ticket.
Mimikatz code diff:

More information on the difficulty of detecting forged Kerberos tickets (Golden Tickets, Silver Tickets, etc) in the in the Detecting Forged Kerberos Tickets section below.
Kerberos Overview & Communication Process:

User logs on with username & password.
1a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an authenticator in the authentication ticket (TGT) request (AS-REQ).
1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) & creates Ticket-Granting Ticket (TGT).
2. The TGT is encrypted, signed, & delivered to the user (AS-REP). Only the Kerberos service (KRBTGT) in the domain can open and read TGT data.
3. The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, TGT = valid. The data in the TGT is effectively copied to create the TGS ticket.
4. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).
5.The user connects to the server hosting the service on the appropriate port & presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash.
6. If mutual authentication is required by the client (think MS15-011: the Group Policy patch from February that added UNC hardening).
Unless PAC validation is required (rare), the service accepts all data in the TGS ticket with no communication to the DC.
Active Directory Kerberos Key Points:
- Microsoft uses the NTLM password hash for Kerberos RC4 encryption.
- Kerberos policy is only checked when the TGT is created & the TGT is the user authenticator to the DC.
- The DC only checks the user account after the TGT is 20 minutes old to verify the account is valid or enabled. TGS PAC Validation only occurs in specific circumstances. When it does, LSASS on the server sends the PAC Validation request to the DC’s netlogon service (using NRPC)
- If it runs as a service, PAC validation is optional (disabled). If a service runs as System, it performs server signature verification on the PAC (computer account long-term key).
Forging Kerberos Tickets:
- Forging Kerberos tickets depends on the password hash available to the attacker
- Golden Ticket requires the KRBTGT password hash.
- Silver ticket requires the Service Account (either the computer account or user account) password hash.
- Create anywhere and user anywhere on the network, without elevated rights.
- Spoof access without modifying AD groups.
- Once the KRBTGT account password is disclosed, the only way to prevent Golden Tickets is to change the KRBTGT password twice, since the current and previous passwords are kept for this account.
Golden Tickets:
Continue reading
Recent Comments