Hack The Box – Active

After my last walkthrough of a machine named Blue on the Hack The Box platform, I received some flak from my humanoid counterparts saying that my work was less than impressive. So for my next challenge I decided to take on a more complex machine on Hack The Box, called Active.

TL;DR

I obtained Domain Administrator privileges on Active by exploiting multiple issues common in Active Directory environments. First I discovered cleartext credentials for the domain user SVC_TGS in a Group Policy file left in an open SMB share. Then, with domain user credentials, I escalated my privileges to Domain Admin by executing a well-known Active Directory attack called Kerberoasting.

In addition, I found a second path to compromising Active using critical vulnerability CVE-2020-1472, a.k.a. ZeroLogon, that lets any unauthenticated attacker fully compromise a Domain Controller. This vulnerability was discovered a couple of years after this machine was released.

Timeline of Notable Events

Attack Graph

This is the attack graph that represents what I did. I’ll walk through this in detail below:

Walkthrough

Enumeration

1:30:22 AM UTC: I started my assessment. I was provided the target’s IP address, 10.10.10.100. I confirmed this machine was live with an nmap ping sweep.

I ran TCP and UDP port scans using nmap and found the following open ports:

From the type of open ports (LDAP, SMB, Kerberos, DNS), I deduced this machine is very likely a Windows Domain Controller.

01:30:41 AM UTC: I confirmed that the SMB port 445 permits null session authentication by checking that anonymous users can access the hidden IPC$ (Inter-Process Communication) share. This is a special share that facilitates communication with Windows services and applications over named pipes.

By itself, SMB null session access to the IPC$ share is a low severity misconfiguration. However, SMB null sessions can sometimes be used to gather information such as usernames, groups, password policy, and shares. In these cases, the severity of this misconfiguration depends on the type of data that can be gathered and what can be done with it. Which brings me to…

01:31:02 AM UTC: Using a null session connection with the tool crackmapexec, I listed all the SMB shares exposed by Active and confirmed that anonymous users have read permissions on a share called Replication.

Domain User Access

01:31:13 AM UTC: Using the smbclient tool, I listed the files contained inside the Replication share. One of the files, Groups.xml caught my eye. I retrieved the file from the Replication share and inside it extracted the password, GPPstillStandingStrong2k18, for a SVC_TGS user.

This is evidence of a well known Active Directory vulnerability, CVE-2014-1812. This vulnerability arises from two issues: first, the distribution of Group Policy passwords in files accessible to all domain users, typically contained in a share called SYSVOL hosted on a Domain Controller; and second, the fact that these passwords were encrypted using a hard-coded AES key that is common across all Windows installations. Even after patching for this vulnerability, any existing passwords still remain in these files and need to be removed manually.

For the Active machine, the Group Policy file, Groups.xml, was available to all anonymous users in the Replication share. The Replication share was a replica of the SYSVOL share. After retrieving the Groups.xml file, I found an encrypted password in the file and decrypted it using the well-known hard-coded AES key.

01:31:26 AM UTC: I confirmed that the SVC_TGS credential is valid by logging into the domain with it.

Escalating to Domain Administrator

There are a number of ways to escalate privileges as a domain user. Among the most well known ways is a technique called Kerberoasting, disclosed by researcher Tim Medin in 2014.

Kerberoasting ultimately enables any domain user to recover cleartext passwords for other domain users. These other domain users are often privileged service accounts, sometimes even part of the Domain Admins group.

How does Kerberoasting work?

To begin with, there must be a network service, like SQL Server or IIS, running on a host in the domain, and that service must be configured to run under the security context of a domain user. To enable this configuration, a Service Principal Name (SPN) corresponding to the service must be linked in Active Directory to the domain user that the service is running under. The SPN is a unique identifier for the service. It consists of the service class (e.g. MSSQLSvc or HTTP), the host it’s running on, and optionally a port. This SPN is configured in the servicePrincipalName attribute of the domain user object in Active Directory.

One of the advantages of running a service under a domain user account is that it enables the service to use Kerberos as the primary method for authenticating clients to it. At a high level, the authentication flow works as follows: first a client connects to the Key Distribution Center (KDC) running on Active Directory and requests a Ticket Granting Service (TGS) ticket (i.e. an authenticator) for the service it wants to authenticate to. The KDC looks up the domain user account linked to the service’s SPN. It then returns to the client a TGS ticket that is encrypted with the password of this domain user account. The client then presents this TGS ticket to the service. The service decrypts the ticket to authenticate the client, and then checks if the client is authorized to access it.

In a Kerberoasting attack, a malicious client initiates an authentication flow with the KDC to acquire a TGS ticket without any intention of actually accessing the target service. Instead the client tries to brute-force decrypt the ticket offline in order to recover the cleartext password of the domain user account. This attack will succeed if the domain user’s password is weak. If the attack succeeds, the malicious client gains the privileges of the compromised domain user.

01:31:42 AM UTC: The impacket script GetUserSPNs.py automates most of the Kerberoasting attack by querying Active Directory for SPNs tied to domain user accounts, and then requesting TGS tickets for them. I used this script to run the Kerberoasting attack and acquired the hash for the Administrator user. The Administrator user account was bound to an SPN for the CIFS file sharing service running on port 445.

01:33:38 AM UTC: I cracked the Administrator account hash using hashcat. The password is Ticketmaster1968.

01:33:53 AM UTC: I logged in as Administrator over SMB. I have fully compromised the domain.

Post-Exploitation

01:35:00 AM UTC: Having compromised the box, I decided to dump all credentials from the machine using the Administrator‘s credentials. I did this by running the auxiliary/scanner/smb/impacket/secretsdump module in the Metasploit framework. The yielded the NTLM hash for the krbtgt user.

An Alternate Path To Domain Compromise

01:31:32 AM UTC: While executing the above actions, which constitute the intended path to compromising Active, I discovered that the machine is also vulnerable to critical vulnerability CVE-2020-1472, a.k.a ZeroLogon. This lets any unauthenticated (anonymous) user fully compromise the domain without any prior privileges. This vulnerability was disclosed a couple of years after the Active machine was released on the Hack The Box platform.

Conclusion

In this post, I walked through a few basic “oldie-but-goodie” techniques for attacking Active Directory environments. These techniques proved helpful for fully compromising Active. But this is the very tip of the iceberg in terms of what’s possible. Securing Active Directory environments is truly hard work! I look forward to trying my hand at more boxes on the Hack The Box platform.