diff --git a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml index 5a55508c3b8..7bf872728d7 100644 --- a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml +++ b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml @@ -2,60 +2,90 @@ 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. """ +event_category_override = "event.provider" 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 -### 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. - -#### 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. - -### 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. +> **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. -### Response and Remediation: - -- **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. - -### Additional Information: +### Investigating AWS EC2 EBS Snapshot Shared or Made Public -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) +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 --create-volume-permission "Remove=[{UserId=}]"` +- 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", @@ -63,9 +93,9 @@ references = [ "https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump", "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/", ] -risk_score = 21 +risk_score = 47 rule_id = "4182e486-fc61-11ee-a05d-f661ea17fbce" -severity = "low" +severity = "medium" tags = [ "Domain: Cloud", "Data Source: AWS", @@ -76,35 +106,14 @@ 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" +"ec2.amazonaws.com" where event.dataset == "aws.cloudtrail" 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") ''' @@ -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", +] + diff --git a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml index c05bd39b30e..0e7a0a7f1a4 100644 --- a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml +++ b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml @@ -2,13 +2,17 @@ creation_date = "2020/06/05" integration = ["aws"] maturity = "production" -updated_date = "2025/01/15" +updated_date = "2025/10/16" [rule] author = ["Elastic"] description = """ -Identifies disabling of Amazon Elastic Block Store (EBS) encryption by default in the current region. Disabling -encryption by default does not change the encryption status of your existing volumes. +Detects when Amazon Elastic Block Store (EBS) encryption by default is disabled in an AWS region. EBS encryption ensures +that newly created volumes and snapshots are automatically protected with AWS Key Management Service (KMS) keys. +Disabling this setting introduces significant risk as all future volumes created in that region will be unencrypted by +default, potentially exposing sensitive data at rest. Adversaries may disable encryption to weaken data protection +before exfiltrating or tampering with EBS volumes or snapshots. This may be a step in preparation for data theft or +ransomware-style attacks that depend on unencrypted volumes. """ false_positives = [ """ @@ -17,9 +21,8 @@ false_positives = [ should be investigated. If known behavior is causing false positives, it can be exempted from the rule. """, ] -from = "now-60m" +from = "now-6m" index = ["filebeat-*", "logs-aws.cloudtrail-*"] -interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS EC2 Encryption Disabled" @@ -30,37 +33,69 @@ note = """## Triage and analysis ### Investigating AWS EC2 Encryption Disabled -Amazon EC2's EBS encryption ensures data at rest is secure by default. Disabling this feature can expose sensitive data, making it vulnerable to unauthorized access. Adversaries might exploit this by disabling encryption to access or manipulate data without detection. The detection rule monitors CloudTrail logs for successful attempts to disable EBS encryption, alerting security teams to potential misuse. - -### Possible investigation steps - -- Review the CloudTrail logs for the specific event.action: DisableEbsEncryptionByDefault to identify the user or role that initiated the action. -- Check the event.provider: ec2.amazonaws.com logs to gather additional context about the environment and any related activities around the time of the event. -- Investigate the IAM policies and permissions associated with the user or role to determine if they have the necessary permissions to disable EBS encryption and if those permissions are appropriate. -- Assess the event.outcome: success to confirm that the action was completed successfully and identify any subsequent actions taken by the same user or role. -- Examine the AWS account's security settings and configurations to ensure that no other security features have been altered or disabled. -- Contact the user or team responsible for the action to understand the rationale behind disabling EBS encryption and verify if it aligns with organizational policies. +Amazon Elastic Block Store (EBS) encryption ensures that all new EBS volumes and snapshots are encrypted at rest using AWS KMS keys. +When encryption by default is disabled, new EBS volumes in the region will no longer inherit automatic encryption. +This action can have serious security implications as it can weaken the organization’s data protection posture, violate compliance requirements, or enable adversaries to read or exfiltrate sensitive information without triggering encryption-based access controls. + +#### Possible investigation steps + +**Identify the initiator and context** +- Review the `aws.cloudtrail.user_identity` fields to determine who or what performed the `DisableEbsEncryptionByDefault` action. + - Examine the `user_identity.type` (e.g., IAMUser, AssumedRole, Root, FederatedUser). + - Validate whether the actor is authorized to modify account-level encryption defaults. +- Check `source.ip` and `user_agent.original` to identify the origin of the request and whether it came from a known administrative system, automation process, or an unfamiliar host. +- Correlate with recent IAM activity such as `AttachUserPolicy`, `UpdateAccountPasswordPolicy`, or `PutAccountSetting` to identify potential privilege escalation or account misuse. +**Review the timing and scope** +- Compare the event `@timestamp` with other CloudTrail management events to determine if the encryption change occurred alongside other administrative modifications. +- Investigate if similar actions were executed in other AWS regions, disabling encryption regionally may be part of a broader campaign. +- Review AWS Config or Security Hub findings to determine whether compliance controls or data protection standards (e.g., CIS, PCI-DSS, ISO 27001) have been violated. +**Assess data exposure risk** +- Identify newly created or modified EBS volumes after the timestamp of this change. + - Query CloudTrail for `CreateVolume` or `CreateSnapshot` events without `Encrypted:true`. +- Determine whether sensitive workloads, such as production databases or applications, rely on unencrypted EBS volumes. +- Check for `CopySnapshot` or `ModifySnapshotAttribute` activity that could indicate data staging or exfiltration. +**Correlate related security events** +- Look for concurrent detections or GuardDuty findings involving IAM privilege misuse, credential exposure, or configuration tampering. +- Review CloudTrail logs for any `DisableKeyRotation` or `ScheduleKeyDeletion` events related to the KMS key used for EBS encryption. These may indicate attempts to disrupt encryption mechanisms entirely. +- Review AWS Config timeline to confirm whether encryption-by-default was re-enabled or remained off. ### False positive analysis -- Routine administrative actions may trigger alerts if encryption is disabled for testing or configuration purposes. To manage this, create exceptions for specific IAM roles or users known to perform these tasks regularly. -- Automated scripts or tools that disable encryption for specific workflows might cause false positives. Identify these scripts and exclude their associated actions from triggering alerts by using specific tags or identifiers. -- Changes in regional settings or policies that temporarily disable encryption could be misinterpreted as threats. Monitor these changes and adjust the detection rule to account for legitimate policy updates. -- Scheduled maintenance or updates that require temporary encryption disabling should be documented and excluded from alerts by setting time-based exceptions during known maintenance windows. - -### Response and remediation +- **Administrative changes**: System or cloud administrators may disable default encryption temporarily for troubleshooting or migration. Verify if the user identity, role, or automation process is part of a legitimate change. +- **Infrastructure testing**: Non-production environments may disable encryption for cost or performance benchmarking. These should be tagged and excluded. +- **Service misconfiguration**: Some provisioning frameworks or scripts may unintentionally disable encryption defaults during environment setup. Ensure automation code uses explicit encryption flags when creating resources. -- Immediately isolate the affected EC2 instances to prevent further unauthorized access or data manipulation. This can be done by modifying security group rules or network ACLs to restrict access. -- Re-enable EBS encryption by default in the affected region to ensure that all new volumes are encrypted. This can be done through the AWS Management Console or AWS CLI. -- Conduct a thorough review of recent changes in the AWS environment to identify any unauthorized modifications or access patterns. Focus on CloudTrail logs for any suspicious activity related to EBS encryption settings. -- Notify the security operations team and relevant stakeholders about the incident, providing them with details of the alert and any initial findings. -- Implement additional monitoring and alerting for any future attempts to disable EBS encryption by default, ensuring that security teams are promptly notified of similar activities. -- Review and update IAM policies to ensure that only authorized personnel have the necessary permissions to modify EBS encryption settings, reducing the risk of accidental or malicious changes. -- If any data manipulation is detected, initiate data recovery procedures to restore affected data from backups, ensuring data integrity and availability. +If confirmed as expected, document the change request, implementation window, and user responsible for traceability. -## Setup +### Response and remediation -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" +**1. Containment and restoration** +- Re-enable EBS encryption by default in the affected region to restore protection for new volumes: + - Via AWS Console: EC2 → Account Attributes → EBS encryption → Enable by default. + - Or via CLI/API: `enable-ebs-encryption-by-default`. +- Audit recently created EBS volumes and snapshots. + - Identify any unencrypted resources and re-encrypt them using KMS keys or snapshot-copy encryption workflows. +- Verify that AWS Config rules and Security Hub controls related to EBS encryption (`ec2-ebs-encryption-by-default-enabled`) are enabled and compliant. +**2. Investigate and scope** +- Review IAM policies to ensure only designated administrators have the `ec2:DisableEbsEncryptionByDefault` permission. +- Check for other regional encryption settings (e.g., S3 default encryption) that may have been modified by the same user or automation role. +- Examine whether any new IAM roles or policies were added that allow similar encryption or security modifications. +**3. Long-term hardening** +- Enable organization-level service control policies (SCPs) to prevent future disabling of encryption-by-default across accounts. +- Establish AWS Config conformance packs or Security Hub standards to continuously monitor this setting. +- Integrate detection correlation (e.g., link EBS encryption disablement with subsequent unencrypted `CreateVolume` events) for improved alert fidelity. +- Educate administrators on data protection implications and require change approvals for encryption-related settings. +**4. Recovery validation** +- After restoring encryption-by-default, validate the change in CloudTrail and AWS Config timelines. +- Confirm that subsequent EBS volumes are created with `Encrypted:true`. +- Conduct a short post-incident review to document root cause, impact, and lessons learned for compliance audits. + +### Additional information + +- **[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. +- **[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 +- **AWS Documentation: [EBS Encryption at Rest](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)** +""" references = [ "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html", "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/disable-ebs-encryption-by-default.html", @@ -103,3 +138,19 @@ id = "TA0040" name = "Impact" reference = "https://attack.mitre.org/tactics/TA0040/" +[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", + "event.action", + "event.outcome", + "cloud.account.id", + "cloud.region", + "aws.cloudtrail.response_elements", +] + diff --git a/rules/integrations/aws/impact_ec2_ebs_snapshot_access_removed.toml b/rules/integrations/aws/impact_ec2_ebs_snapshot_access_removed.toml index 48fad7798e8..5faede38d66 100644 --- a/rules/integrations/aws/impact_ec2_ebs_snapshot_access_removed.toml +++ b/rules/integrations/aws/impact_ec2_ebs_snapshot_access_removed.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/02" integration = ["aws"] maturity = "production" -updated_date = "2025/07/16" +updated_date = "2025/10/16" [rule] author = ["Elastic"] @@ -13,56 +13,82 @@ accessing backups, thereby obstructing recovery efforts after data loss or destr used to evade detection or maintain exclusive access to critical backups, ultimately increasing the impact of an attack and complicating incident response. """ -false_positives = [ - " Access removal may be a part of normal operations and should be verified before taking action.\n ", -] +event_category_override = "event.provider" +false_positives = ["Access removal may be a part of normal operations and should be verified 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 Access Removed" note = """## Triage and analysis -### Investigating AWS EC2 EBS Snapshot Access Removed - -This 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. - -#### 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 should 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. In particular, use the `snapshotId` to see if this snapshot was shared with an unauthorized account. -- **Review UserID**: Check the `userId` field to identify which user's permissions were removed. Verify if this account should be authorized to access the data or if the access removal is expected. - -### 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. - -### Response and Remediation: +> **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. -- **Immediate Review and Reversal if Necessary**: If the change was unauthorized, update the snapshot permissions to 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. - -### Additional Information: +### Investigating AWS EC2 EBS Snapshot Access Removed -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) +This 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. + +#### 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 made the change. Evaluate whether the identity is authorized to manage EBS snapshot permissions (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 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. +- **Examine the scope of the change**: + - Review `aws.cloudtrail.request_parameters` to understand which accounts or entities had access removed. + - Look for unusual patterns such as `createVolumePermission={remove=all}` or removal of specific external or organizational accounts. + - 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. + - Use AWS Config or AWS CLI (`describe-snapshot-attribute`) to verify whether other snapshots were modified within the same timeframe. +- **Correlate with other activities**: + - Search CloudTrail for additional activity from the same actor or `source.ip` around the event time. + - Pay special attention to subsequent `DeleteSnapshot`, `DeregisterImage`, or `RevokeSnapshotAccess` events, which may signal ongoing destruction. + - Check for parallel IAM activity, such as policy changes that grant or revoke permissions. + - Correlate with GuardDuty or Security Hub findings related to data exfiltration, destructive actions, or unauthorized configuration changes. + - Determine if any high-value or production snapshots were affected, especially those linked to business-critical EBS volumes. +- **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. + +### False positive analysis: + +- **Planned administrative maintenance**: Confirm whether this snapshot modification aligns with backup rotation, retention policy enforcement, or snapshot lifecycle automation. +- **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. +- **Testing or sandbox accounts**: Some non-production environments may modify snapshot access for isolation. Validate account purpose before escalating. + +If the action was expected, document the change approval and reconcile against internal audit or change-control systems. + +### Response and remediation: + +**1. Containment and validation** +- Review and, if necessary, restore snapshot permissions using AWS Console or CLI (`modify-snapshot-attribute` with `add` parameters). +- Confirm that no additional snapshots or AMIs have had access removed. +- Restrict `ec2:ModifySnapshotAttribute` permissions to only trusted administrative roles. +**2. Investigate for data destruction or persistence** +- Determine if the same actor also deleted or copied snapshots (`DeleteSnapshot`, `CopySnapshot`). +- Review subsequent volume creation or image registration events that could indicate snapshot reuse. +- Identify whether any snapshot was shared to or copied by an external AWS account. +**3. Strengthen detection and monitoring** +- Enable AWS Config rules and Security Hub controls such as `ebs-snapshot-public-restorable-check`. +- Establish continuous monitoring for `ModifySnapshotAttribute` and `DeleteSnapshot` operations. +- Correlate future detections with user identity and source IP context to identify recurring behavior. +**4. Recovery and hardening** +- Verify that critical snapshots and backups are retained and encrypted. +- Implement backup immutability with AWS Backup Vault Lock or S3 Object Lock for long-term protection. +- Apply service control policies (SCPs) to prevent unauthorized modification of snapshot sharing attributes. +- Conduct a post-incident review to identify the root cause and strengthen least-privilege enforcement for EBS management roles. + +### Additional information + +- **[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. +- **[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 +- **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", "https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifySnapshotAttribute.html", ] -risk_score = 21 +risk_score = 47 rule_id = "713e0f5f-caf7-4dc2-88a7-3561f61f262a" -severity = "low" +severity = "medium" tags = [ "Domain: Cloud", "Data Source: AWS", @@ -73,38 +99,16 @@ tags = [ "Resources: Investigation Guide", ] timestamp_override = "event.ingested" -type = "esql" +type = "eql" query = ''' -from logs-aws.cloudtrail-* metadata _id, _version, _index - -// Filter for successful snapshot modifications -| where - event.provider == "ec2.amazonaws.com" +"ec2.amazonaws.com" where event.dataset == "aws.cloudtrail" and event.action == "ModifySnapshotAttribute" and event.outcome == "success" - -// dissect parameters to extract key fields -| 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}}]}}}" - -// Match on snapshot permission **removal** -| where Esql.aws_cloudtrail_request_parameters_operation_type == "remove" - -// 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.address + and stringContains (aws.cloudtrail.request_parameters, "attributeType=CREATE_VOLUME_PERMISSION") + and stringContains (aws.cloudtrail.request_parameters, "remove={items") ''' - [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] @@ -123,3 +127,21 @@ id = "TA0040" name = "Impact" reference = "https://attack.mitre.org/tactics/TA0040/" +[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", +] +