When Your Security Vendor's Name Is the Subdomain: Brand Impersonation via Amazon SES

The email subject line referenced an electronic payment batch with a reference number. The body was brief: a payment had been processed, and the recipient should follow a link to view the attached report. The greeting was generic. The signature block referenced a DMV contact mailbox. The footer credited an equipment rental company.

None of these identities matched each other. And all of them authenticated.

The message was delivered through Amazon SES infrastructure (PTR: a48-94[.]smtp-out[.]amazonses[.]com, IP 54[.]240[.]48[.]94). SPF passed for amazonses.com. DKIM signatures validated for both the sending domain and amazonses.com. DMARC returned pass. The From address used an opaque bounce-style format on the unrelated domain lucadarmento[.]com, characteristic of mass-mailing platforms and transactional email services. The sender was a first-time contact with a high sender-risk rating.

Inside the attached PDF was the real payload: a URL using "ironscales" as a subdomain on orhanpastacafe[.]com.

Subdomain Impersonation as a Trust Anchor

The malicious URL discovered inside the PDF was structured as hxxps://ironscales[.]orhanpastacafe[.]com/home/8020671812/..., with a long tokenized path typical of tracking or credential-capture landing pages. The domain orhanpastacafe[.]com belongs to an entirely unrelated registrant. WHOIS records showed a recent update, and the A/MX records did not align with any security vendor infrastructure.

The technique is subdomain impersonation: placing a trusted brand name as the leftmost component of a hostname. Humans read URLs from left to right. Seeing "ironscales" at the beginning of a URL creates an immediate association with the security vendor. Most users never parse past the subdomain to identify the actual root domain. Automated link-scanning tools that evaluate reputation at the root domain level would flag orhanpastacafe[.]com as low-reputation, but tools that only check the full hostname against known-bad lists might miss it if the specific subdomain combination is new.

The link was assigned a malicious risk score of approximately 0.92 during analysis, consistent with credential-harvesting intent.

The PDF itself (filename: CCD_047613_Payment_Report_Cloud Email Security Solutions – AI Threat Protection.pdf, 130,011 bytes, MD5: 1d32e428763cb418c2e71e32200ceb4a, SHA256: 7ff7edd0ceeaf019a9e272afe88540c2adebffa61ecf63c94ff9ec5edae866f4) contained the URL as an external link annotation (/URI). No embedded JavaScript or executable payloads were found. The PDF producer metadata listed Prince 16.1, a rendering engine commonly used for automated document generation, suggesting mass-produced phishing lures rather than hand-crafted social engineering.

See Your Risk: Calculate how many threats your SEG is missing

Three Identities, Zero Consistency

The body of the email referenced a governmental-sounding contact (a DMV mailbox) as the sender identity. The footer credited an unrelated equipment rental company The PDF filename referenced "Cloud Email Security Solutions" and "AI Threat Protection." The From address belonged to a domain (lucadarmento[.]com) with no connection to any of these entities.

This layering of mismatched identities is a hallmark of template-based mass phishing. The attacker is reusing a generic email template, swapping in different attachment filenames and PDF payloads for different campaigns without updating the surrounding content. The DMV reference was likely from a previous campaign targeting government service recipients. The equipment rental footer may have been borrowed from a different template entirely.

For defenders, this kind of inconsistency is a high-signal indicator. Legitimate transactional emails from payment processors have consistent branding: the sender, the body, the footer, and the attachment all reference the same organization. When they diverge, it means someone assembled the message from parts rather than generating it from a single, legitimate system.

Authenticated Abuse of Cloud Email Infrastructure

Amazon SES is a legitimate, widely used email delivery service. Its IP ranges have high reputation scores. Messages sent through SES with properly configured DKIM inherit that reputation. Attackers exploit this by registering SES accounts (sometimes using compromised credentials, sometimes through throwaway registrations) and configuring their sending domains with valid DKIM records.

The result is a phishing email that passes every protocol-level authentication check while carrying a malicious payload. The FBI's 2024 Internet Crime Report documented the continued growth of phishing as the most-reported cybercrime category, with cloud infrastructure abuse a significant enabler of attack scale.

Themis flagged this message based on the combination of a first-time sender with an opaque bounce-format address, the branding inconsistencies between the body, footer, and attachment, and the malicious URL embedded in the PDF. Community intelligence across the IRONSCALES network identified the orhanpastacafe[.]com domain as part of an active impersonation campaign. Across the network, 67.5 phishing emails per 100 mailboxes per month bypass traditional secure email gateways, and authenticated messages sent through legitimate cloud infrastructure represent a growing share of that number.

This attack maps to MITRE ATT&CK T1566.001 (Spearphishing Attachment) for the PDF delivery, T1583.001 (Acquire Infrastructure: Domains) for the subdomain impersonation infrastructure, and T1036.005 (Masquerading: Match Legitimate Name or Location) for the brand-name subdomain technique.

What Defenders Should Prioritize

Subdomain impersonation is cheap to deploy and effective against both users and automated systems. Defenders should ensure their URL evaluation logic parses to the root domain, not just the full hostname. PDF inspection should include extraction of link annotations, not just JavaScript and form field analysis. And sender evaluation should weight first-time contacts with bounce-format addresses and cloud ESP infrastructure more heavily, regardless of authentication results.

The branding consistency test is one of the simplest and most effective heuristics available: does the sender match the body? Does the body match the footer? Does the footer match the attachment? When the answer to all three is "no," the message is almost certainly malicious, no matter what the authentication headers say.

Indicators of Compromise