You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Rule Tuning] AWS S3 Bucket Replicated to Another Account (#5405)
AWS S3 Bucket Replicated to Another Account
- updated description and IG
- added `event.type` as `event_category_override` field
- adjusted query to use `info` instead of `any` and added `Account=` instead of `Account` to help reduce chances of capturing unintended requests.
- added highlighted fields
AWS S3 Bucket Policy Added to Share with External Account
- added `event.outcome = success` to query to reduce noise from failed attempts
Co-authored-by: shashank-elastic <[email protected]>
Identifies when the `PutBucketReplication` operation is used to replicate S3 objects to a bucket in another AWS account. Adversaries may use bucket replication to exfiltrate sensitive data to an environment they control.
10
+
Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a
11
+
different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and
12
+
multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently
13
+
exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where
14
+
the configured destination account differs from the source bucket's account, indicating potential unauthorized
15
+
cross-account data movement.
11
16
"""
17
+
event_category_override = "event.type"
12
18
false_positives = [
13
19
"""
14
-
Bucket replication accross accounts is a legitimate practice in some AWS environments. Ensure that the sharing is authorized before taking action.
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.
15
23
""",
16
24
]
17
25
from = "now-6m"
18
26
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
19
27
language = "eql"
20
28
license = "Elastic License v2"
21
29
name = "AWS S3 Bucket Replicated to Another Account"
22
-
note = """
23
-
## Triage and analysis
30
+
note = """## Triage and analysis
24
31
25
32
### Investigating AWS S3 Bucket Replicated to Another Account
26
33
27
-
This rule identifies when an S3 bucket is replicated to another AWS account. While sharing bucket replication is a common practice, adversaries may exploit this feature to exfiltrate data by replicating objects to external accounts under their control.
34
+
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.
28
35
29
-
#### Possible Investigation Steps
36
+
This rule detects successful `PutBucketReplication` events and flags cases where the replication configuration specifies a destination AWS account different from the source.
30
37
31
-
- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who made the change. Verify if this actor typically performs such actions and if they have the necessary permissions.
32
-
- **Review the Sharing Event**: Identify the S3 bucket involved and review the event details. Look for `PutBucketReplication` actions where an `Account` key-value pair is included signifying replication to an external account.
33
-
- **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` fields in the CloudTrail event to identify the role used and account ID where the bucket was replicated.
34
-
- **Verify the Shared Bucket**: Check the S3 bucket that was replicated and its contents to determine the sensitivity of the data stored within it.
35
-
- **Validate External Account**: Examine the AWS account to which the bucket was replicated. Determine whether this account is known and previously authorized to access such resources.
36
-
- **Contextualize with Recent Changes**: Compare this sharing event against recent changes in S3 configurations. Look for any other recent permissions changes or unusual administrative actions.
37
-
- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.
38
-
- **Interview Relevant Personnel**: If the share was initiated by a user, verify the intent and authorization for this action with the person or team responsible for managing DB backups and snapshots.
38
+
#### Possible investigation steps
39
39
40
-
### False Positive Analysis
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.
41
44
42
-
- **Legitimate Backup Actions**: Confirm if the S3 bucket replication aligns with scheduled backups or legitimate automation tasks.
43
-
- **Consistency Check**: Compare the action against historical data of similar actions performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
- The **IAM role ARN** used for replication. (`Role=`)
49
+
- Any filtering rules (prefixes, tags) that narrow or broaden what will be replicated.
44
50
45
-
### Response and Remediation
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
46
58
47
-
- **Immediate Review and Reversal**: If the change was unauthorized, update the S3 configurations to remove any unauthorized replication rules.
48
-
- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
49
-
- **Policy Update**: Review and possibly update your organization’s policies on S3 bucket/object sharing to tighten control and prevent unauthorized access.
50
-
- **Incident Response**: If malicious intent is confirmed, consider it a data breach incident and initiate the incident response protocol. This includes further investigation, containment, and recovery.
59
+
Unrecognized accounts should be treated as a strong exfiltration signal.
51
60
52
-
### Additional Information:
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
53
68
54
-
For further guidance on managing and securing S3 buckets in AWS environments, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security.html/) and AWS best practices for security.
69
+
**Correlate with other suspicious activity**
70
+
Pivot 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**
78
+
Validate:
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**
84
+
During account restructuring or workload migration, administrators may temporarily redirect replication to new accounts.
85
+
86
+
Tuning 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/)**
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
0 commit comments