Skip to content

[Rule Tunings] AWS EC2 EBS Snapshot and Encryption Rules #5229

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
+258 −158
Open

[Rule Tunings] AWS EC2 EBS Snapshot and Encryption Rules #5229

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
21edd18
[Rule Tunings] AWS EC2 EBS Snapshot and Encryption Rules
imays11 Oct 16, 2025
3ce2da5
adding event_category_override = "event.provider"
imays11 Oct 17, 2025
be0a46c
normalizing IG title capitalization
imays11 Oct 17, 2025
55dce65
bumping severity to medium
imays11 Oct 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
133 changes: 80 additions & 53 deletions rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,60 +2,89 @@
creation_date = "2024/04/16"
integration = ["aws"]
maturity = "production"
updated_date = "2025/07/16"
updated_date = "2025/10/16"

[rule]
author = ["Elastic"]
description = """
Identifies AWS EC2 EBS snaphots being shared with another AWS account or made public. EBS virtual disks can be copied
into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this in
order to copy the snapshot into an environment they control, to access the data.
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.
"""
false_positives = [
"""
AMI sharing is a common practice in AWS environments. Ensure that the sharing is authorized before taking action.
""",
]
from = "now-6m"
interval = "5m"
language = "esql"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS EC2 EBS Snapshot Shared or Made Public"
note = """## 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 AWS EC2 EBS snapshot is shared with another AWS account or made public. EBS virtual disks can be copied into snapshots, which can then be shared with an external AWS account or made public. Adversaries may attempt this to copy the snapshot into an environment they control to access the data. Understanding the context and legitimacy of such changes is crucial to determine if the action is benign or malicious.
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 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.
- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific changes made to the snapshot permissions. Look for any unusual parameters that could suggest unauthorized or malicious modifications.
- **Analyze the Source of the Request**: Investigate the `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.
- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the change occurred. Modifications during non-business hours or outside regular maintenance windows might require further scrutiny.
- **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.
- **Review UserID**: Check the `userId` field to identify the AWS account with which the snapshot was shared. Verify if this account is authorized to access the data or if it belongs to a known third party. If this value is `all`, the snapshot is made public.
- **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:

- **Legitimate Administrative Actions**: Confirm if the snapshot sharing aligns with scheduled updates, development activities, or legitimate administrative tasks documented in change management systems.
- **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.
- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the change was successful and intended according to policy.

### Response and Remediation:
- **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.

- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the snapshot permissions to remove any unauthorized accounts and restore it to its previous state.
- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions.
- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning snapshot management and sharing permissions.
- **Audit Snapshots and Policies**: Conduct a comprehensive audit of all snapshots and associated policies to ensure they adhere to the principle of least privilege.
- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.
If verified as legitimate, document the event under change management and reconcile it against organizational policies for snapshot sharing.

### Additional Information:
### Response and Remediation:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Response and Remediation -> Response and remediation to stay consistent with other rules. Same for FP analysis and investigation steps.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!


For further guidance on managing EBS snapshots and securing AWS environments, refer to the [AWS EBS documentation](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html) and AWS best practices for security. Additionally, consult the following resources for specific details on EBS snapshot security:
- [AWS EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html)
- [AWS API ModifySnapshotAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html)
- [AWS EBS Snapshot Dump](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump)
**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

- **[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.
- **[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.
- **AWS Documentation**
- [EBS Snapshot Permissions](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html)
- [ModifySnapshotAttribute API Reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html)
"""
references = [
"https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modifying-snapshot-permissions.html",
Expand All @@ -76,35 +105,15 @@ tags = [
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"
type = "eql"

query = '''
from logs-aws.cloudtrail-* metadata _id, _version, _index
| where
event.provider == "ec2.amazonaws.com"
any where event.dataset == "aws.cloudtrail"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noticed we dont have an ECS event.category for the docs but aws.cloudtrail.event_category exists. I wonder if we can get these mapped and cover more categories that way. Just a thought

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's an example of what @terrancedejesus has done in the past. Although im not sure why he added an override matching the default. 🤔

Copy link
Contributor

@terrancedejesus terrancedejesus Oct 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t recall much beyond a suggestion to override it: #3278 (comment)

Okta categories will be fixed here: elastic/integrations#15235

In my opinion, overriding with the provider does remove the need to use any, but it also changes the query’s context. Instead of saying event type WHERE, we’re now effectively saying service WHERE. I could be mistaken, but my understanding is that the override functionality was introduced to allow specifying a different field from the integration’s data stream that categorizes events.

While event.provider works well and is consistent in AWS, that may not be the case for other CSP audit logs, so this approach might make sense in some cases but could introduce inconsistency overall. Ideally, this should be solved at the data source level rather than in the rule itself.

Copy link
Contributor Author

@imays11 imays11 Oct 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@terrancedejesus I do agree with the ultimate changes being made at the data source level. When I'm finished with the audit I will create an Integrations request that consolidates all the API calls that we currently use in our ruleset that don't have a defined category. However, if performance is an issue, we may want to just implement a solution that we can control for now. It's probably worth putting some thought into normalizing what "backup" fields we should use. I chose event.provider simply because it's a way to group all the events associated with a single AWS service, which we always include in the AWS queries any way. But I'm open to suggestions for a better field.

and event.provider == "ec2.amazonaws.com"
and event.action == "ModifySnapshotAttribute"
and event.outcome == "success"

// Extract snapshotId, attribute type, operation type, and userId
| dissect aws.cloudtrail.request_parameters
"{%{?snapshotId}=%{Esql.aws_cloudtrail_request_parameters_snapshot_id},%{?attributeType}=%{Esql.aws_cloudtrail_request_parameters_attribute_type},%{?createVolumePermission}={%{Esql.aws_cloudtrail_request_parameters_operation_type}={%{?items}=[{%{?userId}=%{Esql_priv.aws_cloudtrail_request_parameters_user_id}}]}}}"

// Check for snapshot permission added for another AWS account
| where
Esql.aws_cloudtrail_request_parameters_operation_type == "add"
and cloud.account.id != Esql_priv.aws_cloudtrail_request_parameters_user_id

// keep ECS and derived fields
| keep
@timestamp,
aws.cloudtrail.user_identity.arn,
cloud.account.id,
event.action,
Esql.aws_cloudtrail_request_parameters_snapshot_id,
Esql.aws_cloudtrail_request_parameters_attribute_type,
Esql.aws_cloudtrail_request_parameters_operation_type,
Esql_priv.aws_cloudtrail_request_parameters_user_id,
source.ip
and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION")
and stringContains (aws.cloudtrail.request_parameters, "add={items")
'''


Expand All @@ -121,3 +130,21 @@ id = "TA0010"
name = "Exfiltration"
reference = "https://attack.mitre.org/tactics/TA0010/"

[rule.investigation_fields]
field_names = [
"@timestamp",
"user.name",
"user_agent.original",
"source.ip",
"aws.cloudtrail.user_identity.arn",
"aws.cloudtrail.user_identity.type",
"aws.cloudtrail.user_identity.access_key_id",
"target.entity.id",
"event.action",
"event.outcome",
"cloud.account.id",
"cloud.region",
"aws.cloudtrail.request_parameters",
"aws.cloudtrail.response_elements",
]

Loading
Loading