HackTheBox: Sauna Walkthrough

Summary

HackTheBox’s Sauna was retired today, and it was an excellent machine for practicing Active Directory (and domain controller) exploitation. Rooting the box did not require any vulnerability exploitation at all, rather it relied on tried and true AD exploitation tactics. Getting an initial foothold on the box required enumerating employee names, creating a list of potential usernames based on common naming conventions, and using that list to perform an ASREPRoast attack against the Kerberos service. After gaining a hash for one user, fsmith, I managed to crack it and utilize Evil-WinRM to get a low shell. During internal enumeration, running winPEAS gave me another set of credentials for a service account, svc_loanmgr. I logged in as that account, loaded Bloodhound, and determined that the account's permissions allowed me to perform a DCSync attack and dump all user credentials. After obtaining the Administrator account's NTLM hash, I gained a root shell via PsExec.

Tools Used

Nmap, Impacket, Hashcat, Evil-WinRM, winPEAS, Bloodhound

Initial Foothold

As always, I began by running Nmap:

Based on the number of open ports and the services running on them, I assumed that this was a Domain Controller. As such, I attempted to enumerate the usual suspects: SMB and LDAP. Unfortunately, both of these were pretty locked down. The only information I managed to get was the domain components: DC=EGOTISTICAL-BANK,DC=LOCAL.

Moving on, I enumerated the website.

Once again, however, there didn’t seem to be any exploitation vectors. After further enumerating the website and still finding nothing, I made a list of potential usernames based on the employee names found on the website.

Using this list of potential usernames, I attempted to perform an ASREPRoast attack and got a hit.

I was easily able to crack the hash using hashcat. After that, I utilized Evil-WinRM to gain a remote shell, which was possible due to the WSMan service being enabled:

Privilege Escalation

Once on the box, I downloaded and ran winPEAS, which revealed some credentials stored within the registry:

Logging in as that user, I performed some additional enumeration. Running Bloodhound revealed that the svc_loanmgr account had both the GetChanges and GetChangesAll privilege. This means that the account can perform a DCSync attack. In simple terms, a DCSync attack is where a user with the aforementioned permissions can impersonate a domain controller and utilize MS-DRSR (Directory Replication Service Remote Protocol) to obtain a dump of all user credentials.

In order to exploit this misconfiguration, I used Impacket’s secretsdump.py to dump the credentials and psexec.py to get a root shell.

Discussion

This machine features a number of misconfigurations and fundamental weaknesses of various protocols used within AD environments, which makes the box both an interesting case study and a useful discussion topic.

The first mistake relates to the ASREPRoast attack. Monimoy Sanyal, a principal architect at Microsoft, has previously written about why Kerberos pre-authentication should not be disabled so I won’t delve too much into that. Basically, when pre-authentication is disabled, any user can request a ticket-granting ticket (TGT) in plain text. When the Kerberos service sends back the encrypted TGT, a malicious actor can simply take the ticket offline and crack the user’s password. Technically speaking, this sort of operation would similarly be possible if pre-authentication was required, but that would require the actor to perform a man-in-the-middle attack.

In most cases, there is no reason for pre-authentication to be disabled. Microsoft even enables it by default, which is an impressive feat for a company so indifferent to its operating system’s insecure default configurations (those are three different links). Often times, pre-authentication is disabled due to legacy support. In some cases, this may be necessary. In those cases, password requirements need to be extremely strong, security event monitoring devices need to be configured to record and alert on plaintext TGT requests from unusual hosts, the scope of the pre-authentication disablement needs to be very limited, and accounts configured this way should be subject to regular review. There’s simply no other way to prevent this attack.

The path to root, as well as the corresponding credential dump, was paved by an account with excessive and poorly thought out privileges. Beyond the obvious, the only thing I have to add is that security audits and reviews should not only feature group members (as is often the case), but also group and user privileges. An organization that truly follows the principle of least privilege needs to ensure that there are no blind spots that could allow a user, regardless of intent, more rights than are necessary. It’s easy to blame MS-DRSR, but its functionality is rooted in necessity. This was fundamentally a case of excess privilege.

Beyond getting access as NT AUTHORITY\SYSTEM (or Administrator, if you used crackmapexec), what could a malicious actor do based on the vulnerabilities noted? For one, they could establish a level of persistence that would cause even the most well-run security programs headaches. With the krbtgt user's NTLM hash, it's possible to create a golden ticket. If one has a golden ticket, they could impersonate any and every user in the domain regardless of whether or not they know the password. Compounding this problem, the only remediation strategy is to change the password for the krbtgt account... Twice. This may or may not break services in the environment. Fortunately, Microsoft has a script for safely resetting the krbtgt account's credentials.

Other methods for persistence include DCShadow, ACL persistence, and setting up backdoors using programs like Empire or Merlin. Additionally, you then have to worry about abusing domain trusts to gain (often times elevated) access to other domains within an organization. In conclusion, security personnel need to understand the risks associated with AD and continuously monitor and audit these risks, whether internally or externally (e.g. security audit, penetration test, etc.).

As always, feedback is greatly appreciated. If you have any questions or comments, feel free to email me at me@infosecmatt.com.

Originally published at https://infosecmatt.com on 2020–07–18. This post has been migrated to Medium as part of a holistic migration. Content has been formatted to accommodate Medium’s styling conventions, however it may not appear as originally designed due to restrictions on styling customization inherent to the platform.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Matt Johnson

Matt Johnson

Freelance cybersecurity consultant based in Düsseldorf, Germany.