Credenziali Cloud Aggiuntive: Additional Cloud Credentials (T1098.001)

L'obiettivo di un red team engagement su questa tecnica è dimostrare quanto sia banale, una volta ottenuti permessi IAM sufficienti, creare backdoor persistenti in ambienti cloud. Il punto di partenza è sempre l'enumerazione dei permessi dell'identità compromessa: senza sapere cosa puoi fare, rischi di generare rumore inutile.

In ambiente AWS, il framework Pacu (open source) è lo strumento di riferimento. Dopo aver configurato le credenziali con il modulo di setup, puoi eseguire il modulo iam__privesc_scan per identificare path di escalation, e successivamente usare il modulo iam__backdoor_users_keys per generare access key aggiuntive su account IAM esistenti. Se vuoi simulare lo scenario della campagna C0027, puoi usare aws_consoler (open source) per convertire credenziali CLI in sessioni console federate senza MFA.

Per operazioni manuali con la AWS CLI, la catena d'attacco si articola così:

aws iam create-access-key --user-name target-user

Questo comando genera una coppia AccessKeyId/SecretAccessKey immediatamente utilizzabile. Per aggiungere un profilo di login alla console:

aws iam create-login-profile --user-name target-user --password ComplexP@ss1 --no-password-reset-required

Per creare credenziali federate temporanee (come nello scenario STS abuse):

aws sts get-federation-token --name fake-session --policy-arns arn=arn:aws:iam::aws:policy/ReadOnlyAccess

In ambiente GCP, la generazione di chiavi service account è altrettanto diretta:

gcloud iam service-accounts keys create output-key.json --iam-account=sa-name@project-id.iam.gserviceaccount.com

Per l'aggiunta di chiavi SSH a livello di OS Login:

gcloud compute os-login ssh-keys add --key-file=~/.ssh/id_rsa.pub

In ambiente Entra ID, puoi usare i moduli PowerShell Az o Microsoft.Graph. Per aggiungere una password credential a un service principal:

New-AzADSpCredential -ServicePrincipalId -EndDate (Get-Date).AddYears(2)

Oppure con Microsoft Graph PowerShell:

Add-MgServicePrincipalPassword -ServicePrincipalId -PasswordCredential @{DisplayName="legit-automation"}

Un consiglio operativo: durante l'engagement, documenta il delta temporale tra la creazione della credenziale e il suo primo utilizzo. Questo dato è fondamentale per il blue team, perché rappresenta la finestra di detection che dovranno colmare.

La detection di questa tecnica ruota attorno a un principio semplice: chi sta aggiungendo credenziali, a cosa, e da dove? La risposta richiede tre flussi di log distinti, ciascuno con la propria logica di tuning.

Per ambienti Entra ID, la log source primaria è azure:audit. L'analytic da implementare monitora l'aggiunta di credenziali — client secret, certificati x509, password e credenziali federate — a service principal e applicazioni OAuth. La chiave per ridurre i falsi positivi è il parametro SourceIPAllowlist: definisci gli IP da cui le operazioni amministrative sono attese (pipeline CI/CD, jump server, PAM) e genera alert per tutto ciò che cade fuori range. Monitora in modo specifico il campo ApplicationCredentialType distinguendo tra client_secret, certificate, password e federated.

Un aspetto critico e spesso trascurato è la app password: se l'ambiente ha questa funzionalità legacy attiva, monitora le operazioni di creazione app password come evento ad alta severità, perché rappresentano un bypass diretto dell'MFA.

Per ambienti AWS, il flusso da catturare è AWS:CloudTrail. Gli eventi da monitorare sono CreateAccessKey, ImportKeyPair, CreateKeyPair, CreateLoginProfile e GetFederationToken. Il tuning critico qui è il CallerIdentityContext: tratta separatamente le chiamate provenienti da account root, identità federate e token STS, perché il profilo di rischio è radicalmente diverso. Implementa anche il parametro NewCredentialUsageWindow con soglia di default a 5 minuti — se una chiave viene creata e usata entro questo intervallo da un'identità diversa, è un indicatore forte di lateral movement.

Per ambienti SaaS (Google Workspace, M365, Slack), i log gcp:audit e m365:unified coprono la creazione di API key, app token e credenziali OAuth utente. Qui il tuning più efficace è OAuthClientRedirectURIBaseline: rileva mismatch tra le redirect URI registrate nei nuovi client OAuth e quelle attese, un segnale tipico di OAuth phishing. Il parametro TokenScopeSensitivity filtra i token che ottengono permessi eccessivi di lettura/scrittura a livello organizzazione.

Come regola trasversale, costruisci una baseline IAM (IAMRoleBaseline) che elenchi esplicitamente gli account e i servizi autorizzati a creare credenziali. Qualsiasi operazione fuori baseline è un alert da investigare con priorità alta.

L'analisi forense di un incident che coinvolge credenziali cloud aggiuntive si sviluppa lungo una catena logica: compromissione iniziale → enumerazione permessi → creazione credenziale → primo utilizzo → lateral movement o escalation. Ogni anello lascia artefatti specifici nei log cloud.

In AWS, la ricostruzione parte da CloudTrail. Cerca gli eventi CreateAccessKey e correla il campo userIdentity.arn (chi ha creato la chiave) con il campo requestParameters.userName (per quale utente). Quando questi due differiscono, hai un forte indicatore di compromissione: un'identità sta creando credenziali per un'altra. Per le credenziali federate, l'evento GetFederationToken registra la policy di sessione e la durata — un dettaglio cruciale perché queste credenziali restano valide anche dopo la disattivazione delle API key dell'account sorgente.

Nella timeline, annota anche gli eventi ConsoleLogin successivi a un CreateLoginProfile: questo pattern indica che l'attaccante ha aggiunto un profilo di login per accedere alla console web AWS, esattamente come documentato nella tecnica.

In Entra ID, gli Azure AD Audit Log contengono gli eventi "Add service principal credentials" e "Update application – Certificates and secrets management". Per ogni evento, estrai l'actor (chi ha eseguito l'operazione), il target (quale service principal o applicazione), il tipo di credenziale aggiunta e l'indirizzo IP sorgente. Nella SolarWinds Compromise (C0024), APT29 ha aggiunto credenziali ad applicazioni OAuth e service principal come meccanismo di persistenza post-compromissione. La correlazione tra i log di aggiunta credenziale e il successivo utilizzo del service principal in chiamate Microsoft Graph API è la chiave per ricostruire la catena di escalation.

In GCP, i Cloud Audit Log registrano le operazioni CreateServiceAccountKey e google.cloud.oslogin.v1.OsLoginService.ImportSshPublicKey. Per ogni chiave creata, verifica il campo serviceData.policyDelta per comprendere se l'operazione ha comportato cambiamenti nei permessi effettivi.

Un artefatto spesso sottovalutato è il metadata delle credenziali stesse: la data di scadenza, il display name scelto dall'attaccante (che spesso cerca di mimetizzarsi usando nomi come "automation-key" o "backup-credential") e la discrepanza temporale tra la creazione dell'account o service principal e l'aggiunta della nuova credenziale. Una credenziale aggiunta a un service principal rimasto dormiente per mesi è un red flag significativo.

Per la campagna C0027, ricostruisci la catena cercando sessioni console AWS originate da token federati il cui creatore non corrisponde ad alcuna identità nota nell'organizzazione: Scattered Spider utilizzava aws_consoler proprio per generare sessioni console da credenziali CLI compromesse, offuscando la catena di attribuzione.

La tecnica T1098.001 è un crocevia tra operazioni sofisticate state-sponsored e campagne finanziariamente motivate. I dati disponibili delineano due profili threat actor con obiettivi e TTP molto diversi, ma convergenti su questa tecnica come pilastro di persistenza cloud.

Storm-0501 (G1053) opera con un approccio pragmatico alla compromissione cloud: identifica account amministrativi privi di MFA, ne resetta la password e registra i propri metodi MFA. Questo pattern — che combina credential manipulation con MFA hijacking — indica un attore che conosce bene le architetture Entra ID ibride e predilige il controllo diretto degli account privilegiati rispetto a meccanismi di persistenza più sottili. Il targeting suggerisce operazioni orientate alla monetizzazione (ransomware, estorsione) piuttosto che allo spionaggio.

La campagna SolarWinds Compromise (C0024, attiva da agosto 2019 a gennaio 2021) rappresenta l'estremo opposto dello spettro: APT29, attribuita all'SVR russo, ha aggiunto credenziali ad applicazioni OAuth e service principal come parte di un'operazione supply chain di portata globale. La sofisticazione risiede nella scelta del vettore di persistenza: anziché compromettere account utente (rumorosi, soggetti a rotazione password), APT29 ha puntato sui service principal — identità non-umane che raramente vengono sottoposte ad audit e i cui permessi tendono ad essere over-provisioned. Le vittime hanno attraversato settori governativi, tecnologici, consulenziali e delle telecomunicazioni in Nord America, Europa, Asia e Medio Oriente.

La campagna C0027 (giugno-dicembre 2022), attribuita a Scattered Spider, introduce un terzo pattern: l'utilizzo di sts:GetFederationToken per creare credenziali federate temporanee associate a utenti fittizi. Questa tecnica offusca quale credenziale AWS sia effettivamente compromessa e consente il pivoting da CLI a console senza MFA. Il contesto — social engineering, SIM swapping, targeting di telecomunicazioni e BPO — colloca questo cluster nella fascia degli attori finanziariamente motivati con capacità tecniche elevate.

Il tool Pacu (open source) funge da denominatore comune nell'ecosistema offensivo: la sua capacità di generare chiavi SSH, API key e access key AWS lo rende lo strumento standard sia per red team legittimi che per attori reali. La sua presenza in un'indagine non è di per sé attribuibile a un gruppo specifico, ma la combinazione con altri indicatori (SIM swap, social engineering di helpdesk) può restringere il campo.

Il trend emergente è chiaro: la persistenza cloud si sta spostando dalle identità umane alle identità non-umane (service principal, managed identity, service account). Per i difensori, questo significa che il perimetro di monitoraggio deve estendersi ben oltre gli account utente tradizionali.

Framework MITRE ATT&CK v16 — T1098.001 (Additional Cloud Credentials), TA0003, TA0004. Campagne: C0027 (Scattered Spider, 2022), C0024 (SolarWinds Compromise, 2019–2021). Detection: DET0531 con analytic AN1469, AN1470, AN1471. Tool: Pacu (open source), aws_consoler (open source). Integrato con conoscenza professionale per tool e procedure operative.