A Toast to Kerberoast
Derek Banks //
This post will walk through a technique to remotely run a Kerberoast attack over an established Meterpreter session to an Internet-based Ubuntu 16.04 C2 server and crack the ticket offline using Hashcat.
Recently I have had a lot of success with privilege escalation in an Active Directory domain environment using an attack called Kerberoasting. Tim Medin presented this technique at SANS Hackfest 2014 and since then there have been numerous awesome articles and conference talks on the details of the attack and tools written for different techniques to pull it off (reference links at the bottom of the post).
The Microsoft implementation of Kerberos can be a bit complicated, but the gist of the attack is that it takes advantage of legacy Active Directory support for older Windows clients and the type of encryption used and the key material used to encrypt and sign Kerberos tickets. Essentially, when a domain account is configured to run a service in the environment, such as MS SQL, a Service Principal Name (SPN) is used in the domain to associate the service with a login account. When a user wishes to use the specific resource they receive a Kerberos ticket signed with NTLM hash of the account that is running the service.
This is a bit of an oversimplification of the details of the process for sure, but the end result is that any valid domain user can request an SPN for a registered service (mostly I have seen SQL and IIS) and the Kerberos ticket received can be taken offline and cracked. This is significant because generally a service account is at the very least going to be an administrator on the server where it runs.
So how do we pull this off? Assuming that Metasploit is installed on the C2 server already, we need to get the Impacket project from Core Impact. This is a collection of Python classes for working with network protocols. If Metasploit is not installed, the PTF framework from TrustedSec makes it easy on Ubuntu 16.04.
#git clone https://github.com/CoreSecurity/impacket
Next, we need to install and configure proxychains. After install, the only configuration change is the desired port (for example, 8080).
#apt-get install proxychains
Now we need an established meterpeter session. There are many ways to go about this in a pen test and different methods can be situationally dependent so we will assume an established session is active.
Next, we set a route in Metasploit to cover the internal subnet that contains the IP address of a Domain Controller.
We now need a method to route externally to Metasploit tools through the meterpreter connection. For this, Metasploit has a module named socks4a that uses the built-in routing to relay connections. Set the SRVPORT option to the same port value used with configuring proxychains.
I am a generally a paranoid person, and since the socks proxy port is now an open socket that routes through to an internal network, I suggest using IP tables to limit connections to 8080 to the localhost. Some proponents of hacking naked may think this is overkill, but sometimes I think wearing around a firewall is appropriate – this is one of those times. The IP tables rules file I use is here.
Place the IP tables rules file in /etc/iptables.rules and run:
#/sbin/iptables-restore < /etc/iptables.rules
Now we are all set to use one of the Impacket example scripts and a valid and unprivileged domain account to gather Kerberos tickets advertised via SPN using proxychains over the meterpreter session.
#proxychains GetUserSPNs.py -request -dc-ip 192.168.2.160 lab.local/zuul
Any Kerberos tickets gathered by the GetUserSPNs script directly crackable with Hashcat without any additional conversion (the hash type was added in version 3.0). On my Windows desktop with a single Radeon R280, the password for the service account was cracked in three minutes using the Crackstation word list.
hashcat -m 13100 -a 0 sqladmin_kerberos.txt crackstation.txt
To take it one step further, the same method of proxying tools over meterpreter can be used to dump out domain account hashes from the domain controller using another example Impacket script named secretsdump.py once domain administrator rights have been obtained.
In this example in my lab, I had the SQL admin service account with a weak password also a member of the Domain Admins group. You may think this is a bit contrived, but it is not. In the last few months, especially in older Active Directory environments that have grown organically over the years, I have directly obtained a domain administrator account using Kerberoasting and cracking a Domain Admins group member password. I have subsequently elevated to domain administrator from further pivoting on numerous occasions.
#proxychains secretsdump.py -just-dc-ntlm LAB/[email protected]
The fix for this at the moment is to make sure that all service accounts in your environment have really long passwords. How long depends on what resources you think your potential attacker has access to for cracking passwords. My current suggestion (based on potential password cracking tool limitations) is 28 characters or longer with a 6-month rotation.
Thank you to everyone who has put a lot of time, research, and effort into attacking Kerberos. As always, I stand on the shoulders of giants. If I left any references out, it was not on purpose, please let us know if any other relevant links should be included:
https://adsecurity.org/?p=2293
https://www.sans.org/cyber-security-summit/archives/file/summit-archive-1493862736.pdf
https://room362.com/post/2016/kerberoast-pt1/
http://www.harmj0y.net/blog/powershell/kerberoasting-without-mimikatz
https://github.com/nidem/kerberoast
https://msdn.microsoft.com/en-us/library/ms677949(v=vs.85).aspx
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
