Sharing this one because it landed in a client's inbox this morning and I think it's a great teaching example — it bypasses pretty much every traditional email security control without ever spoofing a sender, faking a domain, or using a malicious link.

What the user saw

A typical-looking refund scam:

"Congratulations, your Amazon Audible Gold has been renewed for $490. To manage billing or cancel, call 828-316-2115..."

What made it weird is that the email was actually from no-reply@sns.amazonaws.com. Real Amazon infrastructure. Signed, DKIM-aligned, all the auth headers green. The subject line was the giveaway: "AWS Notification - Subscription Confirmation."

How the attack works

AWS Simple Notification Service (SNS) is a pub/sub messaging service. When you create a topic and add an email address as a subscriber, AWS sends that address a confirmation email containing the topic's ARN (Amazon Resource Name) and a "Confirm subscription" link.

The attacker abuses two facts:

1. SNS topic names can be quite long (256 characters)
2. The topic ARN is rendered prominently in the body of the confirmation email

So they create a topic named something like:

Congratulations-Amazon-Audible-Gold-extended-2-more-years-490-USD-renewal-processed-member-only-deals-...-call-828-316-2115

Then they subscribe the victim's email to it. AWS does what AWS is supposed to do and sends a perfectly legitimate confirmation email. The "scam" lives entirely inside the topic name. The phone number is the real payload.

Why it's clever

• Sender is genuinely Amazon. Not a lookalike domain, not a spoof.
• SPF, DKIM, DMARC all pass. There's nothing for upstream filters to fail on.
• No malicious link. The Confirm Subscription URL really does point at sns.us-east-2.amazonaws.com.
• The attack vector is voice. They want the victim to panic about the charge and call the number, where the actual fraud — fake refund flow, remote access tool, gift cards, wire transfer — happens off-email entirely.

Traditional email security is looking for bad senders, bad links, suspicious attachments. None of those exist here. It's a callback phishing attack wearing AWS's clothes.

What to tell users

• Don't click Confirm subscription
• Don't call the number
• Delete the email
• If you didn't click or call, no further action needed

What admins can do

• Report to abuse@amazonaws.com (limited impact, but it's the right channel)
• Add callback phishing examples to your security awareness training — these don't look like the phishing emails users have been trained to spot
• If your users don't legitimately receive SNS notifications, a transport rule that quarantines messages from no-reply@sns.amazonaws.com is reasonable. If they do, a content rule looking for marketing/urgency language inside SNS topic ARNs is more surgical
• For Zoho Mail admins specifically — the Spam Control content filters can pattern-match on subject + body strings, so a rule keying off "AWS Notification - Subscription Confirmation" combined with high-risk keywords in the body (renewal, congratulations, phone number patterns) is a workable layer

Discussion

Has anyone else run into this lately? Curious whether others are seeing it scale up, and what you're doing for users who legitimately need AWS notifications in their inbox. The dual-use nature of sns.amazonaws.com makes this a harder problem than the usual "just block the sender."