Dirottamento Servizi Cloud: Cloud Service Hijacking (T1496.004)

In un contesto di red team autorizzato, la simulazione di Cloud Service Hijacking richiede un tenant di laboratorio dedicato e budget cap rigorosi per evitare costi accidentali. La catena d'attacco tipica parte da credenziali IAM ottenute in fasi precedenti (phishing, key leak in repository, SSRF su istanze EC2) e prosegue con enumerazione dei servizi disponibili.

Per AWS, l'enumerazione dei permessi su SES e SNS si effettua con la AWS CLI (open source, richiede account a pagamento per l'uso reale):

aws ses get-account-sending-enabled --region us-east-1

aws ses get-send-quota --region us-east-1

aws sns list-topics

Se l'account è in modalità sandbox, il primo passo dell'attaccante è richiedere l'uscita dalla sandbox oppure verificare domini già abilitati con aws ses list-verified-email-addresses. Per un test autorizzato, l'invio controllato si esegue con aws ses send-email verso indirizzi di canary interni.

Strumenti utili per la fase di ricognizione IAM includono Pacu (open source), framework di exploitation AWS del team Rhino Security Labs, che offre moduli come iam__enum_permissions e ses__enum. ScoutSuite (open source) e Prowler (open source) permettono di identificare configurazioni SES/SNS troppo permissive prima ancora di tentare l'abuso.

Per lo scenario LLMJacking, l'attaccante enumera l'accesso a servizi come Amazon Bedrock con aws bedrock list-foundation-models e verifica quali modelli sono invocabili tramite aws bedrock-runtime invoke-model. In laboratorio è documentata la tecnica di deploying di un reverse proxy basato su OAI-reverse-proxy (open source, disponibile su GitHub) che espone credenziali cloud rubate come endpoint OpenAI-compatibile, monetizzabile su marketplace clandestini.

Per Azure, l'equivalente con Azure Communication Services si enumera tramite Az PowerShell (open source): Get-AzCommunicationService elenca le risorse di messaggistica, mentre per Microsoft Graph l'abuso di Exchange Online per invio massivo si simula con MailSniper (open source) o script Graph API mirati.

Su GCP, l'equivalente coinvolge SendGrid integrato o Cloud Functions che invocano API di terze parti; l'enumerazione avviene con gcloud services list --enabled e il tool GCPBucketBrute (open source) aiuta a mappare risorse esposte. Ogni test deve prevedere logging CloudTrail attivo, alert su spesa e disabilitazione immediata delle credenziali di test al termine dell'esercizio.

La detection di Cloud Service Hijacking si basa quasi interamente sull'analisi comportamentale dei log del control plane cloud. La fonte primaria per ambienti AWS è CloudTrail, integrato in un SIEM (Splunk, Elastic, Sentinel) o analizzato con Athena (a pagamento, pay-per-query). La detection strategy DET0147 identifica come segnale chiave l'invocazione di API SES/SNS o di runtime AI in volumi anomali, da regioni inusuali o sotto identità non attese.

Un primo indicatore è l'abilitazione recente di servizi dormienti: eventi ses:UpdateAccountSendingEnabled, ses:PutAccountSendingAttributes o bedrock:PutModelInvocationLoggingConfiguration eseguiti da identità che storicamente non hanno mai toccato quel servizio meritano alert immediato. Analogamente, la richiesta di uscita dalla SES sandbox tramite ticket automatizzato è un forte segnale se non correlata a un change request approvato.

Sul piano volumetrico, l'analista deve costruire baseline a 7 giorni per metriche come numero di SendEmail, SendRawEmail, Publish (SNS) e InvokeModel (Bedrock) per identità. La detection nota suggerisce finestre di tuning di 10 minuti o 1 ora per misurare spike di richieste, con soglie personalizzate per volume email/SMS e token LLM. Uno scostamento superiore a 3 deviazioni standard dalla media storica deve generare alert di severità alta.

La correlazione geografica è altrettanto critica. Eventi CloudTrail con campo sourceIPAddress che indica una regione diversa da quella abituale dell'identità, o geo-velocity impossibile (login da IP statunitense seguito entro minuti da invocazione API da IP asiatico), sono pattern tipici dell'abuso. In AWS, l'attivazione di GuardDuty (a pagamento) fornisce già finding come CredentialAccess:IAMUser/AnomalousBehavior e Discovery:IAMUser/AnomalousBehavior che coprono parte del terreno.

Per LLMJacking, l'indicatore più affidabile è la comparsa di chiamate InvokeModel verso modelli mai usati prima nel tenant, spesso concentrate su Claude o GPT-4 di fascia alta, con User-Agent atipici (assenza dell'SDK ufficiale, presenza di stringhe come python-requests o proxy custom).

I falsi positivi più comuni derivano da campagne di marketing legittime schedulate, da nuove integrazioni di sviluppatori che testano servizi, o da automazioni CI/CD che invocano SES in batch. La whitelist per identità automation-only e la correlazione con ticket di change riducono drasticamente il rumore. Controlli preventivi essenziali includono Service Control Policy (SCP) su AWS Organizations che negano l'uso di SES/SNS/Bedrock da regioni non approvate, quote spending alert tramite AWS Budgets (gratuito nel free tier) e MFA obbligatoria per ruoli con permessi ses:*.

L'analisi forense di un incidente Cloud Service Hijacking ruota attorno alla ricostruzione temporale delle chiamate API cloud e all'identificazione del vettore di compromissione iniziale delle credenziali. La fonte principale è l'archivio CloudTrail completo (management events e data events), idealmente conservato in un bucket S3 con object lock in un account di logging separato per garantire immutabilità.

La timeline si costruisce partendo dal primo evento anomalo verso il servizio abusato e risalendo alle azioni precedenti della stessa identità. Query Athena tipiche filtrano per eventName IN ('SendEmail','Publish','InvokeModel') e ordinano per eventTime, correlando userIdentity.arn, sourceIPAddress, userAgent e awsRegion. È fondamentale estrarre anche userIdentity.sessionContext.sessionIssuer per identificare se l'identità è un ruolo assunto (STS AssumeRole) e in tal caso risalire al principal originario.

Gli artefatti chiave da preservare includono i log CloudTrail delle 72 ore precedenti l'attacco, i log VPC Flow se l'abuso è passato per infrastruttura interna, i log di CloudWatch relativi a Lambda o EC2 che potrebbero aver ospitato reverse proxy, e la configurazione IAM al momento dell'incidente (esportabile con aws iam get-account-authorization-details). Per Bedrock, l'attivazione retroattiva del model invocation logging non è possibile: se non era attivo, l'analista deve basarsi solo sui metadata di CloudTrail e sulle metriche di CloudWatch che registrano volumi e latenze.

Per identificare l'origine della compromissione credenziali, gli artefatti utili includono log GuardDuty archiviati, log di IAM Access Analyzer e, sul lato endpoint, la ricerca di credential leak in repository Git tramite tool come TruffleHog (open source) o Gitleaks (open source) applicati alla storia dei commit aziendali. Chiavi statiche IAM che risultano attive da mesi e improvvisamente usate da IP nuovi sono candidate principali per credential leak.

Lato messaggistica, il servizio SES conserva metadata degli invii per un periodo limitato; l'estrazione tempestiva del SES Sending Statistics e delle CloudWatch Metrics BounceRate, ComplaintRate, Reputation permette di quantificare il danno reputazionale (rischio di blacklist del dominio). Per Twilio e SendGrid, i portali offrono export CSV degli invii con timestamp, destinatario e contenuto, essenziali per notifiche ai destinatari e per calcolo dei danni.

Campagne LLMJacking documentate pubblicamente hanno mostrato pattern ricorrenti: chiavi AWS esposte su GitHub, uso di reverse proxy hostati su VPS economici, monetizzazione tramite gruppi Telegram. La correlazione tra timestamp di leak della chiave (rilevabile con GitHub Secret Scanning, gratuito per repo pubblici) e prima invocazione anomala fornisce l'evidenza del vettore iniziale.

I dati MITRE ATT&CK forniti non associano gruppi APT, software o campagne specifiche a T1496.004, riflettendo il fatto che questa tecnica è dominata da attori a motivazione finanziaria e opportunistica più che da threat actor state-sponsored tradizionalmente tracciati. Il profilo di rischio va quindi ricostruito osservando i pattern di abuso emersi negli incidenti pubblici.

Il panorama degli attori si divide in tre macro-categorie. La prima è composta da spammer commerciali e operatori di phishing-as-a-service che acquistano o rubano credenziali AWS/SendGrid per inviare campagne massive aggirando i sistemi di reputazione: sfruttano l'infrastruttura fidata del cloud provider per bypassare filtri SPF/DKIM/DMARC delle destinazioni. La seconda categoria è rappresentata da gruppi specializzati in LLMJacking, emersi come fenomeno strutturato con la diffusione dei modelli generativi commerciali; monetizzano l'accesso rivendendo query a utenti finali tramite proxy o gruppi chiusi, con guadagni stimati in migliaia di dollari al giorno per singola chiave compromessa. La terza è costituita da crypto-miner opportunisti che, pur non rientrando strettamente in T1496.004, condividono la stessa logica di abuso di quote cloud.

Il pattern geografico dell'infrastruttura di monetizzazione mostra concentrazione in giurisdizioni con debole enforcement, mentre le vittime sono distribuite globalmente ma con predominanza di PMI e startup che utilizzano cloud pubblico senza controlli di spesa granulari. Le grandi enterprise sono meno colpite grazie a Service Control Policy e budget alert maturi.

Sul piano dei tool overlap, la comunità offensiva ha convergito su alcuni strumenti ricorrenti: Pacu per l'enumerazione AWS post-compromissione, reverse proxy custom o forkati da progetti open source per LLMJacking, e script Python basati su boto3 per l'invio batch di email tramite SES. La disponibilità di credential leak su GitHub e in dump di infostealer (Redline, Raccoon, Lumma) alimenta continuamente il pool di chiavi utilizzabili.

I trend osservati indicano una crescita marcata del vettore LLMJacking a partire dal 2024, con Anthropic Claude e OpenAI GPT-4 come target preferiti per il loro costo per token elevato. Parallelamente, l'abuso di SES rimane costante e alimenta ondate di phishing bancario e crypto-scam. Un trend secondario è l'abuso di Azure Communication Services e Google Cloud Messaging man mano che le difese su AWS diventano più diffuse. Le raccomandazioni di intelligence per i difensori includono monitoraggio continuo dei repository pubblici aziendali per credential leak, rotazione forzata delle chiavi IAM statiche verso identità federate, e implementazione di quote hard limit sui servizi ad alto costo unitario.

MITRE ATT&CK: tecnica T1496.004 (Cloud Service Hijacking), tattica TA0040 (Impact). Detection strategy DET0147, analytic AN0417. MITRE D3FEND per mapping difensivo. Tool citati: AWS CLI, Pacu, ScoutSuite, Prowler, MailSniper, TruffleHog, Gitleaks, GCPBucketBrute (tutti open source), AWS GuardDuty e Athena (a pagamento). Parte dei contenuti operativi deriva da conoscenza professionale di cybersecurity applicata al perimetro cloud AWS/Azure/GCP.