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 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.
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.
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.
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.