AWS S3 Bucket Replicated to Another Account

Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where the configured destination account differs from the source bucket's account, indicating potential unauthorized cross-account data movement.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/07/12"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/12/04"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a
 11different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and
 12multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently
 13exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where
 14the configured destination account differs from the source bucket's account, indicating potential unauthorized
 15cross-account data movement.
 16"""
 17event_category_override = "event.type"
 18false_positives = [
 19    """
 20    Cross-account S3 replication is common in multi-account AWS Organizations, centralized logging architectures, and
 21    disaster-recovery designs. Confirm whether the destination account is an approved replication target. Unexpected
 22    replication configuration changes should be treated as suspicious.
 23    """,
 24]
 25from = "now-6m"
 26index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 27language = "eql"
 28license = "Elastic License v2"
 29name = "AWS S3 Bucket Replicated to Another Account"
 30note = """## Triage and analysis
 31
 32### Investigating AWS S3 Bucket Replicated to Another Account
 33
 34Cross-account S3 replication enables automated copying of S3 objects into a different AWS bucket. While useful for backup and organizational data flows, adversaries may exploit it as a covert exfiltration channel. Once replication is configured, any future writes to the bucket are silently copied to the destination bucket—even if object-level access controls block the attacker’s direct downloads. For this reason, unauthorized replication configuration should be considered high-risk.
 35
 36This rule detects successful `PutBucketReplication` events and flags cases where the replication configuration specifies a destination AWS account different from the source.
 37
 38#### Possible investigation steps
 39
 40**Understand who initiated the replication change**
 41- Inspect `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify the actor.
 42- Review authentication patterns such as federated session names, role chaining via STS, or unfamiliar IAM roles.
 43- Examine `source.ip`, `source.geo` fields, and `user_agent.original` for unusual locations, automation tools, or anomalous access paths.
 44
 45**Examine the replication rule details**
 46- Inspect `aws.cloudtrail.request_parameters` for:
 47  - The **destination account ID** (`Account=`).
 48  - The **IAM role ARN** used for replication. (`Role=`)
 49  - Any filtering rules (prefixes, tags) that narrow or broaden what will be replicated.
 50
 51**Determine whether the destination account is authorized**
 52- Validate whether the destination AWS account belongs to your AWS Organization.
 53- Check internal documentation, IaC templates, or tagging standards to confirm whether replication to this account is expected.
 54- Look for prior legitimate infrastructure workflows such as:
 55  - Centralized logging
 56  - Backup/DR accounts
 57  - Cross-region compliance replicas
 58
 59Unrecognized accounts should be treated as a strong exfiltration signal.
 60
 61**Assess the scope of potential data exposure**
 62- Determine whether the bucket contains sensitive or regulated data (PII, financial records, secrets, logs, etc.).
 63- Identify whether object versioning, lifecycle rules, or access logging were modified recently.
 64- Check for preceding or subsequent actions such as:
 65  - `PutBucketPolicy` updates granting new principals access
 66  - Creation or modification of IAM roles tied to replication
 67  - `DeleteObject` or `PutObjectRetention` attempts that might pair with exfiltration
 68
 69**Correlate with other suspicious activity**
 70Pivot in CloudTrail on the same principal or same bucket:
 71- Prior reconnaissance such as `ListBuckets`, `GetBucketReplication`, or `GetBucketPolicy`
 72- Modification of KMS policies or unexpected encryption key usage
 73- New access patterns from external IP addresses or unusual automation
 74
 75### False positive analysis
 76
 77**Legitimate cross-account replication**
 78Validate:
 79- The destination account belongs to a known OU or business unit
 80- The replication role ARN matches expected automation
 81- The change aligns with documented deployment or maintenance schedules
 82
 83**Temporary migrations or transitions**
 84During account restructuring or workload migration, administrators may temporarily redirect replication to new accounts.
 85
 86Tuning options:
 87- Exception lists based on IAM role ARNs
 88- Tag-based environment scoping
 89- Change-window-based suppression
 90
 91### Response and remediation
 92
 93**Contain potential exfiltration**
 94- Remove or update replication rules to eliminate unauthorized destinations.
 95- Disable or restrict the replication IAM role until the investigation is complete.
 96- Review S3 object access logs to determine whether data has begun replicating to the external account.
 97
 98**Investigate scope and impact**
 99- Identify the volume and types of data at risk of replication.
100- Determine whether the external bucket shows successful replication traffic (if logs or access are available).
101- Assess whether the actor also modified bucket policies, encryption settings, or KMS keys.
102
103**Credential and role hygiene**
104- Rotate credentials for the initiating user or role if compromise is suspected.
105- Review IAM role trust policies, especially if STS sessions or EC2 role assumptions were involved.
106- Enable MFA and tighten conditions for administrative roles capable of modifying replication.
107
108**Hardening and preventive controls**
109- Enforce SCPs that restrict cross-account replication except for explicitly approved destinations.
110- Require approval workflows before modifying replication or retention settings.
111- Use AWS Config and Security Hub controls to detect:
112  - Buckets with unexpected replication rules
113  - Newly added cross-account permissions
114  - Changes to bucket policies, block-public-access settings, or KMS key policies
115
116### Additional information
117
118- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
119- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
120- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
121"""
122references = [
123    "https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-walkthrough-2.html/",
124    "https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketReplication.html/",
125]
126risk_score = 47
127rule_id = "d488f026-7907-4f56-ad51-742feb3db01c"
128severity = "medium"
129tags = [
130    "Domain: Cloud",
131    "Data Source: AWS",
132    "Data Source: Amazon Web Services",
133    "Data Source: AWS S3",
134    "Resources: Investigation Guide",
135    "Use Case: Threat Detection",
136    "Tactic: Exfiltration",
137]
138timestamp_override = "event.ingested"
139type = "eql"
140
141query = '''
142info where event.dataset == "aws.cloudtrail"
143   and event.action == "PutBucketReplication"
144   and event.outcome == "success"
145   and stringContains(aws.cloudtrail.request_parameters, "Account=")
146'''
147
148
149[[rule.threat]]
150framework = "MITRE ATT&CK"
151[[rule.threat.technique]]
152id = "T1537"
153name = "Transfer Data to Cloud Account"
154reference = "https://attack.mitre.org/techniques/T1537/"
155
156
157[rule.threat.tactic]
158id = "TA0010"
159name = "Exfiltration"
160reference = "https://attack.mitre.org/tactics/TA0010/"
161
162[rule.investigation_fields]
163field_names = [
164    "@timestamp",
165    "user.name",
166    "user_agent.original",
167    "source.ip",
168    "aws.cloudtrail.user_identity.arn",
169    "aws.cloudtrail.user_identity.type",
170    "aws.cloudtrail.user_identity.access_key_id",
171    "aws.cloudtrail.resources.arn",
172    "aws.cloudtrail.resources.type",
173    "target.entity.id",
174    "event.action",
175    "event.outcome",
176    "cloud.account.id",
177    "cloud.region",
178    "aws.cloudtrail.request_parameters",
179]

Triage and analysis

Investigating AWS S3 Bucket Replicated to Another Account

Cross-account S3 replication enables automated copying of S3 objects into a different AWS bucket. While useful for backup and organizational data flows, adversaries may exploit it as a covert exfiltration channel. Once replication is configured, any future writes to the bucket are silently copied to the destination bucket—even if object-level access controls block the attacker’s direct downloads. For this reason, unauthorized replication configuration should be considered high-risk.

This rule detects successful PutBucketReplication events and flags cases where the replication configuration specifies a destination AWS account different from the source.

Possible investigation steps

Understand who initiated the replication change

  • Inspect aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.access_key_id to identify the actor.
  • Review authentication patterns such as federated session names, role chaining via STS, or unfamiliar IAM roles.
  • Examine source.ip, source.geo fields, and user_agent.original for unusual locations, automation tools, or anomalous access paths.

Examine the replication rule details

  • Inspect aws.cloudtrail.request_parameters for:
    • The destination account ID (Account=).
    • The IAM role ARN used for replication. (Role=)
    • Any filtering rules (prefixes, tags) that narrow or broaden what will be replicated.

Determine whether the destination account is authorized

  • Validate whether the destination AWS account belongs to your AWS Organization.
  • Check internal documentation, IaC templates, or tagging standards to confirm whether replication to this account is expected.
  • Look for prior legitimate infrastructure workflows such as:
    • Centralized logging
    • Backup/DR accounts
    • Cross-region compliance replicas

Unrecognized accounts should be treated as a strong exfiltration signal.

Assess the scope of potential data exposure

  • Determine whether the bucket contains sensitive or regulated data (PII, financial records, secrets, logs, etc.).
  • Identify whether object versioning, lifecycle rules, or access logging were modified recently.
  • Check for preceding or subsequent actions such as:
    • PutBucketPolicy updates granting new principals access
    • Creation or modification of IAM roles tied to replication
    • DeleteObject or PutObjectRetention attempts that might pair with exfiltration

Correlate with other suspicious activity Pivot in CloudTrail on the same principal or same bucket:

  • Prior reconnaissance such as ListBuckets, GetBucketReplication, or GetBucketPolicy
  • Modification of KMS policies or unexpected encryption key usage
  • New access patterns from external IP addresses or unusual automation

False positive analysis

Legitimate cross-account replication Validate:

  • The destination account belongs to a known OU or business unit
  • The replication role ARN matches expected automation
  • The change aligns with documented deployment or maintenance schedules

Temporary migrations or transitions During account restructuring or workload migration, administrators may temporarily redirect replication to new accounts.

Tuning options:

  • Exception lists based on IAM role ARNs
  • Tag-based environment scoping
  • Change-window-based suppression

Response and remediation

Contain potential exfiltration

  • Remove or update replication rules to eliminate unauthorized destinations.
  • Disable or restrict the replication IAM role until the investigation is complete.
  • Review S3 object access logs to determine whether data has begun replicating to the external account.

Investigate scope and impact

  • Identify the volume and types of data at risk of replication.
  • Determine whether the external bucket shows successful replication traffic (if logs or access are available).
  • Assess whether the actor also modified bucket policies, encryption settings, or KMS keys.

Credential and role hygiene

  • Rotate credentials for the initiating user or role if compromise is suspected.
  • Review IAM role trust policies, especially if STS sessions or EC2 role assumptions were involved.
  • Enable MFA and tighten conditions for administrative roles capable of modifying replication.

Hardening and preventive controls

  • Enforce SCPs that restrict cross-account replication except for explicitly approved destinations.
  • Require approval workflows before modifying replication or retention settings.
  • Use AWS Config and Security Hub controls to detect:
    • Buckets with unexpected replication rules
    • Newly added cross-account permissions
    • Changes to bucket policies, block-public-access settings, or KMS key policies

Additional information

References

Related rules

to-top