Perfect Auth for a Venue, Zero Ledger Connection

Every authentication check on this message passed. SPF passed. DKIM passed twice, on two independent signatures. DMARC passed, aligned, against the domain in the visible From header.

None of it had anything to do with Ledger, the hardware-wallet brand whose product language and firmware pretext filled the body.

The passes belonged to an Australian events venue: a real function-hire business running its own domain, with a correctly verified transactional sending subdomain behind it. It has no connection to cryptocurrency, and it is the second victim here, not the attacker.

The Passes Were Real, and They Were Earned Somewhere Else

This was no misalignment trick or shared-hosting quirk, and the raw headers confirm it. The envelope sender was a subdomain beneath the venue's transactional sending subdomain, authorizing an Amazon SES outbound address in Amazon's Tokyo region, so SPF passed. Two DKIM signatures verified: one on the venue's own sending subdomain with a selector named after Resend (a transactional email API layered on SES), and one from Amazon SES itself. DMARC passed on the venue's apex domain. Nothing failed anywhere.

That Resend selector is the detail worth sitting with. A platform-specific DKIM selector on a subdomain is not inherited passively: it exists because someone published the platform's DKIM and SPF records inside that DNS zone and completed a verification flow. Deliberate configuration, not a broad include: any mailbox on a shared host could borrow.

The subject line did not match the body. It read as a short, generic firmware announcement, while the rendered HTML was a wallet-verification notice with an artificial deadline just under three weeks out. That is not sloppiness: a bland technical subject gives string matching nothing to grip, while the real pretext waits where only a human reads it. This is T1566.002, Spearphishing Link, with the sender alias performing T1656, Impersonation.

Three Ways to Get That Subdomain, One Set of Headers

What the record cannot settle is more useful here than a clean answer would have been.

There are at least three ways to arrive at these headers. The venue's own sending-platform account could have been taken over, so the attacker sends as an existing verified identity. Or the attacker controlled the DNS zone and verified a sending subdomain of their own, never touching that account. Or the compromise sits further up, at the registrar. All three produce a clean, aligned pass, and nothing in the message separates them.

The response is not the same for each. The first is answered by rotating platform API keys and auditing the sending identities on the account. The second by walking the DNS zone for records nobody on your side created, a check almost nobody runs on a schedule. The third needs registrar credential resets and a registry lock, and it invalidates the other two answers. The apex domain's registry record was updated roughly nine days before the send, which is suggestive, but such updates are also routine.

Neither you nor the abused organization can tell which of the three happened, so both the platform account and the zone have to be examined. T1036.005, Match Legitimate Name or Location, describes the outcome either way.

Every Hop but the Last One Stayed on the Venue

The body carried one button, asking the reader to verify their wallet, and its immediate destination was not the credential page. It pointed at the sending platform's click-tracking hostname on the venue's own subdomain, with the next hop percent-encoded into the path. That next hop was a web hostname on the venue's apex domain, carrying a clean verdict. Only after that was the chain intended to reach the harvesting domain. A one-pixel open beacon on the same account rode alongside it.

Follow that chain the way a cautious recipient or a shallow control would, and it keeps returning the venue. Hover the button, you see the venue. Check reputation, you find a legitimate Australian business. Unwrap one layer, still the venue, still clean. Delivery identity and payload identity were decoupled, and every artifact a hurried check reaches belongs to the first.

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

A Landing Page Nobody Got to See

The intended final destination was a single transposition of the wallet brand, two adjacent interior letters swapped, on a low-cost generic top-level domain. It sat behind a content delivery network, and a WHOIS query returned no public record at all.

At scan time it answered with an HTTP 521, the code a CDN returns when the origin behind it is unreachable, so the page was never rendered. No screenshot of a form, no captured field names, no confirmed harvesting flow.

It still carried a malicious verdict, and it should, because the evidence does not depend on reachability. The one call to action in a message impersonating a hardware-wallet vendor pointed at a deliberate misspelling of that vendor's name, on infrastructure with no registration history, behind a chain laundered via an unrelated business.

What Was Left to Judge

Strip authentication out of the evidence pool and the rest is short but sufficient: a first-time sender, a cryptocurrency brand asserted over an events venue's domain, a subject contradicting its own body, a deadline, and one wrapped link ending in a misspelling of that brand.

That is what caught it. Themis scored the message at 82% confidence with a credential-theft label, flagged the link as malicious, and the incident was automatically resolved as phishing with no explicit mitigation action recorded. Relationships between a brand, a domain and a destination are what Adaptive AI reads once the header block has stopped being informative.

The 2026 Verizon Data Breach Investigations Report puts phishing at 16% of breach initial access vectors and credentials in 39% of breaches across the full kill chain. That is why a credential harvesting page behind a clean sending channel beats any attachment.

Controls That Survive a Clean Header

Compare the brand asserted in the display name against the domain that authenticated, and alert when a financial or cryptocurrency brand appears over an unrelated commercial domain. No authentication mechanism performs that comparison, and RFC 9989 never claimed to. A passing DMARC result is provenance, not intent.

Resolve click-tracking wrappers to the terminal hostname and judge that, not the wrapper and not the first hop. A chain holding one reputable domain for two hops and then leaving it is the shape to look for. Score edit distance against the brands named in the message too, since that works whether or not the destination is up.

If your own domain sends through a transactional platform, inventory the sending subdomains and platform identities under it and confirm you created each. The CISA phishing guidance argues for layered controls, and the NIST definition of phishing is about deceiving a reader, which no DNS record attests to.

Indicators of Compromise

The Bottom Line

This message is trustworthy by every measure a protocol can express. The signatures are valid, the alignment is real, and the DNS work behind them was done properly by a function venue that has never sold a hardware wallet. Authentication answered who was allowed to submit the mail. Nobody asked whether the brand in the body, or the domain at the end of the link, had anything to do with that answer.