SNS subscription hijack: one rogue subscriber copies every message
Add one off-domain endpoint to a sensitive SNS topic and you quietly receive every message, then publish spoofed lures to all the real subscribers. Two harms, one Subscribe call.
An SNS topic fans every published message out to every subscriber. Add one rogue subscriber and all of that traffic is silently copied to the attacker, and a single publish reaches the entire distribution list. It is interception and phishing from the same foothold.
How the attack works
With sns:Subscribe permission, the attacker attaches an external HTTPS or email endpoint to a sensitive topic such as security alerts or transaction notifications. The endpoint auto-confirms, and SNS begins delivering every message, including links and account context, to the attacker alongside the legitimate subscribers. With the audience subverted, the attacker also calls sns:Publish to send a crafted message styled as an internal security notice, fanning a phishing lure out to all real subscribers. Multiple subscribers, successful delivery, and ordinary publishes are all normal operation, so none of those is the tell. CloudTrail records the Subscribe and Publish calls and the endpoint, and SNS delivery logs show what reached the rogue endpoint, which is how you confirm a subscription to a domain that is not on the approved list. In ATT&CK terms this is T1098, Account Manipulation, with T1566, Phishing.
Why it works
Subscribe permission was granted too broadly, and the topic policy did not constrain which protocols or endpoint domains were allowed to subscribe. The topic happily accepted an arbitrary off-domain endpoint.
How to fix it
Do not reset an owner’s password, which does nothing to the subscription. First unsubscribe the rogue endpoint, then lock the topic so it cannot recur: tighten the access policy and restrict sns:Subscribe and sns:Publish to approved principals and endpoints, and deny the abused principal’s session by aws:TokenIssueTime. The teaching move is to audit every topic for off-domain subscribers and constrain allowed endpoint domains in topic policy, because this topic is rarely the only one exposed.
Practice it
We built this as a GraphLattice Range scenario so responders handle both harms, the intercepted content and the outbound phishing lure, not just one.