Sizzle
Amanda Shell
Nmap scan:
$ nmap -p- --min-rate 5000 10.129.73.156
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-26 00:20 EDT
Nmap scan report for 10.129.73.156
Host is up (0.0075s latency).
Not shown: 65507 filtered tcp ports (no-response)
PORT STATE SERVICE
21/tcp open ftp
53/tcp open domain
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
443/tcp open https
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
5985/tcp open wsman
5986/tcp open wsmans
9389/tcp open adws
47001/tcp open winrm
49664/tcp open unknown
49665/tcp open unknown
49666/tcp open unknown
49668/tcp open unknown
49671/tcp open unknown
49688/tcp open unknown
49689/tcp open unknown
49692/tcp open unknown
49695/tcp open unknown
49700/tcp open unknown
49713/tcp open unknownAnonymous FTP
This machine allows for anomyous FTP access, but there's nothing present in the server:
Let's move on for now, we might need this later.
HTTP
This just shows a GIF of bacon sizzling:

When viewing the page source, this is located at the /images directory, which we don't have access to. However, it does tell us this is an IIS server based on the error page:

SMB Shares Enumeration
enum4linux works with guest credentials.
smbmap can confirm this:
Within the Department Shares, there are loads of directories:
The Users directory gives me a list of usernames to work with and perhaps ASREP-Roast:
The ZZ_Archive directory contains a lot of different files which all have the same size and edit date with different extensions.
All of these folders were rather useless and contained nothing of interest. I tried ASREP-Roasting the users but to no avail as well. My thought process was that since we cannot use anything within the share, perhaps we have to put something there.
SCF File -> NTLM Hash
In another machine Driver on HTB, we had to create a .scf file that was being clicked by the user in order to capture NTLM hashes via responder. I tried the same thing here.
First, I mounted the SMB share.
I started with the most out place file to try the exploit, which was the ZZ_ARCHIVE directory. Then, we can place this file within it:
There was nothing for this particular directory, and it looks like nothing was happening. So I decided to check exactly which directories I could write to. I used ChatGPT (the best tool ever) to create a quick script to do this:
The output was this:
So I could also write to that Public file. I copied the test.scf file there and responder captured a hash!

We can crack this hash easily with john:
However, this password cannot be used to evil-winrm in to the machine.
CertEnroll -> User Shell
With these credentials, we can actually access another share:
Now the CertEnroll share is available. CertEnroll is a reference to an ADCS service that provides a web platform to enroll certificates. This means that /certsrv is probably present on the web server, and visiting it requires credentials:

Using the credentials we have, we can access it:

We can try to request a certificate, and this presents us with 2 options:

Clicking on User Certificate brings us to a page requesting its key strength:

For some reason, I cannot specify the key strength in this, so we probably aren't supposed to have this functionality. In this case, we can check the advanced request form:

It appears we have to create a certificate ourselves, then use it to submit a request to be approved. I know that certificates can be used for authentication purposes, and this service is used to signed the certificates to 'make them legit'. As such, we can create a Certificate Signing Request (CSR) via openssl.
Then, we can grab the .csr contents and paste it into the box:

When submitted, we would get the option to download the certificate:

This would download a .cer file to our machine. Using this, we can try to get a shell. Googling online led me to someone's OSCP notes, and it appears it is possible to get a WinRM shell using this certificate with some Ruby code:
Using this, we can get a shell as Amanda:

Privilege Escalation
Bloodhound -> Kerberoastable
Before starting my enumeration within the machine, we can use bloodhound-python to scope what we need to do (else we'll be heading in blind).
Then, start bloodhound and neo4j, then upload the data required. I found that the user amanda has no privileges at all. Checking the Kerberoastable accounts, we find that mrlky is a possible target.

Checking the privileges of this user, we can see that they have DCSync privileges over the forest.

So that's the attack path. Normally, I would aim to Kerberoast remotely for both OPSEC reasons and also because impacket is just so easy to use. However, in our initial nmap scan, port 88 is not public facing. This means that we have to Kerberoast on the machine itself using rubeus.exe.
CLM + AppLocker -> CLM Bypass
I tried to download and execute Rubeus, but this is the error I get due to AppLocker:

Other tools like PowerView.ps1 don't work as well. The current shell that I have is extremely limited in We can check the Execution Context to confirm this:
There are 2 methods of exploitation here. One is we could run a Kerberoast Powershell script that would involve bypassing CLM. Fortunately, iRedTeam has a whole article detailing a method that involves Powershell versions.
All we need to do is specify that we want to use Powershell Version 2:

Using this method, we can run some scripts using this. However, its even better if we can get a CLM Bypassed shell. To do so, we can simply download the Invoke-PowerShellTcp shell to the machine, and then run this command:

Great! Now we have a fully functioning shell.
Invoke-Kerberoast
Since we have a full shell, we don't actually need Rubeus anymore as there are plenty of Kerberoasting Powershell scripts that (hopefully) don't trigger AppLocker.
However, trying to run this gives me a weird error:
We can follow the PowerSploit documentation to resolve this.
The above still doesn't work because it complains that we don't have theInvoke-UserImpersonation cmdlet imported. This means we have to import PowerView.ps1 as well.
After running this, a hash for the user is given to us:

Transfer this to our machine, and we can crack it easily with john:
DCSync
Earlier, we saw that this user had DCSync privileges over the domain, so we can easily use secretsdump.py to dump the administrator hash:

Then, we can use smbexec.py to pass the hash and get an administrator shell.

Then we can capture both the flags!
Last updated