Furto Segreti Cloud: Cloud Secrets Management Stores (T1555.006)

In un ingaggio red team autorizzato su ambiente cloud, la simulazione di T1555.006 parte sempre dall'enumerazione delle identità e dei permessi disponibili. Dopo aver ottenuto credenziali iniziali (via phishing, chiavi statiche esposte in repository, o SSRF su istanze EC2/GCE), il primo passo è capire cosa quell'identità può leggere dal vault.

Su AWS, l'enumerazione parte da aws sts get-caller-identity per confermare il principal, seguita da aws secretsmanager list-secrets per elencare i segreti visibili. Il retrieval avviene con aws secretsmanager get-secret-value --secret-id . Se la policy IAM è permissiva, un ciclo bash sui risultati di list-secrets estrae rapidamente l'intero inventario. Il tool Pacu (open source), framework di exploitation AWS mantenuto da Rhino Security Labs, automatizza questo flusso tramite il modulo enum_secrets, che itera su Secrets Manager e Parameter Store in tutte le regioni abilitate.

Su Azure, dopo l'autenticazione con az login o token da service principal compromesso, si enumera con az keyvault list e az keyvault secret list --vault-name , per poi estrarre con az keyvault secret show --vault-name --name . ROADtools (open source) e MicroBurst (open source) di NetSPI includono moduli specifici per l'enumerazione di Key Vault a partire da identità Entra ID compromesse.

Su GCP, la sequenza è gcloud secrets list, gcloud secrets versions list e gcloud secrets versions access latest --secret=. Il tool GCPBucketBrute e più in generale ScoutSuite (open source) di NCC Group forniscono audit ricognitivi utili in fase di pianificazione.

La catena d'attacco tipica combina più tecniche: compromissione di un'identità con Valid Accounts (T1078.004), escalation via role assumption o abuso di iam:PassRole, quindi estrazione dei segreti. Un pattern particolarmente efficace nei lab è la compromissione di una Lambda function o Cloud Run service con ruolo eccessivamente permissivo: il codice della funzione viene modificato per invocare get-secret-value durante la sua esecuzione naturale, evitando chiamate dirette dall'esterno.

Per allestire un lab di studio, LocalStack (freemium) emula Secrets Manager AWS, mentre CloudGoat (open source) di Rhino Security Labs offre scenari pre-costruiti includendo percorsi che culminano nel furto di segreti. Su Azure, PurpleCloud (open source) e i moduli didattici di AzureGoat (open source) permettono di simulare l'intera catena in modo lab-safe.

La detection di T1555.006 è quasi interamente basata sui log di control plane cloud, dove ogni chiamata API al vault viene registrata con identità chiamante, timestamp, IP sorgente e segreto target. La logica di allerta descritta in AN0366 si fonda sulla correlazione tra retrieval di segreti e contesto autenticativo circostante.

Su AWS, la fonte primaria è CloudTrail: gli eventi rilevanti sono GetSecretValue, BatchGetSecretValue, DescribeSecret e ListSecrets nel service secretsmanager.amazonaws.com. Una query base in Athena o CloudTrail Lake filtra per eventName = 'GetSecretValue' e aggrega per userIdentity.arn, evidenziando principal che accedono a un numero anomalo di segreti in una finestra ristretta. La stessa logica si applica ai Parameter Store con parametri di tipo SecureString.

Su Azure, i log rilevanti risiedono nella categoria AuditEvent di Azure Monitor per Key Vault, con operazioni come SecretGet, VaultGet e KeyGet. In Log Analytics una query KQL su AzureDiagnostics filtrando ResourceType == 'VAULTS' e OperationName == 'SecretGet' espone il pattern d'accesso. Su GCP, i Cloud Audit Logs (categoria Data Access) tracciano AccessSecretVersion nel servizio secretmanager.googleapis.com; questa categoria va abilitata esplicitamente perché non è attiva di default.

Gli indicatori comportamentali chiave, in linea con i parametri di tuning suggeriti in AN0366, sono quattro. PrivilegedRoles: mantenere una allowlist di identità autorizzate a leggere segreti, allertando su ogni deviazione. TimeWindow: correlare la chiamata get-secret con la sessione autenticativa che l'ha originata (assume-role, token issuance, login interattivo) per identificare catene sospette come login da nuovo IP seguito entro pochi minuti dall'enumerazione dei segreti. AccessPatterns: baseline della frequenza e volume di retrieval per identità; una Lambda che normalmente legge un segreto per invocazione, se improvvisamente ne legge dieci, va investigata. RegionConstraints: allerta su accessi a vault da regioni non usate dall'organizzazione.

I falsi positivi tipici arrivano da pipeline CI/CD (GitHub Actions, GitLab Runner, Jenkins) che leggono segreti in batch a ogni deploy, da rotation automatiche schedulate, e da nuove Lambda o container appena deployati che leggono la propria configurazione al primo avvio. La tuning richiede tagging accurato di service account e ruoli automatici, escludendoli dalle regole di volume ma mantenendo l'allerta su cambi di IP sorgente per gli stessi principal.

Integrando gli eventi in Splunk, Sentinel o Chronicle, la correlazione con eventi di AssumeRole, ConsoleLogin da IP anomali e chiamate GetCallerIdentity precedenti al retrieval fornisce il contesto decisivo per distinguere attività legittima da abuso.

L'analisi forense di un incidente T1555.006 ruota interamente attorno ai log di control plane cloud, che costituiscono l'unica timeline affidabile dell'evento. Gli artefatti endpoint sono marginali o assenti: l'operazione non tocca il filesystem della vittima se non nel momento in cui il segreto rubato viene riutilizzato altrove.

Su AWS, la ricostruzione parte dall'export selettivo di CloudTrail verso un bucket S3 dedicato all'indagine e dall'ingestion in Athena. Le tabelle da interrogare contengono i campi eventTime, userIdentity (con sub-campi arn, accessKeyId, sessionContext), sourceIPAddress, userAgent, requestParameters.secretId e responseElements. La sequenza tipica ricostruibile è: evento AssumeRole o GetSessionToken, seguito da ListSecrets per l'enumerazione, quindi una serie di GetSecretValue sui segreti di interesse. L'accessKeyId temporaneo emesso dall'assume-role fa da filo conduttore che lega le chiamate a una singola sessione.

Su Azure, i Diagnostic Settings del Key Vault devono essere configurati per esportare gli eventi verso un Log Analytics Workspace o uno Storage Account; senza questa configurazione la ricostruzione retrospettiva è impossibile. Gli eventi SecretGet, insieme ai log di Microsoft Entra ID Sign-in e Audit, permettono di correlare l'identità che ha effettuato il retrieval con la sessione autenticativa originale, l'IP e l'eventuale token OAuth utilizzato. Nel caso HAFNIUM, il movimento da on-premise ad Azure implica ricostruire anche la catena AD FS o Azure AD Connect che ha permesso l'emissione di token validi per l'ambiente cloud.

Su GCP, i Cloud Audit Logs in Cloud Logging tracciano AccessSecretVersion con dettagli su protoPayload.authenticationInfo.principalEmail e protoPayload.requestMetadata.callerIp. L'export verso BigQuery consente query analitiche sull'intero periodo di retention.

La timeline forense deve includere quattro momenti chiave: acquisizione iniziale dell'identità (login, assume-role, token issuance), enumerazione dei segreti disponibili, retrieval effettivo con lista puntuale dei segreti compromessi, e successivo utilizzo delle credenziali estratte in altri sistemi. Quest'ultimo punto richiede il pivot verso i log dei servizi target: se il segreto era una credenziale database, i log di connessione RDS o Cloud SQL diventano fonte primaria.

Per il caso Storm-0501, l'analisi di operazioni Microsoft.KeyVault/Vaults/write nei log Activity di Azure permette di identificare la creazione o modifica di chiavi usate nella fase di cifratura ransomware, elemento distintivo che collega il vault a un impatto di Impact (TA0040) successivo.

Strumenti utili includono Cartography (open source) di Lyft per mappare relazioni tra identità e risorse cloud, e Prowler (open source) per audit retrospettivi della postura di sicurezza del vault al momento del compromise. Ogni segreto acceduto va considerato compromesso e sottoposto a rotation immediata come parte della response.

L'abuso dei secret manager cloud è un pattern che accomuna attori di natura molto diversa, uniti dal riconoscimento del vault come crown jewel dell'ambiente cloud moderno. I dati MITRE documentano due gruppi con TTP mirate su questa tecnica.

HAFNIUM (G0125), attore state-sponsored di origine cinese noto per lo sfruttamento su larga scala delle vulnerabilità ProxyLogon in Exchange Server nel 2021, ha esteso la propria operatività verso ambienti ibridi. Il gruppo ha dimostrato movimento laterale da on-premise ad Azure Key Vault per esfiltrare password, sfruttando la sincronizzazione di identità tra Active Directory locale ed Entra ID. Questo pattern riflette una tendenza strategica: gli attori APT tradizionalmente focalizzati su on-premise stanno integrando capacità cloud-native per seguire i dati e le credenziali dove effettivamente risiedono nelle organizzazioni moderne.

Storm-0501 (G1053), tracciato da Microsoft Threat Intelligence, è un attore financially-motivated attivo in operazioni ransomware ibride che colpiscono simultaneamente ambienti on-premise e cloud. Il gruppo ha utilizzato Azure Key Vault con l'operazione Microsoft.KeyVault/Vaults/write per archiviare chiavi di cifratura nel contesto delle proprie campagne, ribaltando l'uso legittimo del vault: invece di rubare segreti, li deposita per finalità di estorsione. Storm-0501 opera come affiliate di diverse famiglie ransomware, incluse Hive, BlackCat/ALPHV, Hunters International, LockBit ed Embargo, e rappresenta l'evoluzione del ransomware verso operazioni cloud-aware.

Sul fronte del tooling, Pacu (S1091), framework di exploitation AWS open source, include il modulo enum_secrets che automatizza il retrieval da Secrets Manager. Pacu è ampiamente adottato sia in contesti red team legittimi sia da attori malevoli per la sua modularità; la presenza di comandi Pacu-compatibili nei log CloudTrail (identificabili tramite pattern nel userAgent) è un indicatore da monitorare.

Dal punto di vista dei trend, l'osservazione dei due profili suggerisce due direttrici di evoluzione. La prima è la convergenza tra operatori state-sponsored e financially-motivated verso lo stesso set di TTP cloud: HAFNIUM per intelligence collection, Storm-0501 per estorsione, ma con overlap tecnico sostanziale. La seconda è l'importanza crescente dei service principal e delle managed identity compromesse come vettore d'accesso al vault, poiché frequentemente hanno permessi eccessivi ereditati da configurazioni permissive iniziali mai riviste.

Per un threat intelligence officer, gli indicatori prioritari da monitorare includono chiamate a secret manager da IP non associati all'infrastruttura organizzativa, uso di userAgent generici o riconducibili a tool di offensive security, e sequenze di enumeration-then-retrieval concentrate temporalmente su identità che normalmente accedono a un singolo segreto.

MITRE ATT&CK T1555.006 (Cloud Secrets Management Stores), tattica TA0006. Gruppi: G0125 (HAFNIUM), G1053 (Storm-0501). Software: S1091 (Pacu). Mitigazione M1026 (Privileged Account Management). Detection DET0130 con analytic AN0366 (IaaS). Documentazione ufficiale AWS Secrets Manager, Azure Key Vault, GCP Secret Manager per sintassi CLI. Contenuti Livello 2 (tool Pacu, ROADtools, MicroBurst, ScoutSuite, CloudGoat, Cartography, Prowler, LocalStack) derivano da conoscenza professionale di cybersecurity verificata su repository e documentazione pubblica.