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:
Now that we have an understanding of how Kerberos works in an AD, let’s talk about 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:
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.
There are several methods an adversary can use to generate a Golden Ticket in an AD environment. Below is the Mimikatz command to generate a Golden Ticket using the above requirements:
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.
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]
Genuine Request:
Account Name: mani@lab.tl.org
Account Domain: lab.tl.org
Golden Ticket:
Account Name: TL-DCLAB\notmani@tl-dclab
Account Domain: TL-DCLAB
Genuine Request:
Security ID: TL-DCLAB\mani
Account Name: mani
Account Domain: TL-DCLAB
Golden Ticket:
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:
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.
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.
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 often leaves very few artefacts and evidence for clients to identify and mitigate the attack; however, Triskele Labs concluded that by proactively implementing