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 RDS DB Snapshot Shared with Another Account (#5418)
This rule is performing well in telemetry and producing alerts as expected for both explicit external account sharing and making snapshots public. Both scenarios tested.
- updated description, FP and IG
- added highlighted fields
- added `event.type` as `event_category_override` field because `event.category` is not populated for these events.
Co-authored-by: shashank-elastic <[email protected]>
Identifies an AWS RDS DB snapshot being shared with another AWS account. DB snapshots contain a full backup of an entire DB instance including sensitive data that can be abused if shared with unauthorized accounts or made public. Adversaries may use snapshots to restore a DB Instance in an environment they control as a means of data exfiltration.
10
+
Identifies when an AWS RDS DB snapshot is shared with another AWS account or made public. DB snapshots contain complete
11
+
backups of database instances, including schemas, table data, and sensitive application content. When shared externally,
12
+
snapshots can be restored in another AWS environment, enabling unauthorized access, offline analysis, or data
13
+
exfiltration. Adversaries who obtain valid credentials or exploit misconfigurations may modify snapshot attributes to
14
+
grant access to accounts they control, bypassing network, IAM, and monitoring controls.
11
15
"""
16
+
event_category_override = "event.type"
12
17
false_positives = [
13
18
"""
14
-
DB snapshot sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action.
19
+
Cross-account DB snapshot sharing is common in multi-account AWS Organizations, particularly for backup workflows,
20
+
migrations, analytics pipelines, and disaster recovery. Ensure the added account is expected, previously approved,
21
+
and aligns with operational change plans before taking action.
15
22
""",
16
23
]
17
24
from = "now-6m"
18
25
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
19
26
language = "eql"
20
27
license = "Elastic License v2"
21
28
name = "AWS RDS DB Snapshot Shared with Another Account"
22
-
note = """
23
-
## Triage and analysis
29
+
note = """## Triage and analysis
30
+
31
+
> **Disclaimer**:
32
+
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
24
33
25
34
### Investigating AWS RDS DB Snapshot Shared with Another Account
26
35
27
-
This rule identifies when an RDS DB snapshot is shared with another AWS account. While sharing DB snapshots is a common practice, adversaries may exploit this feature to exfiltrate data by sharing snapshots with external accounts under their control.
36
+
Amazon RDS DB snapshots capture full backups of database instances and clusters. Modifying a snapshot’s restore
37
+
attributes to include external AWS accounts allows those accounts to restore and fully access the underlying data.
38
+
While cross-account snapshot sharing is widely used for migrations and disaster-recovery workflows, adversaries may
39
+
abuse this mechanism for stealthy data exfiltration, restoring the snapshot in infrastructure they control, outside of your monitoring boundary.
40
+
41
+
This rule detects successful modifications to snapshot attributes where one or more additional AWS accounts are added to the snapshot’s restore permissions.
42
+
43
+
#### Possible investigation steps
44
+
45
+
- **Identify the actor and context**
46
+
- Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id`.
47
+
- Determine whether the caller is an automation role, interactive user, CI/CD pipeline, or previously unseen principal.
48
+
- Check `source.ip` and `user_agent.original` for signs of unauthorized access or atypical tooling.
49
+
50
+
- **Understand what snapshot was shared**
51
+
- From `aws.cloudtrail.request_parameters`, extract:
52
+
- The snapshot or cluster snapshot identifier.
53
+
- The list of `valuesToAdd` accounts added to `attributeName=restore`.
54
+
- Identify the associated database instance or cluster and evaluate:
- Subsequent `CopyDBSnapshot` or `StartExportTask` events.
75
+
- Snapshot downloads, exports, or restoration from the external account.
76
+
- Snapshot attributes set to `all` (public sharing), which is extremely dangerous.
28
77
29
-
#### Possible Investigation Steps
78
+
- **Validate operational intent**
79
+
- Contact application owners, DBAs, or platform teams to confirm:
80
+
- Whether migration, replication, or DR workflows explain the share.
81
+
- Whether new accounts were intentionally onboarded.
82
+
- Whether the timing aligns with approved change windows.
30
83
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 DB snapshot involved and review the event details. Look for `ModifyDBSnapshotAttribute` or `ModifyDBClusterSnapshotAttribute` actions where the snapshot attributes were changed to include additional user accounts.
33
-
- **Request and Response Parameters**: Check the `aws.cloudtrail.request_parameters` and `aws.cloudtrail.response_elements` fields in the CloudTrail event to identify the DB Snapshot Identifier and account ID with which the snapshot was shared.
34
-
- **Verify the Shared Snapshot**: Check the DB snapshot that was shared and its contents to determine the sensitivity of the data stored within it.
35
-
- **Validate External Account**: Examine the AWS account to which the snapshot was shared. 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 RDS DB or Cluster configurations and deployments. 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.
84
+
### False positive analysis
39
85
40
-
### False Positive Analysis
86
+
- **Legitimate migration or DR workflows**
87
+
- Many organizations routinely share snapshots with other accounts for staging, analytics, or DR replication.
41
88
42
-
- **Legitimate Backup Actions**: Confirm if the Db snapshot sharing 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.
89
+
- **Automation roles**
90
+
- Infrastructure-as-code pipelines and backup automation tools may modify snapshot permissions as part of normal behavior.
44
91
45
-
### Response and Remediation
92
+
If behavior is expected and consistently performed by a known principal, tune the rule using exceptional user identities, service roles, or controlled organizational accounts.
46
93
47
-
- **Immediate Review and Reversal**: If the change was unauthorized, update the snapshot permissions to remove any unauthorized accounts and restore it to its previous state.
48
-
- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
49
-
- **Audit Snapshots and Policies**: Conduct a comprehensive audit of all snapshots and associated policies to ensure they adhere to the principle of least privilege.
50
-
- **Policy Update**: Review and possibly update your organization’s policies on DB snapshot sharing to tighten control and prevent unauthorized access.
51
-
- **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.
94
+
### Response and remediation
52
95
53
-
### Additional Information:
96
+
- **Revoke unauthorized sharing**
97
+
- Immediately remove unauthorized accounts from snapshot restore attributes.
98
+
- Ensure the snapshot is not publicly shared.
54
99
55
-
For further guidance on managing DB backups and securing AWS environments, refer to the [AWS RDS documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_CommonTasks.BackupRestore.html) and AWS best practices for security. Additionally, consult the following resources for specific details on DB snapshot security:
56
-
- [AWS RDS DB Snapshot Sharing](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html)
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
0 commit comments