Hack The Box: Vintage Machine Walkthrough - Hard Difficulty

Reading Time: 11 minutes

Introduction to Vintage:

In this writeup, we will explore the “Vintage” machine from Hack The Box, categorized as a Hard difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Vintage” machine from Hack The Box by achieving the following objectives:

To obtain the user flag, we exploit a weak password on a legacy computer account (fs01$) to retrieve a Kerberos TGT, which we use to extract the gMSA password. We then reactivate a disabled service account (svc_sql), make it ASREPRoastable, and crack its hash to obtain credentials for another domain user. Using these credentials, we authenticate with Evil-WinRM and capture the user flag.

To capture the root flag, we decrypt DPAPI-protected secrets to obtain credentials for a higher-privileged account (c.neri_adm). With this account, we add a compromised service account to a privileged group, assign an SPN, and perform a Kerberos delegation attack to impersonate a domain admin. This grants SYSTEM-level access and allows retrieval of the root flag.

Enumeration on Vintage Machine

Reconnaissance:

Nmap Scan

nmap -sC -sV -oA 10.10.11.45 -Pn

Nmap Output:

──[dark@parrot]─[~/Documents/htb/vintage]
└──╼ $cat initial.nmap 
# Nmap 7.94SVN scan initiated Wed Apr 16 08:13:06 2025 as: nmap -sC -sV -oA initial -Pn 10.10.11.45
Nmap scan report for 10.10.11.45
Host is up (0.21s latency).
Not shown: 989 filtered tcp ports (no-response)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-04-16 12:13:48Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: vintage.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: vintage.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-time: 
|   date: 2025-04-16T12:14:11
|_  start_date: N/A
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Analysis:

Port 53 (TCP): Simple DNS Plus – DNS service running on the host.
Port 88 (TCP): Microsoft Windows Kerberos – Kerberos authentication service (server time: 2025-04-16 12:13:48Z).
Port 135 (TCP): Microsoft Windows RPC – Microsoft Remote Procedure Call service.
Port 139 (TCP): Microsoft Windows NetBIOS-SSN – NetBIOS Session Service for Windows.
Port 389 (TCP): Microsoft Windows Active Directory LDAP – Lightweight Directory Access Protocol for Active Directory (Domain: vintage.htb0., Site: Default-First-Site-Name).
Port 445 (TCP): Microsoft-DS – Potential Microsoft Directory Services service (exact service not identified).
Port 464 (TCP): Kpasswd5 – Kerberos password change service (uncertain).
Port 593 (TCP): Microsoft Windows RPC over HTTP 1.0 – RPC service running over HTTP.
Port 636 (TCP): TCP Wrapped – Likely a service wrapped by TCP wrappers, possibly SSL/TLS service.
Port 3268 (TCP): Microsoft Windows Active Directory LDAP – Another LDAP instance for Active Directory (Domain: vintage.htb0., Site: Default-First-Site-Name).
Port 3269 (TCP): TCP Wrapped – Similar to port 636, likely wrapped by TCP wrappers or an SSL/TLS service.

SMB Enumeration on Vintage Machine

We have credentials:

P.Rosa : Rosaisbest123

Try using smbclient:

smbclient -L \\vintage.htb -U "vintage/P.Rosa%Rosaisbest123"

You tried to access shared folders on a machine called vintage.htb using the smbclient Command with credentials for the user P.Rosa, expecting to see available SMB shares. Instead, you got the error NT_STATUS_NOT_SUPPORTED, which in simple terms means the server doesn’t support the way you’re trying to log in — likely because it requires a newer SMB protocol or Kerberos authentication rather than the default NTLM method. To fix this, you can try specifying newer protocols with --option='client min protocol=NT1' --option='client max protocol=SMB3', or if you have a Kerberos ticket (TGT), run kinit P.Rosa@VINTAGE.HTB followed by smbclient -k -L //vintage.htb. Alternatively, use crackmapexec smb vintage.htb -u P.Rosa -p Rosaisbest123 --shares it to quickly check share access using a more modern SMB approach.

smbclient -L \vintage.htb -U "P.Rosa" -d 5 > smbclient_debug.log 2>&1

The output shows that your system successfully connected to the SMB service on vintage.htb (IP: 10.10.11.45) using the interface ens33 with IP 192.168.209.204. The SMB client started correctly, but there were several permission-related warnings such as mkdir failed on directory /run/samba: Permission denied, indicating that the client couldn’t create certain runtime directories—likely because it wasn’t run with elevated (root) privileges. While these errors don’t prevent the connection, they could cause issues in specific scenarios. The client also noted the absence of a stored site name for the Kerberos realm, but this doesn’t block SMB communication. It successfully resolved the hostname vintage.htb to its IP address using Netbios and attempted connections over ports 445 and 139.

LDAP enumeration on Vintage machine

Utilise ldapsearch with GSSAPI (Kerberos) authentication to ensure compatibility with Kerberos-only environments:

ldapsearch -x -H ldap://vintage.htb -D "vintage\P.Rosa" -w Rosaisbest123 -b "dc=vintage,dc=htb" "(objectclass=user)" sAMAccountName

To start, we enumerate all directory objects where the objectClass is set to user, allowing us to extract their sAMAccountName values — effectively, the usernames in the domain.

Among the results, we observe a number of standard user accounts, as well as a domain controller account (DC01), a group Managed Service Account (gMSA01$), and a computer account (FS01$).

No accounts were found with pre-authentication disabled, but we did come across three revoked accounts — one of which is the service account svc_sql. The logical next step is to continue gathering information and move forward with enumeration using BloodHound CE. That won’t be an issue, since the bloodhound-ce-python tool works just fine with Kerberos authentication.

BloodHound Enumeration for vintage machine

bloodhound-python -u P.Rosa -p 'Rosaisbest123'  -d vintage.htb -c ALL -dc dc01.vintage.htb

This command uses the bloodhound-python tool to collect Active Directory data for analysis in BloodHound. It authenticates with the username P.Rosa and the password Rosaisbest123 on the vintage.htb domain. The -c ALL The flag tells the tool to gather all possible types of data (like user sessions, group memberships, ACLS, etc.), while -dc dc01.vintage.htb specifying the domain controller to query.

There’s an error that we need to identify and resolve.

Upload results to BloodHound GUI.

Bloodhound-CE Enumeration

Upon initial review, FS01$ is a legacy system predating Windows 2000.

Notably, it also possesses the capability to retrieve group Managed Service Account (gMSA) passwords

Additionally, the serviceManagers group has GenericAll permissions over the three service accounts we identified earlier, including the one we revoked.

Exploitation of Vintage Machine

Compromise FS01$

Since fs01$ has permission to read the password for gMSA01$. The first step is to look for a way to compromise older, pre-Windows 2000 systems. These machines often have a weak default configuration where the computer account’s password is just the computer name itself. The idea here is to request a TGT (Ticket Granting Ticket) for one of these accounts—using the computer name as the password—and then use gMSADumper.py (as suggested by BloodHound CE) to extract the password for gMSA01$. Start by trying to request a TGT for the fs01$ machine account.

impacket-getTGT -dc-ip 10.10.11.45 vintage.htb/fs01$:fs01 
export KRB5CCNAME=fs01$.ccache

The command is using a tool called impacket-getTGT to request a Kerberos Ticket Granting Ticket (TGT) for the machine account fs01$ in the vintage.htb domain. The -dc-ip 10.10.11.45 part specifies the domain controller‘s IP address, which is the server that manages all the network accounts and authentication. The vintage.htb/fs01$:fs01 part indicates that the tool is trying to authenticate using the machine name fs01$ and assuming its password is the same as the machine name (fs01). After successfully getting the ticket, the command stores it in a specific file, fs01$.ccache, by setting an environment variable called KRB5CCNAME. Essentially, the goal is to exploit a weak security setup where a machine’s password may just be its own name, allowing attackers to gain access to network resources.

Troubleshooting the issues

Sadly, we got an error which we need to solve it

#!/bin/bash

echo "[*] Cleaning up old packages..."
pip3 uninstall -y bloodyAD msldap minikerberos msldap-bAD minikerberos-bAD asyauth-bAD --break-system-packages

echo "[*] Installing BloodyAD with correct forks..."
pip3 install \
  msldap-bAD==0.5.19 \
  minikerberos-bAD==0.4.6 \
  asyauth-bAD==0.0.25 \
  bloodyAD==2.1.12 \
  --break-system-packages

echo "[+] Done. Test with:"
echo "bloodyAD --host dc01.vintage.htb -d 'VINTAGE.HTB' --dc-ip 10.10.11.45 -k get object 'GMSA01$' --attr msDS-ManagedPassword"

This script is performing a few tasks related to installing and setting up specific tools for interacting with Active Directory. First, it removes older versions of certain packages (bloodyAD, msldap, minikerberos, etc.) that might be outdated or incompatible. It then installs specific versions of these tools, including msldap-bAD, minikerberos-bAD, asyauth-bAD, and bloodyAD, ensuring the installation is up to date with the correct versions needed for the task at hand. After the installation, the script provides a command to test the installation. This command uses the tool bloodyAD to interact with the Active Directory server (dc01.vintage.htb) and retrieves a specific piece of information related to a service account (GMSA01$), which is useful for further tasks like identifying passwords or security settings related to that account.

Analysis on Bloodhound

The output provides information about a Group Managed Service Account (gMSA), specifically gMSA01$, in the Active Directory domain vintage.htb. The Distinguished Name (DN) is CN=gMSA01,CN=Managed Service Accounts,DC=vintage,DC=htb, indicating its location within the AD hierarchy. The NTLM hash is shown as aad3b435b51404eeaad3b435b51404ee:a317f224b45046c1446372c4dc06ae53, where the first part is the LM hash and the second is the NT hash used for Windows authentication. The Base64-encoded version of the password is included as rbqGzqVFdvxykdQOfIBbURV60BZIq0uuTGQhrt7I1TyP2RA/oEHtUj9GrQGAFahc5XjLHb9RimLD5YXWsF5OiNgZ5SeBM+WrdQIkQPsnm/wZa/GKMx+m6zYXNknGo8teRnCxCinuh22f0Hi6pwpoycKKBWtXin4n8WQXF7gDyGG6l23O9mrmJCFNlGyQ2+75Z1C6DD0jp29nn6WoDq3nhWhv9BdZRkQ7nOkxDU0bFOOKYnSXWMM7SkaXA9S3TQPz86bV9BwYmB/6EfGJd2eHp5wijyIFG4/A+n7iHBfVFcZDN3LhvTKcnnBy5nihhtrMsYh2UMSSN9KEAVQBOAw12g==, which, when decoded, reveals the actual password used by the service account.

GMSA01$ enumeration

To reactivate the service account svc_sql, we can add gMSA01$ to the serviceManagers group. The first step in this process would be to generate a Ticket Granting Ticket (TGT).To reactivate the service account svc_sql, we can add gMSA01$ to the serviceManagers group. The first step in this process would be to generate a Ticket Granting Ticket (TGT).

BloodyAD activity

Next, add P.Rosa to the SERVICEMANAGERS group, use the credentials of the gMSA, and then generate your credentials.

By running the impacket-getTGT command with the specified user credentials vintage.htb/P.Rosa:Rosaisbest123, you successfully generated a Ticket Granting Ticket (TGT) for the user P.Rosa. The ticket was saved in a file named P.Rosa.ccache. Afterwards, you exported the environment variable KRB5CCNAME to point to this cache file (P.Rosa.ccache), which tells the system where to look for the TGT when making further Kerberos requests.

In these commands, the goal is to modify the account settings for two service accounts, SVC_ARK and SVC_SQL, within the domain. First, the command removes the “ACCOUNTDISABLE” flag from SVC_ARK, which effectively re-enables the account if it was previously disabled. Next, the second command adds the “ACCOUNTDISABLE” flag to the SVC_SQL account, disabling it and preventing its use. Finally, the last command removes the “ACCOUNTDISABLE” flag from the SVC_SQL account, re-enabling it and allowing it to be used again.

We have successfully obtained the hash values associated with the user account P.ROSA.

Upon successful cracking, the password was revealed to be Zer0the0ne.

In this sequence, the getTGT.py script from the Impacket toolkit is used to request a Kerberos Ticket Granting Ticket (TGT) for the user c.neri in the vintage.htb domain, using the password Zer0the0ne and specifying the domain controller’s IP address. Upon successful authentication, a TGT is saved in a credential cache file named c.neri.ccache. The KRB5CCNAME environment variable is then set to point to this cache file, ensuring that tools relying on Kerberos authentication can use the ticket. Finally, evil-winrm is used to initiate a remote session with the domain controller dc01.vintage.htb using the Kerberos ticket, granting shell access to the system under the context of the c.neri account.

We can retrieve the user flag by executing the type user.txt command within the remote session.

Escalate to Root Privileges Access

Privilege Escalation

Dump DPAPI-Protected Secrets

DPAPI (Data Protection Application Programming Interface) is a Windows API that applications use to securely store sensitive information, such as passwords, tokens, and other secrets.

Source:

Data blobs are typically located in the following directories:

First, we need to review all relevant details, including the user’s permissions

C:\Users\C.NERI\AppData\Local\Microsoft\Credentials\
C:\Users\C.NERI\AppData\Roaming\Microsoft\Credentials\

You can usually find master keys, derived from the user’s password in

C:\Users\C.NERI\AppData\Roaming\Microsoft\Protect\<User SID>\
C:\Users\C.NERI\AppData\Local\Microsoft\Protect\<User SID>\

Download both files to the local machine.

The first step is to extract the key from the master key file using the user’s password, SID, and blob files.

This process ultimately reveals credentials for another user, c.neri_adm.

Summary:
In this scenario, the credentials for c.neri_adm were protected using the Windows Data Protection API (DPAPI). Both the data blob and the associated master key files are located within the c.neri user’s directory.

By enumerating the delegatedAdmins group, we identify a potential path to Domain Administrators through the l.bianchi_adm account, as l.bianchi_adm is a delegated admin and, consequently, a domain administrator.

S4U2Self to S4U2Proxy Delegation Attack on Vintage Machine

Considering alternative approaches, we could leverage the svc_sql account that we previously reactivated and add it to the delegatedAdmins group. This is feasible as we have control over the c.neri_adm account

The PowerShell command is used to query Active Directory for information about the SVC_SQL user account, specifically retrieving the SERVICEPRINCIPALNAMES (SPNs) associated with it. The GET-ADUSER cmdlet queries details of a specified user account in Active Directory, in this case, the SVC_SQL account. By using the -IDENTITY parameter, the command specifies the user account to query. The -PROPERTIES flag followed by SERVICEPRINCIPALNAMES instructs PowerShell to return the SPNs registered to the SVC_SQL account. SPNs are unique identifiers used to associate a service instance with a particular account, typically utilized for Kerberos authentication.