[Rule Tuning][New Rule][Deprecation] AWS EC2 EBS Snapshot Activity Rules

[imays11]

Pull Request

Issue link(s):
Resolves #3906
Tracked https://github.com/elastic/ia-trade-team/issues/616

Summary - What I changed

1. Rule Tuning - to prevent duplicate alerts for AWS EC2 EBS Snapshot Shared of Made Public, the execution interval has been adjusted from 5m interval with 4m lookback to 5m interval with 1m lookback.

Screenshot - No duplicate Alerts

2. New Rule - to capture when access is removed from an EBS Snapshot. While this may be intentional behavior it could indicate malicious attempts to inhibit system recovery efforts post-compromise, or to maintain exclusive access to critical backups by removing permissions for all users except their own controlled account.

Screenshot of new rule showing `remove` activity type

3. Deprecate - AWS EC2 Snapshot Activity is too broad in scope and encompasses the behavior of the other 2 rules resulting in duplicate alerts and non-specific context for which permission change type is happening (add vs remove).

Screenshot showing duplicate alerts for same activity

How To Test

I have these rules enabled in our shared stack and a Python script available upon request that will trigger the rules. For manual testing with the AWS CLI use the steps below:

---

Step 1: Setup

1. Create a Volume

   aws ec2 create-volume --availability-zone us-east-1a --size 1 --volume-type gp2

   • Replace us-east-1a, 1, and gp2 with your desired availability zone, size, and volume type, respectively.
   • Note down the VolumeId from the response.

2. Wait for the Volume to be Available

   aws ec2 wait volume-available --volume-ids <VolumeId>

3. Create a Snapshot

   aws ec2 create-snapshot --volume-id <VolumeId> --description "Attack simulation snapshot"

   • Note down the SnapshotId from the response.

4. Wait for the Snapshot to Complete

   aws ec2 wait snapshot-completed --snapshot-ids <SnapshotId>

Step 2: Exfiltration

6. Share Snapshot Publicly

   aws ec2 modify-snapshot-attribute --snapshot-id <SnapshotId> --attribute createVolumePermission --operation-type add --group-names all

7. Share Snapshot with a Specific AWS Account (Optional)

   aws ec2 modify-snapshot-attribute --snapshot-id <SnapshotId> --attribute createVolumePermission --operation-type add --user-ids <account-id>

Step 3: Covering Tracks

8. Remove All Permissions

   aws ec2 modify-snapshot-attribute --snapshot-id <SnapshotId> --attribute createVolumePermission --operation-type remove --group-names all

Cleanup

9. Delete the Snapshot

   aws ec2 delete-snapshot --snapshot-id <SnapshotId>

10. Delete the Volume

aws ec2 delete-volume --volume-id <VolumeId>

Notes:

• Replace <VolumeId>, <SnapshotId> and <account-id> with the actual IDs obtained from the previous commands and our shared AWS account Id.

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[terrancedejesus]

Great work @imays11 !

Do we have a red-team or in-the-wild abuse reference we can add to these by chance or is this hypothetical?

[imays11]

Great work @imays11 !

Do we have a red-team or in-the-wild abuse reference we can add to these by chance or is this hypothetical?

@terrancedejesus Mainly hypothetical, there are examples of snapshots being deleted and I considered this for rule dev but think that would be too noisy a rule.