Abusing the Replicator: Silently Exfiltrating Data with the AWS S3 Replication Service

Cyber attackers are increasingly gaining access to cloud control planes, which include capabilities to perform cloud-native backups. Here, I’ll show how these tools can be leveraged to exfiltrate data from across an organization’s production environment.

In this blog, you'll look closely at how an attacker can abuse S3 Replication to efficiently migrate your data out of your environment. I hope you find it as entertaining to read as it was to create.

You will see this attack played out in separate narrative arcs from the perspective of four different actors listed here.

• The S3 Replication Service, as it benignly follows orders dictated as replication rules to replicate S3 data across buckets.
• The Evil S3 Replication Service, as its powers are abused to copy data to external locations.
• The attacker who gains controls of the S3 Replication Service, coopting the service for evil and using its lack of logging to stay under the radar.
• Members of the SOC team (security operations centers) who learn that they are partially blind to data movement via the S3 Replication Service but can now change their detection strategy to compensate.

Introducing the S3 Replication Service, its capabilities and use cases for good

The AWS S3 Service is no longer the 'Simple Storage Service' it was made out to be. With dozens of features and integrations, it has become the data store of choice for enterprise AWS customers. It’s also so complicated that it is difficult to understand and thus secure all its capabilities. One of S3's numerous features is the capability to create and manage backups, across regions and accounts.

What are the consequences if an attacker gains the ability to use S3 Replication in AWS?

Cross-account replication can assist organizations in recovery from a data-loss event. In the wrong hands, however, the replication service allows threat actors to siphon off data to untrusted locations.

How does the S3 Replication Service log its activities? And how does that aid an attacker in going unnoticed?

The authorized movement of data via the S3 Replication Service is less than transparent making it especially difficult to hunt for data exfiltration, enabling an attacker to hide their activity in plain sight within your cloud environment.

What are the consequences for cloud defenders, and can they change tactics to compensate for the lack of visibility into S3 Replication?

Theat hunters can use the malicious updating of replication rules as a clue that data exfiltration may silently be occurring in their environment.

The S3 Replication Service can be used to help organizations become more ransomware resilient but it’s important when building out our threat model to craft evil user stories to help us view cloud capabilities from the viewpoint of an attacker. The Replication Service insufficiently logs destination buckets when Replication Time Control (RTC) is configured making the job of defending one’s data perimeter that much more difficult. As of June 2022, AWS had declined to fix the logging issue with the S3 Replication service, and it continues to exhibit the same behaviors.

Reporting Timeline

10/19/21 - [Vectra]: Initial vulnerability report submitted, and receipt acknowledged same day.

10/20/21 - [AWS]: Responded with their indication that they do not believe this to be a vulnerability: “We do not believe the behavior you describe in this report presents a security concern, rather, it is expected behavior. We offer CloudWatch alarming that will log any changes made to a bucket's replication policy[1], which would give visibility into the destination of the data for the threat model described. See the section detailing "S3BucketChangesAlarm". [1] https://docs.aws.amazon.com/awscloudtrail/latest/userguide/awscloudtrail-ug.pdf

10/20/21 - [Vectra]: Requested confirmation that AWS does not consider the lack of logging a vulnerability. Indicated that I will depict AWS response to this report as ‘won’t fix’ in any public disclosure.

10/26/21 - [AWS]: AWS asked where I would publish the disclosure and if they could have an advance copy of the text.

10/26/21 - [Vectra]: Acknowledged they could receive an advance copy of any public disclosure.

2/2/22 - [Vectra]: Re-sent the original vulnerability report to an internal contact on the AWS Security team suggesting they put in a request for enhanced logging on the S3 replication service.

2/3/22 - [AWS]: Acknowledged they put in the ticket internally.

‍