As it is normal, the best way to start a CTF is with an extensive NMAP scan. So let's do it.

NMAP output

From this we can see it's a standard domain controller. Except the fact that FTP is open, WinRM communication allows HTTPS; also kerberos port (88) is not exposed, which may play a big role later on.

As we can see SMB is open, let's launch crackmapexec on SMB to gather the domain and FQDN.

CrackMapExec SMB

Perfect, we can now add htb.local and sizzle.htb.local to our /etc/hosts and we are ready to go for the foothold.


Since FTP is open, let us take a look to see what we can do with it.

FTP test

Looks like not much, let's move onto anonymous SMB access now.

SMB anonymous list shares

Perfect, we do have some access and looks like AD CS is installed on the DC. May be useful for later on.

From further analysis, there is a Users folder under "Department Shares" share

SMB Department Shares share

The users folder is particularly interesting, as it may contain a share for each user folder in the system.

Users folder

Correct, there seems to be a folder for each potential user and a Public folder. The Public folder is the only one that seems anonymously writable, and we can leverage this to put malicious files in case a user visits the folder and steal its hash. We can use the ntlm_theft github project for this in the following way:

NTLM Theft usage
Start responder listener
Put malicious files in Public folder
Wait for hashes
Crack the hash

Perfect, we now have our first pair of valid credentials. We can now check what we are able to do with it.

Check amanda capabilities

Looks like they are valid, but winRM won't let us in because of the lack of authorization header. Remember that SSL winRM port is open (5986) and Active Directory Certificate Services seems to be installed as we saw previously on SMB shares listing. That may hint to the fact that we need a valid certificate to get into the system. Sometimes a path is exposed in the web services for this. As port 80 is open, we can try to fuzz it with the specific wordlist "IIS.fuzz.txt" by SecLists.

Web Server fuzzing
Active Directory Certificate Services

Correct, we can visit "certsrv" path using our previously obtained Amanda creds to forge our certificate. We can now follow these steps to create it.

Go to advanced certificate request
Generate certificate request and private key with OpenSSL
Submit the request
Download the cert

Perfect, we now have our certificate ready to be used. Let us try again to login into the system with winRM.

Amanda winRM

Great, we finally have the foothold. We are now ready to escalate to domain admin.

Domain Admin

First logical step would be to leverage a bloodhound collector get information on the domain. We can either use local sharphound for this or remote, however, to use the latter we also need to have kerberos port (88) exposed to our attacker machine. So let's use chisel to perform a remote port forwarding to our machine.

Chisel blocked by AppLocker

However, it looks like AppLocker is blocking us. We can try to bypass it with a special path. There are many, but I will be using C:\windows\system32\spool\drivers\color.

Chisel blocked by AppLocker
Chisel AppLocker bypass

Perfect, we can now reach the kerberos service from our kali machine. However, we still can't use bloodhound from our machine as it needs the same IP for both kerberos and LDAP. To make things easy, I will be using SharpHound in the following way:

Download SharpHound into AppLocker Bypass folder
Execute SharpHound
Exfiltrate results

From an initial analysis, we can gather that user MLRKY is kerberoastable and also able to perform DCSYNC on the domain. This may explain the fact that Kerberos port was initially not exposed, as this is a huge security risk. Remember that we already performed a remote port forwarding on port 88. If we also bring to our machine port 389 (LDAP) we can succesfully perform a kerberoasting attack on MRLKY from our machine with impacket-getUserSPNs in the following way.

Bring port 389 (LDAP) to our system. Remember that we already have port 88 from before.
Perform Kerberoast attack on MRLKY
Crack MRKLY hash

And, since we now have the creds for the mrkly user, and since the account can perform a DCSYNC attack on the DC, there is one more step left to domain admin:

Perform DCSYNC attack as mrkly and get code execution as administrator via wmiexec

And that's it for the writeup. Hope you enjoyed it!