Sizzle
Reconnaissance
As it is normal, the best way to start a CTF is with an extensive NMAP scan. So let's do it.
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.
Perfect, we can now add htb.local and sizzle.htb.local to our /etc/hosts and we are ready to go for the foothold.
Foothold
Since FTP is open, let us take a look to see what we can do with it.
Looks like not much, let's move onto anonymous SMB access now.
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
The users folder is particularly interesting, as it may contain a share for each user folder in the system.
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:
Perfect, we now have our first pair of valid credentials. We can now check what we are able to do with it.
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.
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.
Perfect, we now have our certificate ready to be used. Let us try again to login into the system with 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 bloodhound.py, 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.
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.
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:
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.
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:
And that's it for the writeup. Hope you enjoyed it!