Stolen credentials for user and service accounts make it easy for attackers to quickly take over infrastructure and exfiltrate data without a secure service desk. Robust user phishing attack prevention paired with strong password practices is crucial to protecting an organization.
In this article, I demonstrate how a stolen user account can be used in a Kerberoasting attack. Kerberoasting is a method of retrieving service account password hashes, intended to be cracked and used in lateral attacks.
This post is kindly sponsored by Specops Software.
The Ins and Outs of Kerberoasting
Before diving into a practical attack, first, it’s helpful to understand how the Kerberoasting attack works. Active Directory (AD) utilizes the Kerberos protocol for mutual authentication of both the client and the server. To avoid repeatedly asking for a user or service account password, an authentication mechanism is implemented via service tickets.
When an initial authentication request is made, the Key Distribution Center (KDC) issues a Ticket Granting Ticket (TGT) to a successfully authenticated client. This TGT allows future authentication requests against the Ticket Granting Service (TGS) without prompting for an account’s password.
This is great for usability, but the resulting in-memory TGS ticket is encrypted with RC4_HMAC_MD5 and the NTLM hash. The resulting hash value is able to be brute-forced and cracked if the passwords are not complex enough. Furthermore, any authenticated domain account can request the TGS ticket of any service account with a service principal name (SPN), potentially allowing the less secure hash to be retrieved for subsequent cracking.
Anatomy of a Kerberoasting Attack
Now that you know more about how Active Directory Kerberos authentication works, how does one go about requesting a TGS ticket for a service account? Before I can retrieve the actual ticket, I need to know the SPN of the target account. An SPN is made up of the service, such as HTTP (typical for IIS), and the hostname with an optional port. An example might be HTTP/client.domain.local.
But wait, do all service accounts have an SPN? By default, an account will not have an SPN unless it has been assigned for a service, such as IIS. An SPN is required for service accounts that use Kerberos authentication.
In this example, a specific application pool in IIS is running under the account domain.local\IISAppPool01, with an SPN set via the command below.
setspn -S HTTP/WIN10CLIENT.domain.local domain.local\IISAppPool01
To discover all accounts, in Active Directory, with an SPN assigned I can use the following PowerShell code. This code quickly returns the domain accounts with a ServicePrincipalName value set using the ActiveDirectory module command, Get-ADUser.
Import-Module -Name 'ActiveDirectory'
Get-ADUser -Filter { ServicePrincipalName -Like "*" } -Properties ServicePrincipalName | Select-Object SamAccountName, ServicePrincipalName
The
krbtgtaccount is the TGS service account. If this account is compromised, this can lead to a Golden Ticket Attack where tickets can be granted for any AD account.
In this attack, I will be targeting the IISAppPool01 account. Often, service accounts have far too many privileges or they may be reused across applications. Despite the name, IISAppPool01, this may control multiple application pools and therefore have access to those resources.
With the target account in hand, I need to retrieve and export the hash in a format that the password cracking tool, Hashcat, is able to utilize. Mimikatz is also able to retrieve the hash, but does not output in the correct format natively. To avoid additional steps, the Invoke-Kerberoast function from the PowerShell post-exploitation toolkit Empire is used, as shown below.
.\Invoke-Kerberoast.ps1
Invoke-Kerberoast -OutputFormat hashcat | Select-Object SamAccountName, ServicePrincipalName
Invoke-Kerberoast -OutputFormat hashcat | ForEach-Object { $PSItem.Hash } | Out-File -Encoding ASCII hash.txt
This must be run in Windows PowerShell, PowerShell 7 will not be able to run this code. Behind the scenes, this runs the following code to request the ticket from TGS and only runs under Windows PowerShell, as shown in the below code.
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList 'HTTP/internaltools.site'
With the password hash saved in the right format, Hashcat can go to work cracking the password. Using the format of 13100, “Kerberos 5, etype 23, TGS-REP”, Hashcat makes quick work of the insecure password. This is especially so when paired with a large passphrase list (of over 20 million known password hashes), as shown below.
.\hashcat.exe -m 13100 -O ..\hash.txt passphrases.txt
Detecting and Preventing Kerberoasting Attacks
Once an attacker has made it into your network through a compromised account, you must be able to detect their probing and ultimately the attacks themselves. In the sections below are steps that you can take to prevent the password of a service account from being cracked, and most importantly, prevent a user account from being compromised in the first place.
Detecting Suspicious Activity
How do you know if Kerberoasting activity is happening on your network? One way is to turn on Kerberos service ticket request monitoring group policy setting, “Audit Kerberos Authentication Service”. This policy should be set on the Domain Controller under the Advanced Audit Policy Configuration section in a Group Policy Object (GPO).
Once enabled, the audit logs will fill with Kerberos service ticket requests. On a domain controller, this can be very noisy, necessitating filtering out unnecessary entries. Some common rules that may help cut down on how much noise is in the logs are below.
- Filter out Audit Failure requests and look only for Audit Success.
- A user account is more likely to be compromised so filter out known service accounts.
- Computer accounts and gMSA (Group Managed Service Accounts) use accounts prefixed with
$, which most likely will not be compromised, so those accounts may be filtered out.
You are looking for suspicious accounts requesting tickets, and for excessive 4769 Event IDs in the audit logs.
You may still see false positives, but you can start to investigate where the malicious activity might be originating from. With Windows PowerShell logging enabled on client and server systems, you can look for potentially malicious commands.
Don’t forget that you will need to enable PowerShell 7 logging as well. This can be done via the command cd "C:\Program Files\PowerShell\7"; .\InstallPSCorePolicyDefinitions.ps1. The relevant Group Policies are in Computer Administrative Templates under the PowerShell Core section. For Windows PowerShell, the relevant Group Policy settings are in the Application Settings\Windows PowerShell section.
Once auditing is enabled, a common script block attack pattern may be ServicePrincipalName -Like "*", which is used with the Get-ADUser command to find all service accounts containing SPNs. Another indicator in PowerShell is the usage of the KerberosRequestorSecurityToken method, used to request Kerberos tickets for in-memory storage that can be later cracked.
Preventing Kerberoasting and Stolen Credentials
Even if a user account is compromised, active scanning for service account SPNs occurs, with the ultimate retrieval of a password hash does that mean all is lost? There are a number of steps to take that will prevent the actual service account from being taken over, not just having a secure service desk.
Unfortunately, service accounts are often forgotten about, with reused passwords and wider privileges than they should have. Therefore it’s no surprise that the following will go a long way to limiting attack exposure and effectiveness.
- Provision service accounts with long passwords, 25 characters or longer ensure that it will be near impossible to crack by brute force alone.
- Utilize random complex passwords with a variety of special characters to avoid dictionary attacks with the usage of common words.
- Rotate service account passwords frequently. There should be a policy to change the service account passwords at a regular interval. gMSA accounts change their password every 30 days, which would be ideal, but not all service accounts are able to be changed regularly without outages. Nonetheless, a plan to rotate all accounts should be taken into account.
- Limit the permissions of a service account to the bare minimum of what is necessary. For example, instead of administrator rights on a system, perhaps a service account just needs access to a specific directory.
- Avoid using service accounts for multiple services. Not only does this prevent scope and access creep, but also prevents an increased attack surface.
The above may cover the protection of service accounts in the event that the password hashes are retrieved, but what about preventing an account takeover in the first place? To avoid that, it’s first crucial to avoid accounts being stolen through phishing or social engineering.
It’s hard for any user to sometimes know what is a legitimate request for a password reset, or if an email is valid. Training users to look for the common signs of a phishing email, implementing controls and spam management in email systems, and teaching users about social engineering attacks are all critical steps to preventing account takeovers in the first place. Learn more about how a secure service desk can benefit you.
Avoid Compromised Accounts with Specops Secure Service Desk
One of the fastest ways to take over an account is via a fraudulent password reset. How do you avoid having an attacker making a false or malicious request for a password reset?
There are many ways that an organization can use to verify who a user is. Building these multi-factor authentication mechanisms into the helpdesk makes sure that the individual contacting is who they say they are.
Specops Secure Service Desk is a great way to empower your helpdesk to quickly and securely verify the contacting individual. You may set up policies that require a caller to verify who they are via a wide variety of methods. A non-exhaustive list of methods is below, but highlight some of the more unique offerings!
- Specops Fingerprint
- Secret Questions
- Trusted Network Locations
- Manager Identification
- Duo Security
- Okta
As shown below, the interface is easy for any employee to use. In one spot, you can verify the user with multiple methods, look up user details, and ultimately perform common actions to quickly get the user on their way.
All of the verification methods are well-complemented by in-depth reporting capabilities. For example, find out who has not been enrolled, the number of password resets and by whom, and if those password resets were done for verified users.
Conclusion
As I have demonstrated, Kerberoasting is still a valid attack and one that should be accounted for via auditing and monitoring. A single compromised non-administrator user account is all that’s needed for an attacker to start picking apart your infrastructure.
There are a lot of ways you can mitigate potential issues, from using long, complex, and frequently rotated service account passwords, to in-depth logging and reporting on potential attacker activity. But avoiding a compromised user account in the first place is the best way to avoid the issue altogether, and Specops Secure Service Desk goes a long way to making that a reality.
With a large number of authentication methods that may be layered together, a helpdesk worker is empowered to securely verify that a caller is who they say they are, and quickly get them the help they need. Take the next steps today to make sure that your infrastructure and processes are secure!
