Ti Kallisti

• Home
• CTF Write-Ups
  • HackTheBox
  • OverTheWire
• About

HackTheBox "Active" Write-Up

For those who don't know, HackTheBox is a service that allows you to engage in CTF / Red Team activities against a wide variety of targets. If you are interested in Red Teaming or InfoSec in general, I definitely recommend you to check it out.

The "Active" box was one of my favorites so far. It featured some really good real-world examples plus, for me, as a Windows noob, it was a really good learning journey into the world of Windows hacking.

Like in most cases, the first step we want to do is reconnaissance. In a situation where we don't need to be stealthy, I like to use the following command to look for open ports:

nmap -A [IP]

The -A means aggressive, and delivers all the information we need in most cases. Sometimes a

nmap -p- -A [IP]

can be useful, as it may discover some left-of-field ports that usually aren't used. The -p- just means scan ALL ports from 1 to 65535. Running the first command against the "Active" box gives us following information:

There's a lot to digest here. Good ways to gain an initial foothold are either LDAP (default port: 389/tcp), and SMB (default ports: 139/tcp and 445/tcp). This line:

tells us that there's also an LDAP service running on the non-standard port 3268/tcp. To query LDAP from Linux, I like to use ldapsearch. For some initial information, we can use:

Let's go ahead and unpack this command first.

• -H ldap://[IP]:[Port]
  tells the program which host and what port to query. If no port is specified, this will use the default port of 389. (Use ldaps instead of ldap to work with LDAP over SSL).
• -x tells the program to use simple authentication, which allows us to query LDAP without credentials, if the server is configured to allow that.
• -LLL cuts away a lot of information that is not useful to us from the output.
• -s base tells the program to set the scope to a base object, as we want to look at top-level information first.
• -b "" defines the searchbase. An empty string means that we want to start at the very top, to get as much information as possible.
• namingContexts applies a filter to the output, so that we only get a list of the naming Contexts (which is what we want here [see below], omit this part to receive more information)

Let us run this against the box:

With this list of naming Contexts, we can now proceed to search them for useful information with the following command:

By changing the searchbase to one of the naming Contexts and the scope to "sub", we can get more detailed information that's listed under active.htb. Running this against "Active" gives us this output:

Huh, bummer. The Error message tells us that an LDAP bind couln't be performed. This is most likely due to insufficient permissions. Querying the other naming Contexts leads to similar results. As we don't have any credentials yet, we can't progress here. Let us thus go to the other angle aforementioned: SMB. To connect to SMB from Linux, we can use smbclient. Initially, we want to run the following command:

smbclient -L [IP]

-L just means that we want to list the shares instead of connecting to one. Running it gives us this output:

As we didn't specify any workgroup or username in the command, it will use the default workgroup "WORKGROUP" and the username of the user on our machine. By pressing enter we can test if anonymous login is possible:

And it works! Because we didn't specify any Share to connect to, we get the error message at the end (NT_STATUS_RESOURCE_NAME_NOT_FOUND) - of course, because there is no Share without a name. We can just ignore this error and instead specify on the list of Shares we were provided with. Using:

we can now try all of these Shares. Using the "Press Enter on Password Prompt" technique from above, we can test if we can connect anonymously to any of these Shares. Spoiler: We can connect to "IPC$", but can't really execute any commands. So that is less useful. Trying to connect to "Replication", we get:

We have a prompt! Using dir or ls to list the directory contents and cd to go through the directories, we can look for any juicy stuff in here (You can use TABULATOR for auto-completion, to save some time typing some of the longer directory or file names). To save some time, I'll just skip the step of searching and go right to the juicy stuff:

The Groups.xml (normally located in "SYSVOL") is so interesting, because there is a good chance it contains AES-encrypted user passwords. Let's take a look:

Gotcha! As you can see, we have a username

And there we have our password! We can now use it to go through the Shares again, this time with more privileges. To use credentials with smbclient, we have to call it like this:

-U specifies the user to use for authentication. The domain can be constructed out of the information from LDAP:

There we have our user flag!

We can also continue with querying LDAP, because now we have valid credentials:

.. or, not? Seems the user we found isn't allowed to query LDAP. Thankfully, we already have two clues on where to look next. The first one is this line from our port-scan:

This tells us than Kerberos Authenticaton is used on the target machine. The second clue is a little more subtle, the username we found in the Groups.xml: "SVC_TGS". This could just be random letters, OR the "SVC" could be short for "Service" and the "TGS" could be short for... what exactly? As I said in the beginning, I am a Windows noob, so this was a lot less obvious for me than for people who have more experience attacking Windows machines. But "TGS" - turns out - is short for "Ticket Granting Server". Kerberos hands out tickets to users who authenticated against it, so that they can authenticate against other servers without having to send their passwords again (at least that's my basic understanding of it).

So with these two hints, there's a good chance that our attack Vector here is Kerberos. The most famous privilege escalation exploit for Kerberos is "Kerberoast". It's a relatively safe way to get administrative privileges after you have valid user credentials and it is still very wide-spread in real-world productive enviroments. So let's try it! There's a lot of way to pull this of, I opted for a relatively lazy choice of using a tool that has all the capabilities I need - impacket. The specific tool I wanna use here is located under examples/GetUserSPNs.py. With this, we can run the Kerberoast exploit get an Admin Password hash:

Let's break this call down:

• -request tells the program to request a ticket and save a password hash.
• -outputfile crack.john
  specifies the file in which to save the password hash.
• -dc-ip [IP] specifies the IP of the domain controller (our target)
• The domain, username and password are the ones we got previously.
• -request-user [Username]
  specified the user for which to request the TGS. Not necessary here, as there is only one (Administrator).

This will give us the hashfile crack.john, which we can now proceed to crack with JohnTheRipper. The command looks somewhat like this:

• --format=krb5tgs tells john that the hash is a Kerberos 5 TGS ticket. AFAIK, this does only work with the bleeding-jumbo version, not the default installation on Kali Linux.
• --worldlist=[filename]
  tells john which wordlist to use. I personally prefer rockyou.

This will provide us with the following output:

Et voilà, we have a password: "Ticketmaster1968".

With this, we can go back to SMB, login to the "C$" share, and get the root flag:

And we have the root flag!