Email-to-S3 OSINT Pivot: SMTP Reconnaissance Chaining to Cloud Storage Data Exposure

osint_soc_enrichment Difficulté 1–5 30 min certifiable

Théorie

Why This Matters

Email infrastructure is one of the most information-rich surfaces in open-source intelligence. Threat intelligence teams at major financial institutions routinely map adversary email infrastructure before an engagement by correlating MX records, SMTP banners, and SPF policy data. Investigative journalists following corporate fraud chains pivot from a leaked invoice email address to the full mail server stack within hours. Red team operators use email server analysis to identify hosting providers, software versions, and associated hostnames — intelligence that directly informs phishing infrastructure and credential-harvesting campaigns. The pivot from SMTP banner to S3 bucket discovery is a documented real-world pattern: mail server hostnames frequently share a naming convention with cloud storage buckets, and public bucket policies sometimes expose backup files containing employee email lists or archived correspondence.

Core Concept

SMTP banner grabbing is the first step: when a client connects to port 25, 465, or 587, the mail server transmits a greeting string containing the server software name and version (e.g., 220 mail.company.com ESMTP Postfix 3.6.4) and often the fully qualified domain name (FQDN). This FQDN is the pivot point. The MX record for a domain is a DNS Resource Record (type MX) that specifies the mail exchange server hostname; examining it with dig or nslookup exposes the same FQDN visible in the banner.

SPF records (Sender Policy Framework, a TXT DNS record beginning v=spf1) list every IP range and hostname authorized to send mail on behalf of the domain. This is a deliberate disclosure — SPF must be public for spam filters to work — and it frequently reveals cloud provider ranges, internal relay subnets, and third-party email platforms (SendGrid, Mailchimp) used by the target organization. DKIM records (DomainKeys Identified Mail, a TXT record at selector._domainkey.domain.com) expose the public key used for signing, and the selector name itself often encodes the mail provider (e.g., google._domainkey for G Suite). DMARC records (at _dmarc.domain.com) reveal policy posture and often a reporting URI that is an email address — another pivot.

Hostname pattern inference for S3: AWS S3 bucket names must be globally unique but follow predictable naming conventions. If the MX hostname is mail-backup.company.com or smtp01.company.com, administrators frequently create buckets named company-mail-backup, company-smtp-backup, or mail.company.com (with periods replaced by hyphens). The public URL pattern https://BUCKET.s3.amazonaws.com/ allows direct enumeration. A publicly accessible bucket returns an XML directory listing; a private bucket returns AccessDenied.

smtp-user-enum performs SMTP user enumeration via three SMTP commands: VRFY user (verify a user exists), EXPN list (expand a mailing list), and RCPT TO:<user@domain> within a fake MAIL FROM transaction. Misconfigured servers respond differently to valid and invalid addresses, allowing an attacker to confirm which email addresses are active.

MX record history on platforms like SecurityTrails reveals past mail providers — an organization that previously used a self-hosted Postfix server before migrating to Google Workspace may have left backup buckets or legacy credentials from the old infrastructure online.

hunter.io uses crawled web data, email pattern heuristics, and contributed data to infer the dominant email format for a domain (e.g., {first}.{last}@company.com) and enumerate known employee addresses, enabling construction of a targeted email list without touching any live server.

Technical Deep-Dive

# 1. MX record discovery and SMTP banner grab
dig MX company.com +short
# Output: 10 mail.company.com.

nslookup -type=MX company.com
# Reveals: mail exchanger = 10 mail.company.com

nc -w 3 mail.company.com 25
# Banner: 220 mail.company.com ESMTP Postfix 3.6.4 Ubuntu

# 2. SPF / DKIM / DMARC record extraction
dig TXT company.com | grep spf
# v=spf1 ip4:203.0.113.0/24 include:sendgrid.net include:_spf.google.com ~all

dig TXT google._domainkey.company.com
# v=DKIM1; k=rsa; p=MIIBIjANBgkq...

dig TXT _dmarc.company.com
# v=DMARC1; p=reject; rua=mailto:[email protected]

# 3. MX history lookup (SecurityTrails CLI or web UI)
# Tool: securitytrails CLI (requires API key)
securitytrails domain company.com history/dns --type MX

# 4. S3 bucket name inference from hostname
# Hostname: mail.company.com => test bucket variants:
curl -s https://company-mail.s3.amazonaws.com/ | head -30
curl -s https://company-mail-backup.s3.amazonaws.com/ | head -30
curl -s https://mail-company.s3.amazonaws.com/ | head -30
# Public bucket returns XML: <ListBucketResult>...

# 5. smtp-user-enum against discovered mail server
smtp-user-enum -M RCPT -U /usr/share/wordlists/unix-users.txt 
  -D company.com -t mail.company.com
# Confirmed: [email protected], [email protected]

# 6. hunter.io domain search (API)
curl "https://api.hunter.io/v2/domain-search?domain=company.com&api_key=KEY"
# Returns: pattern: "{first}.{last}", emails: [...]

Intelligence Collection Methodology

Start with dig and nslookup to enumerate MX records for the target domain. Record the full FQDN of each mail server and its priority value.
Use nmap (nmap -p 25,465,587 --script smtp-commands mail.company.com) or netcat to connect to the mail server and capture the SMTP banner. Note the software, version, and FQDN in the greeting.
Query SPF, DKIM, and DMARC records using dig TXT. Document every IP range, include-mechanism hostname, and third-party provider revealed in SPF. Note DMARC reporting addresses as employee email pivots.
Search SecurityTrails MX record history to find previously used mail servers. Past self-hosted servers are more likely to have associated public cloud storage from migration periods.
Use hunter.io domain search to identify the email format pattern and enumerate known employee addresses. Cross-reference with LinkedIn for name lists to build a fuller address set.
Derive S3 bucket name candidates from the mail server hostname using common patterns: company-mail, company-mail-backup, company-smtp, company-email-archive. Test each with curl for public XML listing or with the AWS CLI (aws s3 ls s3://bucketname --no-sign-request).
Run smtp-user-enum using VRFY, EXPN, and RCPT TO modes against the mail server to validate discovered email addresses and identify additional accounts.
Document all discovered infrastructure in a pivot map: domain → MX hostname → SPF includes → bucket names → employee email list.

Common Intelligence Collection Errors

Treating the SPF ~all (softfail) as a security control: ~all means unauthorized senders fail softly — spam filters may still deliver the mail. It is not a rejection policy. Analysts sometimes under-report SPF scope because they assume ~all means the record is incomplete when it is often fully populated.
Ignoring third-party includes in SPF: The include:sendgrid.net mechanism delegates authorization to SendGrid's IP ranges, not a company-controlled address. Analysts must recursively resolve all include: mechanisms to the final IP ranges to understand the full authorized sending surface.
Assuming S3 bucket names exactly match the hostname: Bucket names frequently drop the TLD, reverse segments, or abbreviate the company name. Test multiple patterns rather than a single direct mapping and use wordlist-based permutation tools like AltDNS adapted to bucket name formats.
Running smtp-user-enum without rate limiting: Many mail servers implement greylisting or rate-limit SMTP connections. An aggressive enumeration attempt triggers block rules and may alert the target's security team. Use the -t (timeout) and -r (retry) flags and limit requests per minute.
Discarding short-lived MX history records: Mail servers used for less than 30 days during a cloud migration are sometimes missed in automated history tools. Always inspect the full paginated history and note any hostnames associated with periods of infrastructure change.
Conflating DKIM selector with mail provider: A selector named google does not guarantee G Suite — administrators can name selectors arbitrarily. Always verify the DKIM public key and check the p= field in the record against known provider key fingerprints.

NICE Framework Alignment

Code	Knowledge/Skill/Task Statement	How This Card Develops It
K0058	Knowledge of network protocols	Applying DNS (MX, TXT, SPF), SMTP, and HTTP protocols to extract intelligence from mail infrastructure
K0145	Knowledge of security assessment approaches	Chaining SMTP banner analysis, DNS enumeration, and cloud storage discovery into a structured recon methodology
K0272	Knowledge of network security architecture	Mapping mail infrastructure topology: MX servers, relay chains, SPF includes, and cloud storage relationships
K0427	Knowledge of encryption algorithms	Interpreting DKIM RSA public keys and identifying key strength from the `p=` field in DNS TXT records
S0040	Skill in identifying and extracting data of interest	Extracting employee email addresses, server software versions, and infrastructure hostnames from public DNS and SMTP sources
T0569	Apply and utilize authorized cyber capabilities to achieve objectives	Using smtp-user-enum, dig, hunter.io, and AWS CLI to achieve systematic mail infrastructure intelligence within authorized scope