A Single Partner for Everything You Need Optiv works with more than 450 world-class security technology partners. By putting you at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can.
We Are Optiv Greatness is every team working toward a common goal. Winning in spite of cyber threats and overcoming challenges in spite of them. It’s building for a future that only you can create or simply coming home in time for dinner. However you define greatness, Optiv is in your corner. We manage cyber risk so you can secure your full potential.
Breadcrumb Home Insights Source Zero Kerberos - A Domains Achille's Heel June 02, 2021 Kerberos - A Domain's Achilles' Heel 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: A user provides their NTLM password to get a TGT from the DC. Then they use their TGT to get a Service Ticket from the DC. After that, they use the Service Ticket to authenticate to the desired service. 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. Image Figure 1: A step by step diagram of authenticating to a service using Kerberos 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: WSMAN - Service name Windows Remoting (WinRM) and Powershell Remoting services. TERMSRV - Service name for Microsoft Remote Desktop server (Terminal Server) services. HOST - A catch-all service name for many services, including RPC, DCOM and WMI. If you are interested other SPNs that could reside on a system, give this ADSecurity's article a read. Image Figure 2: Viewing SPN's on two hosts in my AD lab environment The last things we need to know about Kerberos to put this exploitation puzzle together are: Kerberos tickets are encrypted using the NTLM hash of the service principal. TGT's (Ticket Granting Ticket) are encrypted with the special krbtgt hash. Service Tickets are encrypted with the hash of the associated principal. For example, a Service Ticket for the TERMSRV/WS01 SPN would be encrypted with the NTLM password hash of the WS01$ computer account. 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. Image Figure 3: Authentication flow for using a silver ticket (forged Service Ticket) to access a resource 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. Image Figure 4: Access DENIED: Failing to log in with a local account after dumping SAM hashes 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. Image Figure 5: Grabbing the WS01$ computer account's NTLM hash from LSA 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: SPN for the service we want to access Domain name Computer NTLM hash Domain Controller IP address Domain SID Domain User account to impersonate 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. python3 ticketer.py -spn HOST/WS01.borgar.local -domain borgar.local -nthash 3c0ca92a8fa19374d19bf887543a5e19 -dc-ip 192.168.1.20 -domain-sid S-1-5-21-3010306422-4235424541-3945354764 Administrator Image Figure 6: Creating our Silver Ticket with ticketer.py 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. export KRB5CCNAME=Administrator.ccache Image Figure 7: Viewing and exporting our newly created ccache Silver Ticket file 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. Image Figure 8: Using the silver ticket to authenticate as Borgar.local/Administrator to WS01 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! Image Figure 9: Using an IP address instead of a hostname? Access DENIED! 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: Domain name Domain SID Computer NTLM hash User to impersonate User ID User group IDs Kerberos Principal (target computer hostname) Kerberos Service 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. kerberos::golden /domain:borgar.local /sid:S-1-5-21-3010306422-4235424541-3945354764 /rc4:3c0ca92a8fa19374d19bf887543a5e19 /user:"Administrator" /id:500 /groups:500,501,513,512,520,518,519 /target:WS01.borgar.local /service:cifs /ptt Image Figure 10: Creating a Silver Ticket for CIFS using the kerberos::golden Mimikatz command 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. Image Figure 11: Confirming we can view the C$ share on WS01 A second reminder that we still cannot use IP addresses to authenticate to hosts: Image Figure 12: Getting access denied when using an IP address instead of the WS01 hostname 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. Image Figure 13: Viewing CIFS and HOST Kerberos tickets with kerberos::list Now we can use PsExec to log into WS01 without needing to enter in administrator credentials. Image Figure 14: Using PsExec to log into WS01 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. Image Figure 15: Authentication flow for a Golden Ticket: Submit forged TGT to DC and request service tickets 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. Image Figure 16: Using CrackMapExec to get the krbtgt hash We can use the ticketer.py script in Impacket again, to forge a Golden Ticket. For this, the following is required: Domain name NTLM hash for the krbtgt account Domain Controller IP address Domain SID Domain User account to impersonate 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: ticketer.py -domain borgar.local -nthash 47d91aca4b29907d30251a0bfe9b189c -dc-ip 192.168.1.20 -domain-sid S-1-5-21- 3010306422-4235424541-3945354764 Batman Image Figure 17: Generating a golden ticket with Ticketer.py Once the golden ticket is generated and we export the ccache file as before, we can log in to any system in the domain. Image Figure 18: Using the golden ticket and logging into WS01 as Batman! 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. Image Figure 19: Viewing a golden ticket created with the default ticket lifetime of 10 years Image Figure 20: Viewing another golden ticket created with a lifetime of 1 day We can verify that the ticket really expires when it says it does. Image Figure 22: Using the same golden ticket after its expiration date and failing to log in 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: Child domain name Child domain SID Child domain krbtgt NTLM hash User to use (can be anything) User ID to use (can also be anything) Parent domain Enterprise Admins SID (Parent domain SID plus -519) Below is a sample command to generate a golden ticket with extra SIDs: kerberos::golden /domain:child.borgar.local /sid:S-1-5-21-3676245630-1584519168-1098963459 /krbtgt:cf28a3d01502d7912dedc4500d5ac990 /user:batman /id:500 /ptt /sids:S-1-5-21-3010306422-4235424541-3945354764-519 Image Figure 23: Using Mimikatz to generate a golden ticket with the extra SID for enterprise admin After generating our golden ticket, we can DCSync any hash from the root-level domain controller. Image Figure 24: Using DCSync to download the krbtgt NTLM hash for the parent domain This same privilege escalation technique can be performed as a one-shot using Impacket's raiseChild.py script. Image Figure 25: Fully automated pentesting with raiseChild.py 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. Image Figure 26: A login event from a golden ticket with mismatched SID and username Image Figure 27: A golden ticket login event (left) next to a legitimate Kerberos login event (right). 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. Image Figure 28: Hardcoding the ticket's Account Domain into ticketer.py After generating a new ticket and logging in, the login event using this golden ticket looks identical to a legitimate Kerberos login. Image Figure 29: A login from a forged ticket after ticketer.py modification 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: Silver Ticket: Gain code execution on any domain-joined host that we have the computer account's NTLM hash Golden Ticket: Own an entire forest from just one compromised domain Detection: Weak detections for forged tickets can be built by looking for abnormal or inconsistent login events References Impacket (https://github.com/SecureAuthCorp/impacket) Mimikatz (https://github.com/gentilkiwi/mimikatz) CrackMapExec (https://github.com/byt3bl33d3r/CrackMapExec) By: Kevin Clark Security Consultant | Optiv Kevin Clark has more than five years’ experience in computing and the Information Technology industry. He’s a life-long learner in all things hacking and penetration testing, and his areas of expertise include external/internal penetration testing, phishing and malware development. Share: Source Zero® Red Team Penetration Testing Copyright © 2024 Optiv Security Inc. All rights reserved. No license, express or implied, to any intellectual property or other content is granted or intended hereby. This blog is provided to you for information purposes only. While the information contained in this site has been obtained from sources believed to be reliable, Optiv disclaims all warranties as to the accuracy, completeness or adequacy of such information. Links to third party sites are provided for your convenience and do not constitute an endorsement by Optiv. These sites may not have the same privacy, security or accessibility standards. Complaints / questions should be directed to Legal@optiv.com
Copyright © 2024 Optiv Security Inc. All rights reserved. No license, express or implied, to any intellectual property or other content is granted or intended hereby. This blog is provided to you for information purposes only. While the information contained in this site has been obtained from sources believed to be reliable, Optiv disclaims all warranties as to the accuracy, completeness or adequacy of such information. Links to third party sites are provided for your convenience and do not constitute an endorsement by Optiv. These sites may not have the same privacy, security or accessibility standards. Complaints / questions should be directed to Legal@optiv.com