Modifica Configurazioni Cloud Compute: Modify Cloud Compute Configurations (T1578.005)

In un ingaggio red team autorizzato su ambiente cloud, la simulazione di T1578.005 richiede un account con privilegi sufficienti per toccare quote e policy tenant-wide. Il primo passo consiste nel mappare le quote correnti per capire quali sono i vincoli attivi.

Su AWS, l'enumerazione delle quote di servizio si effettua con la CLI ufficiale (open source):

aws service-quotas list-service-quotas --service-code ec2

Seguito da aws service-quotas request-service-quota-increase --service-code ec2 --quota-code L-1216C47A --desired-value 500 per simulare la richiesta di aumento del limite Running On-Demand Standard instances. In un lab controllato, questa richiesta genera un ticket interno e permette di validare se il SOC intercetta la chiamata RequestServiceQuotaIncrease in CloudTrail.

Su Azure, l'equivalente è la modifica delle quote via az vm list-usage --location westeurope per enumerare, seguito da az quota update per richiedere l'aumento. Le policy tenant-wide che limitano SKU di VM sono gestite tramite Azure Policy: az policy assignment list per elencarle, az policy assignment delete per rimuoverle in scenario di attacco.

Su GCP, l'enumerazione avviene con gcloud compute project-info describe --project e le richieste di quota passano attraverso la Console o l'API Service Usage.

Per l'abilitazione di regioni inutilizzate — vettore particolarmente insidioso perché il logging in regioni non usate raramente è centralizzato — su AWS si opera con aws ec2 enable-region (dove disponibile) o con la modifica delle Service Control Policy in AWS Organizations tramite aws organizations update-policy.

Strumenti utili in laboratorio includono Pacu (open source), framework di offensive security specifico per AWS con moduli come iam__enum_permissions e enum__account per capire cosa l'account compromesso può realmente modificare. ScoutSuite (open source) consente invece un assessment configurativo pre-attacco per identificare policy deboli. Per Azure, MicroBurst (open source) offre script PowerShell come Get-AzPasswords e moduli per enumerare configurazioni tenant.

La catena completa in un esercizio realistico prevede: compromissione iniziale di credenziali con privilegi IAM elevati, enumerazione delle quote esistenti, richiesta di aumento mirato (non enorme, per non insospettire), attesa dell'approvazione automatica se prevista, deployment di risorse compute nella nuova capacità, opzionalmente pivot verso una regione poco monitorata. Documentare ogni step per il report finale è essenziale per dimostrare l'impatto business.

La detection strategy DET0492 con analytic AN1356 indica chiaramente il perimetro: monitorare cambiamenti anomali o non autorizzati alle configurazioni compute che alterano quote, policy tenant-wide, associazioni di sottoscrizione o regioni consentite. La log source principale è AWS CloudTrail, con equivalenti Azure Activity Log e GCP Cloud Audit Logs.

Gli eventi chiave da instrumentare su AWS includono RequestServiceQuotaIncrease, PutServiceQuotaIncreaseRequestIntoTemplate, AssociateServiceQuotaTemplate e le modifiche a UpdatePolicy di AWS Organizations. Su Azure occorre osservare le operazioni Microsoft.Quota/quotas/write e Microsoft.Authorization/policyAssignments/delete. Su GCP le operazioni serviceusage.googleapis.com relative a quota increase e le modifiche a Organization Policy.

La vera efficacia detection nasce dalla correlazione di catene comportamentali, non dal singolo evento. Il pattern sospetto tipico è: richiesta di aumento quota → approvazione (spesso automatica sotto certe soglie) → creazione entro poche ore di istanze compute nella nuova capacità disponibile. Un'altra catena rilevante è: disabilitazione o modifica di una policy tenant-wide che limita SKU → deployment immediato di VM di grandi dimensioni.

Il tuning suggerito dal framework include quattro dimensioni: UserContext (identità che esegue la modifica, filtrando admin noti e service account di automazione), TimeWindow (finestra di correlazione tra modifica configurativa e successivo provisioning, tipicamente 1-6 ore), ChangeType (quota, policy, regione — con soglie di rischio diverse) e GeoLocation (regione da cui origina la modifica rispetto alla geografia operativa attesa).

Dal punto di vista D3FEND, le tecniche difensive rilevanti sono Operational Activity Mapping e Administrative Network Activity Analysis, che consistono nel costruire una baseline delle attività amministrative attese per identificare deviazioni. Anche Domain Trust Policy nella sua estensione cloud (tenant policy monitoring) è pertinente.

Come regole SIEM concrete, un alert utile è: evento di quota increase seguito entro 4 ore da N eventi di RunInstances dello stesso account, dove N eccede la baseline storica. Un secondo alert riguarda l'abilitazione di regioni non presenti nella whitelist operativa aziendale. Un terzo intercetta modifiche a Service Control Policy da parte di identità non appartenenti al gruppo autorizzato.

I falsi positivi più comuni derivano da legittime espansioni di capacità (lancio di prodotto, evento stagionale), attività di FinOps team che ridimensiona quote, migrazioni verso nuove regioni per compliance o latenza. Serve un raccordo stretto con Cloud Engineering per mantenere una allowlist di change window pianificate e di identità autorizzate a operare sulle policy tenant-wide.

L'analisi forense di un incidente T1578.005 è essenzialmente log-centric e si svolge sui piani di controllo cloud, non su artefatti endpoint tradizionali. La timeline di riferimento si costruisce a partire da CloudTrail su AWS, Activity Log su Azure e Cloud Audit Logs su GCP.

Gli artefatti primari da acquisire su AWS sono i CloudTrail events completi, con particolare attenzione ai campi eventName, userIdentity (inclusi arn, accessKeyId, sessionContext), sourceIPAddress, userAgent, requestParameters e responseElements. Gli eventi target includono RequestServiceQuotaIncrease, AssociateServiceQuotaTemplate, EnableRegion, UpdatePolicy di Organizations, oltre alle modifiche IAM che hanno preceduto e reso possibile l'azione — spesso una AttachUserPolicy o PutUserPolicy con privilegi servicequotas:* o organizations:UpdatePolicy.

Su Azure gli artefatti equivalenti si trovano nell'Activity Log e nell'Azure AD Audit Log, esportabili verso Log Analytics workspace o storage account per retention estesa. I campi Caller, CallerIpAddress, OperationName e Properties consentono di ricostruire chi ha fatto cosa. Su GCP il Cloud Audit Log con i suoi tre stream (Admin Activity, Data Access, System Event) fornisce visibilità analoga.

La timeline di attacco tipica che l'analista deve ricostruire ha questa forma: T0 compromissione credenziale (spesso via phishing o key leak su repository pubblici — verificabile con TruffleHog (open source) o con ricerche in Certificate Transparency); T+ore enumerazione privilegi tramite chiamate GetUser, ListAttachedUserPolicies, SimulatePrincipalPolicy; T+ore modifica configurativa — richiesta quota o modifica policy; T+ore/giorni deployment di risorse compute abusive.

Per arricchire l'attribuzione, gli indirizzi IP sorgente vanno correlati con feed di threat intelligence e con VirusTotal (freemium) per verificare associazioni note a infrastrutture malevole. Il campo userAgent può rivelare l'uso di SDK sospetti o tool automatizzati (spesso Boto3 con versione specifica, o user agent di Pacu).

In assenza di CloudTrail multi-region abilitato, un'importante verifica forense è se l'attaccante ha operato in una regione dove il logging non era attivo — scenario particolarmente rilevante quando il vettore d'attacco include proprio l'abilitazione di regioni inutilizzate. Strumenti come CloudTrail Lake (a pagamento) o Athena su S3 con log CloudTrail (a pagamento pay-per-query) consentono query SQL efficienti su grandi volumi.

Per la conservazione a fini legali, i log vanno esportati in storage immutabile (S3 Object Lock, Azure Immutable Blob) con hash SHA-256 documentato nella chain of custody. La ricostruzione dei costi cloud generati dall'attività abusiva, tramite Cost Explorer o Cost Management, è elemento probatorio essenziale per quantificare il danno.

I dati MITRE ATT&CK forniti per T1578.005 non associano gruppi APT, software o campagne documentate specificamente a questa tecnica. Questa assenza non va interpretata come mancanza di rilevanza operativa, ma piuttosto come riflesso di due fattori: la relativa recenza della sottotecnica nel catalogo ATT&CK cloud e la difficoltà intrinseca di attribuzione delle azioni sul piano di controllo cloud a cluster di attività noti, dato che le modifiche configurative sono spesso indistinguibili da attività amministrativa legittima senza contesto approfondito.

Dal punto di vista del threat intelligence officer, l'analisi deve concentrarsi sui pattern comportamentali e sulle motivazioni degli attori piuttosto che su attribuzioni specifiche. La modifica di configurazioni compute è tipicamente osservata in due contesti motivazionali. Il primo è il cybercrime finanziariamente motivato, dove il compromise di tenant cloud serve a lanciare operazioni di cryptomining su larga scala — pattern noto come cryptojacking cloud. In questi scenari, l'aumento di quota è strumentale alla massimizzazione del profitto prima che la vittima scopra l'abuso, tipicamente attraverso la bolletta cloud del mese successivo.

Il secondo contesto è quello di actor state-sponsored che utilizzano risorse compute della vittima per campagne di lunga durata: infrastruttura di staging per exfiltration, nodi C2, o processing di credenziali rubate. In questo caso la modifica configurativa è più chirurgica — piccoli aumenti di quota, abilitazione di regioni specifiche con favorevole giurisdizione — e mira alla persistenza silenziosa.

Un trend rilevante è la crescita dell'abuso di cloud regions inutilizzate. La sottotecnica correlata T1535 (Unused/Unsupported Cloud Regions) è spesso combinata con T1578.005 in kill chain integrate. Le organizzazioni tendono a non abilitare logging e monitoring in regioni dove non operano commercialmente, creando zone cieche persistenti che gli adversary sfruttano sistematicamente.

Per arricchire l'intelligence interna, i team dovrebbero mantenere una watchlist di indicatori comportamentali: incrementi di quota superiori al 200% della baseline, richieste di quota provenienti da nuovi paesi geografici, modifiche a Service Control Policy fuori orario lavorativo, abilitazione di regioni non presenti nel piano commerciale.

Dal punto di vista della priorità di mitigazione, T1578.005 va considerata ad alto impatto perché combina evasione difensiva e monetizzazione diretta. Le mitigazioni M1018 (User Account Management) e M1047 (Audit) vanno implementate insieme: la prima limita chi può richiedere modifiche, la seconda garantisce che quelle modifiche siano tracciate e riviste. L'integrazione con processi FinOps e con approval workflow multi-persona per modifiche a policy tenant-wide rappresenta una barriera organizzativa efficace che va oltre il puro controllo tecnico.

MITRE ATT&CK T1578.005 - Modify Cloud Compute Configurations, tattica TA0005. Mitigazioni M1018 (User Account Management) e M1047 (Audit). Detection strategy DET0492 con analytic AN1356 su log source AWS CloudTrail. MITRE D3FEND per tecniche difensive di Operational Activity Mapping. La sezione forensic e ethical hacker integra conoscenza professionale su tool cloud (Pacu, ScoutSuite, MicroBurst, TruffleHog), CLI ufficiali AWS/Azure/GCP e servizi di logging nativi, verificati come attivi e documentati pubblicamente.