Cancellazione via Lifecycle Policy: Lifecycle-Triggered Deletion (T1485.001)

Simulare T1485.001 in un esercizio red team richiede un account cloud di laboratorio isolato e permessi controllati. L'obiettivo è dimostrare l'impatto senza toccare dati produttivi: creare un bucket di test popolato con oggetti fittizi e riprodurre l'intera catena di modifica policy.

Su AWS, la catena minima parte da un principal con s3:PutLifecycleConfiguration sul bucket target. Con AWS CLI (open source) si prepara un file JSON che descrive la regola di scadenza, ad esempio con Status: Enabled, Filter vuoto (match su tutti gli oggetti) e Expiration.Days: 1. Il comando operativo è:

aws s3api put-bucket-lifecycle-configuration --bucket --lifecycle-configuration file://policy.json

Per versionamento attivo, aggiungere una regola NoncurrentVersionExpiration.NoncurrentDays: 1 elimina anche le versioni storiche, rendendo il recovery via ListObjectVersions inefficace. La verifica avviene con aws s3api get-bucket-lifecycle-configuration --bucket .

Su Azure, il tool nativo è Azure CLI (open source) con az storage account management-policy create, passando un JSON che definisce actions.baseBlob.delete.daysAfterModificationGreaterThan: 1. Su GCP, gsutil lifecycle set policy.json gs:// (open source, incluso nel Google Cloud SDK) applica una regola con action.type: Delete e condition.age: 1.

Per un'operazione red team più realistica, framework come Pacu (open source) — il toolkit di offensive AWS di Rhino Security Labs — includono moduli per l'enumerazione IAM che identificano principal con permessi PutLifecycleConfiguration sfruttabili. ScoutSuite (open source) e CloudSploit (open source) aiutano nella fase di reconnaissance per mappare bucket privi di Object Lock o MFA Delete.

La catena d'attacco tipica in un esercizio prevede: compromissione di credenziali IAM (via phishing o Instance Metadata Service abuse), enumerazione dei bucket con aws s3api list-buckets, identificazione dei target ad alto valore (log bucket CloudTrail, snapshot DB), applicazione della lifecycle policy distruttiva e uscita. L'attaccante non deve restare connesso: il ciclo di valutazione del provider farà il lavoro nelle 24 ore successive.

Per evidenziare l'impatto, documentare i tempi: applicazione policy T+0, primo ciclo di valutazione S3 tipicamente T+12/24h, cancellazione completa entro T+48h. Concludere sempre il test ripristinando la policy originale o cancellando il bucket di laboratorio.

La detection di T1485.001 ruota attorno al monitoraggio delle API di configurazione lifecycle sui provider cloud. Su AWS la fonte primaria è CloudTrail, dove l'evento chiave è eventName: PutBucketLifecycle o PutBucketLifecycleConfiguration con eventSource: s3.amazonaws.com. L'analisi comportamentale, come suggerito dalla detection DET0041 / AN0117, deve concentrarsi su quattro dimensioni correlate.

La prima è il valore di LifecycleExpirationDays: policy che impostano Expiration.Days a valori estremamente bassi (0 o 1) sono anomalie forti. Una regola SIEM efficace parsa il campo requestParameters.LifecycleConfiguration.Rules[].Expiration.Days e alza severity alta sotto la soglia di 7 giorni, critical sotto 2. Va monitorato anche NoncurrentVersionExpiration.NoncurrentDays con la stessa logica, perché copre lo scenario di eliminazione delle versioni precedenti.

La seconda dimensione è il TargetBucket: le priorità di allerta devono essere tarate sul tipo di bucket. Bucket contenenti log CloudTrail, VPC Flow Logs, snapshot RDS o backup applicativi meritano detection dedicate con soglia zero-tolerance. Mantenere una lista curata di bucket critici, arricchita da tag come Environment: Production o DataClassification: Critical, permette correlazioni mirate.

La terza è il Principal: correlare l'identità IAM che effettua la chiamata con la baseline storica. Un principal che non ha mai invocato PutBucketLifecycle nei 90 giorni precedenti è sospetto, specialmente se agisce da IP geografici anomali o tramite AssumeRole con sessioni brevi. UEBA su userIdentity.arn e sourceIPAddress aiuta a distinguere DevOps legittimi da account compromessi.

La quarta è la TimeWindow: la modifica lifecycle raramente arriva isolata. Correlare con chiamate precedenti a GetBucketPolicy, PutBucketVersioning (per disabilitarlo), DeleteBucketReplication o PutBucketAcl costruisce una catena di staged deletion. Un pattern di ricognizione seguito da modifica di policy entro 30 minuti dallo stesso principal è indicatore forte.

Su Azure, monitorare l'operation Microsoft.Storage/storageAccounts/managementPolicies/write in Activity Log. Su GCP, l'audit log storage.buckets.update con delta sul campo lifecycle è l'equivalente.

I falsi positivi provengono da attività IaC legittima: pipeline Terraform o CloudFormation che riapplicano policy in modo idempotente. La whitelist si costruisce sui userIdentity.sessionContext delle role assumibili solo dalle pipeline CI/CD, escludendo modifiche fuori orario o da IP non appartenenti ai runner. Come controllo preventivo, applicare Service Control Policy a livello di Organization per negare s3:PutLifecycleConfiguration su bucket con tag specifici è la contromisura più efficace.

L'analisi forense di un evento T1485.001 è complicata dal fatto che l'artefatto primario — gli oggetti cancellati — potrebbe non esistere più al momento dell'indagine. La timeline deve essere ricostruita a partire dalle fonti di audit del control plane e da eventuali copie residue.

Su AWS, il punto di partenza è CloudTrail, idealmente configurato con delivery su un bucket dedicato in un account separato di logging. Gli eventi da estrarre sono PutBucketLifecycle, PutBucketLifecycleConfiguration e le loro variazioni, filtrando per il bucket vittima. Ogni record contiene eventTime, userIdentity (con ARN completo, accountId, accessKeyId, sessionContext per sessioni STS), sourceIPAddress, userAgent e il payload requestParameters con la lifecycle configuration applicata. Confrontare la policy applicata con quella precedente (ottenibile da CloudTrail eventi GetBucketLifecycle o da snapshot AWS Config) quantifica l'impatto.

AWS Config (a pagamento) è la fonte più preziosa se attivo con registrazione delle risorse S3: fornisce diff temporali della configurazione del bucket e permette di risalire allo stato esatto prima della modifica. La query CLI aws configservice get-resource-config-history --resource-type AWS::S3::Bucket --resource-id restituisce la cronologia.

La timeline tipica ricostruisce: T-N giorni con eventuali accessi anomali di enumerazione (ListBuckets, GetBucketPolicy), T0 con la chiamata PutBucketLifecycle distruttiva, T+12/24h con inizio della cancellazione batch visibile come eventi DeleteObject massivi provenienti da userIdentity.type: AWSService e invokedBy: s3.amazonaws.com. Questa firma distingue la cancellazione via lifecycle da una cancellazione manuale.

Se il bucket aveva versioning attivo e la policy non eliminava le versioni non correnti, il recovery è possibile con aws s3api list-object-versions e ripristino selettivo. Se Object Lock in modalità Compliance era configurato, gli oggetti sopravvivono anche alla policy. In assenza di questi controlli, verificare l'esistenza di replicazione cross-region (GetBucketReplication) o backup AWS Backup (a pagamento).

Per l'attribuzione, incrociare sourceIPAddress con log VPC Flow, log di autenticazione SSO/IdP (Okta, Azure AD) e sessioni AssumeRole risalendo la catena fino al principal umano originario. Se le credenziali sono state esfiltrate, cercare eventi GetSessionToken o AssumeRole anomali nelle 72 ore precedenti.

Su Azure, l'equivalente è Activity Log esportato in Log Analytics e Azure Resource Graph per lo storico configurazione. Su GCP, Cloud Audit Logs (Admin Activity) e Asset Inventory per gli snapshot di configurazione bucket. Documentare timestamp UTC, principal, delta di policy e volume dati perso costituisce il pacchetto minimo per il report di incident response.

I dati MITRE ATT&CK non associano gruppi APT, software o campagne specifiche a T1485.001, il che riflette la natura relativamente recente e opportunistica della tecnica piuttosto che l'assenza di rilevanza operativa. La lifecycle-triggered deletion emerge come strumento tattico in scenari di cloud extortion e post-compromise cleanup, tipicamente adottato da attori che hanno già stabilito accesso persistente all'ambiente cloud della vittima.

Il profilo dell'attore che sfrutta questa tecnica è coerente con due categorie principali. La prima è quella dei gruppi ransomware con capability cloud-native, che hanno progressivamente esteso l'arsenale oltre l'encryption tradizionale verso la distruzione o esfiltrazione di dati cloud-hosted. Per questi attori la lifecycle policy è preferibile alla cancellazione diretta perché richiede una singola chiamata API a basso volume — evadendo detection basate su threshold di DeleteObject — e produce l'effetto distruttivo in modo differito, dando tempo all'attaccante di uscire dall'ambiente prima che la vittima si accorga del danno.

La seconda categoria è quella degli insider threat e degli attori con obiettivi di Indicator Removal. Cancellare un bucket di log CloudTrail tramite lifecycle policy è operativamente più elegante che eliminare singoli file: la modifica appare come normale attività amministrativa, mentre l'effetto è la distruzione totale della catena di evidenze. Questo pattern è osservato in scenari di frode finanziaria cloud dove l'attaccante necessita di eliminare tracce di operazioni fraudolente compiute nell'ambiente compromesso.

Il tool overlap è concentrato su strumenti legittimi di amministrazione cloud: AWS CLI, Azure CLI, gsutil, PowerShell Az module. Non esistono malware dedicati per questa tecnica perché la primitiva è nativa del provider e non richiede codice custom. Framework offensivi come Pacu (open source) forniscono moduli di post-exploitation che includono manipolazione di configurazioni S3, ma la tecnica in sé è tipicamente eseguita hands-on-keyboard o via script minimali.

Dal punto di vista del trend, la crescita è correlata all'aumento della superficie cloud aziendale e alla maturazione delle cloud kill chain documentate. Gruppi che storicamente colpivano on-premise stanno acquisendo competenze IAM e API cloud, e la lifecycle deletion rappresenta uno dei low-effort/high-impact più attraenti del catalogo. La geografia degli incidenti riflette quella dell'adozione cloud: Nord America ed Europa occidentale come vittime primarie, con settori finance, healthcare e SaaS particolarmente esposti per la concentrazione di dati critici in bucket S3 e Blob Storage.

La prospettiva difensiva richiede di trattare le lifecycle policy come high-privilege configuration, sottoponendole a change management, MFA obbligatoria e review peer come già avviene per policy IAM.

MITRE ATT&CK T1485.001 (Lifecycle-Triggered Deletion), tattica TA0040 Impact. Mitigazioni M1018 (User Account Management) e M1053 (Data Backup). Detection DET0041 con analytic AN0117 su log AWS CloudTrail. Documentazione ufficiale AWS S3 Lifecycle, Azure Blob Storage Lifecycle Management, GCP Object Lifecycle Management. Per comandi operativi e tool (AWS CLI, Azure CLI, gsutil, Pacu, ScoutSuite, CloudSploit, AWS Config, AWS Backup) è stata utilizzata conoscenza professionale di cybersecurity cloud, con riferimento a documentazione pubblica dei rispettivi progetti e vendor.