Hack The Box — Netmon — without Metasploit (TJNull’s list for OSCP)

Netmon

This is my 3rd write-up for Netmon a machine from TJNull’s list of HackTheBox machines for OSCP Practice. The full list can be found here.

In a general penetration test or a CTF, there are usually 3 major phases that are involved.

1. Enumeration and Scanning (Information Gathering).
2. Initial Foothold.
3. Privilege Escalation.

Let’s get started with the box!

Enumeration

In order to hack into a system we need to first gather some information about it. For that, we use Nmap to scan the ports of the target machine to find out what services are running; services that we can target.

nmap -sC -sV -A -T4 -p- 10.129.96.142

• -sC is used to run default scripts to enumerate the services further.
• -sV is used for Version enumeration of the services
• -A is used for aggressive (not usually recommended in real environment)
• -T4 is used to set the number of parallel threads.
• -p- is used to do a full port scan from 1–65535.

Nmap

Some of the interesting ports are 21 (FTP, with anonymous login allowed) and ports 80, 5985, 47001 (are HTTP ports). Port 445 is used for SMB. We can read, and write files using SMB, but we don’t really need it since FTP is enabled. Also, SMB shares usually need credentials to read or write files and we don’t have them yet. If guest login was enabled on SMB, Nmap would have reported that since we used -sC to run default scripts and it contains SMB enumeration scripts as well.

Let’s start enumerating the box by logging into FTP with user Anonymous and blank password.

FTP

It looks like the root of C drive is accessible through FTP. This is a very huge scope and we can look into a lot of things to find juicy stuff.

There could be many files that we can look into. This list contains a list of many of those files that can help in enumerating any of the Windows box.

Unfortunately, after enumerating many of these files, I couldn’t find anything that could help me to launch an exploit against the box and get a shell.

Let’s move on to HTTP server on port 80 and enumerate that.

HTTP Server 80

So, here we have login page for PRTG Network Monitor.

Let’s try admin:admin as credentials.

admin:admin login failed

Login failed… Let’s check for default credentials for PRTG Network Monitor.

PRTG default credentials

It appears that ‘prtgadmin:prtgadmin’ are the default credentials. Let’s try them.

prtgadmin:prtgadmin login failed

Nope. Default credentials are not being used. Now we can try brute forcing the login, but wait… We have FTP enabled. How about we do a little research that what’s the default location for PRTG Network Monitor’s configuration files and we may be able to find something there.

A quick Google search gave us the following Directories:

Data Directory:

For Windows Server 2012 (R2), Windows Server 2016, Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2008 R2:

%programdata%\Paessler\PRTG Network Monitor

For Windows XP, Windows 2003

%ALLUSERSPROFILE%\Application data\Paessler\PRTG Network Monitor

For the deprecated PRTG versions 7 and 8, the paths are the following:

PRTG 7 (deprecated):

%ALLUSERSPROFILE%\Application data\Paessler\PRTG Network Monitor\V7

PRTG 8 (deprecated):

%ALLUSERSPROFILE%\Application data\Paessler\PRTG Network Monitor\V8

Since we know that the box has Windows Server OS running

And the PRTG Data Directory in all Windows Servers is:

%programdata%\Paessler\PRTG Network Monitor

Navigating to Data Directory

The contents does indeed include the configuration files for PRTG.

Let’s get all three of them and see what we have.

Error 550

While getting the files I was facing Error 550, I don’t know the reason but switching from ASCII to Binary mode, solved the problem for me.

config file transfer

Going through these files, open them in text editor and searching for user, password, pass, credentials keywords; we find the credentials in PRTG configuration.old.bak

Let’s try these credentials.

prtgadmin:PrTg@dmin2018 login failed

Even these credentials don’t work. It took me a long time to figure this one out. The thing is, the file we found credentials in is actually old.bak. And the credentials we see in it give us the the idea about the password pattern.

Since, old.bak has password PrTg@dmin2018, the hacker mindset tells us that the old password had 2018 in it. So, we should start from 2018 in password and go all the way up to the present year. PrTg@dmin2018 doesn’t work, let’s try PrTg@dmin2019.

login successful

And we have a login!! :)

Initial Foothold

Let’s see what version of PRTG we have running here. For that, right click on the login page and view-source. Then search for keyword version to see if the version is mentioned anywhere in the code.

The currently installed version is 18.1.37.13946.

Let’s search for prtg in searchsploit.

searchsploit prtg

We have a Remote Code Execution exploit for version 18.2.38 which is the later version than our version.

If the later version is vulnerable, chances are that previous versions would be vulnerable too (however, this is not always the case).

Let’s run the exploit and see if there’s any usage help

Example Usage tells us that the exploit needs URL, and cookies to run. Let’s copy the by going to inspect-element > storage after logging in to PRTG admin panel.

Use these cookies along with the URL.

The exploit created a new user pentest for us with the password p3nT3st. And this user has been added to the administrators group, which means that we may not need to escalate the privileges.

Since, SMB was enabled on the machine we can simply use psexec from impacket with our new credentials to get a shell.

Reverse shell

We got a root shell!!! Let’s collect the flags now.

User.txt flag

Root.txt flag