Elevazione Temporanea in Cloud: Temporary Elevated Cloud Access (T1548.005)

L'enumerazione delle permission è il punto di partenza. In un ambiente AWS, dopo aver ottenuto credenziali iniziali (chiave IAM leaked, istanza EC2 con instance profile permissivo, credenziali in un repo Git), il primo passo è mappare le policy associate all'identità corrente.

Con AWS CLI (gratuito) l'operatore esegue aws sts get-caller-identity per verificare il principal attivo e aws iam list-attached-user-policies --user-name per elencare le policy gestite. Per un'analisi automatizzata dei percorsi di escalation, Pacu (open source, framework di exploitation AWS di Rhino Security Labs) offre moduli come iam__privesc_scan che identificano combinazioni pericolose di permission, inclusa la presenza di iam:PassRole associata a lambda:CreateFunction o ec2:RunInstances. Un altro strumento chiave è PMapper (open source), che costruisce un grafo delle relazioni IAM e calcola i percorsi di privilege escalation con query tipo pmapper graph query "who can do sts:AssumeRole with ".

Una catena tipica in AWS: l'attaccante controlla un utente con iam:PassRole e lambda:CreateFunction; crea una Lambda che assume un ruolo amministrativo passato al servizio, poi la invoca. Il comando è aws lambda create-function --function-name esc --role arn:aws:iam:::role/AdminRole --runtime python3.11 --handler index.handler --zip-file fileb://payload.zip. Il codice della Lambda usa il ruolo pass-ato per emettere chiamate privilegiate.

In GCP, con gcloud (gratuito) si enumera con gcloud iam service-accounts list e si verifica la possibilità di generare token con gcloud iam service-accounts get-access-token --impersonate-service-account=. Se l'identità ha roles/iam.serviceAccountTokenCreator sul target, il token viene emesso e usato per operare come il service account bersaglio. GCPBucketBrute e hayat (entrambi open source) supportano il recon iniziale, mentre lo script gcp_scanner di Google (open source) enumera permission accessibili.

Per Microsoft 365, il ruolo ApplicationImpersonation consente a un service principal di operare come utente arbitrario contro Exchange Online. Il tool MailSniper (open source) di Beau Bullock automatizza l'accesso a mailbox tramite impersonation, mentre ROADtools (open source) e AADInternals (open source) permettono di enumerare application permission e delegated permission nel tenant Azure AD. Il comando Get-ManagementRoleAssignment -Role ApplicationImpersonation in PowerShell Exchange Online (gratuito con licenza) elenca gli assegnatari del ruolo, punto di partenza per identificare account abusabili nel lab.

La detection di questa tecnica si basa quasi interamente su log del control plane cloud, perché l'attività avviene tramite API legittime e non genera artefatti endpoint. La strategia DET0393 definita da MITRE identifica tre analytics chiave, una per ciascun ecosistema principale.

Per AWS, l'analytic AN1105 si concentra su CloudTrail, in particolare sugli eventi PassRole e AssumeRole correlati temporalmente. L'indicatore forte è la sequenza in cui un principal invoca iam:PassRole verso un servizio (Lambda, EC2, ECS) seguita a breve da una AssumeRole che restituisce credenziali temporanee per un ruolo privilegiato non abitualmente assunto da quel principal. Le query Athena o Splunk devono correlare eventName=PassRole con eventName=AssumeRole entro una finestra di pochi minuti, filtrando per requestParameters.roleArn e userIdentity.arn. Il tuning suggerito da MITRE include una allowlist di targetRoleName consentiti, una TimeWindow di correlazione (tipicamente 5-15 minuti) e il filtro sul invokingService per limitare i servizi autorizzati al role passing.

Per GCP, l'analytic AN1106 monitora gcp:iam e gcp:workspaceaudit. Gli eventi di interesse sono GenerateAccessToken, GenerateIdToken e SignJwt emessi dal servizio iamcredentials.googleapis.com, oltre alle azioni di domain-wide delegation su Google Workspace. Un pattern sospetto è un service account che genera token per un altro service account amministrativo, o un principal umano che impersona un service account con ruoli Editor/Owner. Il tuning richiede una allowlist di userEmailFilter legittimi e la restrizione degli delegatedScope alle sole funzionalità di business.

Per Microsoft 365, l'analytic AN1107 guarda ai log m365:unified e m365:signinlogs. L'assegnazione del ruolo ApplicationImpersonation genera l'evento New-ManagementRoleAssignment con Role=ApplicationImpersonation, che dovrebbe essere estremamente raro e sempre soggetto ad approval. Anche gli accessi a mailbox effettuati con LogonType=Delegated o Owner=Service verso mailbox VIP o rarely accessed vanno correlati con UserAgent, ClientIP e GeoLocation.

I falsi positivi più comuni includono pipeline CI/CD legittime che usano PassRole verso ruoli di build, backup automatizzati che impersonano service account, e integrazioni SaaS che accedono a mailbox tramite impersonation. La contromisura è una baseline di comportamento per identità e finestre temporali, oltre a un inventario aggiornato di service principal autorizzati. Sul lato preventivo, la mitigazione M1018 raccomanda di applicare least privilege sui permessi IAM, richiedere approval manuale per il JIT access e usare soluzioni PAM (CyberArk, BeyondTrust — a pagamento) per governare le richieste di elevazione temporanea.

L'analisi forense di un abuso di T1548.005 è interamente cloud-native: gli artefatti risiedono nei log di audit del provider, non su disco endpoint. La ricostruzione della timeline richiede l'export completo dei log di control plane per la finestra sospetta e la correlazione tra eventi di autenticazione, emissione di credenziali temporanee e azioni compiute con tali credenziali.

In AWS, CloudTrail è la fonte primaria. Ogni chiamata AssumeRole produce un evento con responseElements.credentials.accessKeyId — una chiave temporanea con prefisso ASIA. Questa chiave diventa il pivot forense: tutte le azioni successive compiute con quelle credenziali riportano lo stesso accessKeyId nel campo userIdentity.accessKeyId, permettendo di isolare l'intera sessione. La query tipica in Athena filtra userIdentity.sessionContext.sessionIssuer.arn per il ruolo assunto e userIdentity.accessKeyId per la chiave temporanea. Va estratto anche sourceIPAddress e userAgent per identificare l'origine, con particolare attenzione a IP che non corrispondono a range aziendali o a user-agent atipici (SDK Python su console amministrative, per esempio). Se la Lambda è stata il vettore, gli CloudWatch Logs della funzione mostrano l'esecuzione del payload; AWS Config aiuta a ricostruire le modifiche allo stato delle risorse.

In GCP, i Cloud Audit Logs (Admin Activity e Data Access) contengono gli eventi GenerateAccessToken con protoPayload.authenticationInfo.principalEmail (l'identità richiedente) e protoPayload.request.name (il service account bersaglio). Il token generato è opaco, ma le azioni successive che lo utilizzano riportano il service account impersonato come principalEmail, mentre authenticationInfo.serviceAccountDelegationInfo mantiene la catena di delega, permettendo di risalire all'identità originaria. Per la domain-wide delegation verso Workspace, i log admin.googleapis.com e i Workspace Audit Logs mostrano l'accesso a Drive, Gmail o Calendar effettuato per conto di utenti target.

In Microsoft 365, l'Unified Audit Log (accessibile via Search-UnifiedAuditLog in PowerShell o dal Purview portal — freemium in base alla licenza) registra gli eventi MailItemsAccessed con LogonType=2 (Delegated) o LogonType=3 (Admin). La proprietà AppId del service principal impersonante e MailboxOwnerUPN del target vanno correlate con ClientInfoString e ClientIPAddress. Azure AD Sign-in Logs completano il quadro mostrando l'autenticazione dell'application con AuthenticationProtocol=OAuth2 e i consent grant sospetti.

La timeline finale deve includere: momento dell'assegnazione o abuso della permission, emissione del token/impersonation, azioni compiute con i privilegi elevati, eventuale creazione di persistenza (nuove chiavi, nuovi service account, backdoor IAM). Strumenti come Cartography (open source, Lyft) e CloudMapper (open source) aiutano a ricostruire lo stato IAM al momento dell'incidente confrontandolo con lo stato attuale.

Nei dati MITRE ATT&CK forniti per T1548.005 non risultano gruppi APT, software o campagne specificamente attribuiti a questa tecnica. Questa assenza non significa che l'abuso di elevazione temporanea in cloud sia raro — anzi, i report pubblici di incident response mostrano che è un vettore ricorrente — ma indica che al momento MITRE non ha formalizzato attribution consolidate. Un threat intelligence officer deve quindi trattare questa tecnica come un capability trasversale piuttosto che come firma di un attore specifico.

Dal punto di vista strategico, l'abuso di meccanismi IAM temporanei si inserisce nel trend più ampio dello spostamento del baricentro degli attacchi dall'endpoint al cloud control plane. Gli attaccanti che ottengono un initial access in ambiente cloud — tramite phishing di credenziali federate, compromissione di CI/CD pipeline, chiavi statiche esposte in repository pubblici, o exploitation di webhook — cercano immediatamente di mappare le permission per identificare percorsi di escalation. La logica è pragmatica: assumere un ruolo temporaneo con AssumeRole o generare un token via serviceAccountTokenCreator produce credenziali con TTL breve (tipicamente 1-12 ore) ma potere elevato, e lascia meno tracce persistenti rispetto alla creazione di nuovi utenti o all'assegnazione di ruoli permanenti (che rientrerebbe in T1098.003 Additional Cloud Roles).

Il pattern di detection evasion è la ragione principale per cui questa tecnica è preferita da attori sofisticati: le API di impersonation e role assumption sono progettate per essere invocate frequentemente da workload legittimi, quindi il rumore di fondo è elevato. Un adversary che sceglie AssumeRole invece di CreateUser sta esplicitamente investendo in stealth, spesso perché consapevole che il target dispone di monitoring cloud.

Sul piano geografico e settoriale, i settori più esposti sono quelli con adozione cloud-native matura e superficie IAM ampia: fintech, SaaS provider, media e streaming, e-commerce. Le pipeline DevOps sono un bersaglio privilegiato perché tipicamente detengono permission ampie e sono meno monitorate delle console amministrative.

Dal punto di vista di trend futuri, l'espansione di Workload Identity Federation (GCP, AWS IAM Identity Center, Azure Workload Identity) sta introducendo nuovi percorsi di trust tra provider e piattaforme esterne (GitHub Actions, GitLab CI, Kubernetes cluster on-prem). Ogni nuova federazione è un potenziale vettore di abuso se la trust policy non specifica claim sufficientemente restrittivi (branch, environment, workflow). Il threat intel deve monitorare le advisory di Rhino Security Labs, Datadog Security Labs, Wiz Research e Orca Security, che pubblicano regolarmente ricerche su nuove tecniche di escalation IAM cross-cloud. La priorità operativa è mantenere aggiornato l'inventario dei percorsi di escalation possibili nel proprio ambiente tramite tool come PMapper e Cartography, trattando la mappa IAM come un asset di threat intelligence interno.

MITRE ATT&CK: T1548.005 Temporary Elevated Cloud Access, tattiche TA0004 e TA0005, mitigazione M1018, detection strategy DET0393 con analytics AN1105 (AWS CloudTrail), AN1106 (GCP IAM/Workspace) e AN1107 (Microsoft 365 Unified Audit). Per comandi, tool (Pacu, PMapper, ROADtools, MailSniper, Cartography, CloudMapper, gcloud, AWS CLI) e procedure operative è stata integrata conoscenza professionale di cybersecurity cloud, verificata rispetto a documentazione ufficiale dei rispettivi progetti e provider.