Service Account Attack #2: Extracting Service Account Passwords
In our first post, we explored how an attacker can perform reconnaissance to discover service accounts within an Active Directory (AD) domain. Now that we know how to find service accounts, let’s look at how an attacker can compromise those accounts and use them to exploit their privileges. In this post, we will explore one such method for doing that: Kerberoasting. This method is especially scary because it requires no elevated privileges within the domain, is very easy to perform once you know how, and is virtually undetectable.
Kerberoasting takes advantage of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs). If you remember, in the reconnaissance post we focused on discovering service accounts by scanning for user objects’ SPN values. Kerberoasting allows us to crack passwords for those accounts. By logging into an Active Directory domain as any authenticated user, we are able to request service tickets (TGS) for service accounts by specifying their SPN value. Active Directory will return an encrypted ticket, which is encrypted using the NTLM hash of the account that is associated with that SPN. You can then brute force these service tickets until successfully cracked, with no risk of detection or account lockouts. Once cracked, you have the service account password in plain text.
Even if you don’t fully understand the inner-workings of Kerberos, the attack can be summarized as:
Scan Active Directory for user accounts with SPN values set.
Request service tickets from AD using SPN values
Extract service tickets to memory and save to a file
Brute force attack those passwords offline until cracked
With those steps in mind, you can imagine how easy it may be to get access to a domain and begin cracking all service accounts within minutes. From there, it’s just a waiting game until you have compromised one or more service accounts.
Step 1 – Obtain a list of SPN values for user accounts
We focus on user accounts because they have shorter, less secure passwords. Computer accounts have long, complex, random passwords that change frequently. There are many ways to get this information, including:
Step 2 – Request Service Tickets for service account SPNs
To do this, you need to simply execute a couple lines of PowerShell and a service ticket will be returned and stored in memory to your system.
These tickets are encrypted with the password of the service account associated with the SPN. We are almost ready to start cracking them.
Step 3 – Extract Service Tickets Using Mimikatz
Mimikatz allows you to extract local tickets and save them to disk. We need to do this so we can pass them into our password cracking script. To do this, you must install Mimikatz and issue a single command.
Step 4 – Crack the Tickets
Now that you have the tickets saved to disk, you can begin cracking the passwords. Cracking service accounts is a particularly successful approach because their passwords very rarely change. Also, cracking the tickets offline will not cause any domain traffic or account lockouts, so it is undetectable.
The Kerberoasting toolkit provides a useful Python script to do this. It can take some configuration to make sure you have the required environment to run the script; there is a useful blog here, which covers those details for you.
The script will run a dictionary of passwords as NTLM hashes against the service tickets you have extracted until it can successfully open the ticket. Once the ticket can be opened, you have cracked the service account and are provided with its clear-text password!
Protecting Yourself from Kerberoasting Attacks
The best mitigation for this attack is to ensure your service accounts that use Kerberos with SPN values leverage long and complex passwords. If possible, rotate those passwords regularly. Using group managed service accounts will enforce random, complex passwords that can be automatically rotated and managed centrally within AD.
To detect the attack in progress, monitor for abnormal account usage. Service accounts traditionally should be used from the same systems in the same ways, so it is possible to detect authentication anomalies. Also, you can monitor for service ticket requests in Active Directory to look for spikes in those requests.
Here are the other blogs in the series:
Service Account Attack #1 – Discovering Service Accounts without using Privileges Read Now
Service Account Attack #3 – Targeted Service Account Exploitation with Silver Tickets Read Now
Service Account Attack #4 – Exploiting the KRBTGT service account for Golden Tickets Read Now
To watch the Service Account Attacks webinar, please click here.
Learn how StealthDEFEND helps protect against AD attacks here.
Don’t miss a post! Subscribe to The Insider Threat Security Blog here:
You say in this post “we will explore one such method for doing that: Kerberoasting. This method is especially scary because it requires no elevated privileges within the domain”
Then later you say that you need to “install and run Mimikatz” on the local machine attached to the AD domain. How does one do the latter without ‘local admin’ privileges?
This command does not require admin privileges to run. Many Mimikatz commands require debug rights using the privilege::debug command, but the Kerberos::list command is not one of them. So as a regular user of a PC you can run both the PowerShell to get the ticket through the SPN request and then export it from that box.
Hi Jeff, in the first post you shared how to enumerate service accounts that do not have SPNs associated with them. However in this article you only cover how to request tickets using the KerberosRequestorSecurityToken class to request tickets using SPNs. How do I get tickets for service accounts without any SPNs? Furthermore how do I then convert those tickets into a format hashcat can use (as opposed to using tim medins python script)?
Guys, check the Invoke-Kerberoast.ps1 powershell script. It can automatically
enumerate all service principal names in the domain, request service tickets for
them, and export them in a format ready for cracking in both John the Ripper and
Hashcat, completely eliminating the need for Mimikatz