AWS EC2 EBS Snapshot Access Removed

  1[metadata]
  2creation_date = "2024/06/02"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/10/24"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the removal of access permissions from a shared AWS EC2 EBS snapshot. EBS snapshots are essential for data
 11retention and disaster recovery. Adversaries may revoke or modify snapshot permissions to prevent legitimate users from
 12accessing backups, thereby obstructing recovery efforts after data loss or destructive actions. This tactic can also be
 13used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack
 14and complicating incident response.
 15"""
 16event_category_override = "event.type"
 17false_positives = ["Access removal may be a part of normal operations and should be verified before taking action."]
 18from = "now-6m"
 19index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 20language = "eql"
 21license = "Elastic License v2"
 22name = "AWS EC2 EBS Snapshot Access Removed"
 23note = """## Triage and analysis
 24
 25> **Disclaimer**:
 26> 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.
 27
 28### Investigating AWS EC2 EBS Snapshot Access Removed
 29
 30This rule detects when access is removed for an AWS EC2 EBS snapshot. EBS virtual disks can be copied into snapshots, which can then be used as backups for recovery and data retention efforts. Adversaries may attempt to remove access to snapshots in order to prevent legitimate users or automated processes from accessing or restoring from snapshots following data loss, ransomware, or destructive actions. This can significantly delay or even prevent recovery, increasing the impact of the attack. Restricting snapshot access may help adversaries cover their tracks by making it harder for defenders to analyze or recover deleted or altered data. Attackers may remove permissions for all users except their own compromised account, allowing them to maintain exclusive access to backups for future use or leverage. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious.
 31
 32#### Possible investigation steps:
 33
 34- **Identify who performed the action**: Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to identify who made the change. Evaluate whether the identity is authorized to manage EBS snapshot permissions (check IAM policies for `ec2:ModifySnapshotAttribute`). 
 35- **Analyze the source of the request**: Examine `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access. Review `user_agent.original` to determine if the request came from an expected administrative tool or host.
 36- **Examine the scope of the change**:
 37  - Review `aws.cloudtrail.request_parameters` to understand which accounts or entities had access removed.  
 38    - Look for unusual patterns such as `createVolumePermission={remove=all}` or removal of specific external or organizational accounts.  
 39  - Cross-check the affected `snapshotId` in the AWS console or via CLI to confirm current sharing status and determine if any copies or dependent volumes exist.  
 40  - Use AWS Config or AWS CLI (`describe-snapshot-attribute`) to verify whether other snapshots were modified within the same timeframe.
 41- **Correlate with other activities**:
 42  - Search CloudTrail for additional activity from the same actor or `source.ip` around the event time.  
 43    - Pay special attention to subsequent `DeleteSnapshot`, `DeregisterImage`, or `RevokeSnapshotAccess` events, which may signal ongoing destruction.  
 44    - Check for parallel IAM activity, such as policy changes that grant or revoke permissions.  
 45  - Correlate with GuardDuty or Security Hub findings related to data exfiltration, destructive actions, or unauthorized configuration changes.  
 46  - Determine if any high-value or production snapshots were affected, especially those linked to business-critical EBS volumes.
 47- **Evaluate timing and intent**: Compare `@timestamp` with maintenance windows or known change requests. Actions taken outside approved hours or without associated tickets may indicate compromise or sabotage. If this change coincides with other detections (for example, `EBS encryption disabled` or `root login` events), treat it as part of a coordinated impact campaign.
 48
 49### False positive analysis:
 50
 51- **Planned administrative maintenance**: Confirm whether this snapshot modification aligns with backup rotation, retention policy enforcement, or snapshot lifecycle automation.  
 52- **Automation and tooling**: Infrastructure-as-code pipelines or DevOps scripts may legitimately remove snapshot sharing to enforce compliance. Review tags, user agents, and automation identifiers.  
 53- **Testing or sandbox accounts**: Some non-production environments may modify snapshot access for isolation. Validate account purpose before escalating.
 54
 55If the action was expected, document the change approval and reconcile against internal audit or change-control systems.
 56
 57### Response and remediation:
 58
 59**1. Containment and validation**
 60- Review and, if necessary, restore snapshot permissions using AWS Console or CLI (`modify-snapshot-attribute` with `add` parameters).  
 61- Confirm that no additional snapshots or AMIs have had access removed.  
 62- Restrict `ec2:ModifySnapshotAttribute` permissions to only trusted administrative roles.
 63**2. Investigate for data destruction or persistence**
 64- Determine if the same actor also deleted or copied snapshots (`DeleteSnapshot`, `CopySnapshot`).  
 65- Review subsequent volume creation or image registration events that could indicate snapshot reuse.  
 66- Identify whether any snapshot was shared to or copied by an external AWS account.
 67**3. Strengthen detection and monitoring**
 68- Enable AWS Config rules and Security Hub controls such as `ebs-snapshot-public-restorable-check`.  
 69- Establish continuous monitoring for `ModifySnapshotAttribute` and `DeleteSnapshot` operations.  
 70- Correlate future detections with user identity and source IP context to identify recurring behavior.
 71**4. Recovery and hardening**
 72- Verify that critical snapshots and backups are retained and encrypted.  
 73- Implement backup immutability with AWS Backup Vault Lock or S3 Object Lock for long-term protection.  
 74- Apply service control policies (SCPs) to prevent unauthorized modification of snapshot sharing attributes.  
 75- Conduct a post-incident review to identify the root cause and strengthen least-privilege enforcement for EBS management roles.
 76
 77### Additional information
 78
 79- **[AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**: guidance for investigating unauthorized access to modify account settings.  
 80- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/)**: Example framework for customers to create, develop, and integrate security playbooks in preparation for potential attack scenarios when using AWS services
 81- **AWS Documentation**  
 82  - [EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html)  
 83  - [ModifySnapshotAttribute API Reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html)
 84"""
 85references = [
 86    "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html",
 87    "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html",
 88]
 89risk_score = 47
 90rule_id = "713e0f5f-caf7-4dc2-88a7-3561f61f262a"
 91severity = "medium"
 92tags = [
 93    "Domain: Cloud",
 94    "Data Source: AWS",
 95    "Data Source: Amazon Web Services",
 96    "Data Source: AWS EC2",
 97    "Use Case: Threat Detection",
 98    "Tactic: Impact",
 99    "Resources: Investigation Guide",
100]
101timestamp_override = "event.ingested"
102type = "eql"
103
104query = '''
105info where event.dataset == "aws.cloudtrail"  
106  and event.action == "ModifySnapshotAttribute"
107  and event.outcome == "success"
108  and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION")
109  and stringContains (aws.cloudtrail.request_parameters, "remove=")
110'''
111
112[[rule.threat]]
113framework = "MITRE ATT&CK"
114[[rule.threat.technique]]
115id = "T1485"
116name = "Data Destruction"
117reference = "https://attack.mitre.org/techniques/T1485/"
118
119[[rule.threat.technique]]
120id = "T1490"
121name = "Inhibit System Recovery"
122reference = "https://attack.mitre.org/techniques/T1490/"
123
124
125[rule.threat.tactic]
126id = "TA0040"
127name = "Impact"
128reference = "https://attack.mitre.org/tactics/TA0040/"
129
130[rule.investigation_fields]
131field_names = [
132    "@timestamp",
133    "user.name",
134    "user_agent.original",
135    "source.ip",
136    "aws.cloudtrail.user_identity.arn",
137    "aws.cloudtrail.user_identity.type",
138    "aws.cloudtrail.user_identity.access_key_id",
139    "target.entity.id",
140    "event.action",
141    "event.outcome",
142    "cloud.account.id",
143    "cloud.region",
144    "aws.cloudtrail.request_parameters",
145    "aws.cloudtrail.response_elements",
146]