Silenziare il Cloud: Disable or Modify Cloud Log (T1685.002)

In un esercizio di red team autorizzato su AWS, la simulazione parte dopo aver ottenuto credenziali con privilegi cloudtrail:StopLogging o cloudtrail:DeleteTrail. Il framework di riferimento è Pacu (open source), sviluppato da Rhino Security Labs, che espone moduli dedicati alla manipolazione del logging. Dopo aver importato le chiavi con set_keys e configurato la sessione, il modulo detection__disruption enumera i trail attivi e permette di disabilitarli, cancellarli o deviarne la destinazione. La sintassi tipica è:

run detection__disruption --trails --action disable

In alternativa, con AWS CLI (open source) l'operatore può eseguire direttamente aws cloudtrail stop-logging --name oppure aws cloudtrail update-trail --name --no-include-global-service-events --no-is-multi-region-trail per ridurre silenziosamente la copertura senza arrestare completamente il servizio. Un approccio più subdolo è la rimozione del topic SNS associato o la disabilitazione della log file validation con --no-enable-log-file-validation, che compromette l'integrità senza generare un evento vistoso.

Su GCP il red teamer può usare gcloud CLI (open source) per aggiornare o cancellare un sink di esportazione con gcloud logging sinks delete , interrompendo il flusso verso BigQuery o Cloud Storage.

Nel contesto Microsoft 365, la simulazione richiede un account con ruolo Exchange Administrator o superiore. Il modulo Exchange Online PowerShell V3 (gratuito) consente di eseguire:

Set-MailboxAuditBypassAssociation -Identity -AuditBypassEnabled $true

Questo comando esclude l'utente indicato dal mailbox auditing senza rimuovere la configurazione globale, rendendo l'operazione difficile da notare. In alternativa, la disabilitazione di Purview Audit a livello di organizzazione avviene con Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $false, mossa più rumorosa ma efficace.

Per la fase di validazione post-exploitation, tool come ScoutSuite (open source) e Prowler (open source) permettono di verificare quali controlli di logging risultano attivi dopo la manipolazione, simulando la prospettiva del difensore. CloudSploit (freemium, con versione community open source e tier Aqua a pagamento) offre una terza opzione per il baseline check. È fondamentale che ogni azione sia tracciata in un log separato del red team e che le modifiche vengano ripristinate al termine dell'esercizio tramite il journal delle operazioni Pacu.

La detection di questa tecnica poggia su un principio contro-intuitivo: l'evento più importante è l'ultimo evento prima del silenzio. Il SOC deve trattare le API che gestiscono la telemetria come asset di massima criticità, monitorate con la stessa intensità dei sistemi di autenticazione.

Su AWS le chiamate CloudTrail da attenzionare sono StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors e le modifiche ai topic SNS collegati. Una regola di detection efficace correla queste API con l'identità del chiamante, escludendo un allowlist ristretto di ruoli di automazione (tuning AdminRoles). L'evento UpdateTrail con parametri che disattivano IsMultiRegionTrail o EnableLogFileValidation è particolarmente insidioso perché non interrompe il servizio ma ne degrada la copertura (tuning RegionScope). La log source primaria è AWS CloudTrail management events, integrata via Kinesis o direttamente in SIEM.

Su GCP l'evento equivalente è google.logging.v2.ConfigServiceV2.DeleteSink o UpdateSink nel log gcp:config, con particolare attenzione ai sink che esportano verso repository di sicurezza.

Per Microsoft 365 e Entra ID il monitoraggio si sposta sul Unified Audit Log (m365:unified): gli eventi Set-MailboxAuditBypassAssociation, Set-AdminAuditLogConfig e i cambi di licenza da E5 a E3 su account VIP devono generare alert immediati (tuning CriticalAccounts e UserScope). Un pattern particolarmente rilevante — associato ad attività di APT29 — è la disabilitazione di Purview Audit su singole caselle prima di operazioni di raccolta email.

Per piattaforme SaaS (Slack, Zoom, Salesforce, Okta) il segnale è la rimozione di integrazioni di export via API o modifiche alle policy di retention nei log saas:audit. Definire un inventario delle integrazioni attese e alertare su qualsiasi deviazione è la strategia più solida (tuning IntegrationScope).

Un indicatore comportamentale di alto valore è il gap temporale: la scomparsa improvvisa di eventi da una sorgente storicamente attiva. Una detection basata su anomalia sul volume orario per source (Z-score o EWMA) intercetta la disattivazione anche quando l'evento di configurazione viene occultato. I falsi positivi provengono principalmente da manutenzione pianificata, rotazione di trail per compliance e dismissione di account: tenere un change calendar consultabile dall'analista riduce drasticamente il triage. Ogni alert dovrebbe scatenare una playbook di verifica dello stato reale del logging tramite chiamata read-only fuori banda.

L'analisi forense di eventi di disabilitazione del logging cloud si scontra con un paradosso: il difensore deve ricostruire ciò che è accaduto proprio quando la fonte primaria è stata compromessa. La strategia si basa sulla triangolazione tra fonti ridondanti e sull'analisi del confine temporale.

Su AWS l'artefatto centrale resta il record CloudTrail dell'evento StopLogging o DeleteTrail, che tipicamente sopravvive perché scritto prima che l'interruzione diventi effettiva. I campi da estrarre sono userIdentity.arn, sourceIPAddress, userAgent, requestParameters.name e eventTime. Se il trail è configurato con delivery cross-account verso un account di sicurezza dedicato, la copia rimane integra anche se l'attaccante compromette l'account operativo — pratica raccomandata proprio per casi come questo. Il CloudTrail Digest firmato con validazione file di log, quando abilitato, permette di dimostrare l'integrità (o la manomissione) della catena.

Fonti secondarie da correlare: VPC Flow Logs (che continuano se non specificamente disattivati), AWS Config configuration history, GuardDuty findings e i log di CloudWatch stesso. La ricostruzione della timeline parte dall'ultimo evento CloudTrail e prosegue analizzando le sessioni STS attive al momento del silenzio, per identificare quali identità potrebbero aver operato durante la finestra cieca.

Su GCP il Cloud Audit Log — Admin Activity è protetto contro la disattivazione e conserva le modifiche ai sink; l'analista deve confrontare la configurazione precedente con quella successiva per determinare cosa non è più esportato.

In Microsoft 365 l'artefatto chiave è il record Set-MailboxAuditBypassAssociation nel Unified Audit Log, con timestamp, UPN dell'operatore e target. Il downgrade di licenza è tracciato nel log di Entra ID come Update user con delta sulle assigned licenses. La campagna documentata di APT29 contro tenant M365 mostra come il bypass di Purview Audit venga applicato in modo mirato subito prima delle operazioni di raccolta email, quindi la finestra investigativa deve estendersi a ritroso di alcune ore rispetto al primo alert.

La timeline finale deve includere: momento di ottenimento del privilegio necessario (evento di role assumption o consent grant), evento di modifica del logging, durata della finestra cieca, evento di ripristino (se avvenuto). Per la catena di custodia, è essenziale acquisire snapshot delle configurazioni tramite API read-only autenticata con credenziali investigative separate, esportando i risultati in formato JSON firmato e conservando gli hash SHA-256 in un repository WORM.

L'adozione della disabilitazione del logging cloud come tecnica ricorrente segna la maturazione degli avversari nel dominio cloud-native: non più semplice accesso alle risorse, ma gestione attiva del proprio footprint di rilevabilità. La tecnica è caratteristica di attori con obiettivi di persistenza lunga e raccolta prolungata di intelligence.

Il profilo di riferimento è APT29 (G0016), gruppo attribuito al Foreign Intelligence Service russo (SVR) e noto anche come Cozy Bear, Midnight Blizzard o NOBELIUM. La sua modalità operativa documentata prevede la disabilitazione di Purview Audit su caselle di posta specifiche all'interno di tenant Microsoft 365 compromessi, immediatamente prima di operazioni di esfiltrazione email. Questo pattern è coerente con la storica focalizzazione del gruppo su targeting di governi occidentali, think tank e organizzazioni tecnologiche, dove la persistenza silenziosa vale più dell'ampiezza dell'accesso. La scelta di operare a livello di singolo account — anziché disabilitare l'auditing globale, che sarebbe rumoroso — riflette una raffinata comprensione dei meccanismi di detection di Microsoft e una postura operativa disciplinata.

Sul fronte del tooling, Pacu (S1091) rappresenta il framework offensivo AWS di riferimento anche per attori non-state. Sviluppato originariamente come strumento di red team, è stato osservato in mano ad attori criminali che operano cryptojacking, data theft e ransomware cloud-native. La sua modularità e la disponibilità pubblica su GitHub abbassano drasticamente la barriera d'ingresso: un attore con credenziali AWS rubate può disattivare CloudTrail e VPC Flow Logs con pochi comandi, senza sviluppare capacità proprie.

Dal punto di vista dei trend, si osserva una convergenza tra gruppi state-sponsored e cybercrime nell'uso della manipolazione del logging come precondizione operativa. Il valore strategico della tecnica risiede nella sua natura di force multiplier: ogni successivo movimento laterale, raccolta o esfiltrazione avviene in una zona di opacità che dilata drasticamente il dwell time medio dell'intrusione. In ambienti multi-cloud, dove la telemetria è spesso frammentata tra provider, la disabilitazione anche parziale del logging su una sola piattaforma può compromettere l'intera capacità di ricostruzione dell'incidente.

Per il threat intelligence officer la raccomandazione operativa è duplice: mantenere aggiornata la mappa delle identità con privilegi di modifica del logging in ogni tenant cloud, e monitorare la disclosure pubblica di nuove tecniche di log tampering nei provider emergenti (SaaS verticali, piattaforme AI), dove i controlli di audit sono spesso meno maturi rispetto ai grandi hyperscaler. La disciplina di APT29 nella tecnica suggerisce inoltre che l'assenza di log su un account critico debba essere trattata come indicatore forte di compromissione avanzata, non come banale problema di configurazione.

MITRE ATT&CK: T1685.002 (Disable or Modify Cloud Log), TA0112 (Defense Impairment), G0016 (APT29), S1091 (Pacu), M1018 (User Account Management). Detection strategy DET0289 con analytics AN0801-AN0804. Per comandi operativi, sintassi di tool e procedure di detection è stata integrata conoscenza professionale verificata su documentazione ufficiale AWS CLI, gcloud, Exchange Online PowerShell V3 e repository pubblici di Pacu, ScoutSuite, Prowler e CloudSploit.