Enterprise (Domain-Admin to RDP Users + PowerUp privesc)

TryHackMe - Enterprise

After finishing Crocc Crew the day before, I decided to double down and get back to Enterprise. I think Iโ€™ve previously attempted, half heartedly, to do this one, but never got far with it. Those were pre-OSEP days, so I thought let me test to see what I know now. It was a tough challenge, but a lot easier when I stuck to proper AD exploit methodology.

The room is called Enterprise, and is available at https://tryhackme.com/room/enterprise.

Portscan

The first thing I did was a portscan:

We clearly have what looks like a domain controller here.

HTTP - Port 80

As per normal, we see port 80 open, and we immediately start throwing wordlists at it.

The first interesting thing we notice is a robots.txt file.

All we get is this though:

SMB - Port 445

For some reason I cannot use smbmap with guest login, but using smbclient manually Iโ€™m able to view shares.

I have had this before, and for this reason Iโ€™ve setup a simple smbcheck.sh, that basically just runs a number of SMB checks. If it wasnโ€™t for this, I wouldโ€™ve missed the open shares.

smbcheck.sh:

I enumerated the shares, and found that I had access to Users and Docs.

Users

I copied over all the files locally, to be able to browse and grep through the contents.

I found a Consolehost_history.txt (basically your Powershell .bash_history) file that looked interesting.

That password and username must lead to something, right? Wrong.

I tried that username and password combination on everything I had at my disposal, but it did not work.

Docs

Here I found password protected documents.

I got the hashes from them, and started running it through hashcat.

This turned out to be a dead-end as well.

HTTP - Port 7990

I turned my attention to the HTTP found on port 7990.

After trying to see how the logins worked, I finally re-read the message on that page.

Hoping to avoid seeing any spoilers, I headed to Google and search for Enterprise THM.

Luckily for me what I wanted was listed as the first found page.

I headed over to the Github page.

Browsing the repository, I didnโ€™t find anything interesting in the code files. But I did find a list of their developers.

Following the trailer, I started looking at Nikโ€™s repositories and his commits. I came across a commit where he included a username and password.

Now this is where things got tricky for me. I took down the username as nic instead of nik. This led me on a wild goose chase because I was getting strange errors from SMB when using that combination.

Eventually I realised my mistake, and was able to authenticate properly.

LDAP - Port 389

With valid credentials, I was able to utilise ldapdomaindump to get information on the AD users.

Here I found a user whose password was listed as a comment/note.

I checked, and was still able to use these credentials.

Kerberos - Port 88

I decide to turn my attention back to the previous user, as I wasnโ€™t getting further joy from the newly found user.

I decide to see which SPNs are linked to the user.

Lucky for me, this dumps a hash for the bitbucket user.

Running hashcat I was able to get the password for this user.

I validated that the credentials were correct.

Going back to my LDAP dump, I look at this user and see they are able to RDP into the machine.

It is once logged in that I get the first flag.

Privilege Escalation

The first thing I do is get a meterpreter shell back to my Kali box. I prefer working on that terminal, instead of through RDP.

Once I get a meterpreter shell back, I upload winPEAS to run some privelege escalation checks.

I had to enable console colors for it to look a bit better.

I immediately spot two options that look easy to exploit.

Although I have access to the files for the AtlassianBitbucket service, I cannot control the service itself.

The second one is much better, and Iโ€™m able to control the zerotieroneservice service as well as write files to the C:\Program Files (x86)\Zero Tier directory. As noted the file path suffers from a unquoted service path vulnerability.

From here I generated a exe-service payload using msfvenom.

I uploaded it to be placed in C:\Program Files (x86)\Zero Tier\Zero.exe

Setup up msfconsole to capture the shell, and got a reverse shell as SYSTEM.

The only thing left was the last flag.

Profit

Last updated