smtp-penetration-testing – skill Lập trình cho agent AI

> ⚠️ 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](references/detailed-guide.md) 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.