Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
Original file line number Diff line number Diff line change
@@ -0,0 +1,116 @@
[[prebuilt-rule-8-19-27-aws-backup-recovery-point-deleted]]
=== AWS Backup Recovery Point Deleted

Identifies deletion of an AWS Backup recovery point via DeleteRecoveryPoint. A recovery point is a stored backup of a protected resource (EBS, RDS, DynamoDB, EFS, S3, and others). Deleting recovery points removes the ability to restore the associated data and is a core anti-recovery technique used in ransomware and data-destruction attacks to ensure victims cannot recover without paying or rebuilding. Routine lifecycle expirations are performed by the AWS Backup service itself; deletion by a non-service principal is rare and should be reviewed.

*Rule type*: query

*Rule indices*:

* logs-aws.cloudtrail-*

*Severity*: high

*Risk score*: 73

*Runs every*: 5m

*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)

*Maximum alerts per execution*: 100

*References*:

* https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteRecoveryPoint.html
* https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html

*Tags*:

* Domain: Cloud
* Data Source: AWS
* Data Source: Amazon Web Services
* Data Source: AWS Backup
* Use Case: Threat Detection
* Tactic: Impact
* Resources: Investigation Guide

*Version*: 1

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Investigation guide



*Triage and analysis*



*Investigating AWS Backup Recovery Point Deleted*


AWS Backup recovery points are the restorable copies of protected resources. "DeleteRecoveryPoint" permanently removes a recovery point from its vault, eliminating the ability to restore that backup. Adversaries delete recovery points to inhibit recovery after data destruction or encryption, maximizing the impact of ransomware or sabotage. Because scheduled expirations are carried out by the AWS Backup service itself (excluded by this rule), a deletion by a user or role principal is uncommon and high-signal, especially when several recovery points are removed in a short window.


*Possible investigation steps*


- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip", "source.as.organization.name", and "user_agent.original" for an unexpected origin.
- Identify the affected recovery point and vault from "aws.cloudtrail.request_parameters", and determine which resource and data it protected.
- Determine whether multiple recovery points or vaults were affected in the same window, indicating a broader anti-recovery effort.
- Correlate with adjacent destructive or evasion activity by the same principal, such as DeleteBackupVault, Vault Lock removal, KMS key deletion, or resource deletions.


*False positive analysis*


- Retention cleanup, migration, or decommissioning may delete recovery points. Confirm the deletion is expected and exclude known administration roles on "aws.cloudtrail.user_identity.arn" after validation.


*Response and remediation*


- If the deletion is unauthorized, treat it as a potential precursor to or part of a destructive attack: preserve remaining backups, enable Vault Lock where possible, and engage incident response.
- Rotate or restrict credentials for the principal if compromise is suspected, and restrict "backup:DeleteRecoveryPoint" to a small set of trusted administrators via IAM and SCPs.


*Additional information*


- https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteRecoveryPoint.html[DeleteRecoveryPoint API]
- https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html[AWS Backup Vault Lock]


==== Setup


This rule requires AWS CloudTrail management events for AWS Backup and ingestion via the Elastic AWS CloudTrail integration. See https://docs.elastic.co/integrations/aws/cloudtrail.

==== Rule query


[source, js]
----------------------------------
data_stream.dataset: "aws.cloudtrail"
and event.provider: "backup.amazonaws.com"
and event.action: "DeleteRecoveryPoint"
and event.outcome: "success"
and not aws.cloudtrail.user_identity.type: "AWSService"

----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Impact
** ID: TA0040
** Reference URL: https://attack.mitre.org/tactics/TA0040/
* Technique:
** Name: Inhibit System Recovery
** ID: T1490
** Reference URL: https://attack.mitre.org/techniques/T1490/
Original file line number Diff line number Diff line change
@@ -0,0 +1,127 @@
[[prebuilt-rule-8-19-27-aws-backup-vault-deleted-or-vault-lock-removed]]
=== AWS Backup Vault Deleted or Vault Lock Removed

Identifies deletion of an AWS Backup vault or removal of its Vault Lock configuration via DeleteBackupVault or DeleteBackupVaultLockConfiguration. A backup vault stores recovery points, and Vault Lock enforces WORM (write-once, read-many) immutability that prevents recovery points from being deleted before their retention expires. Removing the lock defeats the primary control designed to stop ransomware from destroying backups, and deleting the vault removes the backup container entirely. Both actions are strong anti-recovery signals and are rare in normal operations.

*Rule type*: query

*Rule indices*:

* logs-aws.cloudtrail-*

*Severity*: high

*Risk score*: 73

*Runs every*: 5m

*Searches indices from*: now-6m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)

*Maximum alerts per execution*: 100

*References*:

* https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html
* https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVault.html
* https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVaultLockConfiguration.html

*Tags*:

* Domain: Cloud
* Data Source: AWS
* Data Source: Amazon Web Services
* Data Source: AWS Backup
* Use Case: Threat Detection
* Tactic: Impact
* Tactic: Defense Evasion
* Resources: Investigation Guide

*Version*: 1

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Investigation guide



*Triage and analysis*



*Investigating AWS Backup Vault Deleted or Vault Lock Removed*


A backup vault is the container for AWS Backup recovery points, and Vault Lock applies immutability so recovery points cannot be deleted or shortened before retention expires. "DeleteBackupVaultLockConfiguration" removes that immutability (for governance-mode locks), and "DeleteBackupVault" deletes the vault itself. Adversaries remove the lock to enable subsequent deletion of otherwise-immutable recovery points, or delete the vault to destroy backups outright. These are high-impact, rare operations and should be deliberate and tightly controlled.


*Possible investigation steps*


- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip", "source.as.organization.name", and "user_agent.original" for an unexpected origin.
- Determine the affected vault from "aws.cloudtrail.request_parameters" and whether it held recovery points.
- For lock removal, check whether DeleteRecoveryPoint or DeleteBackupVault followed shortly after, indicating a staged anti-recovery sequence.
- Correlate with other destructive or evasion activity by the same principal (KMS key deletion, resource deletions, logging changes).


*False positive analysis*


- Decommissioning of empty vaults or planned governance changes may match. Confirm the change is expected and exclude known administration roles on "aws.cloudtrail.user_identity.arn" after validation.


*Response and remediation*


- If unauthorized, treat as a likely precursor to backup destruction: preserve remaining recovery points, re-apply Vault Lock (in compliance mode where appropriate), and engage incident response.
- Rotate or restrict credentials for the principal if compromise is suspected, and restrict "backup:DeleteBackupVault" and "backup:DeleteBackupVaultLockConfiguration" to break-glass roles via IAM and SCPs.


*Additional information*


- https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html[AWS Backup Vault Lock]
- https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVault.html[DeleteBackupVault API]
- https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVaultLockConfiguration.html[DeleteBackupVaultLockConfiguration API]


==== Setup


This rule requires AWS CloudTrail management events for AWS Backup and ingestion via the Elastic AWS CloudTrail integration. See https://docs.elastic.co/integrations/aws/cloudtrail.

==== Rule query


[source, js]
----------------------------------
data_stream.dataset: "aws.cloudtrail"
and event.provider: "backup.amazonaws.com"
and event.action: ("DeleteBackupVault" or "DeleteBackupVaultLockConfiguration")
and event.outcome: "success"
and not aws.cloudtrail.user_identity.type: "AWSService"

----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Impact
** ID: TA0040
** Reference URL: https://attack.mitre.org/tactics/TA0040/
* Technique:
** Name: Inhibit System Recovery
** ID: T1490
** Reference URL: https://attack.mitre.org/techniques/T1490/
* Tactic:
** Name: Defense Evasion
** ID: TA0005
** Reference URL: https://attack.mitre.org/tactics/TA0005/
* Technique:
** Name: Impair Defenses
** ID: T1562
** Reference URL: https://attack.mitre.org/techniques/T1562/
Original file line number Diff line number Diff line change
@@ -0,0 +1,111 @@
[[prebuilt-rule-8-19-27-aws-ecr-repository-or-registry-policy-granted-public-access]]
=== AWS ECR Repository or Registry Policy Granted Public Access

Detects when an Amazon ECR repository or registry policy is modified to grant public access using a wildcard principal (Principal:"*") statement. This rule analyzes SetRepositoryPolicy and PutRegistryPolicy events whose policy document grants an Allow effect to a wildcard ("*") principal, indicating that pull (and potentially push) permissions were extended to all identities, including unauthenticated users. A public container registry can expose proprietary images and any secrets baked into their layers, and, if push is allowed, enables supply-chain implantation. Public ECR access is sometimes intentional for image distribution, so the granting principal and the permissions should be validated.

*Rule type*: esql

*Rule indices*: None

*Severity*: medium

*Risk score*: 47

*Runs every*: 10m

*Searches indices from*: now-15m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)

*Maximum alerts per execution*: 100

*References*:

* https://docs.aws.amazon.com/AmazonECR/latest/APIReference/API_SetRepositoryPolicy.html
* https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html

*Tags*:

* Domain: Cloud
* Data Source: AWS
* Data Source: Amazon Web Services
* Data Source: AWS ECR
* Use Case: Threat Detection
* Tactic: Exfiltration
* Resources: Investigation Guide

*Version*: 1

*Rule authors*:

* Elastic

*Rule license*: Elastic License v2


==== Investigation guide



*Triage and analysis*



*Investigating AWS ECR Repository or Registry Policy Granted Public Access*


This rule detects "SetRepositoryPolicy" or "PutRegistryPolicy" calls where the policy document grants an Allow effect to a wildcard ("*") principal, granting access to all identities. A public ECR repository allows anyone to pull its images, exposing proprietary code and any secrets embedded in image layers; if push actions are granted, an adversary can implant a malicious image that downstream ECS, EKS, or Lambda workloads then run.


*Possible investigation steps*


- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" for an unexpected origin or tool.
- Extract the policy from "aws.cloudtrail.request_parameters" and identify the granted actions; pull actions (BatchGetImage, GetDownloadUrlForLayer) expose images, while push actions (PutImage, UploadLayerPart) enable implantation.
- Confirm whether a Deny statement restricts the same access, in which case the alert may be a false positive.
- Determine which repository is affected and whether it contains sensitive images, and correlate with subsequent pull or push activity from external principals.


*False positive analysis*


- Public image distribution legitimately uses Principal:"*". Confirm the exposure is intended, the actions are pull-only, and the granting principal is approved.


*Response and remediation*


- If the exposure is unauthorized, restore a known-good policy or remove the public statement, and review for any external pulls or pushes since the change.
- Rotate or restrict credentials for the principal if compromise is suspected, and restrict "ecr:SetRepositoryPolicy" and "ecr:PutRegistryPolicy" to trusted administrators.


==== Setup


This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details.

==== Rule query


[source, js]
----------------------------------
FROM logs-aws.cloudtrail-* METADATA _id, _version, _index
| WHERE event.provider == "ecr.amazonaws.com"
AND event.action IN ("SetRepositoryPolicy", "PutRegistryPolicy")
AND event.outcome == "success"
AND (aws.cloudtrail.user_identity.type IS NULL OR aws.cloudtrail.user_identity.type != "AWSService")
AND aws.cloudtrail.request_parameters RLIKE """.*\"Effect\": *\"Allow\".*"""
AND (aws.cloudtrail.request_parameters RLIKE """.*\"Principal\": *\"\*\".*"""
OR aws.cloudtrail.request_parameters RLIKE """.*\"Principal\": *\{ *\"AWS\": *\"\*\".*""")
| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.*

----------------------------------

*Framework*: MITRE ATT&CK^TM^

* Tactic:
** Name: Exfiltration
** ID: TA0010
** Reference URL: https://attack.mitre.org/tactics/TA0010/
* Technique:
** Name: Transfer Data to Cloud Account
** ID: T1537
** Reference URL: https://attack.mitre.org/techniques/T1537/
Loading
Loading