A Homoglyph Brand Spoof Rode Amazon SES and S3

The message that reached a member of an international commercial bank's IT leadership office looked like routine paperwork: a Final Distribution Payment notice, waiting for an eSign review, from an account manager at a logistics and maritime company the bank appeared to do business with. It carried a real signature block, a plausible reference number, and a single Review button. It also passed every email authentication check a receiving server could run. And almost none of that was what it seemed.

Start with the sender name, because the first deception was hiding in plain sight. The word that read as eSign in the subject line did not use the Latin letter e. It used a Cyrillic character that renders identically in most fonts. The reference tag that read as REF ID used the same trick. The displayed brand domain swapped a Latin o for its Cyrillic twin. To a person skimming an inbox, the spelling was flawless. To a filter matching on the real brand's name or domain, the strings simply did not match anything on a watchlist, because underneath the identical-looking glyphs they were different characters entirely.

Authenticated, because the attacker owned the domain

Here is the part that trips up an auth-only mindset. This message passed SPF, DKIM, and DMARC cleanly. It was not spoofing anyone's mail server. It was genuinely sent through Amazon Simple Email Service from a domain the attacker controlled, with valid records published for that domain. SPF passed against the SES sending infrastructure, DKIM was aligned to both the sender domain and Amazon's signing domain, and DMARC passed on the strength of that alignment.

Authentication answers one narrow question: did this domain really send this message? The answer was yes. What authentication never claims to answer is whether the domain deserves your trust in the first place. The sending domain had been registered roughly five and a half months before the email arrived, through a registrar that shielded the registrant behind privacy protection. A young, anonymous domain sending through a reputable provider is a well-worn pattern, and it is one that passes authentication every time precisely because the attacker did the paperwork honestly.

The link hid behind Amazon's own infrastructure

The single Review CTA is where the operation showed its ambition. Rather than link straight to an attacker-registered site, the button pointed first at an Amazon click-tracking redirector, the same kind of engagement-tracking wrapper legitimate SES senders use. From there it forwarded to a static HTML page hosted in an Amazon S3 storage bucket. No standalone malicious domain appeared anywhere in the chain. The credential-harvest landing page lived inside general-purpose cloud storage, fronted by a provider redirect, both of them carrying the kind of trusted reputation and valid certificates that reputation-only filters hesitate to touch.

This is living off trusted infrastructure, and it is deliberate. When the delivery path, the tracking hop, and the hosting layer are all owned by a major cloud provider, there is nothing obviously bad to block without risking collateral damage to legitimate traffic. The attack borrows credibility at every stage.

The signature block did the social engineering

The body itself was light on text and heavy on props. Three image attachments, all scanned clean, served as template and logo assets to dress the message as a real transactional notice. The payload was entirely link-based. What sold it was a fabricated signature block impersonating an account manager at the logistics firm, complete with a link to a genuine LinkedIn profile. That real profile is the social-proof anchor: a curious recipient who checks the name finds a real person at a real company and relaxes. The identity was borrowed, the relationship was invented, and the LinkedIn link made the fiction verifiable in the worst way.

Full auth pass, still not clean

For all its authentication hygiene, the message did not sail through untouched. The receiving organization's anti-spam stack scored it at SCL 8, near the top of the confidence scale, and quarantined it. When the actual landing-page link was analyzed, it came back with a mixed, partial-malicious verdict rather than a clean pass. The signals that mattered were behavioral and contextual: a homoglyph-built brand name, a freshly registered privacy-shielded sender, a single link laundered through cloud redirection, and a payment-review pretext aimed at one senior recipient. None of those are authentication failures. All of them are risk.

That gap is the whole lesson. The 2024 Verizon Data Breach Investigations Report put phishing in 15% of all breaches and measured the median time to click a phishing link at 21 seconds. When a lure is this well dressed and the sender authenticates cleanly, that 21-second window is the entire fight. Detection has to reason about the message the way our Adaptive AI does, weighing sender age, brand-string anomalies, redirect behavior, and landing-page reputation together, rather than clearing anything that clears SPF, DKIM, and DMARC. Because the credential page behind that Review button was built to take over an account, layered account takeover protection is what contains the damage if a click gets through. And the distance between what a gateway verifies and what actually endangers your users is worth measuring directly, which is exactly what our SEG email security gap analysis is built to surface.

Indicators of Compromise

Authentication summary: SPF pass, DKIM pass (aligned), DMARC pass. Anti-spam disposition: SCL 8, quarantined. Homoglyph note: Cyrillic characters substituted for Latin e and o in the subject line and the displayed brand domain.

MITRE ATT&CK mapping

• T1566.002 (Phishing: Spearphishing Link): a single cloud-laundered Review link as the sole payload.
• T1583.001 (Acquire Infrastructure: Domains): a purpose-registered, privacy-shielded sending domain built to authenticate cleanly.
• T1204.001 (User Execution: Malicious Link): the attack depends on the recipient clicking through to the hosted page.
• T1585.002 (Establish Accounts: Email Accounts): an Amazon SES sending identity stood up specifically for the campaign.

See you next time

Clean authentication is table stakes, not a verdict. The attacks worth studying are the ones that pass every check you already trust, dress themselves in letters that look right, and hide behind infrastructure you would never blocklist. Look at the sender's age, the shape of the link, and where it actually lands, not just whether the headers verify.