# Hack The Box - Sizzle

## Quick Summary

Hey guys today Sizzle retired and here’s my write-up about it. Sizzle was a great machine, everything about it was great. It was very realistic, fun and of course challenging as it was rated Insane. Personally one of my favorites and one of the best Active Directory boxes I have ever solved. It starts by getting write access to a directory in an smb share, a simple scf file attack with responder and john could give me a password for a user. With that password I could generate a certificate request and get a certificate then a WinRm session. After that comes the most challenging part about the box which is bypassing antivirus, kerberoasting and privilege escalation but before doing that we will take a look at an unintended way first. That was the box in a nutshell, It’s a Windows box and its ip is 10.10.10.103, I added it to /etc/hosts as sizzle.htb. Let’s jump right in !

## Nmap

As always we will start with nmap to scan for open ports and services :
nmap -sV -sT -sC sizzle.htb

Full Output :

We got a lot of ports, we got ftp on port 21, dns on port 53, http on port 80, smb and ldap. We also see that the domain is HTB.LOCAL and commonName is sizzle.htb.local, so I added it to /etc/hosts :

anonymous authentication on ftp was allowed but there was nothing there so I will skip that.

## HTTP

I checked that http server and the index only had this gif :

So I ran gobuster :

/certenroll sounds interesting, but unfortunately it’s a 403 :

It’s time to check smb .

## SMB, SCF File Attack, amanda’s Credentials

First thing we need to know is the shares, we can use smbclient to list the shares :
smbclient --list //sizzle.htb/ -U ""

I noticed that there was a share for Active Directory Certificate Services. Most likely /certsrv will be on the web server :
http://sizzle.htb/certsrv

Yes it was there, and we need credentials. Back to smb the only share I could access anonymously was Department Shares :

It had a lot of directories, I could write to 2 of them : ZZ_ARCHIVE and Users/Public.

We are looking for credentials. Since we can write to one of the directories then we can possibly apply an scf file attack. You can read about it here. We are going to put an scf file in Users/Public. It looks like this :

Then we will run responder. Whenever a user browses that directory he will automatically try to connect to my box through smb, that’s when responder catches the hashes. More info in the link above.

reponder -I tun0

responder caught hash for a user called amanda. Let’s crack it with john :

The password is Ashare1972

## Requesting a Certificate, WinRm Session as amanda

I tried to access certenroll as amanda and it worked fine :

So I went to /certsrv and used amanda‘s credentials to authenticate

Now it’s time to get a certificate. But wait a second, what’s the certificate for anyway ?
A full nmap scan shows that WinRm ports are open :
nmap -p- -T5 -vvv --max-retries 1 sizzle.htb

Full Output :

nmap -p 5985,5986 -sV -sT -sC sizzle.htb

Full Output :

Port 5985 uses http while 5986 uses https. When I got amanda‘s credentials I tried to connect to port 5985 and I couldn’t, So we will do it through port 5986 that’s why we need a certificate. (If you don’t know how to connect through WinRm, we’ll get to that later.)
We will generate a certificate request and a private key :
openssl req -newkey rsa:2048 -nodes -keyout request.key -out request.csr

Then we will submit an advanced certificate request, paste our request and download the certificate (base64 encoded)

Now we can use WinRm, but what’s WinRm ?

Windows Remote Management (WinRM) is the Microsoft implementation of WS-Management Protocol, a standard Simple Object Access Protocol (SOAP)-based, firewall-friendly protocol that allows hardware and operating systems, from different vendors, to interoperate.
The WS-Management protocol specification provides a common way for systems to access and exchange management information across an IT infrastructure. WinRM and Intelligent Platform Management Interface (IPMI), along with the Event Collector are components of the Windows Hardware Management features. -Microsoft

WinRm is not meant to be used from Linux but luckily there’s a Ruby library for it. That’s how we will connect.
I used Alamot’s shell and added some stuff for the cert and the key :

And it worked :

But there was no user.txt :

## Stored NTLM Hashes, Secretsdump, Privilege Escalation

Through the filesystem enumeration I found a file called file.txt in C:\Windows\System32. That file had NTLM hashes for all users !

Honestly I don’t know how did that get there, After resetting the machine the file was still there. I don’t know if the creator made an unintended mistake but anyway let’s see how can we use that.
That Administrator hash was useless, I tried it with smb, I cracked it, tried psexec. It didn’t work. I cracked mrlky‘s hash :

The password was Football#7, I used it with secretsdump.py from impacket and got another Administrator’s hash :

It was uncrackable, I tried psexec metasploit module and for some reason it didn’t work so I used the hash with smb to access C\$ then I downloaded the flags.

Now forget that we saw that, Let’s try something more realistic.

## Backtrack

Back to the WinRm session as amanda, let’s examine our environment.
There was AppLocker :

Antivirus :

We were even in Constrained Language Mode in PowerShell :

Since this was an Active Directory environment I wanted to do kerberoasting, but Invoke-Kerberoast.ps1 needed Full Language Mode, I couldn’t use GetUserSPNs.py because the services were internal only. And my attempts to evade the antivirus failed. I could bypass the constrained language mode with PSByPassCLM and still couldn’t use Invoke-Kerberoast.ps1. AppLocker is easy to bypass so it wasn’t an issue. But I had to bypass the antivirus.

## Bypassing AV

First time I created the payload like this :

And I added the shellcode to the POC and applied the exploit :

The antivirus detected it. I added an encoder and 100 iterations and tried again :

Then I added the shellcode to shellcode.xml
shellcode.xml :

This time it worked and I got meterpreter !

## Kerberoasting, Privilege Escalation

Now we have a meterpreter session, we can route the internal subnet, use a proxy then use GetUserSPNs.py and see if any user is kerberoastable. This technique is covered here
First thing is to configure proxychains to use port 8080 :
/etc/proxychains.conf

Then we will use auxiliary/server/socks4a to add the route and set up the proxy :

route add 10.10.10.0 255.255.255.0 1 this adds a route of the whole internal subnet where 1 is the session number.
Now we are ready. Let’s kerberoast !

User mrlky was kerberoastable and we got a hash, let’s pass it to john :

Password is Football#7, now we can use secretdump.py again and do the same thing we did before :

And we owned root !
That’s it , Feedback is appreciated !