Abuse S3 Replication and Batch Ops to Exfiltrate Data

What this lab covers

You enumerate what your credentials permit, discover that configuration rights over storage are as valuable as read rights, and use two native data management features to move both future and existing objects out of the account.

The lesson is about detection blind spots. Almost everyone monitors for large volumes of object reads, and this technique produces very few. The suspicious event is a single configuration change, and configuration changes are usually reviewed weekly rather than watched in real time.

It suits anyone building cloud detections as much as anyone testing them, and no prior AWS experience is required.

How replication and batch operations enable exfiltration

S3 replication copies objects from a source bucket to a destination automatically, and the destination can be a bucket in a different AWS account. It is a supported feature built for resilience and compliance, and once configured it operates continuously without further involvement from whoever set it up.

The critical property is who performs the copy. Replication runs under a service role, so the objects are read by AWS on behalf of the configuration, not by the attacker's identity. An attacker who never issues a read call does not appear in read-based detections at all.

Replication only covers objects written after it is configured, which is where batch operations come in. Batch operations apply an action across an existing inventory, so the two together handle future and historical data respectively. Both are ordinary features doing exactly what they are designed to do.

How to detect this in your own environment

Alert on replication configuration changes. This is a management event recorded by default, it is rare in normal operations, and a replication rule pointing at a destination outside your organization should be treated as an incident rather than a finding.

Watch for role creation and policy changes that grant replication permissions, since the attacker generally has to create or modify a service role first. That preparation step is often more visible than the configuration change itself.

Reconcile destinations against an allow list of accounts you own. The question is not whether replication exists but whether every destination belongs to you, and that check is cheap to automate and rarely performed.

How to prevent it

Use service control policies to deny replication to destinations outside your organization. This is the strongest control available because it removes the capability rather than detecting its use, and legitimate cross-organization replication is rare enough to handle by exception.

Separate configuration rights from data rights when scoping IAM. Teams reason carefully about who can read a bucket and then grant bucket configuration permissions freely, without registering that the second is a superset of the first.

Restrict who can create roles that S3 can assume. The service role is the mechanism that makes this work, so controlling role creation and the passing of roles to services constrains the whole technique.

Real-world context

Using a platform's own data movement features for exfiltration is an established pattern, because it inherits the platform's reliability and blends with legitimate administrative activity. Backup, replication and synchronisation features are attractive for exactly the reasons they were built.

It also defeats a common assumption in data loss monitoring. Controls oriented around volume of reads or egress from a known identity do not fire when the platform performs the copy under a service role, and the total data moved may be substantial while the attacker's own API activity is negligible.

The pattern maps to MITRE ATT&CK T1537 Transfer Data to Cloud Account and T1530 Data from Cloud Storage Object.

Applying this at work

• List every replication rule across your buckets and confirm each destination is an account you own.
• Add a service control policy denying replication destinations outside your organization.
• Alert on replication configuration changes and on batch operation job creation.
• Review which identities hold bucket configuration permissions, separately from those holding read permissions.
• Test whether your data exfiltration detection would fire on a replication-based copy. For most teams it will not.

Frequently asked questions

Why is replication harder to detect than downloading objects?

Because the copy is performed by AWS under a service role rather than by the attacker's identity. Detections built around volume of object reads by a principal see almost nothing, since the attacker only made one configuration change.

Can S3 replication target another AWS account?

Yes, cross-account replication is a supported feature and a legitimate pattern for backup and compliance. That is precisely why the destination account matters more than the existence of the rule.

What are S3 Batch Operations used for here?

Replication only applies to objects written after it is configured. Batch operations apply an action across an existing object inventory, which covers the historical data that replication alone would miss.

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 data exfiltration and privilege escalation paths in full, and is assessed hands-on in a live AWS account.