Privilege escalation has become harder to perform from an adversary point of view. Testing and patch management mechanisms have closed off a lot of the common vectors that attackers historically relied on, but this does not mean that privilege escalation has become impossible. Instead, attackers have turned to new techniques that may be virtually impossible to stop. Many of these techniques rely on an authentication protocol native to all windows Active Directory (AD) environments and utilized by all organizations called Kerberos. Kerberos is designed to provide strong authentication for client/server applications by using secret-key cryptography in the form of a ticket. By compromising these tickets, attackers can gain elevated privileges that often lead to a full, domain-wide compromise.

 

 

Why do attackers care about Kerberos?

Attackers often leverage New Technology LAN Manager (NTLM) protocols to authenticate to services in an AD domain. NTLM authentication requires a username and password (or password hash) to authenticate. This method is easy and usually works. Kerberos is another option for authenticating in Windows domains, but presents some challenges to use, such as requiring the use of a hostname instead of an IP address. So why would an attacker target Kerberos over NTLM? The primary reason is because some attacks are unique to Kerberos and cannot be performed using NTLM. You may already be familiar with Kerberos abuse if you ever heard of Kerberoast, or Kerberoasting, an attack that allows any "Domain Joined" user the ability to request the hash for a service account. These hashes can then be subjected to an offline dictionary attack to recover the cleartext password.

 

In this post I’ll address two commonly abused Kerberos features: silver and golden tickets. In the context of AD, Kerberos is intended to be a more secure method of authentication when compared to NTLM. Instead of using passwords (like NTLM), Kerberos uses tickets to authenticate to services. Kerberos tickets contain a user’s logon information in an encrypted form. Using tickets instead of passwords is already more secure, as it avoids the possibility of a password capture or credential-relaying attack. A ticket contains a user’s group membership and can be presented to services as a proof of identify. In the context of Kerberos, a service is something you can log into, like a file share or email. There are two kinds of Kerberos tickets: ticket granting tickets (TGTs) and service tickets (TGSs).

 

Logging into a service using Kerberos is a three-step process:

 

 

This process is entirely transparent to the end user. The user’s computer performs these actions on behalf of the user when they attempt to access a service. Lastly, a principal is just the Kerberos name for any Active Directory identity object. For this blog post, we really only care about user and computer objects as principals.

 

 

 

What is a Service Principal Name?

Briefly, a service principal name (SPN) is a unique identifier for services available to be accessed via Kerberos on a network. SPNs allow a service on a particular server to be associated with an account responsible for its management via Kerberos authentication. If a valid SPN does not exist, an account cannot use Kerberos to authenticate to that service, preventing the user from accessing resources hosted by the service. SPNs can be defined on user accounts when a service or application is running under that user’s security context. Typically, these types of user accounts are known as “service accounts.” When a computer hosts its own service, an SPN is set on the computer account. When a user requests a service ticket, the SPN for the requested service is included in the ticket. A lot of great articles already exist regarding SPNs. For more details about SPNs, read this blog post.

 

Using the following PowerShell script, we can see a list of all SPNs in the AD environment:

 

# From https://www.saotn.org/list-spns-used-active-directory/

$search = New-Object DirectoryServices.DirectorySearcher([ADSI] "")
$search.filter = "(servicePrincipalName=*)"

## You can use this to filter for OU's:
## $results = $search.Findall() | ?{ $_.path -like '*OU=whatever,DC=whatever,DC=whatever*' }
$results = $search.Findall()

foreach( $result in $results ) {

$userEntry = $result.GetDirectoryEntry()
Write-host "Object Name = " $userEntry.name -backgroundcolor "yellow" -foregroundcolor "black"
Write-host "DN = " $userEntry.distinguishedName
Write-host "Object Cat. = " $userEntry.objectCategory
Write-host "servicePrincipalNames"

$i=1
foreach( $SPN in $userEntry.servicePrincipalName ) {

Write-host "SPN ${i}: $SPN"
$i+=1

}
Write-host ""

}

 

Using the above script, we can see several SPNs per computer that reside in this test environment. While there are many SPNs, some of the more common ones are:

 

 

If you are interested other SPNs that could reside on a system, give this ADSecurity's article a read.

 

 

 

The last things we need to know about Kerberos to put this exploitation puzzle together are:

 

 

For attackers, this means a few important things. If an attacker has a Kerberos ticket, but does not know the password of the service, he/she can attempt to crack the plaintext password out of the ticket. This is Kerberoasting. It is important to note passwords for computer accounts and the krbtgt account are randomly generated and extremely long, which means all TGTs and service tickets for SPNs with computers cannot be cracked. This explains why Impacket’s Kerberoast tool, GetUserSPNs.py, only targets SPN’s configured with user accounts.

 

Next, attackers who have the NTLM hash for a computer account can create a forged service ticket. Forged service tickets are called silver tickets. It is important to remember that service tickets are only good for a specific host and service and cannot be used domain-wide. In order to access other domain-joined systems, an attacker must forge a silver ticket for each host they want to access.

 

Lastly, if an attacker has the NTLM hash for the krbtgt account, he/she can create a forged TGT. Forged TGTs are called golden tickets (we will discuss these below).

 

 

Silver Tickets: Bring your own ticket

By creating our own, we skip the steps in the standard Kerberos procedure of requesting a TGT and a service ticket. Instead, we authenticate directly to the service we want to access with our forged ticket. Silver ticket usage is rather hard to detect since an attacker does not need to interact with the domain controller.

 

 

 

So when would it make sense to make a silver ticket? Often when dumping a machine's local Security Account Manager (SAM) hashes, it is observed that a local administrator’s logon is denied.

 

 

 

You might be wondering, “Why would I want to create a silver ticket if I am already a local admin?” During testing it’s common to lose administrator privileges after a credential relaying session ends or if the admin user changes their password. Fortunately, we can use the computer account hash to generate a silver ticket, allowing us to impersonate any user for that specific computer. To reiterate, when given only a machine NTLM hash, it is possible to become an administrator (and gain code execution) on that machine. It is also possible to get a computer's NTLM without being an admin, such as finding a server backup in a share or reversing a captured NTLMv1 hash. For demonstration purposes, the below image outlines how one can dump a host’s local secrets using the pentesting tool, CrackMapExec.

 

 

 

We will use the Impacket's ticketer.py script to create our silver ticket. Before we do though, we need a list of the following items:

 

 

Once we have all of those, we can create our silver ticket. Below is a sample command, along with what the output should look like if everything went right.

 

 

 

 

Our silver ticket file located in Administrator.ccache is now saved on our machine and we can start using it with tools supporting Kerberos authentication, without being prompted for authentication. Using the following command, we can tell Impacket (among other tools) to use our Silver Ticket for Kerberos authentication.

 

 

 

 

Once we have that set up, we can use Impacket's wmiexec or smbexec scripts to gain a shell on WS01. Use the -k option to specify Kerberos authentication, and the --no-pass option because we are not authenticating with a password.

 

 

 

Lastly, the mistake most often made when dealing with Kerberos is defaulting to IP addresses. We are so accustomed to using IP addresses for NTLM, it is easy to forget that Kerberos requires hostnames for all authentication. The screenshot below shows what happens if you accidentally use an IP address instead of a hostname. Learn from my mistakes: do not use IP addresses when dealing with Kerberos!

 

 

 

During engagements, you may be limited to only Windows hosts, so next we will explain how to create a silver ticket on Windows. The popular post-exploitation tool for dumping passwords from LSASS, Mimikatz, also supports creating and importing Kerberos tickets into our current session. To do this, we need the following items:

 

 

Despite the name, kerberos::golden is the Mimikatz command used to create silver tickets. Below is a sample command to execute along with what the output should look like if everything went right.

 

 

 

 

We can access the CIFS service to easily verify our ticket works properly. After creating the ticket and using /ptt to pass-the-ticket into our current session, use misc::cmd to open another command prompt from Mimikatz. Next, use the dir command on the C$ or ADMIN$ shares on WS01 to confirm we are indeed the Administrator.

 

 

 

A second reminder that we still cannot use IP addresses to authenticate to hosts:

 

 

 

The SysInternals network admin tool PsExec can be used to gain a remote shell on WS01 with our silver ticket. Since PsExec requires connections to both MSRPC and SMB to gain execution, a second ticket for the HOST service will need to be created. Simply replace /service:cifs with /service:host. Using kerberos::list shows we have tickets for both CIFS and HOST services.

 

 

 

Now we can use PsExec to log into WS01 without needing to enter in administrator credentials.

 

 

 

Golden tickets

As we discussed earlier, a golden ticket is a forged TGT. This means we can use forged TGTs to request legitimate service tickets from Active Directory. An attacker who can create golden tickets can impersonate any user in the domain, including highly privileged users like domain admins. The authentication flow is different from silver tickets since the golden ticket must be submitted to the domain controller every time a new service is accessed. After a service ticket is granted, authentication takes place as normal.

 

 

 

To create a golden ticket, we need the krbtgt NTLM hash, which almost always means we need domain admin privileges. We can use Secretsdump or CrackMapExec to download the domain secrets from a domain controller.

 

 

 

We can use the ticketer.py script in Impacket again, to forge a Golden Ticket. For this, the following is required:

 

 

The user does not matter, at least initially, as the KDC service does not validate the user accounts in the TGT until the TGT is older than 20 minutes. For this example, I chose the non-existent user "Batman." Below is a sample command to generate a golden ticket:

 

 

 

 

Once the golden ticket is generated and we export the ccache file as before, we can log in to any system in the domain.

 

 

 

How long do these tickets last?

Tickets generated by Mimikatz or ticketer.py have the maximum ticket lifetime allowed by Kerberos of 10 years. Silver tickets will stop functioning when the computer account password cycles, which is by default every 30 days. The krbtgt account, however, has no such password rotation policy. Golden tickets created with a lifetime of 10 years will be valid for that period, unless the krbtgt account password is manually changed. It is for this reason that pentesters should limit the lifetime of their golden tickets to a few days or weeks. Impacket's ticketer.py allows specifying shorter lifetime values with the -duration flag. Likewise, ticket duration can be limited in Mimikatz with the /endin flag. Using Mimikatz, we can see the expiration dates on two different tickets.

 

 

 

 

 

We can verify that the ticket really expires when it says it does.

 

 

 

In addition, generated golden or silver tickets should be treated with the same sensitivity as passwords or NTLM password hashes. Like any other credential material, Kerberos tickets should be securely stored and securely deleted when they are no longer needed.

 

 

Golden ticket as privilege escalation

Golden tickets aren't just for fun, though. Thanks to another wonderful Microsoft feature, we can use a golden ticket to go from domain compromise to complete forest compromise. This means if we own one domain in a forest, we can compromise all other parent and child domains in that forest. Upon creation of a child domain in Active Directory, a two-way trust is created between the parent and child domains. This allows any object in the child domain to authenticate to resources in the parent domain. Additionally, since intra-domain trusts perform no SID filtering, we can forge a golden ticket that states we are part of the enterprise admins group. Yes, it actually is that simple. Mimikatz allows us to create a golden ticket with an extra SID for the enterprise admins group. To this we will need:

 

 

Below is a sample command to generate a golden ticket with extra SIDs:

 

 

 

 

After generating our golden ticket, we can DCSync any hash from the root-level domain controller.

 

 

 

This same privilege escalation technique can be performed as a one-shot using Impacket's raiseChild.py script.

 

 

 

 

Detecting forged Kerberos tickets

Silver and golden ticket generation and usage are unfortunately extremely difficult to differentiate from legitimate Kerberos activity. Detections can be built around subtle discrepancies, like the differences between how Active Directory and third-party tools create tickets, or through mismatches between SIDs and usernames. We can find examples of these discrepancies with Event Viewer to view login events on the DC.

 

 

 

 

 

The problem with these detections is that they rely on an attacker making mistakes or using tools with non-standard behavior. Knowing that legitimate login events use the NETBIOS domain name (e.g., BORGAR) instead of the fully qualified domain name (e.g., BORGAR.local), an attacker only needs to change their ticket to use the NETBIOS name to evade such a detection. Unfortunately, it is not as simple as changing the ticketer.py command from -domain borgar.local to -domain BORGAR, but we can break the detection above by hard-coding the domain into the "LogonDomainName" field.

 

 

 

After generating a new ticket and logging in, the login event using this golden ticket looks identical to a legitimate Kerberos login.

 

 

 

Protecting your environment

Unfortunately, since golden tickets are a post-domain compromise technique, there is not much the blue team can do to clean up after an attacker obtains a golden ticket. As shown above, a golden ticket gives attackers complete and total access to the entire forest, leaving defenders with no choice but to rebuild Active Directory from scratch. The good news is that silver and golden ticket attacks can be prevented by properly securing domain-joined computers and the domain itself. Using the principle of least privilege, setting strong passwords and applying updates on time will all go a long way toward keeping an Active Directory domain secure.

 

In summary:

 

 

References

Impacket (https://github.com/SecureAuthCorp/impacket)
Mimikatz (https://github.com/gentilkiwi/mimikatz)
CrackMapExec (https://github.com/byt3bl33d3r/CrackMapExec)