AWS RDS DB Snapshot Shared with Another Account

Identifies when an AWS RDS DB snapshot is shared with another AWS account or made public. DB snapshots contain complete backups of database instances, including schemas, table data, and sensitive application content. When shared externally, snapshots can be restored in another AWS environment, enabling unauthorized access, offline analysis, or data exfiltration. Adversaries who obtain valid credentials or exploit misconfigurations may modify snapshot attributes to grant access to accounts they control, bypassing network, IAM, and monitoring controls.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/06/25"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/12/05"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies when an AWS RDS DB snapshot is shared with another AWS account or made public. DB snapshots contain complete
 11backups of database instances, including schemas, table data, and sensitive application content. When shared externally,
 12snapshots can be restored in another AWS environment, enabling unauthorized access, offline analysis, or data
 13exfiltration. Adversaries who obtain valid credentials or exploit misconfigurations may modify snapshot attributes to
 14grant access to accounts they control, bypassing network, IAM, and monitoring controls.
 15"""
 16event_category_override = "event.type"
 17false_positives = [
 18    """
 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.
 22    """,
 23]
 24from = "now-6m"
 25index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 26language = "eql"
 27license = "Elastic License v2"
 28name = "AWS RDS DB Snapshot Shared with Another Account"
 29note = """## 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.
 33
 34### Investigating AWS RDS DB Snapshot Shared with Another Account
 35
 36Amazon RDS DB snapshots capture full backups of database instances and clusters. Modifying a snapshot’s restore
 37attributes to include external AWS accounts allows those accounts to restore and fully access the underlying data.
 38While cross-account snapshot sharing is widely used for migrations and disaster-recovery workflows, adversaries may
 39abuse this mechanism for stealthy data exfiltration, restoring the snapshot in infrastructure they control, outside of your monitoring boundary.
 40
 41This 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:
 55    - Data classification level (PII, customer data, secrets, credentials, financials, etc.)
 56    - Application ownership and business impact.
 57
 58- **Validate the external account**
 59  - Determine whether the recipient account:
 60    - Belongs to your AWS Organization.
 61    - Has previously been authorized for snapshot restore operations.
 62    - Represents a new or unexpected dependency.
 63  - Cross-reference with known partner accounts or migration plans.
 64
 65- **Correlate with related activity**
 66  - Pivot in CloudTrail on the same user identity or account to identify:
 67    - Prior reconnaissance actions (`DescribeDBSnapshots`, `DescribeDBInstances`).
 68    - Snapshot copying or creation of manual snapshots just before sharing.
 69    - IAM privilege escalation (`AttachRolePolicy`, `PutUserPolicy`, `AssumeRole` patterns).
 70    - Unusual RDS configuration changes (backup retention decrease, deletion protection toggles).
 71
 72- **Assess for exfiltration indicators**
 73  - Look for:
 74    - 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.
 77
 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.
 83
 84### False positive analysis
 85
 86- **Legitimate migration or DR workflows**
 87  - Many organizations routinely share snapshots with other accounts for staging, analytics, or DR replication.
 88
 89- **Automation roles**
 90  - Infrastructure-as-code pipelines and backup automation tools may modify snapshot permissions as part of normal behavior.
 91
 92If behavior is expected and consistently performed by a known principal, tune the rule using exceptional user identities, service roles, or controlled organizational accounts.
 93
 94### Response and remediation
 95
 96- **Revoke unauthorized sharing**
 97  - Immediately remove unauthorized accounts from snapshot restore attributes.
 98  - Ensure the snapshot is not publicly shared.
 99
100- **Contain potential compromise**
101  - Rotate access keys or credentials for the principal that performed the modification.
102  - Review IAM permissions to ensure only approved roles can share snapshots.
103
104- **Assess impact**
105  - Determine whether the external account restored the snapshot and accessed data.
106  - If data exposure is likely, notify compliance, legal, and incident response teams.
107
108- **Hardening and preventive controls**
109  - Restrict snapshot sharing via IAM condition keys (`kms:ViaService`, `rds:dbSnapshotArn`, `aws:PrincipalArn`).
110  - Use AWS Organizations SCPs to block cross-account snapshot sharing in production accounts.
111  - Enable Config rules and Security Hub controls for public or cross-account snapshot access.
112
113### Additional information
114- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
115- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
116- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
117"""
118references = [
119    "https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshotAttribute.html",
120    "https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html",
121    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation#rds-modifydbsnapshotattribute-rds-createdbsnapshot",
122]
123risk_score = 47
124rule_id = "4577ef08-61d1-4458-909f-25a4b10c87fe"
125severity = "medium"
126tags = [
127    "Domain: Cloud",
128    "Data Source: AWS",
129    "Data Source: Amazon Web Services",
130    "Data Source: AWS RDS",
131    "Resources: Investigation Guide",
132    "Use Case: Threat Detection",
133    "Tactic: Exfiltration",
134]
135timestamp_override = "event.ingested"
136type = "eql"
137
138query = '''
139info where event.dataset == "aws.cloudtrail"
140    and event.provider == "rds.amazonaws.com"
141    and event.outcome == "success"
142    and event.action in ("ModifyDBSnapshotAttribute", "ModifyDBClusterSnapshotAttribute")
143    and stringContains(aws.cloudtrail.request_parameters, "attributeName=restore")
144    and stringContains(aws.cloudtrail.request_parameters, "valuesToAdd=[*]")
145'''
146
147
148[[rule.threat]]
149framework = "MITRE ATT&CK"
150[[rule.threat.technique]]
151id = "T1537"
152name = "Transfer Data to Cloud Account"
153reference = "https://attack.mitre.org/techniques/T1537/"
154
155
156[rule.threat.tactic]
157id = "TA0010"
158name = "Exfiltration"
159reference = "https://attack.mitre.org/tactics/TA0010/"
160
161[rule.investigation_fields]
162field_names = [
163    "@timestamp",
164    "user.name",
165    "user_agent.original",
166    "source.ip",
167    "aws.cloudtrail.user_identity.arn",
168    "aws.cloudtrail.user_identity.type",
169    "aws.cloudtrail.user_identity.access_key_id",
170    "target.entity.id",
171    "event.action",
172    "event.outcome",
173    "cloud.account.id",
174    "cloud.region",
175    "aws.cloudtrail.request_parameters",
176    "aws.cloudtrail.response_elements",
177]

Triage and analysis

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

Investigating AWS RDS DB Snapshot Shared with Another Account

Amazon RDS DB snapshots capture full backups of database instances and clusters. Modifying a snapshot’s restore attributes to include external AWS accounts allows those accounts to restore and fully access the underlying data. While cross-account snapshot sharing is widely used for migrations and disaster-recovery workflows, adversaries may abuse this mechanism for stealthy data exfiltration, restoring the snapshot in infrastructure they control, outside of your monitoring boundary.

This rule detects successful modifications to snapshot attributes where one or more additional AWS accounts are added to the snapshot’s restore permissions.

Possible investigation steps

  • Identify the actor and context

    • Review aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.access_key_id.
    • Determine whether the caller is an automation role, interactive user, CI/CD pipeline, or previously unseen principal.
    • Check source.ip and user_agent.original for signs of unauthorized access or atypical tooling.
  • Understand what snapshot was shared

    • From aws.cloudtrail.request_parameters, extract:
      • The snapshot or cluster snapshot identifier.
      • The list of valuesToAdd accounts added to attributeName=restore.
    • Identify the associated database instance or cluster and evaluate:
      • Data classification level (PII, customer data, secrets, credentials, financials, etc.)
      • Application ownership and business impact.
  • Validate the external account

    • Determine whether the recipient account:
      • Belongs to your AWS Organization.
      • Has previously been authorized for snapshot restore operations.
      • Represents a new or unexpected dependency.
    • Cross-reference with known partner accounts or migration plans.
  • Correlate with related activity

    • Pivot in CloudTrail on the same user identity or account to identify:
      • Prior reconnaissance actions (DescribeDBSnapshots, DescribeDBInstances).
      • Snapshot copying or creation of manual snapshots just before sharing.
      • IAM privilege escalation (AttachRolePolicy, PutUserPolicy, AssumeRole patterns).
      • Unusual RDS configuration changes (backup retention decrease, deletion protection toggles).
  • Assess for exfiltration indicators

    • Look for:
      • Subsequent CopyDBSnapshot or StartExportTask events.
      • Snapshot downloads, exports, or restoration from the external account.
      • Snapshot attributes set to all (public sharing), which is extremely dangerous.
  • Validate operational intent

    • Contact application owners, DBAs, or platform teams to confirm:
      • Whether migration, replication, or DR workflows explain the share.
      • Whether new accounts were intentionally onboarded.
      • Whether the timing aligns with approved change windows.

False positive analysis

  • Legitimate migration or DR workflows

    • Many organizations routinely share snapshots with other accounts for staging, analytics, or DR replication.
  • Automation roles

    • Infrastructure-as-code pipelines and backup automation tools may modify snapshot permissions as part of normal behavior.

If behavior is expected and consistently performed by a known principal, tune the rule using exceptional user identities, service roles, or controlled organizational accounts.

Response and remediation

  • Revoke unauthorized sharing

    • Immediately remove unauthorized accounts from snapshot restore attributes.
    • Ensure the snapshot is not publicly shared.
  • Contain potential compromise

    • Rotate access keys or credentials for the principal that performed the modification.
    • Review IAM permissions to ensure only approved roles can share snapshots.
  • Assess impact

    • Determine whether the external account restored the snapshot and accessed data.
    • If data exposure is likely, notify compliance, legal, and incident response teams.
  • Hardening and preventive controls

    • Restrict snapshot sharing via IAM condition keys (kms:ViaService, rds:dbSnapshotArn, aws:PrincipalArn).
    • Use AWS Organizations SCPs to block cross-account snapshot sharing in production accounts.
    • Enable Config rules and Security Hub controls for public or cross-account snapshot access.

Additional information

References

Related rules

to-top