Ethical Hacking Lessons — Active Writeup

Kamran Bilgrami
7 min readDec 15, 2019

--

This write-up is for the hackthebox Active machine. According to some estimates, 95% of the Fortune 1000 companies use Active Directory. Given these types of stats, its no surprise that hackers always have a deep interest in exploiting any vulnerabilities around Domain Controllers. Kerberos is considered the heart of Active Directory (AD) as the authentication mechanism between AD and any computers joining its domain. This post describes an AD specific technique called Kerberoasting that malicious users can use to attack the AD infrastructure.

An easy rated Windows machine with an IP address of 10.10.10.100. The radar-graph is showing a strong inclination towards Real-life metrics. These type of boxes are my personal favorites as it seems to give more exposure to real-life scenarios.

Recon

Let’s start active recon with the Nmap TCP scan.

nmap -A -T4 -p- -oX tcp_scan_results.xml 10.10.10.100

Below are the results produced by the scan.

Quite a few important findings by NMap. The Kerberos service on port 88, the LDAP on port 389 & 3268 is a strong indicator this could be a Windows Domain Controller machine. In addition, port 139 and 445 running SMB is also an interesting find. DNS service running on port 53 is noteworthy too. Quite a few other ports open that can come into picture if we don’t find anything useful from the most notable ones I described here.

I also performed a UDP scan but it did not complete.

Recon Results Analysis

Quite a few important findings by NMap including SMB, Kerberos and DNS services.

Enumeration

Let’s start by enumerating the SMB service on the box. I used smbmap with -H switch (for providing Host IP address) to list all the shares available and the permissions to those shares.

This shows that we have Read-Only permission against the Replication share. Let’s try to browse to that folder using smbclient utility.

The result of running the smbclient utility shows that with the Anonymous login, we can access the Replication share. This share contains acive.htb directory. Browsing in that folder shows more sub-directories. Rather than just browsing through these folders to discover the contents, we can use the smbmap tool again to list down all the contents recursively by using its -R switch. That gave us a long list of files and folders.

One interesting file from these results is Groups.xml which is linked to the famous GPP Vulnerability. GPP was introduced with Windows Server 2008 and provides the ability to configure Domain-attached machines via the group policy. However, it also exposes a vulnerability that allows setting the passwords for the Local Administrator account. These passwords used to get stored in Groups.xml file deep inside the SYSVOL folder. Even though the passwords stored in this file were encrypted but the encryption method was using AES with a 32-bit key that was static and publically available. Microsoft later issued a security bulletin MS14–025 but if any system that does not have the vulnerability patched can still be subject to GPP Vulnerability.

Enumeration Analysis

We found that the GPP Vulnerability is a possibility. Its time to try to exploit that vulnerability.

Exploitation

Keeping all this background information in mind, let’s get this file and inspect its contents. In order to download this file, I go back to using smbmap utility again but this time with -A and -q switches. -A switch lets us specify the file to download whereas -q switch does this in a quite, non-verbose mode.

Once we have this file downloaded, inspecting its contents shows that it contains the encrypted password for a domain user SCG_TGS.

Kali Linux comes with a tool called gpp-decrypt that could be used to decrypt a GPP encrypted password. Using gpp-decrypt tool against the password in Groups.xml file gave us the password GPPstillStandingStrong2k18 as shown below.

Now that we have a username and password, we can try to connect to smb shares using these credentials. I again used smbmap utility using -d switch for specifying the domain, -u switch for the username and -p switch for the password. We were able to connect with a new list of shares and permissions for this user.

The Users share could be interesting, so let’s try to recursively search through this folder.

As you can see from the results, it looks like we may have found the user flag file user.txt located at \\SVC_TGS\Desktop. Let’s download this file.

TaDa, we have the user flag :)

Privilege Escalation

Since we have established that its an Active Directory Domain Controller box. There is an interesting article called Top Five Ways I Got Domain Admin on Your Internal Network before lunch. I am going to use item #4 from that list called Kerberoasting. The article describe this technique as follows.

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, the 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.

In summary, a Kerberoasting attack allows a valid domain user account to request a Kerberos service ticket for any service. This ticket can then be used to crack the password offline by brute-forcing it. This attack has a greater chance of success if the account is using a weak password.

In order to perform this attack, we can use the Impacket which is a collection of python classes that works with network protocols. You can setup Impacket from its Github repo. Impacket contains a GetUserSPN.py script that could be used to find the SPN associated with a normal user account. My first attempt using this script failed with KRB_AP_ERR_SKEW error.

Googling suggested that this error could be caused due to the fact that NTP service may not be sync with the DC box. This requires us to use ntpdate against the active box IP of 10.10.10.100. After doing this, I ran the script again and we did get the required results this time.

I stored the ticket in a local file called hash.txt and then used John the Ripper to try to bruteforce against a local word list. The result was we were able to crack the password: Ticketmasater1968

I then used another Impacket script called psexec.py to try to connect to Active box with the Administrator user and newly cracked password. That gave us a root shell.

It was quite trivial to locate the root flag.

yayyyyyy. The box solved.

Root Cause Analysis

  • The system not patched against a known vulnerability
  • Anonymous login allowed to the SMB Share

--

--

No responses yet