During a recent Red Team engagement, Triskele Labs was able to compromise a Domain Controller (DC) in a client environment. As most readers will know, at this point, it’s game over.
If a DC is compromised by a real-world adversary, the recommendation of course must be made to rebuild the entire network, including the Active Directory (AD) infrastructure. However, this is a huge process that could take several weeks and significant financial investment. What if the organisation decides to instead purge the adversary from the network and recover?
A primary consideration that would have to be made in this scenario would be the Kerberos Golden Ticket. Triskele Labs often finds that this is a relatively unknown attack vector and that often, the assumption is made that a simple password change is enough to remediate a domain compromise.
In this post, we will talk about the concept of Kerberos authentication and the Golden Ticket, and how this ticket can be used by an adversary to maintain persistence over an organisation’s internal network, even after a password change of all AD accounts. We will then deep dive into how we can identify and remediate Golden Ticket attack vectors.
In any AD environment, there are often two primary authentication protocols used: NT Lanman (NTLM) and Kerberos. Due to some inherit weaknesses in NTLM, the default authentication mechanism in modern Windows hosts is set to Kerberos. Below is the Kerberos authentication flow, explained by Microsoft:
Figure 1 Kerberos Authentication Flow
To dig deeper into this, we have used Sean Metcalf’s blog for explaining typical Kerberos authentication flows, which are as follows:
1: The Kerberos Key Distribution Center (KDC) validates the user’s authentication request
a. The user sends an authentication request (AS-REQ) that includes the date and time of the authentication to the Kerberos Key Distribution Center (KDC), which is essentially runs on Domain Controller (DC). This authentication request is partly encrypted with the NTLM hash of the requesting user’s password.
b. Since KDC has all the users’ credentials stored in its database, it will attempt to decrypt the encrypted authentication message from the client in order to validate that the user is who they claim to be.
2: The KDC creates a Ticket-Granting Ticket (TGT)
a. Once the KDC has authenticated the user and checked the user’s information (logon restrictions, group membership, etc), the authentication message will be discarded and a Ticket-Granting Ticket (TGT) will be created.
b. The TGT is encrypted, signed, and delivered to the user (AS-REP). Only the Kerberos Service Account (KRBTGT) in the domain can open and read TGT data. This TGT, once sent to the user’s system, will be stored in the Kerberos tray in RAM, which makes the storage of TGT volatile on user’s system. It is also worth noting that the defaultvalidity for TGT is ten (10) hours.
3: The client requests the access to resources using the TGT [TGS REQ & TGS REP]. Once the TGT is received by the client, they can request the access to any resource such as a File Server using this TGT, which includes the following steps:
a. The client presents the TGT to the KDC and request access to a specific resource/service on the network.
b. When the KDC receives the TGT from the client, it knows the client is already authenticated as only the KDC can open and read the TGT data.
c. Now, the KDC will create another ticket known as Ticket Granting Service (TGS) ticket (TGSREQ). The data in the TGT is effectively copied to create the TGS ticket.
d. Since the KDC knows the requested resource/service’s password, it will encrypt the ticket with the NTLM hash of that resource/service’s password.
e. The new ticket, TGS, for the requested resource/service is then given back to the client to store in the Kerberos tray (TGS-REP) and it is valid for ten (10) hours by default.
4: The client uses the TGS to access the resource
a. Once the TGS for that requested resource/service is obtained, the client will use this TGS to access the resource, whenever required until it expires.
b. The client will connect to the server hosting the resource/service on the appropriate port and present the TGS (APREQ). The resource/service decrypts the TGS ticket using its NTLM password hash, verify the client and grant them the appropriate access.
5: User logs on with username and password on the workstation.
a. Password is converted to a 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).
b. The Domain Controller (KDC) checks the user information (logon restrictions, group membership, etc) & creates a Ticket-Granting Ticket (TGT).
So, from the above Kerberos authentication flow, we understand that a user has an authentication ticket (TGT) and service tickets (TGS) which provide access to Kerberos enabled services. Also, it is important to understand that the Kerberos Service Ticket (KRBTGT) is an account on the DC which is automatically created with each new Active Directory (AD) setup with the following attributes:
- The account is named ‘krbtgt’ and is disabled and hidden by default.
- While this account service is not used to run any service on the domain, the password of this account is used to sign all the AD Kerberos tickets and encrypt the TGT tickets so that only KDC can open them. It is also used to sign the service tickets (TGS).
- The password of this account is set when the domain is created, and the password expiry is set to never. So if the password of KRBTGT account needs to be changed, it has to be performed manually or by using the PowerShell script provided by Microsoft.
- KDC stores the current and previous passwords of this account and therefore, either are valid for Kerberos ticket signing/encryption.
Now that we have an understanding of how Kerberos works in an AD, let’s talk about Golden Tickets.
Understanding Golden Tickets
A Golden Ticket is essentially a forged authentication ticket (TGT) which is encrypted and signed by the KRBTGT account. In order to forge a TGT to generate a Golden Ticket, an adversary would require the KRBTGT password hash, which can only be obtained if the adversary has compromised and accessed the DC as a privileged user. The Golden Ticket is encrypted using the KRBTGT account password hash and can be decrypted by any KDC on the AD, meaning that no resource or service on that Domain can question its validity.
It is also worth noting that KDC sets the domain Kerberos policy on the tickets (TGT and TGS) when the tickets are generated. So, when the TGT is provided later to the KDC to generate a TGS or when a TGS is provided to any server/workstation to access specific services, the validity mentioned on the ticket is trusted. An adversary could use this trust and forge a ticket using the KRBTGT account with a validity of ten (10) years which would be accepted by all the resources/services on AD. In this way, the adversary could create a Golden Ticket or a TGS with access to all the AD resources/services and maintain the persistence over the network without getting detected for 10 years.
In order to create a Golden Ticket, the following is required:
- Domain Name
- Domain SID
- Domain KRBTGT Account NTLM Password Hash
- UserID for impersonation
Once the adversary obtains privileged access on the DC, the KRBTGT account NTLM hash can be extracted from NTDS.dit using various methods. Also, the Golden Ticket remains valid, even if the password of the user account used for impersonation is changed.
kerberos::golden /admin:ANYACCOUNTNAME /domain:DOMAINFQDN /id:ACCOUNTRID /sid:DOMAINSID /krbtgt:KRBTGTPASSWORDHASH /ptt
To summarise, once the KRBTGT account hash is compromised, an adversary can use this hash to generate a Golden Ticket to impersonate any user and this ticket can then be used to generate a valid TGS with access to any resource/service in the AD. This is a great method for an adversary to use to persist on the domain with access to ALL the resources/services.
Identifying and Detecting Golden Ticket Attacks
Now that we understand Kerberos and Golden Tickets, let us move to next step on how to identify and detect a forged Kerberos ticket attack in an AD environment.
Since Golden Tickets are generated using the KRBTGT account, no resource or service on that domain can question the validity of such tickets, which makes it hard to identify the creation of these forged tickets on the network. However, there are few events or artifacts the organisation can check to identify if such a ticket has been created or used.
When an adversary has used any arbitrary account name with a valid Relative Identifier (RID) of an existing AD account, the following security log events on the DC could become the artifacts of Golden Ticket creation:
[Note: In the below event examples, ‘TL-DCLAB’ is the Domain NetBIOS name, ‘lab-tl.org’ is the Account Domain, ‘mani’ is the user account associated with the provided RID and ‘notmani’ is the provided arbitrary Account Name]
- Event ID 4769: A Kerberos service ticket was requested
Account Name: email@example.com
Account Domain: lab.tl.org
Account Name: TL-DCLAB\notmani@tl-dclab
Account Domain: TL-DCLAB
- Event IDs 4672 and 4634
Security ID: TL-DCLAB\mani
Account Name: mani
Account Domain: TL-DCLAB
Security ID: mani
Account Name: TL-DCLAB\notmani
Account Domain: <BLANK>
So, genuine/valid account logon events should have the following data structure:
Security ID: Domain\AccountName
Account Name: AccountName
Account Domain: Domain
However, Golden Ticket events have one of the following issues:
- The ‘Account Domain’ field will be blank
- The ‘Account Domain’ field will have a Domain NetBIOS name
- If the ticket is generated using Mimikatz, then the ‘Account Domain’ field will contain the ‘eo.oe.kiki :)’ value
Check the Event IDs: 4624 (logon), 4672 (admin logon), 4634 (logoff) for such artifacts
The organisation could also check the validity of all the service tickets used on the domain and if any service ticket with a validity period different from validity set in AD’s Kerberos Domain Policy are found, then that service ticket could be a potential forged ticket and further investigation would be required.
Lastly, if it has been identified that the DC is compromised in any way by an adversary, then it is wise to assume that a Golden Ticket has also been created by that adversary in order to maintain persistence across the network.
Remediating Golden Ticket Attacks
In most scenarios involving an AD compromise, it is difficult and tedious to identify and detect all possible backdoors created by an adversary, including Golden Ticket attacks on the network. As such, the victim organisation is often left with only the option of rebuilding their complete AD infrastructure. However, rebuilding the whole environment is not feasible for all organisations and some might decide to strengthen the security posture of their existing environment to protect the AD resources/services, and restrict and block the adversary’s access over the network.
As a recognised security service provider, we recommend the following remediations. These will not only protect the AD environment against Kerberos service tickets attacks, but also strengthen the overall security posture while revamping the whole environment.
- Use long (>25 characters) and complex passwords for Service Accounts (SAs)
- It is strongly recommendedto configure the Maximum lifetime for a service ticket to 600 minutes/10 hours. This can be done by configuring the policy value in the Default Domain Policy on Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Kerberos Policy -> “Maximum lifetime for user ticket” to a maximum of 10 hours, but not 0 which equates to “Ticket doesn’t expire”.
- Reset the KRBTGT account password twice, if any unauthorised access on the DC is observed. Since both the current and previous passwords of the KRBTGT account are used by the KDC to validate Kerberos tickets, the password must be changed twice, approximately 12-24 hours apart to prevent potential service disruptions. Note: Changing the KRBTGT account password twice in rapid succession (before AD replication completes) will invalidate all existing TGTs forcing clients to re-authenticate since the KDC service will be unable to decrypt the existing TGTs. Choosing this path will likely require rebooting the servers/workstations (or at least re-starting application services to get them talking to the KDC correctly again).
- Limit the groups and users with DC admin/logon rights.
- Create a separate user account and admin account (g. mani and mani-admin) for users who require privilege access on certain resources/services. Also, the admin accounts should have privileged access on specified and required resources/services only.
- Implement Microsoft LAPS (or similar solution) to randomise local admin passwords on every workstation and server.
- PowerShell logging and associated alerting. PowerShell provides extended capabilities to the adversaries as it can run .Net code and execute dynamic code in the memory without even touching the disk, therefore avoiding detection. Nowadays, Offensive PowerShell script ‘PowerSploit’ has become an integral component of any adversary post-exploitation arsenal. Hence, it is strongly recommended to implement logging of all the system PowerShell commands using Group Policy on all the workstations and servers. Also, implement Constrained Mode on the PowerShell which restrict the PowerShell usage to core capability only.
- Restrict internet access to DCs and servers where possible.
- Change the KRBTGT account password (twice) every year and when an AD administrator leaves the organisation.
- Last but not the least, Microsoft has introduced a security solutioncalled Microsoft Advanced Threat Analytics (ATA), which reviews and forward network traffic to DCs. ATA provides the capability to detect modern reconnaissance and attack activities including Golden Ticket usage.
In an AD environment, Golden Ticket attacks have significant consequences and can be highly complex to remediate. This attack gives an adversary a widespread and long-term access over an organisation’s network. This attack does often leaves very few artefacts and evidence for clients to identify and mitigate the attack; however, Triskele Labs concluded that by proactively implementing