J. Perez Duertojperezduerto.info
← all walkthroughs

Netmon

Windows· Easy· Credential Access
owned
2026-06-29
time to own
5m12s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I browsed the target's entire hard drive through an anonymously accessible FTP service, recovered the PRTG Network Monitor administrator password from an undeleted configuration backup file, then guessed the current password by incrementing the year in the stale credential, and finally exploited a known authenticated command-injection vulnerability in that PRTG version to execute operating-system commands as LocalSystem — the highest-privilege account on the machine.

Command conventions

The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].

export TARGET="<retired-instance-ip>"
export PASSWORD="<a-password-you-choose>"
export PASSWORD3="<a-password-you-choose>"

Attack path — how the box was taken

1ReconnaissanceNetwork port scanning (Nmap)
Mapped all exposed services with a port scan
A full-port scan revealed FTP on port 21 (Microsoft FTP service), a Paessler PRTG Network Monitor web interface on port 80 running version 18.1.37.13946, SMB on port 445, and WinRM on port 5985. These findings immediately flagged two high-value targets: an FTP service that might allow anonymous login, and a specific, versioned web application that could carry known CVEs.
Services confirmed: 21/tcp Microsoft ftpd, 80/tcp Indy httpd 18.1.37.13946 (Paessler PRTG), 445/tcp SMB, 5985/tcp WinRM.
Exact commands 1
Full-port version scan; -sC runs default NSE scripts to grab banners and check common misconfigurations.
nmap -sV -sC -p- --open --min-rate 5000 $TARGET -oN /tmp/nmap_full.txt
2Initial AccessAnonymous FTP access (MITRE T1190)
Logged into FTP as an anonymous user and browsed the entire system drive
The Microsoft FTP service accepted connections from anyone presenting the username 'anonymous' with any password. The FTP root was mapped to the system drive (C:\), so I could freely list directories and download files — including application data folders normally invisible from the network. As an immediate payoff, the user-level flag file was readable directly over this unauthenticated channel.
FTP service on 21/tcp accepted anonymous login; directory listing of C:\ and subdirectories returned successfully.
Exact commands 3
At the prompt enter 'anonymous' as username and leave the password blank (or any string).
ftp $TARGET
Non-interactive directory listing of the FTP root — shows the full C:\ drive.
curl -s --user anonymous: ftp://$TARGET/ --list-only
Retrieve the user flag directly over FTP — no shell required. Value: <user.txt>
curl -s --user anonymous: "ftp://$TARGET/Users/Public/user.txt"
FixDisable anonymous FTP access and restrict the FTP root directoryCritical
WeaknessThe FTP service on port 21 accepted connections from any anonymous user and exposed the entire system drive (C:\), giving any network-reachable an unauthorised user read access to application data directories, configuration files, and user home folders — all without providing a single credential.
FixDisable the FTP service entirely if it is not operationally required. If FTP must remain, disable anonymous authentication in IIS FTP settings (Authentication → Anonymous Authentication → Disabled), require named user accounts with strong passwords, restrict the FTP root to a dedicated isolated directory that contains no application or system data, and enforce TLS (FTPS, explicit or implicit). Block inbound connections to TCP port 21 from untrusted networks at the perimeter firewall.
3Credential HarvestCredential exposure in backup/configuration file
Downloaded the PRTG configuration backup and extracted the admin password
PRTG stores its configuration — including administrator credentials in near-plaintext XML — under C:\ProgramData\Paessler\PRTG Network Monitor\. An old backup copy named 'PRTG Configuration.old.bak' had been left on disk and was readable over anonymous FTP. Searching the file revealed the PRTG administrator username 'prtgadmin' and the password '[REDACTED: recovered credential]'.
File C:\ProgramData\Paessler\PRTG Network Monitor\PRTG Configuration.old.bak retrieved over anonymous FTP; contained dbpassword field with prtgadmin credentials.
Exact commands 2
Download the PRTG backup configuration file over anonymous FTP.
curl -s --user anonymous: "ftp://$TARGET/ProgramData/Paessler/PRTG%20Network%20Monitor/PRTG%20Configuration.old.bak" -o prtg_config.bak
Extract credential fields from the XML backup; look for <dbpassword> tags.
grep -i 'dbpassword\|password\|prtgadmin' prtg_config.bak | head -30
FixDelete PRTG configuration backup files and tighten file-system permissions on PRTG dataHigh
WeaknessAn old PRTG configuration backup (PRTG Configuration.old.bak) containing the administrator password in near-plaintext XML was left on disk in the PRTG data directory. Anyone who gained any level of file-system read access — including through the anonymous FTP misconfiguration — could harvest a valid administrative credential immediately.
FixDelete all .old, .bak, and .dat configuration files from C:\ProgramData\Paessler\PRTG Network Monitor\ that are no longer operationally required. Restrict NTFS permissions on the live configuration file so only the PRTG service account and local Administrators can read it. Establish a periodic (weekly) automated check that alerts if credential-bearing backup files exist for more than 24 hours. Never expose the ProgramData tree via FTP, file shares, or web roots.
4Credential AccessPassword pattern inference / credential reuse
Guessed the current admin password by incrementing the year in the stale credential
The backup held the password '[REDACTED: recovered credential]'. Knowing that administrators routinely rotate passwords by advancing the year, I tried '[REDACTED: recovered credential]' against the PRTG web login. It was accepted immediately, confirming the password had been changed with only a single character replaced — a predictable pattern a determined my reaches in one attempt after finding any historical version.
Curl POST to /public/checklogin.htm with [REDACTED: recovered credential] returned a valid Set-Cookie session token, confirming successful authentication.
Exact commands 1
A Set-Cookie line in the response confirms the credential is valid.
curl -s -k -i --data-urlencode username=prtgadmin --data-urlencode "password=$PASSWORD" --data 'loginurl=/index.htm' http://$TARGET/public/checklogin.htm | grep -i 'set-cookie\|location'
FixReplace the PRTG admin password with a long, randomly generated credential and enforce a rotation policyHigh
WeaknessThe PRTG administrator account used a password built on a predictable pattern: the product's well-known default base string ('[REDACTED: recovered credential]') followed by the current year. Once any historical version was recovered from a backup, the live credential was guessable in a single attempt.
FixImmediately change the prtgadmin account password (and any other shared PRTG accounts) to a randomly generated passphrase of at least 20 characters, stored in a password manager or secrets vault. Prohibit patterns that include product names, seasons, or years. Enable PRTG's built-in failed-login lockout to slow brute-force and guessing attempts. Audit all service and application accounts across the environment for similarly predictable patterns.
5ExploitationAuthenticated command injection — CVE-2018-9276 (EDB-46527)
Exploited authenticated PRTG command injection (CVE-2018-9276) for a SYSTEM shell
PRTG Network Monitor versions before 18.2.39 contain an authenticated command-injection flaw in the sensor notification feature. An admin-level user can supply a crafted notification name that embeds arbitrary Windows shell commands; PRTG executes them as the LocalSystem account. The public exploit script EDB-46527 automates the full chain: it logs in with the supplied session cookie, creates a malicious notification object, triggers it, and by default adds a new local administrator account — giving me full remote control.
Bash /usr/share/exploitdb/exploits/windows/webapps/46527.sh -u http://$TARGET -c "$cookie" executed with the [REDACTED: recovered credential] session cookie and completed successfully.
Exact commands 3
Capture the authenticated session cookie into a shell variable.
cookie=$(curl -s -k -i --data-urlencode username=prtgadmin --data-urlencode "password=$PASSWORD" --data 'loginurl=/index.htm' http://$TARGET/public/checklogin.htm | awk -F': ' 'BEGIN{ORS=""} /^Set-Cookie:/ {split($2,a,";"); print a[1]"; "}')
echo "Cookie captured: $cookie"
Runs EDB-46527; by default adds local admin account 'pentest' / '[REDACTED: recovered credential]'. Alternatively edit the script to execute a reverse shell command.
bash /usr/share/exploitdb/exploits/windows/webapps/46527.sh -u http://$TARGET -c "$cookie"
Confirm SYSTEM-level code execution via the newly created admin account.
nxc smb $TARGET -u pentest -p '$PASSWORD3' --local-auth -x 'whoami'
FixUpgrade PRTG Network Monitor to 18.2.39 or later to fix CVE-2018-9276Critical
WeaknessThe installed PRTG version (18.1.37.13946) contains an authenticated command-injection vulnerability in its notification subsystem. Any user holding PRTG administrator credentials can execute arbitrary operating-system commands as LocalSystem — the highest-privilege Windows account — without any additional exploit step.
FixUpgrade PRTG Network Monitor to version 18.2.39 or the current latest stable release, which removes the vulnerable notification parameter. Until the patch is applied, restrict access to the PRTG web interface (ports 80 and 443) to trusted management IP addresses only using firewall or host-based ACL rules. Consider enabling Windows Defender Credential Guard and limiting the PRTG service account privileges to reduce the blast radius of any future authenticated-RCE class vulnerability.
6Full ControlPrivileged file access as SYSTEM
Read the administrator flag as LocalSystem — complete machine compromise
The PRTG exploit runs operating-system commands under the LocalSystem account, which has unrestricted access to every file on the host. I read the administrator desktop flag, confirming complete, unrestricted control of the machine with no further escalation needed.
Root.txt retrieved from C:\Users\Administrator\Desktop\root.txt with SYSTEM privileges; value redacted.
Exact commands 1
Read root flag as SYSTEM. Value: <root.txt>
nxc smb $TARGET -u pentest -p '$PASSWORD3' --local-auth -x 'type C:\Users\Administrator\Desktop\root.txt'

Exposed services

21/tcp
80/tcp
135/tcp
139/tcp
445/tcp
5985/tcp
47001/tcp
49664/tcp
49665/tcp
49666/tcp
49667/tcp
49668/tcp
49669/tcp