TryHackMe – Gatekeeper

This is my writeup for the TryHackMe “Gatekeeper” room at https://tryhackme.com/room/gatekeeper. Gatekeeper is a delightfully vague room requiring me only to submit a User flag and a Root flag. There is little description beyond mentioning a gate and fire twice. Sounds exciting! Let’s begin.

Note: since TryHackMe does not accept writeups for this room, I will be keeping in the spirit of learning and exploration and will keep this writeup similarly vague. It should be enough to guide you along if you’re familiar with the concepts, or show you what areas you need to learn more about to work through the room. Check out my other two buffer overflow writeups for Task 7 and Task 9 if you need more detail about the actual buffer overflow process itself.

Booting the machine and running the initial nmap scan, I see it’s a Windows machine (NetBIOS, SMB, and RDP ports open) plus an interesting service on 31337 called Elite by nmap. Examining the service fingerprint and a quick netcat session to the port, it appears to be some sort of service which echoes input back to the terminal.

From this initial assessment, I see two possible attack vectors:

  • Brute force SMB credentials. Nmap reports a “gatekeeper” username which is likely a Windows user, so the credentials would work for RDP as well.
  • Buffer overflow the application. It appears to be poorly written. Let’s take this approach so we don’t have to deal with potential account lockouts on SMB/RDP.

From enumerating the shares with the nmap script smb-enum-shares, I find a \Users share with read access to the Guest user. That looks promising. Diving deeper, I used smbmap to find what files I can read and found a gatekeeper.exe file in the share.

smbmap -u guest -p '' -d . -H 10.10.223.67 -r Users/Share --depth 1 --no-banner -q

I downloaded the gatekeeper.exe file, copied it to my Windows VM, and got it loaded into Immunity Debugger.

From here, it was a straightforward process to generate the buffer overflow. At first, I thought my script was buggy since it was crashing on the second fuzz size, but I manually tested and found the overflow really was at less than 200 bytes. Running the cyclical pattern through gatekeeper.exe showed the offset at 146.

Checking for bad chars, I found one of 0A and excluded that when generating my payload with msfvenom.

I used Mona to search for the available JMP ESP addresses and there were only two available. The first one worked so I could craft the payload and run it on the target now.

I used msfconsole multi/handler to catch the reverse shell and got a command shell to the natbat Desktop folder from the exploit.

The first User flag was sitting on the desktop so I grabbed that before looking for the root flag.

There was a “mayor” user folder that looked interesting, but access was denied. I need to somehow get permissions into that folder. On the desktop folder, there’s a Firefox link. I know users often save passwords in Firefox and frequently reuse them. Let’s see if I can dump any saved creds from Firefox that might work.

MSF has a multi/gather/firefox_creds module which does exactly what you’d expect. It scans all available Firefox profiles and attempts to dump the relevant files containing credential info. All I have to do is set which meterpreter session to use and the module does the rest. I didn’t have a meterpreter session yet so I updated my buffer overflow script to run a meterpreter shell instead of a reverse shell and then I was able to run the module.

MSF found the saved password files in a profile and saved them to the loot folder. I had to rename the files from the dumped format back to the original formats.

There’s a handy Firefox saved password decrypt Python script on GitHub that I ran to extract the saved credentials. I moved the dumped Firefox files into the same folder as the script and ran it with this command:

https://github.com/unode/firefox_decrypt

python3 firefox_decrypt.py ./

There was one saved password for the “mayor” user. Let’s try that to RDP as “mayor”.

I ran xfreerdp with the username and password and it worked! I connected to the mayor\Desktop folder and had access to the root.txt file.