AWS EC2 EBS Snapshot Shared or Made Public

Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data in an environment they control. This activity often precedes data exfiltration or persistence operations, where the attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/04/16"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/10/24"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS
 11snapshots contain copies of data volumes that may include sensitive or regulated information. Adversaries may exploit
 12ModifySnapshotAttribute to share snapshots with external accounts or the public, allowing them to copy and access data
 13in an environment they control. This activity often precedes data exfiltration or persistence operations, where the
 14attacker transfers stolen data out of the victim account or prepares a staging area for further exploitation.
 15"""
 16event_category_override = "event.type"
 17false_positives = [
 18    """
 19    AMI sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action.
 20    """,
 21]
 22from = "now-6m"
 23index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 24language = "eql"
 25license = "Elastic License v2"
 26name = "AWS EC2 EBS Snapshot Shared or Made Public"
 27note = """## Triage and analysis
 28
 29> **Disclaimer**:
 30> 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.
 31
 32### Investigating AWS EC2 EBS Snapshot Shared or Made Public
 33
 34This rule detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots store copies of data volumes that may contain sensitive or regulated information. Adversaries may exploit the `ModifySnapshotAttribute` API to share these snapshots externally, allowing them to copy and access the data in an environment they control. This activity is commonly associated with data exfiltration or persistence techniques, where attackers transfer data outside the victim account or prepare backups they can later retrieve. Public sharing (`group=all`) represents a severe data exposure risk, as it makes the snapshot globally readable.
 35
 36#### Possible investigation steps:
 37
 38- **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who modified the snapshot’s permissions. Evaluate whether this identity is authorized to share EBS snapshots (check IAM policies for `ec2:ModifySnapshotAttribute`).
 39- **Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An unfamiliar or external location may indicate compromised credentials or unauthorized access. Review `user_agent.original` to confirm whether the request originated from an expected administrative tool or host.
 40- **Examine the scope of the change**:
 41  - Review `aws.cloudtrail.request_parameters` to determine which AWS account(s) were added to the `createVolumePermission` list.  
 42    - If the account ID matches the snapshot owner’s account, this is redundant and typically non-malicious.  
 43    - If another account ID or `group=all` appears, verify whether the target is an approved AWS Organization account or an external party.  
 44  - Cross-check the affected `snapshotId` in the AWS console or via CLI (`describe-snapshot-attribute`) to confirm current sharing status.  
 45  - Identify whether other snapshots or AMIs were shared in the same timeframe.
 46- **Correlate with other activities**:
 47  - Search CloudTrail for related events involving the same actor or `source.ip`.  
 48    - Look for `CreateSnapshot`, `CopySnapshot`, `ExportImage`, or `PutBucketAcl` events that could indicate broader exfiltration or replication behavior.  
 49    - Correlate with detections such as `EBS Snapshot Access Removed` or `EBS Encryption Disabled`, which may signal a coordinated campaign involving both exfiltration and impact.  
 50  - Check GuardDuty and Security Hub for findings related to data exposure, cross-account sharing, or unauthorized data transfer.
 51- **Evaluate timing and intent**: Compare `@timestamp` against scheduled maintenance or approved change windows. Actions performed outside business hours or without documented change tickets should be prioritized for review.
 52
 53### False positive analysis:
 54
 55- **Authorized internal sharing**: Confirm if the snapshot sharing was part of an approved workflow, such as internal replication or migration between AWS Organization accounts.  
 56- **Automated replication or tooling**: Infrastructure-as-code or backup automation may temporarily share snapshots for cross-region or cross-account transfers. Verify automation identifiers, source IPs, and tags.  
 57- **Self-account addition**: Adding the owner’s own account ID to `createVolumePermission` has no operational impact and can be safely ignored.  
 58
 59If verified as legitimate, document the event under change management and reconcile it against organizational policies for snapshot sharing.
 60
 61### Response and remediation:
 62
 63**1. Containment and validation**
 64- If unauthorized, immediately remove added permissions using the AWS CLI:  
 65  `aws ec2 modify-snapshot-attribute --snapshot-id <id> --create-volume-permission "Remove=[{UserId=<unauthorized_id>}]"`  
 66- Revoke public sharing (`group=all`) to prevent external access.  
 67- Restrict `ec2:ModifySnapshotAttribute` permissions to trusted administrative roles only.
 68**2. Investigate for data exfiltration or persistence**
 69- Determine whether the shared snapshot was copied to another account (`CopySnapshot`).  
 70- Engage AWS Support if evidence suggests external copying or data theft.  
 71- Review subsequent API calls or IAM changes for further persistence or data movement.
 72**3. Strengthen detection and monitoring**
 73- Enable AWS Config rules such as `ebs-snapshot-public-restorable-check`.  
 74- Implement continuous monitoring for `ModifySnapshotAttribute` and `CopySnapshot` operations.  
 75- Correlate future detections by actor, access key, and source IP to identify repeated or automated exfiltration attempts.
 76**4. Recovery and hardening**
 77- Enable default encryption and validate that all snapshots remain private.  
 78- Apply Service Control Policies (SCPs) to prevent public snapshot sharing organization-wide.  
 79- Audit existing snapshots to ensure no others have unauthorized permissions.  
 80- Implement least-privilege IAM principles and enforce multi-factor authentication (MFA) for administrative accounts.
 81
 82### Additional information
 83
 84- **[AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**: reference playbooks for investigating data exfiltration and unauthorized access.  
 85- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/)**: example framework for developing custom playbooks for snapshot configuration and data protection.  
 86- **AWS Documentation**  
 87  - [EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html)  
 88  - [ModifySnapshotAttribute API Reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html)  
 89"""
 90references = [
 91    "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html",
 92    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html",
 93    "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump",
 94    "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/",
 95]
 96risk_score = 47
 97rule_id = "4182e486-fc61-11ee-a05d-f661ea17fbce"
 98severity = "medium"
 99tags = [
100    "Domain: Cloud",
101    "Data Source: AWS",
102    "Data Source: Amazon Web Services",
103    "Data Source: AWS EC2",
104    "Use Case: Threat Detection",
105    "Tactic: Exfiltration",
106    "Resources: Investigation Guide",
107]
108timestamp_override = "event.ingested"
109type = "eql"
110
111query = '''
112info where event.dataset == "aws.cloudtrail"  
113  and event.action == "ModifySnapshotAttribute"
114  and event.outcome == "success"
115  and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION")
116  and stringContains (aws.cloudtrail.request_parameters, "add=")
117'''
118
119
120[[rule.threat]]
121framework = "MITRE ATT&CK"
122[[rule.threat.technique]]
123id = "T1537"
124name = "Transfer Data to Cloud Account"
125reference = "https://attack.mitre.org/techniques/T1537/"
126
127
128[rule.threat.tactic]
129id = "TA0010"
130name = "Exfiltration"
131reference = "https://attack.mitre.org/tactics/TA0010/"
132
133[rule.investigation_fields]
134field_names = [
135    "@timestamp",
136    "user.name",
137    "user_agent.original",
138    "source.ip",
139    "aws.cloudtrail.user_identity.arn",
140    "aws.cloudtrail.user_identity.type",
141    "aws.cloudtrail.user_identity.access_key_id",
142    "target.entity.id",
143    "event.action",
144    "event.outcome",
145    "cloud.account.id",
146    "cloud.region",
147    "aws.cloudtrail.request_parameters",
148    "aws.cloudtrail.response_elements",
149]

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 EC2 EBS Snapshot Shared or Made Public

This rule detects when an Amazon Elastic Block Store (EBS) snapshot is shared with another AWS account or made public. EBS snapshots store copies of data volumes that may contain sensitive or regulated information. Adversaries may exploit the ModifySnapshotAttribute API to share these snapshots externally, allowing them to copy and access the data in an environment they control. This activity is commonly associated with data exfiltration or persistence techniques, where attackers transfer data outside the victim account or prepare backups they can later retrieve. Public sharing (group=all) represents a severe data exposure risk, as it makes the snapshot globally readable.

Possible investigation steps:

  • Identify who performed the action: Review aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.access_key_id to identify who modified the snapshot’s permissions. Evaluate whether this identity is authorized to share EBS snapshots (check IAM policies for ec2:ModifySnapshotAttribute).
  • Analyze the source of the request: Examine source.ip and source.geo fields to determine the geographical origin of the request. An unfamiliar or external location may indicate compromised credentials or unauthorized access. Review user_agent.original to confirm whether the request originated from an expected administrative tool or host.
  • Examine the scope of the change:
    • Review aws.cloudtrail.request_parameters to determine which AWS account(s) were added to the createVolumePermission list.
      • If the account ID matches the snapshot owner’s account, this is redundant and typically non-malicious.
      • If another account ID or group=all appears, verify whether the target is an approved AWS Organization account or an external party.
    • Cross-check the affected snapshotId in the AWS console or via CLI (describe-snapshot-attribute) to confirm current sharing status.
    • Identify whether other snapshots or AMIs were shared in the same timeframe.
  • Correlate with other activities:
    • Search CloudTrail for related events involving the same actor or source.ip.
      • Look for CreateSnapshot, CopySnapshot, ExportImage, or PutBucketAcl events that could indicate broader exfiltration or replication behavior.
      • Correlate with detections such as EBS Snapshot Access Removed or EBS Encryption Disabled, which may signal a coordinated campaign involving both exfiltration and impact.
    • Check GuardDuty and Security Hub for findings related to data exposure, cross-account sharing, or unauthorized data transfer.
  • Evaluate timing and intent: Compare @timestamp against scheduled maintenance or approved change windows. Actions performed outside business hours or without documented change tickets should be prioritized for review.

False positive analysis:

  • Authorized internal sharing: Confirm if the snapshot sharing was part of an approved workflow, such as internal replication or migration between AWS Organization accounts.
  • Automated replication or tooling: Infrastructure-as-code or backup automation may temporarily share snapshots for cross-region or cross-account transfers. Verify automation identifiers, source IPs, and tags.
  • Self-account addition: Adding the owner’s own account ID to createVolumePermission has no operational impact and can be safely ignored.

If verified as legitimate, document the event under change management and reconcile it against organizational policies for snapshot sharing.

Response and remediation:

1. Containment and validation

  • If unauthorized, immediately remove added permissions using the AWS CLI:
    aws ec2 modify-snapshot-attribute --snapshot-id <id> --create-volume-permission "Remove=[{UserId=<unauthorized_id>}]"
  • Revoke public sharing (group=all) to prevent external access.
  • Restrict ec2:ModifySnapshotAttribute permissions to trusted administrative roles only. 2. Investigate for data exfiltration or persistence
  • Determine whether the shared snapshot was copied to another account (CopySnapshot).
  • Engage AWS Support if evidence suggests external copying or data theft.
  • Review subsequent API calls or IAM changes for further persistence or data movement. 3. Strengthen detection and monitoring
  • Enable AWS Config rules such as ebs-snapshot-public-restorable-check.
  • Implement continuous monitoring for ModifySnapshotAttribute and CopySnapshot operations.
  • Correlate future detections by actor, access key, and source IP to identify repeated or automated exfiltration attempts. 4. Recovery and hardening
  • Enable default encryption and validate that all snapshots remain private.
  • Apply Service Control Policies (SCPs) to prevent public snapshot sharing organization-wide.
  • Audit existing snapshots to ensure no others have unauthorized permissions.
  • Implement least-privilege IAM principles and enforce multi-factor authentication (MFA) for administrative accounts.

Additional information

References

Related rules

to-top