Loading AttackTrace...
Loading AttackTrace...
Lifecycle Triggered Deletion (T1485.001) is a MITRE ATT&CK technique associated with Impact . Adversaries may modify the lifecycle policies of a cloud storage bucket to destroy all objects stored within.
Lifecycle-Triggered Deletion (T1485.001) is a MITRE ATT&CK technique associated with Impact. Adversaries may modify the lifecycle policies of a cloud storage bucket to destroy all objects stored within.
Attackers use Lifecycle-Triggered Deletion because it provides a reliable way to advance their objective within the Impact tactic, often with a favorable balance of impact versus detectability on IaaS environments. Defenders should assess this behavior in the context of the affected platform and adjacent activity rather than treating it as a standalone indicator.
Adversaries may modify the lifecycle policies of a cloud storage bucket to destroy all objects stored within.
Cloud storage buckets often allow users to set lifecycle policies to automate the migration, archival, or deletion of objects after a set period of time.(Citation: AWS Storage Lifecycles)(Citation: GCP Storage Lifecycles)(Citation: Azure Storage Lifecycles) If a threat actor has sufficient permissions to modify these policies, they may be able to delete all objects at once.
For example, in AWS environments, an adversary with the PutLifecycleConfiguration permission may use the PutBucketLifecycle API call to apply a lifecycle policy to an S3 bucket that deletes all objects in the bucket after one day.(Citation: Palo Alto Cloud Ransomware)(Citation: Halcyon AWS Ransomware 2025) In addition to destroying data for purposes of extortion and Financial Theft, adversaries may also perform this action on buckets storing cloud logs for Indicator Removal.(Citation: Datadog S3 Lifecycle CloudTrail Logs)
No universal command represents Lifecycle-Triggered Deletion. Capture the exact command line, arguments, parent process, account, host, and execution time from the investigated environment; do not operationalize unverified examples.
| Event ID | Log Channel | What It Indicates |
|---|---|---|
| Not universally applicable | Validate platform coverage | This technique may not produce a Windows event; use telemetry native to the affected platform. |
| Sysmon Event ID | Name | Why It's Relevant Here |
|---|---|---|
| Environment-specific | Validate configured telemetry | Use process, network, file, registry, DNS, or image-load telemetry only when relevant and enabled. |
No MITRE detection guidance published for this technique.
Relevant ATT&CK Data Sources: N/A
A universal Sigma rule would create unreliable results because this technique has no single guaranteed observable. Build detection logic from a documented behavior and supported data source, scope it to the affected platform, and validate it against benign administrative activity before deployment.
Start with the data sources named in the detection section. Scope searches by asset, identity, and time window; correlate the primary behavior with preceding access and subsequent actions. A portable query is intentionally not provided where the technique lacks a universal schema or observable.