Credenziali Cloud Aggiuntive: Additional Cloud Credentials (T1098.001)
La tecnica T1098.001 - Additional Cloud Credentials descrive la manipolazione di account cloud tramite l'aggiunta di credenziali controllate dall'attaccante — chiavi x509, password, SSH key, access key IAM o app password — per garantire un accesso persistente indipendente dalle credenziali originali. Rientra nelle tattiche TA0003 (Persistence) e TA0004 (Privilege Escalation), coprendo la fase post-Initial Access della kill chain, quando l'avversario ha già ottenuto un primo appiglio in un tenant Azure/Entra ID, in un account AWS o in un progetto GCP.
L'operazione è particolarmente insidiosa perché non richiede exploit: sfrutta funzionalità legittime delle API cloud. In Entra ID un ruolo Application Administrator può aggiungere un secret a un Service Principal esistente ed ereditarne i permessi; in AWS l'API CreateAccessKey genera chiavi programmatiche per un utente IAM, mentre sts:GetFederationToken produce credenziali temporanee che sopravvivono anche alla revoca dell'utente originale. In GCP, comandi come gcloud iam service-accounts keys create aggiungono chiavi JSON a service account privilegiati.
L'impatto è significativo: la campagna C0024 (SolarWinds Compromise) ha visto APT29 aggiungere credenziali a OAuth Application e Service Principal per mantenere accesso a tenant M365 dopo la compromissione iniziale, mentre in C0027 Scattered Spider ha usato token federati per bypassare MFA e pivotare verso console AWS senza ulteriori autenticazioni.
In un esercizio red team autorizzato, la simulazione di T1098.001 parte sempre da un accesso iniziale a un principal con permessi sufficienti. In ambiente AWS, dopo aver compromesso un utente IAM con policy iam:CreateAccessKey, l'operatore può generare una seconda coppia di chiavi con:
aws iam create-access-key --user-name
L'output restituisce AccessKeyId e SecretAccessKey immediatamente utilizzabili. Per creare backdoor su istanze EC2, aws ec2 import-key-pair --key-name backdoor --public-key-material fileb://key.pub inietta una chiave SSH controllata. Per token federati che sopravvivono alla revoca dell'utente:
aws sts get-federation-token --name tempsession --policy-arns arn=arn:aws:iam::aws:policy/AdministratorAccess
Lo strumento Pacu (open source), framework di exploitation AWS mantenuto da Rhino Security Labs, automatizza queste catene tramite moduli come iam__backdoor_users_keys e iam__privesc_scan, coprendo oltre 30 vettori di privilege escalation documentati.
In Azure/Entra ID, con un principal che detiene il ruolo Application Administrator, la persistenza si costruisce aggiungendo un client secret a un Service Principal esistente:
az ad app credential reset --id
Oppure via AzureAD PowerShell (a pagamento nelle sue evoluzioni Microsoft Graph, ma il modulo base è gratuito) con New-AzureADApplicationPasswordCredential. Il tool ROADtools (open source) di Dirk-jan Mollema permette enumerazione offline del directory graph per identificare Service Principal con permessi API sensibili prima di iniettare credenziali. MicroBurst (open source) di NetSPI include Get-AzurePasswords e funzioni per abusare Managed Identity.
In GCP, la creazione di chiavi JSON su service account privilegiati avviene con:
gcloud iam service-accounts keys create key.json --iam-account=
Mentre gcloud compute os-login ssh-keys add --key-file=id_rsa.pub garantisce accesso SSH persistente alle VM.
La catena tipica in un engagement prevede: enumerazione dei permessi correnti con aws iam simulate-principal-policy o ScoutSuite (open source), identificazione di principal privilegiati sfruttabili, aggiunta di credenziali secondarie e test di sopravvivenza dopo revoca simulata. È fondamentale documentare ogni chiave creata per la fase di cleanup, evitando che credenziali di test rimangano attive oltre l'engagement.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo