EscapeTwo started with credentials for a low-privilege domain account, rose, in the sequel.htb lab. The scan showed a Windows domain controller with SMB, LDAP, MSSQL, and WinRM among its services. The route to administrator access crossed several distinct permissions; each credential and directory relationship needed verification before moving to the next step.
Follow the share to SQL Server
I first checked where rose could authenticate. SMB and MSSQL worked, but WinRM did not. A direct MSSQL connection allowed limited queries and did not initially give me xp_cmdshell, so I returned to the SMB shares.
The initial scan covered all TCP ports, then ran service detection on the open set. SMB, LDAP, MSSQL, and WinRM made the domain controller role clear.
The readable Accounting Department share contained spreadsheet files. Although the files did not open cleanly in an office suite, their sharedStrings.xml content exposed usernames and passwords, including the SQL Server sa credential. That is a useful reminder that a damaged spreadsheet can still disclose its underlying XML data.
The decisive sharedStrings.xml entries included sa@sequel.htb and the corresponding SQL password. The password is omitted here; the important finding is that it was recoverable from the spreadsheet XML.
I connected to MSSQL as sa and enabled command execution through xp_cmdshell. The resulting process ran as sql_svc. A SQL Server configuration file supplied another password, which I tested against enumerated domain users. It worked for ryan, a member of the Remote Management Users group, allowing a WinRM session and access to user.txt.
evil-winrm -u ryan -p '<recovered password>' -i dc01.sequel.htb
*Evil-WinRM* PS C:\Users\ryan\Desktop> type user.txtFollow the directory permissions
I collected Active Directory relationships and loaded them into BloodHound. Ryan had the ability to take ownership of the ca_svc account. I used that path to set Ryan as owner, grant control over ca_svc, and add a temporary key credential. Certificate authentication as ca_svc yielded its NT hash; the key credential was then restored.
impacket-owneredit -action write -new-owner ryan -target ca_svc 'SEQUEL.HTB/ryan:<password>'
impacket-dacledit -action write -rights FullControl -principal ryan -target ca_svc 'SEQUEL.HTB/ryan:<password>'
certipy-ad shadow -account ca_svc -u ryan@sequel.htb -p '<password>' autoThe final command returned a TGT and the ca_svc NT hash, then restored the old key credentials.
With ca_svc, I changed the DunderMifflinAuthentication certificate template and requested a certificate with administrator@sequel.htb as its UPN. The first request failed because the certificate service required a DNS name. After changing the template configuration, the request succeeded and produced an administrator certificate. A subsequent certificate authentication returned the administrator NT hash.
[*] Successfully requested certificate
[*] Got certificate with UPN 'administrator@sequel.htb'
[*] Saving certificate and private key to 'administrator.pfx'
[*] Got TGT
[*] Got hash for 'administrator@sequel.htb'The captured walkthrough ends at recovery of the administrator hash. It demonstrates domain administrator credential access, but does not show an interactive administrator session or a root flag. The important chain is the sequence of permissions: a readable share exposed SQL credentials, a service configuration exposed a WinRM account, and directory ownership plus certificate template control enabled the final escalation.