Poisoning of mail logs is an obscure variation of log poisoning that is no less effective than web access log poisoning. However, in this case, the malicious content, rather than being placed into a web access log file, is injected directly into the mail server's log file (mail.log, maillog, etc.) through the use of SMTP headers. Once the log is poisoned, any LFI vulnerability, debug page, or misconfigured include that reads the mail log can turn it into a hidden spam or phishing page on the legitimate domain.
It’s quiet, low-profile, and keeps working because mail logs are rarely monitored for web-based attacks.
Description of the Process
This is the basic flow of an attack:
1. An attacker sends crafted SMTP emails to one or more (or all) addresses on a target domain (including non-existent addresses) while inserting spam/phishing HTML into the SMTP headers of the email message. Some common headers the attacker would attempt to inject HTML into are as follows:
a) From
b) Subject
c) To
d) Return Path
e) X-Mailer
f) Custom headers (X-Custom-Header)
2. The attacker poisons the mail.log file. One common method for the attacker to poison the mail.log file is to insert the following data into the mail.log: Subject: <title>Buy Cheap Products – 70% OFF Today</title><h1>Fast & Discreet Delivery</h1>...
Because the mail server logs the entire header information into the mail.log without filtering any HTML, the attacker will have taken advantage of this open hole.
3. The attacker will find any way possible to read the mail.log file via the Internet. For example:
a) A local file inclusion (LFI) vulnerability: /page.php?file=../../var/log/mail.log
b) A debug/admin page that shows recent mail logs
c) A misconfigured backup script or monitoring script
4. A spam page based on the inserted content in the mail.log will be served as a normal page of content from the target domain. Google will index the page → The page will start to rank in search results → The attacker will generate revenue from affiliates and/or by delivering malware.
Why This Variant Is Particularly Sneaky
1. Mail logs are almost never checked for web spam content.
2. Email messages are anticipated to be purely text, which allows headers with HTML to slide into the server.
3. Most servers will log complete headers by default for troubleshooting purposes.
4. There is no need to physically interact with the web server to execute this attack.
5. It works even on well-hardened web apps if there’s any LFI or log-viewing functionality.
Practical Hunting Steps
To detect this in your environment:
1. Search mail logs for suspicious content
grep -E "<title>|<h1>|<meta>|casino|crypto|pharmacy" /var/log/mail.log
2. Look for mass injection attempts
grep -E "Subject:|From:|To:" /var/log/mail.log | tail -5000 | grep -E "<|>"
3. Review web logs for attempts to include logs
grep -E "mail\.log|maillog" /var/log/apache2/access.log
4. Keep an eye on search engine results
Practical Prevention Steps
1. Clean any incoming email headers before logging them (remove harmful characters and HTML tags).
2. Place your email logs outside of the webroot; this will limit the possibility of them being accessed through a web browser.
3. Disable dangerous PHP wrappers.
allow_url_fopen = Off
allow_url_include = Off
4. Do not allow your raw email logs to be viewed from an admin/debug interface that can be accessed through the internet.
5. Use a proper mail logging system (like rsyslog with filtering) to sanitize or drop dubious headers.
6. Regularly rotate and scan mail logs for HTML content.
Mail log poisoning is a clever way attackers create hidden spam pages without ever uploading a file to the web server. Because mail logs are trusted and rarely scrutinized, this technique can stay hidden for a long time.
A few simple configuration changes, sanitizing headers, moving logs out of the web root, and disabling dangerous wrappers can close this vector completely.
If your server handles email and has any LFI risk or log-viewing features, it’s worth checking your mail.log today.
