Contact Form Spam Attack: An Innocent Feature Caused a Massive Problem

How a simple “Send a copy to yourself” feature led to 149,700 spam emails and what you can do to prevent it

The Emergency Call

It started like many server emergencies do – with a panicked message about massive server performance issues. A client’s website was grinding to a halt, CPU usage was through the roof, and something called dovecot/lmtp was consuming enormous resources. But this wasn’t just a performance problem – it was the beginning of uncovering a sophisticated spam operation hiding in plain sight.

The Initial Symptoms

When we first connected to the server, the signs were alarming:

• High CPU usage from email-related processes.
• Massive email queue building up.
• Server struggling under unexpected load.
• Spam complaints from recipients.

The first command we ran revealed the scope of the problem:

exim -bp | wc -l
149700

149,700 emails were sitting in the outbound queue. This wasn’t just a small spam problem – this was a massive issue for the server.

Following the Digital Breadcrumbs

Step 1: Understanding the Email Headers

The investigation began by examining the email headers from the server logs. Here’s what we found in the failed delivery reports:

Sender User: website_user
Sender Domain: website.com
From Address: website_user@serverhost.net
Sender Host: localhost
Sender IP: 127.0.0.1
Authentication: localuser

The key indicators were:

• Localhost origin (127.0.0.1) – emails were being generated by scripts on the server.
• Local user authentication – not external SMTP relay abuse.
• Consistent sender domain – all emails appeared to come from the legitimate website.

Step 2: Examining the Email Logs

We dove deeper into the PHP error logs and found the smoking gun:

[29-Sep-2025 15:06:58 UTC] mail() on [/home/user/public_html/libraries/vendor/phpmailer/phpmailer/src/PHPMailer.php:880]: 
To: "info@website.com " 
Subject: Website_Name:Adult_dating_with_tens_of 

[29-Sep-2025 15:06:59 UTC] mail() on [/home/user/public_html/libraries/vendor/phpmailer/phpmailer/src/PHPMailer.php:880]: 
To: "spammer@sender.com " 
Subject: Copy_of:Adult_dating_with_tens_of_millions_of 

This revealed a crucial pattern:

1. Dual email delivery: Each spam submission generated TWO emails.
2. First email: Went to the site owner (info@website.com).
3. Second email: Went to external addresses with “Copy of:” prefix.
4. Timing: Sent within seconds of each other.
5. Reply-To manipulation: Headers pointed back to the spammers.

Step 3: The Hunt for the Source

Initially, we suspected the usual culprits:

• Malware-infected WordPress plugins
• Compromised PHP files with backdoors
• Hacked PHPMailer library

We systematically checked each possibility:

grep -r 'eval(' /home/user/public_html/ --include=".php" 
grep -r 'base64_decode' /home/user/public_html/ --include=".php" 
find /home/user/public_html -name "*.php" -mtime -7 -exec ls -la {} ; 
head -20 /home/user/public_html/libraries/vendor/phpmailer/phpmailer/src/PHPMailer.php

Surprisingly, everything checked out. The PHPMailer library was legitimate, no malicious files were found, and no obvious backdoors existed.

The Discovery

The pattern in the email logs held the key. The “Copy of:” prefix in the subject lines was the crucial clue. This wasn’t random – it suggested an automated “copy to sender” feature.

While checking for all possible culprits, we stumbled across something unusual. It all came down to the contact form below. Can you spot the issue?

Yes, the “Send a copy to yourself” checkbox.

How the Attack Worked

1. Spammers discovered the contact form on the website.
2. They identified the “Send a copy to yourself” feature.
3. They automated form submissions with:
   • Spam content in the message field.
   • Their email address as the “copy recipient”.
   • Various fake sender names and subjects.
4. Each submission triggered two emails:
   • One to the website owner (normal contact form behavior).
   • One to the spammer (the “copy” feature).
5. Bots submitted the form thousands of times, generating 149,700 emails across several websites with the same issue in the same hosting. Even though the contact form says “Captcha”, we identified no Captcha system in place to stop the bots. Even if the Captcha system was working, malicious actors could still manually send spam emails to other people.

The Perfect Storm

This attack was particularly effective because it:

• Bypassed spam filters – emails came from a legitimate server.
• Appeared as normal website activity – just contact form submissions.
• Provided double delivery – spammers got their content delivered twice.
• Required no file uploads or system compromise – just form abuse.
• Scaled infinitely – bots could submit 24/7.

The Emergency Response

Immediate Actions Taken:

1. Stopped the email service.
2. Suspended the user account temporarily to halt all email generation.
3. Cleared the email queue.
4. Disabled the contact form immediately.

Damage Assessment

• 149,700 spam emails were queued for delivery.
• Server IP reputation was compromised.
• Potential blacklisting by spam databases.
• Resource exhaustion affecting other websites on the server.

Long-term Prevention Strategies

1. Contact Form Security Best Practices:
   • Never trust user input.
   • Add CAPTCHA protection.
2. Remove Dangerous Features such as “Send copy to myself” options:
   • These features provide minimal user value.
   • They create significant security risks.
   • Users rarely need copies of their own messages.
   • If necessary, implement with strict validation.
3. Input Validation and Sanitization:
   • Email validation
   • Content filtering
4. Use a tool like SpamAssassin and enable options in WHM to help with spam.
   • Navigate to “WHM / Home / Service Configuration / Exim Configuration Manager” and enable one of the following options:
     • “Do not forward mail to external recipients if it matches the Apache SpamAssassin™ internal spam_score setting”.
     • “Do not forward mail to external recipients based on the defined Apache SpamAssassin™ score”.
5. Implement SPF Records for Email Authentication:
   • SPF (Sender Policy Framework) records can help mitigate contact form abuse. In the case described here, the spam emails were originating from localhost, but appearing to come from the legitimate domain. A properly configured SPF record would limit them to the domain itself or a specific public server IP address.

Red Flags to Watch For

Immediate Warning Signs

• Sudden increase in email queue size.
• High CPU usage from email processes (dovecot/lmtp, exim).
• Spam complaints from recipients.
• Server performance degradation.

Email Log Patterns

• Dual email delivery (same timestamp, similar content).
• “Copy of:” prefixes in subject lines.
• External reply-to addresses in contact form emails.
• High volume from single IP addresses.

Form Submission Anomalies

• Rapid-fire submissions (multiple per second).
• Similar content patterns across submissions.
• Suspicious email addresses (temporary email services).
• Generic names with marketing content.

The Broader Implications

This attack highlights several important security principles:

1. Every Feature is a Potential Attack Vector: Even innocent features like “Send a copy to yourself” can be weaponized by attackers. Security must be considered at every level of functionality.
2. Legitimate Infrastructure Can Be Abused: Spammers increasingly use legitimate servers and services to bypass spam filters, making detection more difficult.
3. Scale Amplifies Everything: What seems like a minor feature flaw becomes a major security incident when automated tools are involved.
4. Defense in Depth is Essential: No single security measure would have prevented this attack. Multiple layers of protection are necessary.

Conclusion and Action Items

The contact form spam attack we investigated demonstrates how quickly a small oversight can escalate into a major security incident. A simple “Send a copy to yourself” feature, combined with inadequate input validation, allowed attackers to generate nearly 150,000 spam emails.

Immediate Actions for Website Owners

1. Audit all contact forms for “copy to sender” features.
2. Implement CAPTCHA on all public forms.
3. Add rate limiting to prevent automated abuse.
4. Monitor email queue sizes regularly.
5. Set up alerts for unusual email volumes.

Long-term Security Practices

1. Regular security audits of all user-facing features.
2. Input validation on every form field.
3. Logging and monitoring of form submissions.
4. Regular review of email sending patterns.
5. Incident response planning for spam attacks.

For Developers

1. Security-first design approach to new features.
2. Threat modeling for user input mechanisms.
3. Regular security training and awareness.
4. Code reviews focused on abuse potential.
5. Testing with malicious inputs during development.

The digital landscape is constantly evolving, and attackers are becoming more sophisticated in their methods. Even so, simple vulnerabilities like these can go under developers’ radar.

Attackers are constantly looking for ways to take advantage of websites’ vulnerabilities. The key is being prepared with the right tools, knowledge, and response procedures to minimize the impact when it happens.