Manipolazione Gerarchia Cloud: Modify Cloud Resource Hierarchy (T1666)

In un ingaggio red team autorizzato, la simulazione di T1666 richiede un tenant di laboratorio dedicato per evitare impatti su ambienti reali. Il prerequisito è l'ottenimento di credenziali con privilegi elevati: in AWS un ruolo con permessi organizations:LeaveOrganization o organizations:CreateAccount, in Azure un account con ruolo Global Administrator o Owner sulla root management group.

Sul versante AWS, la baseline di enumerazione parte dalla AWS CLI (open source). Il comando aws organizations describe-organization rivela la struttura corrente, mentre aws organizations list-accounts mappa gli account membri e aws organizations list-policies --filter SERVICE_CONTROL_POLICY elenca le SCP attive. Per simulare la creazione di un account fuori policy si usa aws organizations create-account --email

La detection di T1666 si fonda sulla correlazione multi-evento tra elevazione di privilegi e modifiche gerarchiche in una finestra temporale ristretta. La sorgente log primaria in AWS è CloudTrail, con particolare attenzione agli eventi management-level dell'API Organizations. Gli event name critici sono LeaveOrganization, CreateAccount, MoveAccount, RemoveAccountFromOrganization, CreateOrganizationalUnit e DeletePolicy. In Azure la fonte è Azure Activity Log integrato con Microsoft Entra ID audit logs, monitorando operazioni come Microsoft.Management/managementGroups/write, Microsoft.Subscription/aliases/write e i trasferimenti di billing ownership.

Una regola di detection efficace correla l'assegnazione recente di ruoli privilegiati (Global Administrator, User Access Administrator in Azure; assunzione di OrganizationAccountAccessRole in AWS) con successive modifiche gerarchiche entro 60 minuti. Il tuning richiede la definizione di tre parametri chiave: la TimeWindow di correlazione, una PrivilegedRoleList con i ruoli sensibili dell'organizzazione, e i SubscriptionTransferPatterns che identificano trasferimenti anomali verso tenant esterni.

In ambiente Splunk (a pagamento) o Microsoft Sentinel (a pagamento), una query di base filtra su eventSource=organizations.amazonaws.com combinata con eventName appartenenti alla lista sopra, arricchendo con l'identità sourceIPAddress e userAgent per identificare chiamate da SDK non standard. Su Sentinel il KQL analogo interroga AzureActivity con OperationNameValue contenente le stringhe di management group o subscription movement.

Gli indicatori comportamentali di alto valore includono: creazione di sottoscrizioni Azure al di fuori degli orari lavorativi, chiamate CreateAccount provenienti da IP non associati al team cloud, e sequenze in cui un utente eleva privilegi tramite PIM (Privileged Identity Management) e immediatamente esegue modifiche strutturali. Il trasferimento di sottoscrizione verso tenant esterni è particolarmente critico perché dopo l'accettazione da parte del tenant destinatario, la visibilità sui log operativi viene persa definitivamente.

I falsi positivi principali derivano da attività legittime di riorganizzazione aziendale, provisioning automatizzato tramite Terraform (open source) o AWS Control Tower, e onboarding di nuove business unit. Il triage deve verificare se la modifica è tracciata in un change ticket approvato e se l'identità operante è un service principal noto. Come misura di hardening preventivo, è consigliabile applicare una SCP che neghi organizations:LeaveOrganization a tutti gli account membri e una Azure Policy che blocchi i subscription transfer verso directory esterne non approvate, come raccomandato dalla mitigazione M1054.

L'indagine forense su T1666 è particolare perché gran parte delle prove risiede nel piano di controllo cloud, non su endpoint tradizionali. La ricostruzione della timeline parte dall'esportazione completa dei log CloudTrail o Azure Activity Log relativi alla finestra sospetta, idealmente ampliata di 30 giorni prima e dopo l'evento pivot per catturare ricognizione preparatoria e attività post-modifica.

In AWS gli artefatti primari sono gli eventi CloudTrail con eventSource=organizations.amazonaws.com. Ogni record contiene userIdentity (con tipo, ARN, accountId, sessionContext), sourceIPAddress, userAgent, requestParameters e responseElements. Per un evento CreateAccount il responseElements.createAccountStatus.id permette di seguire lo stato asincrono della creazione tramite DescribeCreateAccountStatus. Per LeaveOrganization è cruciale identificare se l'evento è stato preceduto da modifiche alle SCP che avrebbero dovuto impedirlo, indicando manomissione della catena di controllo. La query CloudTrail Lake con SQL permette pivot temporali efficienti: filtrando per userIdentity.arn si ricostruiscono tutte le azioni dell'identità compromessa.

In Azure l'analisi si concentra su tre fonti complementari. Azure Activity Log registra le operazioni sui resource provider Microsoft.Management e Microsoft.Subscription. Entra ID Audit Logs traccia le assegnazioni di ruolo, incluse le attivazioni PIM che precedono le modifiche. Entra ID Sign-in Logs correla l'attività amministrativa con l'origine geografica, il device e lo stato del conditional access. Per il subscription hijacking, l'evento chiave è Transfer billing ownership nella sezione Microsoft.Billing, con dettagli sul tenant di destinazione nel campo properties.

La timeline forense deve integrare: (1) evento di autenticazione iniziale con IP e user agent, (2) eventuale escalation di privilegi tramite PIM o role assignment diretto, (3) enumerazione della gerarchia tramite chiamate read-only come ListAccounts o ListManagementGroups, (4) esecuzione della modifica strutturale, (5) attività post-modifica sull'infrastruttura riorganizzata. Strumenti utili includono AWS CloudTrail Lake (a pagamento) per query SQL su volumi elevati, Azure Log Analytics (a pagamento) con KQL, e CloudGrappler (open source) per la ricerca di TTP noti nei log AWS.

Un aspetto critico è che dopo un LeaveOrganization riuscito, l'account esce dalla visibilità del management account: i log successivi risiedono solo nell'account separato e potrebbero essere stati sanitizzati dall'attaccante. Analogamente, sottoscrizioni Azure trasferite non generano più log nel tenant originario. La preservazione delle evidenze richiede quindi export immediato verso storage immutabile (S3 Object Lock o Azure Blob immutable storage, entrambi a pagamento) prima che l'attaccante possa completare l'esfiltrazione strutturale.

Il framework MITRE ATT&CK non associa attualmente a T1666 gruppi APT documentati, software specifici o campagne nominali. Questa assenza di attribuzione formale riflette la natura relativamente recente della tecnica, aggiunta al framework per rispondere all'evoluzione degli attacchi cloud-native, e la difficoltà di raccogliere telemetria condivisibile su incidenti che coinvolgono modifiche strutturali dei tenant.

Dal punto di vista dell'intelligence, la tecnica si inserisce in un trend più ampio di cloud-conscious threat actors che dimostrano competenze specifiche sui modelli di identità e billing dei principali cloud provider. La rilevanza strategica di T1666 risiede nel suo utilizzo come capstone technique: raramente rappresenta il vettore iniziale, ma è tipicamente osservata in fasi avanzate della kill chain quando l'attaccante, già in possesso di credenziali privilegiate, cerca di consolidare l'accesso o preparare esfiltrazione di risorse compute a lungo termine.

I pattern di rischio più significativi da monitorare in threat intelligence includono le operazioni di cryptojacking su larga scala, dove il subscription hijacking Azure consente di spostare il costo del mining su tenant vittima senza generare alert sul consumo anomalo nel tenant originario. Un secondo pattern riguarda operazioni di business email compromise evolute in cui l'attaccante, dopo aver compromesso un Global Administrator, crea sottoscrizioni parallele per hosting di infrastruttura di phishing che appare legittimamente associata al dominio della vittima.

Dal punto di vista della prioritizzazione difensiva, le organizzazioni più esposte sono quelle con strutture Organization AWS o Azure Management Group complesse, spesso frutto di acquisizioni o riorganizzazioni, dove la governance sui ruoli root è frammentata. Il rischio aumenta significativamente in presenza di account payment consolidator che raggruppano decine di sottoscrizioni figlie, poiché la compromissione del management account espone l'intera gerarchia.

Gli indicatori di threat intelligence tattici da inserire nei feed interni includono: pattern di user agent associati a SDK cloud utilizzati da automazione malevola (comune l'uso di boto3 o Az PowerShell da IP residenziali o VPS commerciali), timing anomalo delle chiamate Organizations API, e tenant di destinazione ricorrenti nei tentativi di subscription transfer. La condivisione di questi indicatori tramite ISAC settoriali resta limitata, ma i cloud provider security bulletin di AWS e Microsoft rappresentano fonti di riferimento per pattern emergenti.

La maturazione della threat intelligence su T1666 dipenderà dalla capacità della community di correlare incidenti cloud attualmente trattati in silos, e dall'adozione di framework di reporting come OCSF (Open Cybersecurity Schema Framework, open source) che facilitino la normalizzazione degli eventi multi-cloud.

MITRE ATT&CK: T1666 (Modify Cloud Resource Hierarchy), tattica TA0005. Mitigazioni M1018 (User Account Management), M1047 (Audit), M1054 (Software Configuration). Detection strategy DET0155 con analytic AN0442. Per comandi CLI, tool di detection (Prowler, ScoutSuite, Pacu, CloudGrappler) e piattaforme SIEM citate è stata integrata conoscenza professionale di cybersecurity cloud, verificando l'esistenza e la sintassi dei tool tramite documentazione ufficiale dei rispettivi progetti.