Connessioni Dirette a VM Cloud: Direct Cloud VM Connections (T1021.008)

In un esercizio red team, la simulazione di T1021.008 parte dal presupposto di aver già compromesso credenziali o profili IAM con i permessi adeguati. Il primo passo è l'enumerazione delle autorizzazioni disponibili sul principal corrente.

Su AWS, con la AWS CLI (open source) verifichiamo l'identità attiva:

aws sts get-caller-identity

Quindi enumeriamo le istanze bersaglio e i loro tag:

aws ec2 describe-instances --filters "Name=instance-state-name,Values=running"

Per EC2 Instance Connect il flusso prevede l'invio temporaneo di una chiave pubblica seguito dalla connessione SSH. Il comando dedicato dell'ultima generazione della CLI è:

aws ec2-instance-connect ssh --instance-id i-xxxxxxxx

In alternativa, tramite AWS Systems Manager Session Manager si apre una sessione senza esporre la porta 22, ottenendo spesso privilegi elevati:

aws ssm start-session --target i-xxxxxxxx

Questo approccio è particolarmente apprezzato in un contesto offensivo perché non richiede indirizzo IP pubblico né regole di ingresso nei security group: il traffico transita attraverso l'endpoint SSM. Verificate sempre i permessi con ssm:StartSession prima di procedere.

Su Azure, la Azure CLI (open source) permette di aprire la Serial Console o eseguire comandi tramite il canale VMAccess. L'enumerazione parte da:

az vm list --show-details --output table

e la connessione RunCommand consente esecuzione diretta sull'ospite:

az vm run-command invoke --command-id RunShellScript --name --resource-group --scripts "id"

Per l'automazione dell'intera catena in laboratorio, strumenti come Pacu (open source), framework di exploitation dedicato ad AWS, includono moduli per enumerare istanze e testare l'accesso via SSM. Per la ricognizione IAM è utile ScoutSuite (open source), che genera un report delle configurazioni cloud e delle policy troppo permissive.

Una catena d'attacco tipica in ambiente lab: compromissione di un access key esposto, enumerazione con get-caller-identity, identificazione di istanze con ruolo IAM privilegiato tramite describe-instances, apertura di una sessione SSM verso l'istanza target e infine pivoting verso il metadata service (curl http://169.254.169.254/latest/meta-data/iam/security-credentials/) per raccogliere credenziali temporanee aggiuntive.

Mantenete l'esercizio confinato ad account cloud di test isolati, evitando istanze di produzione e documentando ogni chiamata API per la fase di reporting.

La detection di T1021.008 ruota attorno alla correlazione tra eventi del control plane cloud e attività sull'host, come indicato dall'analitica AN0594. Le due fonti di log fondamentali sono AWS CloudTrail per il piano di controllo e Sysmon (open source) per la telemetria endpoint sulla VM.

Gli artefatti digitali coinvolti includono la sessione di autenticazione cloud, l'account utilizzato e il processo generato sull'host. Il pattern di allarme più affidabile è temporale: un evento di login o apertura sessione nel cloud seguito, entro una finestra ristretta (idealmente inferiore a 60 secondi), da creazione di processo o attività di privilege escalation sulla macchina.

Su CloudTrail monitorate le chiamate API rilevanti: SendSSHPublicKey per EC2 Instance Connect, StartSession e TerminateSession per SSM, e le operazioni relative alla Serial Console. Un evento StartSession verso un'istanza taggata come produzione, originato da una regione inconsueta, è un candidato prioritario per l'escalation.

Il tuning raccomandato dall'analitica prevede quattro dimensioni. La prima è la finestra temporale, che correla login cloud e attività host. La seconda è il metodo di autenticazione (CloudAuthMethod), che distingue tra chiave SSH, sessione SSM o console connect. La terza è la regione di origine della sessione (SessionOriginRegion), utile a individuare accessi da reti non attendibili o fuori area. La quarta sono i tag dell'istanza bersaglio (TargetInstanceTags), per elevare la severità sugli asset sensibili.

Sul lato host, con Sysmon osservate l'EventCode 1 (process creation) generato da agent come amazon-ssm-agent o processi che avviano shell interattive subito dopo l'apertura di una sessione. La comparsa improvvisa di processi con contesto SYSTEM o root non associati a job di automazione pianificata merita indagine.

Sul piano preventivo, coerentemente con le mitigazioni M1018 e M1042, il SOC dovrebbe verificare che l'accesso via metodi nativi sia limitato a un insieme ristretto di principal IAM e che le funzionalità di connessione diretta siano disabilitate dove non necessarie.

Attenzione ai falsi positivi: pipeline di patch management, tool di automazione infrastrutturale e sessioni legittime di amministratori generano gli stessi eventi. La chiave è profilare la baseline di chi normalmente apre sessioni SSM o Serial Console, in quali orari e da quali regioni, per far emergere le deviazioni.

L'analisi forense di T1021.008 deve intrecciare la timeline del control plane cloud con gli artefatti presenti sull'istanza compromessa. Il punto di partenza è quasi sempre AWS CloudTrail, che registra ogni chiamata API con timestamp, principal, indirizzo IP sorgente e regione.

Ricercate nel journal CloudTrail gli eventi SendSSHPublicKey, StartSession e le operazioni Serial Console. Ogni record espone il campo userIdentity, l'eventTime e il sourceIPAddress, elementi che permettono di ricostruire chi ha aperto la sessione e da dove. La correlazione con l'instanceId consente di collegare l'evento cloud all'host fisico da esaminare.

Sull'istanza Linux, gli artefatti chiave sono i log di autenticazione in /var/log/auth.log o /var/log/secure, dove EC2 Instance Connect lascia traccia dell'iniezione temporanea della chiave pubblica e del successivo login SSH. Le sessioni SSM sono documentate nei log dell'agent, tipicamente in /var/log/amazon/ssm/, e includono i comandi eseguiti quando è abilitato il logging di sessione. Esaminate anche /root/.bash_history e i timestamp MAC dei file tramite stat per collocare l'attività nella cronologia.

Su host Windows la telemetria di Sysmon (open source) fornisce l'EventCode 1 per la creazione di processi e l'EventCode 13 per le modifiche di registro; correlate questi eventi con i log di sistema per identificare processi avviati dall'agent SSM subito dopo l'apertura della sessione registrata in CloudTrail. Il Security event log con EventCode 4688 completa il quadro sulla catena di processi.

La costruzione della timeline segue quindi tre ancoraggi: l'evento API nel cloud (momento di apertura sessione), l'evidenza di autenticazione sull'host (log auth o agent SSM) e infine l'attività di esecuzione (process creation). L'obiettivo è dimostrare la sequenza login cloud → accesso privilegiato → azioni sull'host entro la finestra temporale osservata.

Per l'acquisizione delle evidenze, se l'istanza è ancora attiva, considerate uno snapshot del volume EBS prima di qualsiasi interazione, preservando l'integrità con hash. Strumenti come Velociraptor (open source) permettono la raccolta remota di artefatti da host cloud in modo forensicamente solido.

Non dimenticate di verificare le chiavi SSH temporanee autorizzate e i profili IAM associati all'istanza al momento dell'incidente, poiché possono rivelare il vettore di pivoting successivo verso il metadata service.

I dati MITRE ATT&CK associati a T1021.008 non riportano gruppi APT, software o campagne specificamente mappati a questa sotto-tecnica. Questa assenza è essa stessa un dato di intelligence significativo e va interpretata con attenzione analitica anziché colmata con attribuzioni non supportate.

La mancanza di attribuzioni consolidate riflette la natura relativamente recente dei metodi nativi di connessione cloud come vettore di movimento laterale documentato pubblicamente. Le connessioni dirette alle VM tramite API del provider rappresentano una superficie che è emersa con la maturazione delle infrastrutture cloud, e la telemetria per attribuire questo comportamento a specifici attori è ancora in fase di consolidamento nella community di threat intelligence.

Dal punto di vista del pattern comportamentale, l'elemento distintivo di questa tecnica è che si colloca esclusivamente nella fase di movimento laterale (TA0008) e presuppone il possesso di account validi. Questo la rende un anello intermedio di una catena più ampia: qualsiasi attore che abbia già ottenuto credenziali cloud o profili IAM privilegiati — attraverso phishing, esposizione di access key o compromissione di identità — può adottare questo vettore per spostarsi verso asset di calcolo. L'attrattiva per gli avversari risiede nella capacità di ottenere accesso a livello SYSTEM o root aggirando i controlli di rete perimetrali.

Il trend che un analista di intelligence dovrebbe monitorare è l'abuso crescente di funzionalità di gestione legittime come SSM e Serial Console, che appartengono alla categoria più ampia del "living off the cloud": l'uso di strumenti nativi del provider per finalità offensive, riducendo l'impronta di malware custom e complicando la detection basata su firme.

Sul piano difensivo strategico, le due mitigazioni mappate indicano dove concentrare le priorità di riduzione del rischio. La gestione degli account (M1018) suggerisce di applicare il principio del privilegio minimo alle policy IAM che autorizzano connessioni native, imporre MFA sugli account amministrativi e limitare quali principal possano avviare sessioni verso le istanze. La disabilitazione delle funzionalità non necessarie (M1042) raccomanda di spegnere i canali di connessione diretta laddove non servano per l'amministrazione.

Per un programma di threat intelligence maturo, il consiglio operativo è costruire rilevamenti basati sul comportamento e alimentare la baseline degli accessi legittimi, poiché l'assenza di indicatori atomici (hash, domini, IP) rende inefficace un approccio puramente IOC-centrico verso questa tecnica.

MITRE ATT&CK: T1021.008 (Direct Cloud VM Connections), tattica TA0008, mitigazioni M1018 e M1042, detection DET0211/AN0594. Documentazione ufficiale AWS CLI, AWS Systems Manager, EC2 Instance Connect e Azure CLI per la sintassi dei comandi. Progetti open source citati: Sysmon, Pacu, ScoutSuite, Velociraptor. Parte dei comandi e delle procedure operative deriva da conoscenza professionale di cybersecurity verificata sulla documentazione dei rispettivi tool.