Hack The Box - Active
Published December 8, 2018Box Info
Box profile: Active
OS: Windows
Maker: eks & mrb3n
Release date: July 28, 2018
Retire date: December 8, 2018
Own date: September 8, 2018
Foreword
These writeups should be taken as insight into the processes and techniques involved rather than a walkthrough to completing the boxes in question. You should never execute code without first understanding what it does, and always do outside research in order to figure out why you're taking the steps you are. This is for your safety, and also ensures that you have an understanding of the fundamentals involved with the ability to reproduce things in new and different scenarios. As such, while these guides outline fairly precise steps to take, some of the more basic information may be omitted for brevity.
If you do not understand what is going on, read the manual until you do.
Introduction
Active was a box that felt like a very real-world target. It was the first Windows box that I had ever penetrated, but in hindsight it was very straightforward without any tricks or gimmicks. I can look back to it as a box that really gave me the experience and tools needed to take on other Windows boxes that come my way in the future, and didn't blind me with any cheap throwaway techniques.
Initial Enumeration
From our first Nmap scan we can see that the server is hosting DNS, SMB, LDAP, and Kerberos. There are some others available, but these are the most interesting to us.
att$ nmap -A -p- -T4 10.10.10.100
PORT STATE SERVICE VERSION
53/tcp open domain Microsoft DNS 6.1.7601 (1DB15D39) (Windows Server 2008 R2 SP1)
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2018-11-15 06:13:32Z)
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: active.htb, Site: Default-First-Site-Name)
445/tcp open microsoft-ds?
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: active.htb, Site: Default-First-Site-Name)
Sometimes we'll find that the SMB or LDAP services will allow users to log in anonymously, potentially resulting in an info leak or even system compromise right off the bat. Let's start with SMB; Nmap doesn't report it as such, but we know that SMB is hosted on port 445. Upon connection, we can see that we've successfully obtained a listing of the SMB shares!
att$ smbclient --list=10.10.10.100 --no-pass
Anonymous login successful
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
Replication Disk
SYSVOL Disk Logon server share
Users Disk
Information Disclosure
Checking through each of the shares at a time, some of them are accessible to us and some of them are not. Of the currently-accessible shares, the only one that seems to allow file listing is Replication so we might be able to find sensitive information that will prove useful. And sure enough, after exploring around in it for a little while, we do in fact come across a Group Policy Preferences (GPP) file containing a username and an encrypted password.
att$ smbclient //10.10.10.100/Replication --no-pass
smb> cd active.htb\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Preferences\Groups\
smb> get Groups.xml
This encrypted password, for better or worse, is built using the same key that all GPP passwords are built with. This key has released publicly by Microsoft, so it's become trivial to decrypt it. To make things even easier than that, Kali includes a simple tool that we can use to decrypt it from the command line.
att$ gpp-decrypt "<cpassword>"
Kerberoasting
Now that we have access to an account on the target's SMB, let's see if we can use a technique called Kerberoasting to obtain the password to the Administrator account.
For background, Kerberos is an authentication protocol that uses secret keys to verify connections. Basically, you authenticate to a Key Distribution Center (KDC) and get a Ticket Granting Ticket (TGT). This TGT is then used as proof of identity to request service tickets for specific services on the domain. Part of this service ticket is encrypted using the NTLM hash of the domain user's password. On Windows, this account is determined by the user's Service Principal Name (SPN). Any user can request a service ticket from the Ticket Granting Server (TGS) for any user at all as long as the target user has an SPN registered, since it doesn't necessarily grant them access.
The takeaway here is that the service ticket is encrypted with the user's NTLM hash. With the ticket in our posession, we can generate NTLM hashes and attempt to decrypt it offline. Once it's successfully decrypted, we know what the password is!
Since we're currently accessing this server remotely, we'll use SecureAuth's Impacket library, which comes with a set of example tools, one of which we can use to retrieve the service ticket using the account that we've thus far gained access to.
att$ git clone --depth=1 https://github.com/SecureAuthCorp/impacket.git
att$ cd impacket
att$ pip install .
att$ cd examples
att$ python GetUserSPNs.py -request -request-user Administrator -outputfile ~/active_admin_ticket.txt -dc-ip 10.10.10.100 active.htb/SVC_TGS
We should now have a the ticket waiting for us, so the only thing left to do is to send it to Hashcat. Since we're dealing with Kerberos 5 TGS-REP, our hash type will be 13100. After just a couple minutes, we should have the plaintext password back and we'll be able to log in and do as we please!
att$ hashcat -m 13100 -o ~/active_admin_plain.txt --outfile-format 2 ~/active_admin_ticket.txt ~/rockyou.txt
Extra Thoughts
For more information on Kerberoasting, please check out the blog post Kerberoasting Without Mimikatz by harmj0y. The post explains it much better than I can, and I referenced it heavily while I was learning to understand the protocol better.
For more information in general about Kerberos itself, Explain like I'm 5: Kerberos offers a great explanation without getting too technical to understand.
And for even more information on Kerberoasting, check out Cracking Kerberos TGS Tickets Using Kerberoast. Harmj0y's post did a great job explaining, but this one really sent it home for me.
Lastly, if you're interested in learning how to retrieve a desired user's SPN manually, you can read through the GetUserSPNs PowerShell script located here. Even though it was unecessary in the end, I tried it during my research and found it very interesting. The rest of the scripts in that repo make for similarly interesting insights into the inner workings of it all.
Conclusion
We used an anonymous SMB session to gain access to a Group Policy Preferences (GPP) file that was mistakenly added to a replication share. This GPP file contained the username and AES-encrypted password of an SMB user, which we decrypted using Microsoft's publicly-published AES key. From there, we obtained the TGS ticket of the Administrator account from the Kerberos service by asking nicely for it, and used that ticket offline in Hashcat to crack the password that was used to encrypt it.
As this was the first Windows box that I had penetrated, it was quite an intimidating experience that I was honestly in the dark about during the majority of. With that being said, it taught me a lot about the services surrounding Windows' Active Directory and gave me a lot of experience that I can use moving forward.
References
Explain like I’m 5: Kerberos
Cracking Kerberos TGS Tickets Using Kerberoast
Kerberoasting Without Mimikatz