Phantom
Phantom is a medium-difficulty Windows machine that requires extracting credentials from a leaked PDF and a VeraCrypt-encrypted router backup to gain initial access. Privilege escalation highlights an
Enumeration
Nmap
We start things off with an nmap scan. The output displays that the target is a domain controller with the domain name of phantom.vl, and the actual machine name is DC.
SMB Enumeration
A publicly accessible SMB share is always worth enumerating, especially if no other significant vector is available. We will use NetExec to verify our guest user access level. The Public share is readable by the guest user.
We access the Public share and enumerate its contents.
Reading the email shows that a PDF has been sent. This PDF is included in the email but encoded with Base64.
To decode it, we echo the Base64 content into a PDF file. After opening the PDF, we find a welcome template with the default password: Ph4nt0m@5t4rt!.
Since we have guest access to the SMB share, we can enumerate users' RIDs, to get usernames to spray password with
Initial Access
With a valid password, we can attempt the password spray again and see if we get any hits this time.
We found a valid domain user who is not a guest account. Using these credentials, we go back to the SMB shares. The share contains multiple directories, and navigating to IT\Backup, we find a VeraCrypt backup container.
We generate a wordlist based on the details we know (Company name, and year with mutations).
Using this wordlist, we perform password cracking using Hashcat in mode 13721 for VeraCrypt.
With the password Phantom2023!, we can mount the backup volume and explore the contents.
Lateral Movement
Extracting the vyos_backup.tar.gz archive gives us the internal filesystem of the VyOS router. Checking the vyos user's .bash_history revealed that the administrator had recently configured an SSTP VPN and struggled to create a system backup.
Checking the vyos user's .bash_history revealed that the administrator had recently configured an SSTP VPN and struggled to create a system backup.
This history log was the missing link. It told me exactly where the config.boot file was located, confirmed that an SSTP VPN was running, and explained the origin of the system_backup.tar.gz file I extracted earlier.
By extracting and analyzing the VyOS config.boot file from the backup archive, I was able to review the router's running configuration. I immediately hunted for the system and vpn blocks to see how access was being managed.
This configuration file yielded massive results. I extracted the SHA-512 hashes for both the admin and vyos users to crack offline if needed. More importantly, I found a set of plaintext credentials for the user lstanley, along with the knowledge that the internal VPN network operates on the 10.0.0.x subnet. With these credentials, I could bypass hash cracking entirely and attempt to tunnel straight into the internal network
We find a set of credentials for the lstanley user. We attempt a password spray with the newly found password and see that we can reuse the credentials. It seems that we have a valid hit for the svc_sspr user.
We check if we can authenticate with WinRM. Once connected, we can retrieve the user flag.
Privilege Escalation
Analysis of BloodHound data shows that svc_sspr has ForceChangePassword over the users crose, wsilva, and rnichols. Further analysis shows that wsilva is a member of the ICT Security group and can modify the msds-AllowedToActOnBehalfOfOtherIdentity attribute on the DC.phantom.vl computer object. This indicates that we can perform an RBCD (Resource-Based Constrained Delegation) attack from the wsilva user account.
We begin by changing the passwords for our target users via RPC.
Since the MachineAccountQuota is set to 0, we cannot create computer objects, so the standard RBCD attack will not work. We'll have to use an unusual way to execute RBCD, using a user account
Standard Resource-Based Constrained Delegation (RBCD) attacks typically rely on the attacker creating a new computer account in Active Directory to act as the delegate. However, when the domain's MachineAccountQuota is set to 0, creating computer objects is impossible, rendering the standard attack path ineffective.
To bypass this restriction, we can abuse RBCD using a standard, non-machine user account instead. Because regular user accounts lack the Service Principal Names (SPNs) required for standard Kerberos delegation flows, we must leverage a User-to-User (U2U) authentication flow. This advanced technique involves extracting the Kerberos Ticket Session Key from the compromised user's TGT and temporarily replacing their actual NTLM hash with this session key. This tricks the Key Distribution Center (KDC) into accepting the authentication, allowing us to perform S4U2Self and S4U2Proxy flows to successfully forge a Service Ticket as a Domain Admin.
First, we must obtain write permissions over the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the DC.phantom.vl machine account. We delegate write permissions to the computer object.
To begin with RBCD exploitation, we sync our time with the target.
We then need to get a TGT for wsilva and extract the session key value.
For the attack to be successful, we need to set the session key as wsilva's new NTLM hash.
After that, we can perform S4U2Self + U2U + S4U2Proxy flows to get a service ticket to the target as the domain admin.
Once we receive the forged service ticket, we leverage Pass-The-Ticket to dump the machine hashes and authenticate through WinRM as the domain admin.
Now we can obtain the flag from C:\Users\Administrator\Desktop\root.txt.
Last updated