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

Durante un red team engagement, la creazione di credenziali alternative garantisce persistenza anche dopo la scoperta dell'accesso iniziale. In AWS, il comando più diretto per generare nuove chiavi di accesso è:

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

Questa chiamata API restituisce immediatamente AccessKeyId e SecretAccessKey utilizzabili per accesso programmatico. Per ambienti che richiedono console access, la creazione di un profilo di login secondario bypassa eventuali policy MFA:

aws iam create-login-profile --user-name backup-admin --password ComplexP@ss123! --no-password-reset-required

Pacu, il framework di exploitation AWS, automatizza queste tecniche attraverso moduli dedicati. Il modulo iam__enum_permissions seguito da iam__privesc_scan identifica path di escalation basati sulla capacità di creare credenziali per ruoli privilegiati.

In Azure/Entra ID, l'aggiunta di certificati a Service Principal esistenti offre accesso duraturo:

az ad sp credential reset --name "existing-sp-name" --append

L'opzione --append mantiene le credenziali esistenti attive, riducendo il rischio di detection. Per scenari più sofisticati, la registrazione di nuove applicazioni OAuth con scope elevati permette accesso delegato:

az ad app create --display-name "LegitimateBackupTool" --required-resource-accesses @manifest.json

GCP offre vettori simili attraverso la gestione delle chiavi dei service account. Il comando per creare nuove chiavi JSON è particolarmente utile:

gcloud iam service-accounts keys create ~/key.json --iam-account=target-sa@project.iam.gserviceaccount.com

Durante la campagna C0027, Scattered Spider ha dimostrato l'efficacia di aws_consoler per generare credenziali federate temporanee. Questo tool converte chiavi CLI in sessioni console senza MFA, perfetto per pivoting:

python aws_consoler.py -a AKIAXXXXXXXX -s wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

La detection efficace richiede correlazione tra multiple data source cloud-native. In Azure, gli eventi di audit log mostrano pattern distintivi quando vengono aggiunte credenziali anomale. Focus principale su operazioni che coinvolgono servicePrincipals.create o applications.addPassword.

Per AWS CloudTrail, le API call critiche da monitorare includono CreateAccessKey, ImportKeyPair e CreateLoginProfile. Un alert efficace correla l'identità del chiamante con il target:

eventName = CreateAccessKey AND 
userIdentity.principalId != requestParameters.userName AND
sourceIPAddress NOT IN trusted_admin_ranges

La baseline comportamentale è fondamentale. Storm-0501 ha dimostrato come il reset di password amministrative senza MFA seguito dall'aggiunta immediata di propri metodi MFA sia un pattern ricorrente. Alert su sequenze temporali strette (< 5 minuti) tra reset password e modifiche MFA.

In ambienti Entra ID, particolare attenzione alle app password che bypassano completamente MFA. Query KQL per Microsoft Sentinel:

AuditLogs
| where OperationName contains "app password"
| where ResultType == "Success"
| join kind=inner (SigninLogs | where AuthenticationRequirement != "multiFactorAuthentication")

GCP richiede monitoring degli audit log per operazioni setIamPolicy che aggiungono nuovi binding o creazione di chiavi per service account esistenti. La correlazione con l'IP source e l'identità del caller distingue operazioni legittime da compromissioni.

I falsi positivi derivano principalmente da automation legittime. Whitelisting basata su service account dedicati per CI/CD riduce il rumore mantenendo visibilità sulle anomalie reali.

L'analisi forense delle credenziali cloud aggiuntive richiede correlazione temporale tra diversi piani di controllo. In AWS, CloudTrail fornisce timestamp precisi per ogni operazione API, ma la chiave sta nell'identificare il momento di primo utilizzo delle nuove credenziali.

Durante SolarWinds Compromise, APT29 ha aggiunto credenziali a OAuth Applications esistenti. L'analisi dei log Entra ID mostra pattern temporali distintivi: creazione credenziale → primo utilizzo → escalation permessi, spesso nell'arco di ore.

Gli artefatti principali risiedono nei log di audit cloud-native. Per AWS, focus su:

• CloudTrail per le API call di creazione (eventTime, sourceIPAddress, userAgent)
• S3 access logs per identificare il primo utilizzo delle nuove chiavi
• Config snapshots per tracciare modifiche ai ruoli IAM

In Azure, la ricostruzione richiede:

• Activity Log per operazioni su Service Principal
• Sign-in logs per primo utilizzo delle nuove credenziali
• Audit logs per modifiche a OAuth app permissions

La timeline reconstruction beneficia dell'analisi dei metadati. Le chiavi AWS includono timestamp di creazione nel prefisso AKIA, mentre i certificati x509 contengono validity period che indica quando sono stati generati.

Pattern comuni emergono dall'analisi di campagne documentate. Scattered Spider durante C0027 mostrava intervalli di 10-30 minuti tra compromissione iniziale e creazione di credenziali federate, seguiti da accesso console entro un'ora.

Per ambienti GCP, il comando gcloud logging read con filtri temporali precisi ricostruisce la sequenza:

gcloud logging read "protoPayload.methodName=google.iam.admin.v1.CreateServiceAccountKey" --format=json --project=victim-project

Storm-0501 rappresenta l'evoluzione delle tecniche di persistenza cloud-native. Il gruppo mostra preferenza marcata per account amministrativi privi di MFA, sui quali esegue reset password seguito da registrazione immediata di propri metodi di autenticazione. Pattern geografico concentrato su vittime con presenza cloud ibrida.

APT29 durante SolarWinds ha dimostrato capacità avanzate di manipolazione OAuth. Il gruppo preferisce aggiungere credenziali a Service Principal esistenti piuttosto che creare nuove entità, riducendo la superficie di detection. Tool overlap minimo con altri gruppi, indicando sviluppo custom.

Scattered Spider mostra approccio più opportunistico ma tecnicamente sofisticato. L'uso di aws_consoler per generare credenziali federate temporanee indica comprensione profonda dei meccanismi AWS STS. Il gruppo target principalmente BPO e telco per accesso laterale a clienti downstream.

Pattern emergenti mostrano evoluzione verso:

• Preferenza per credenziali certificate-based rispetto a password
• Uso di federated token con durata estesa (12+ ore)
• Target su identity provider come punto di controllo centralizzato
• Abuso sistematico di legacy authentication mechanism

La sovrapposizione di TTP tra gruppi rimane limitata. Storm-0501 focus su Azure/Entra, APT29 multi-cloud con preferenza GCP per victim governo, Scattered Spider quasi esclusivamente AWS. Trend indica specializzazione crescente per cloud provider.

Campagne future probabilmente sfrutteranno managed identity e workload identity federation, riducendo ulteriormente l'uso di credenziali statiche tradizionali.

Framework MITRE ATT&CK T1098.001. Campagne documentate: SolarWinds Compromise (C0024) con attribuzione APT29/SVR, C0027 Scattered Spider targeting telco/BPO. Detection tramite cloud-native audit log con focus su API call CreateAccessKey, ImportKeyPair, servicePrincipals.create. Risorse: AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs per visibility completa.