Shibuya
User enum→weak creds→plaintext service account password→WIM registry dump→offline hash crack→SSH key upload→PTH as domain user→NTLM coerce active RDP session→crack hash→ESC1 cert as Administrator→PWN

Target: 10.129.234.42
Domain: shibuya.vl
Domain Controller: AWSJPDC0522.shibuya.vl
Difficulty: Medium
Tags: Active Directory, Kerberos, WIM Forensics, DPAPI, NTLMv2 Relay, ADCS / ESC1/ESC2/ESC3
1. Reconnaissance
A full nmap service scan against the target revealed a classic Windows Server 2022 Active Directory domain controller
A follow-up UDP scan (nmap -sU) confirmed standard AD UDP services: DNS (53), Kerberos (88), NTP (123), and LDAP (389).
Anonymous LDAP queries were blocked — the server required an authenticated bind before returning any directory data.
2. Initial Access — Credential Discovery via Kerbrute
With no valid credentials yet, Kerbrute was used against the xato-net-10-million-usernames wordlist to enumerate valid domain accounts via Kerberos pre-authentication responses:
Valid usernames discovered:
Password spraying these accounts with their usernames as passwords succeeded — both accounts used trivially weak credentials (purple:purple, red:red). This is a common pattern on lab environments but also seen in real-world environments for service or test accounts.
Both accounts authenticated successfully but had only standard read access to IPC$, NETLOGON, SYSVOL, and users.
3. SMB Enumeration & Credential Leak in User Description
Using the red account to enumerate all domain users via SMB:
The output revealed something immediately valuable — the svc_autojoin service account had its password stored in plaintext in the description field:
This is a well-known misconfiguration where administrators set a description on service accounts during provisioning and forget to remove it. The --users flag in NetExec queries the description attribute for every account, making this a trivial find.
Credential validation confirmed svc_autojoin:K5&A6Dw9d8jrKWhV and revealed it had READ access to the images$ share — which purple and red did not.
4. WIM Image Exfiltration via images$ Share
Authenticating as svc_autojoin using Kerberos and browsing the images$ share via impacket-smbclient:
The naming convention AWSJPWK0222 maps to the workstation found later in AD (AWSJPWK0222). These .wim files are Windows Imaging Format disk images, almost certainly Volume Shadow Copy (VSS) snapshots of the workstation, confirmed by the vss-meta.cab metadata archive.
All four files were retrieved and extracted with 7-Zip:
Contents of each WIM:
wim_loot (01)
User profiles: Administrator, Default, Public, simon.watson
wim_loot2 (02)
Windows registry hives: SAM, SECURITY, SYSTEM, SOFTWARE, DRIVERS, etc.
wim_loot3 (03)
Boot files: EFI, PCAT, Fonts, DVD boot environment
The registry hives in WIM 02 were the most interesting — the SAM, SECURITY, and SYSTEM hives together allow full offline secrets extraction.
5. Offline Secrets Dump from WIM Registry Hives
With the SAM, SECURITY, and SYSTEM hives extracted locally, impacket-secretsdump was used to perform an offline registry secrets dump — no network connection to the DC required:
Key findings:
Local
operatoraccount NT hash:5d8c3d1a20bd63f60f469f6763ca0d50Cached domain credential (DCC2) for
Simon.Watson— this hash format is not directly usable for PTH, but the local NT hash foroperatormatchedsimon.watson's hash when tested against the DC (the workstation was presumably provisioned with the same local admin hash, orsimon.watsonis the localoperatorequivalent)DPAPI machine and user keys extracted for potential future DPAPI decryption
6. Lateral Movement to simon.watson (PTH + SSH)
The operator local NT hash (5d8c3d1a20bd63f60f469f6763ca0d50) was tested against the domain controller as simon.watson using Pass-the-Hash:
Authentication succeeded, confirming password reuse between the local workstation account and the domain account.
User flag retrieved via SMB:
Persistent SSH access was then established by uploading an SSH public key to simon.watson's profile via SMB:
This gave a full interactive Windows command prompt on the DC.
7. Domain Enumeration as simon.watson
Checking simon.watson's group membership via whoami /all showed membership in:
SHIBUYA\shibuyaSHIBUYA\sshSHIBUYA\t2_admins
The t2_admins group membership is significant — it implies Tier 2 admin rights (workstation-level), but not Tier 1 (server/DC-level).
Enumerating t1_admins:
explorer and mstsc tells someone is sitting on the RDP
Running qwinsta via RunasCs to check active RDP sessions:
nigel.mills is actively logged into an RDP session on the DC (Session ID 1). This is the pivot point — nigel.mills is a t1_admin whose credentials can be targeted via NTLM relay from their active session.
8. NTLMv2 Hash Capture via RemotePotato0
Since nigel.mills had an active RDP session (Session 1), RemotePotato0 was used to coerce NTLM authentication from that session by spawning a COM object that triggers a cross-session authentication attempt back to our listener.
Attack setup: On the attacker machine, forward port 135 to the victim's RogueOxidResolver:
On the victim (as simon.watson):
-m 2— mode 2 (cross-session NTLM relay)-r— attacker IP for the RPC relay listener-x— attacker IP for the RogueOxidResolver-p 8888— port for the RogueOxidResolver-s 1— target Session ID 1 (nigel.mills' RDP session)
RemotePotato0 spawns a COM object (CLSID: 5167B42F-C111-47A1-ACC4-8EABE61B0B54) in session 1, which authenticates back over DCOM/RPC, routing through our socat relay and captured as an NTLMv2 hash:
Cracking with John the Ripper:
Credentials confirmed: nigel.mills:Sail2Boat3
9. ADCS Enumeration — ESC1/ESC2/ESC3 via Certipy
With nigel.mills (a t1_admin), an SSH SOCKS proxy was set up and Certipy was run through it to enumerate ADCS:
CA found: shibuya-AWSJPDC0522-CA
Vulnerable template found: ShibuyaWeb
Client Authentication
✅ True
Enrollment Agent
✅ True
Any Purpose
✅ True
Enrollee Supplies Subject
✅ True
Requires Manager Approval
❌ False
Enrollment Rights
SHIBUYA\t1_admins, Domain Admins, Enterprise Admins
Key Size
4096
Validity
100 years
Vulnerabilities flagged:
ESC1 — Enrollee can supply an arbitrary Subject Alternative Name (SAN/UPN), and the template enables client authentication. This allows any
t1_adminto impersonate any user, including domain admins.ESC2 — Template allows Any Purpose EKU.
ESC3 — Template has Certificate Request Agent EKU, enabling enrollment-on-behalf-of attacks. Since
nigel.millsis a member oft1_admins, all three are exploitable. ESC1 is the most direct path.
10. Privilege Escalation — ESC1 Certificate Request as _admin
Exploiting ESC1: request a certificate from ShibuyaWeb with the UPN set to _admin (the domain's built-in Administrator account, SID -500):
The certificate was issued immediately (no manager approval required). The SID pinning (-sid) ensures the certificate is bound to the Administrator's SID even if the UPN doesn't match exactly.
Authenticating with the certificate to retrieve the NT hash:
Certipy uses PKINIT (certificate-based Kerberos pre-authentication) to obtain a TGT as _admin, then performs a U2U Kerberos exchange to extract the NT hash via the PAC.
11. Domain Compromise
With the _admin NT hash, a semi-interactive shell was obtained via impacket-smbexec:
Full domain compromise achieved.
12. Flags
User (simon.watson)
73531560a013b61326392eba28efc261
Root (_admin / Administrator)
5b15xxxxxxxxxxxxxxxxxxxxxxxx98f1
13. Attack Chain Summary
Tools Used
nmap
Port scanning and service fingerprinting
kerbrute
Kerberos username enumeration
NetExec (nxc)
SMB authentication, share/user enumeration
impacket-smbclient
SMB file operations (download WIM, upload SSH key)
7-Zip
WIM archive extraction
impacket-secretsdump
Offline registry hive secrets dump
ssh / ssh-keygen
Persistent access, SOCKS proxy
RunasCs
Running commands in alternate security contexts
RemotePotato0
Cross-session NTLM hash coercion
socat
TCP port forwarding for RogueOxidResolver
john
NTLMv2 hash cracking
certipy-ad
ADCS enumeration and ESC1 exploitation
impacket-smbexec
Semi-interactive shell via SMB
proxychains
SOCKS5 proxy tunnelling through SSH
Last updated