SMTP Smuggling

Reading time: 7 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Vérifiez les plans d'abonnement !
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

Informations de base

Ce type de vulnérabilité a été originally discovered in this post où il est expliqué qu'il est possible d'exploiter des divergences dans la manière dont le protocole SMTP est interprété lors de la finalisation d'un e-mail, permettant à un attaquant de smuggler plusieurs e-mails dans le corps du message légitime, ce qui permet d'usurper d'autres utilisateurs du domaine affecté (comme admin@outlook.com) en contournant des défenses telles que SPF.

Pourquoi

Ceci s'explique parce que, dans le protocole SMTP, les données du message à envoyer dans l'e-mail sont contrôlées par un utilisateur (attaquant) qui pourrait envoyer des données spécialement conçues en abusant des différences entre les parsers pour smuggler des e-mails supplémentaires chez le récepteur. Regardez cet exemple illustré tiré du post original :

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

Comment

Pour exploiter cette vulnérabilité, un attaquant doit envoyer des données que l'Outbound SMPT server considère comme un seul e‑mail alors que l'Inbound SMTP server considère qu'il y en a plusieurs.

Les chercheurs ont découvert que différents Inbound servers considèrent différents caractères comme la fin des données du message e‑mail, que les Outbound servers ne considèrent pas forcément.
Par exemple, une fin de données régulière est \r\n.\r. Mais si l'Inbound SMTP server supporte aussi \n., un attaquant pourrait simplement ajouter ces données dans son e‑mail et commencer à indiquer les commandes SMTP d'un nouveau message à smuggler, comme dans l'image précédente.

Évidemment, cela ne fonctionnerait que si l'Outbound SMTP server ne traite pas aussi ces données comme la fin des données du message, car dans ce cas il verrait 2 e‑mails au lieu d'un seul — c'est cette désynchronisation qui est exploitée.

Données potentielles de désynchronisation :

\n.
\n.\r

Notez aussi que SPF est contourné parce que si vous smugglez un e‑mail depuis admin@outlook.com à partir d'un e‑mail de user@outlook.com, l'expéditeur reste outlook.com.

Liste de vérification de l'attaquant (quelles conditions doivent être remplies ?)

Pour smuggler avec succès un second e‑mail, vous avez typiquement besoin de :

Un outbound server A que vous pouvez utiliser (souvent avec des identifiants valides) qui va transférer une séquence de fin‑de‑DATA non standard sans la modifier. Beaucoup de services ont historiquement forwardé des variantes comme \n.\r\n ou \n.\n.
Un receiving server B qui interprétera cette séquence non standard comme la fin de DATA puis parsera ce qui suit comme de nouvelles commandes SMTP (MAIL/RCPT/DATA...).
Outbound doit effectivement envoyer avec DATA (et non BDAT). Si A supporte CHUNKING/BDAT, le smuggling ne fonctionne que s'il revient à DATA (par ex. si B n'annonce pas CHUNKING), sinon BDAT avec encadrement par longueur empêche l'ambiguïté.
PIPELINING n'est pas requis mais aide à masquer les commandes injectées dans un seul write TCP pour que des dispositifs intermédiaires ne resynchronisent pas.

Variantes communes de fin‑de‑DATA à tester (dépend du receiver) :

\n.\n
\n.\r\n
\r.\r\n
\r\n.\r (CR nu à la fin)

Note : Ce qui fonctionne est l'intersection de « ce que A forwarde » ∩ « ce que B accepte ».

Exemple d'exploitation manuelle (session unique)

L'exemple suivant illustre l'idée en utilisant une session STARTTLS SMTP brute. Après le premier bloc DATA, nous insérons un terminateur non standard, puis un autre dialogue SMTP que le serveur récepteur peut interpréter comme un nouveau message.

Session de smuggling manuelle (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

Si A transmet `\n.\r\n` et que B l'accepte comme fin‑de‑DATA, le message “hello B” peut être accepté comme un deuxième e‑mail provenant de `admin@target.com` tout en passant SPF (aligné avec les IPs d'A).

Conseil : Lorsque vous testez en interactif, assurez‑vous d'utiliser `-crlf` afin qu'OpenSSL préserve les CRLF dans ce que vous tapez.

---

## Automation and scanners

- hannob/smtpsmug: send a message ending with multiple malformed end‑of‑DATA sequences to see what a receiver accepts.
- Exemple : `./smtpsmug -s mail.target.com -p 25 -t victim@target.com`
- The‑Login/SMTP‑Smuggling‑Tools: scanner for both inbound and outbound sides plus an analysis SMTP server to see exactly which sequences survive a sender.
- Vérification rapide (inbound) : `python3 smtp_smuggling_scanner.py victim@target.com`
- Sortant via un relais : `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 '...'
`

Ces outils vous aident à cartographier les paires A→B où le smuggling fonctionne réellement.

---

## 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.

---

## Notes on affected software and fixes (for 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>`.

Utilisez les scanners ci‑dessus pour vérifier le comportement actuel ; de nombreux fournisseurs ont changé les paramètres par défaut début 2024–2025.

---

## Tips for red team ops

- Favorize large commodity senders for A (historically Exchange Online, shared hosters, etc.). If they still forward some non‑standard EOM and they’re in the victim’s SPF, your smuggled MAIL FROM will inherit their reputation.
- Énumérez les extensions SMTP de B : bannière `EHLO` pour PIPELINING/CHUNKING ; si CHUNKING est absent vous avez de meilleures chances avec des senders BDAT‑first. Combinez avec des EOM malformés pour sonder l'acceptation.
- Surveillez les headers : le message smuggled créera généralement une chaîne Received séparée commençant à B. DMARC passera souvent parce que le MAIL FROM s'aligne avec l'espace IP d'A.

---

## **Références**

- [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>


Apprenez et pratiquez le hacking 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;">\
Apprenez et pratiquez le hacking 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;">
Apprenez et pratiquez le hacking 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>Soutenir HackTricks</summary>

- Vérifiez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) !
- **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous sur** **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
- **Partagez des astuces de hacking en soumettant des PR au** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.

</details>

</div>