Intermediate Business Lab 
aws
Exfiltrate Secrets via Amazon SNS Abuse
Automations like Amazon SNS are easily overlooked when it comes to securing cloud platforms, and can be a route for attackers to exfiltrate sensitive data without triggering alarms!
Overview
This hands-on lab guides students through the process of understanding this attack technique and implementing defenses against AWS SNS service abuse for data exfiltration by gaining practical experience that emphasizes real-world scenarios and provides students with both the technical knowledge and practical skills needed to identify and mitigate similar cloud service exploitation techniques.
Scenario
Huge Logistics operates a centralized internal portal where DevOps Engineers manage API secrets via AWS Secrets Manager, providing a single point of control for sensitive credential management across their cloud infrastructure. An attacker compromised a Huge Logistics DevOps Engineer's AWS access keys found on a public GitHub repository, unfortunately a common oversight, that provides the initial foothold into the organization's cloud environment. Using these legitimate credentials, the attacker then performs systematic reconnaissance across the multiple AWS services including IAM, Secrets Manager, Lambda, and SNS, methodically mapping the organization's cloud architecture and identifying potential attack vectors.
Lab prerequisites
- Good understanding of AWS services (IAM, SNS, Lambda and Secret manager)
- An external email address (e.g. GMail)
- Basic understanding of AWS CLI Commands
- Basic understanding of API endpoints
Learning outcomes
- Understand how attackers can abuse legitimate AWS SNS services and automated lambda workflow for data exfiltration.
- Understand how a compromised AWS access key with broad permissions enables data exfiltration.
- Learn defensive strategies to prevent SNS-based exfiltration.
Real-world context
This lab mirrors real-world cloud security incidents where attackers exploit overlooked AWS services such as SNS to exfiltrate sensitive data without triggering alarms. Many web applications rely on SNS for sending notifications, and when developers overlook what is included in these messages, they risk exposing sensitive data to unverified endpoints. In environments with misconfigured IAM policies and limited monitoring of notification services, SNS becomes an attractive target for sophisticated threat actors who recognize its potential as a covert communication channel.
Attackers leverage SNS's deep integration into automated workflows and its broad permissions to silently deliver confidential information outside the organization. The service's legitimate business purpose provides perfect cover for malicious activity, as data exfiltration disguised as routine notifications rarely raises suspicions among security teams focused on traditional attack vectors like direct database access or file transfers. This technique has proven particularly effective because most organizations implement robust monitoring for their databases and storage systems while neglecting to scrutinize the content and recipients of their notification streams, creating a blind spot that experienced adversaries are quick to exploit.
KEY TAKEAWAY
A messaging service is an exfiltration channel with delivery guarantees. Subscribing an external endpoint to a topic means the platform forwards every future message to the attacker automatically, with no repeated access and nothing that resembles data being downloaded.
What this lab covers
You enumerate messaging infrastructure in an AWS account, identify a topic whose policy allows more than intended, and demonstrate how a subscription turns internal messages into an ongoing outbound feed.
The lab then covers the defensive side, because this technique is defeated by policy and detection rather than by any product feature, and the detection is straightforward once you know what to watch.
It is rated intermediate and suits anyone building detections for AWS, since it is a good example of exfiltration that volume-based data loss monitoring will not see.
How SNS subscription exfiltration works
Amazon SNS delivers messages published to a topic out to every subscribed endpoint. Endpoints can be queues, functions, email addresses or HTTP endpoints, and the last two can point outside the account entirely.
Subscribing is a one-time configuration action. After that, the platform performs the delivery, so the attacker makes no further API calls and does not read any data directly. Everything that flows through the topic afterwards arrives at their endpoint as a normal, retried, reliable delivery.
What makes it valuable is what topics carry. Application events, notifications and operational messages frequently include identifiers, personal data and occasionally credentials, because the topic was designed as an internal channel and treated as trusted.
How to detect this in your own environment
Alert on subscription creation, particularly for HTTP and email endpoints, and above all where the endpoint is outside your organization. This is a control plane event recorded by default and it is rare enough to review individually.
Reconcile subscriptions against an inventory of expected endpoints. As with replication destinations, the question is not whether subscriptions exist but whether each one belongs to you.
Watch for topic policy changes that broaden who may subscribe, which is the preparation step when the existing policy does not already permit it.
How to prevent it
Scope topic policies so that only specific principals within your organization may subscribe. Broad subscribe permissions are commonly granted during development and rarely revisited.
Use service control policies to deny subscriptions to endpoints outside your organization, which removes the capability rather than relying on detecting its use.
Reconsider what goes into messages. Topics frequently carry more sensitive content than intended because they were treated as internal, and reducing the payload limits the value of any exfiltration channel.
Real-world context
Abusing a platform's own delivery mechanisms for exfiltration is an established pattern, because it inherits the platform's reliability and blends with legitimate configuration. Replication, notification and integration features are all attractive for the same reason.
It also defeats a common assumption in monitoring. Controls built around volume of data read by an identity do not fire, because the attacker read nothing. The only anomaly is a single configuration change followed by ongoing platform-performed delivery.
The pattern maps to MITRE ATT&CK T1537 Transfer Data to Cloud Account and T1567 Exfiltration Over Web Service.
Applying this at work
- List every SNS subscription across your accounts and confirm each endpoint belongs to you.
- Review topic policies for broad subscribe permissions and scope them to named principals.
- Add a service control policy denying subscription endpoints outside your organization.
- Alert on subscription creation for HTTP and email endpoints.
- Review what your topics actually carry, on the assumption that anyone subscribed reads all of it.
Frequently asked questions
How does subscribing to a topic exfiltrate data?
Once an endpoint is subscribed, AWS delivers every subsequent message to it automatically. The attacker performs one configuration action and then receives data continuously without making any further API calls.
Why is this hard to detect with data loss monitoring?
Because no data is read by the attacker's identity. The platform performs the delivery, so controls built around volume of reads or downloads by a principal see nothing unusual.
What is the most effective control?
Restricting who may subscribe, ideally with an organization-level policy denying endpoints outside your accounts, combined with alerting on subscription creation. Both are cheap and neither depends on inspecting message contents.
Do I need my own AWS account to practice this?
No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.
Which certification covers this in depth?
The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack and detection paths in full, including IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.
.png)
Cloud Security Training To Protect Your Business
Pwned Labs for Business gives your team access to dedicated business content, including labs and cyber ranges.
We also offer in-person or remote workshops, and our cloud penetration services are helping businesses become more secure!