Istanze Cloud Fantasma: Create Cloud Instance (T1578.002)

La simulazione di questa tecnica in laboratorio richiede un account cloud con permessi di compute management. L'obiettivo è dimostrare come, partendo da credenziali rubate, un attaccante possa creare un'istanza ombra, montarvi dati esistenti e operare al di fuori delle policy di sicurezza del tenant.

Scenario AWS — Catena snapshot-to-instance

Il flusso realistico parte dalla creazione di uno snapshot di un volume EBS esistente, poi dalla creazione di un'istanza EC2 con quello snapshot montato e un security group aperto. Su AWS CLI (open source), la sequenza è la seguente:

aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 --description "backup"

Una volta ottenuto lo snapshot ID, si crea un AMI da quello snapshot:

aws ec2 register-image --name "temp-image" --root-device-name /dev/xvda --block-device-mappings DeviceName=/dev/xvda,Ebs={SnapshotId=snap-0123456789abcdef0}

Infine si lancia l'istanza con un security group permissivo, magari creato ad hoc:

aws ec2 run-instances --image-id ami-xxxxxxxxx --instance-type t2.micro --security-group-ids sg-xxxxxxxxx --key-name attacker-key

L'intera catena produce eventi CloudTrail distinti per ogni chiamata API: CreateSnapshot, RegisterImage, RunInstances. In un red team engagement, questa sequenza dimostra al blue team esattamente cosa monitorare.

Scenario Azure — VM nel tenant vittima

Su Azure CLI (open source), il comando per creare una VM nel resource group della vittima è diretto:

az vm create --resource-group TargetRG --name shadow-vm --image Ubuntu2204 --admin-username testadmin --generate-ssh-keys

Per replicare il pattern della campagna C0027, dove Scattered Spider operava nel tenant Azure delle vittime, si può creare la VM in una region diversa da quelle abituali dell'organizzazione — dettaglio che il SOC dovrebbe intercettare.

Strumenti complementari per il lab

• Pacu (open source): framework di exploitation AWS che automatizza l'enumerazione dei permessi e la creazione di risorse. Il modulo ec2__startup_shell_script consente di lanciare istanze con user-data malevoli.
• ScoutSuite (open source): utile nella fase di ricognizione pre-attacco per mappare le misconfiguration IAM che rendono possibile la creazione di istanze.
• Stratus Red Team (open source) di DataDog: offre scenari di attacco cloud pre-confezionati, inclusa la creazione di istanze EC2 anomale, ideali per generare telemetria realistica in ambiente lab.

Il consiglio operativo è documentare ogni API call generata durante la simulazione e confrontarla con i log CloudTrail o Azure Activity per costruire detection rule precise.

La detection di questa tecnica poggia interamente sui log nativi delle piattaforme cloud: AWS CloudTrail e Azure Activity Log sono le fonti primarie. Non esistono artefatti endpoint tradizionali da correlare — l'intera azione avviene tramite API cloud.

Log source e eventi chiave

Su AWS, l'evento CloudTrail da monitorare è RunInstances nel servizio EC2. Su Azure, l'equivalente è l'operazione Microsoft.Compute/virtualMachines/write nel log attività. Entrambi registrano l'identità del chiamante, la region, il timestamp e i parametri della risorsa creata.

La strategia di detection suggerita si basa su quattro assi di tuning che vanno calibrati sull'ambiente specifico:

Il primo è il contesto utente (UserContext): la creazione di istanze da parte di account IAM che non lo fanno abitualmente — o peggio, da account appena creati — è un segnale forte. Va costruita una allowlist degli account e dei service account di automazione (Terraform, CloudFormation, Ansible) che creano istanze regolarmente, e generare alert per tutto ciò che esce dalla lista.

Il secondo asse è la geolocalizzazione: una chiamata API RunInstances da una region inusuale o da un IP sorgente in un paese dove l'organizzazione non opera merita attenzione immediata. Correlare la source IP del chiamante con le baseline geografiche note riduce drasticamente i falsi positivi.

Il terzo è il rate threshold: sequenze rapide di CreateSnapshot → RegisterImage → RunInstances in finestre temporali strette (minuti) sono anomale rispetto al provisioning ordinario. Una regola che conta il numero di istanze create per utente in una finestra di 30 minuti, con soglia calibrata sui pattern di scaling dell'organizzazione, intercetta la catena d'attacco tipica.

Il quarto è la tagging policy: le organizzazioni mature impongono tag obbligatori (owner, cost center, progetto) su ogni risorsa cloud. Un'istanza creata senza tag, o con tag generici, è un indicatore di provisioning non autorizzato.

Gestione dei falsi positivi

Il nemico principale è l'autoscaling. Servizi come AWS Auto Scaling Groups o Azure VM Scale Sets creano istanze continuamente e generano volume. La soluzione è filtrare per service-linked role: le creazioni da AWSServiceRoleForAutoScaling vanno escluse dalla regola. Analogamente, le pipeline CI/CD che usano istanze ephemeral devono essere mappate e allowlistate per service account.

Un alert ad alta fedeltà combina più segnali: istanza creata da utente non in allowlist, in region atipica, senza tag obbligatori, seguita da una modifica al security group che apre porte verso l'esterno. Questa correlazione multi-evento riduce il rumore e produce incident actionable.

L'analisi forense di questa tecnica è interamente cloud-native: gli artefatti risiedono nei log delle piattaforme, non sui filesystem delle istanze compromesse. La sfida è ricostruire la catena di azioni API che ha portato alla creazione dell'istanza malevola e correlare gli eventi a monte (compromissione delle credenziali) e a valle (esfiltrazione dati).

Ricostruzione della timeline su AWS

Il punto di partenza è CloudTrail. Ogni evento contiene campi cruciali per la timeline: eventTime, userIdentity (con dettaglio su account, ARN e session context), sourceIPAddress, awsRegion e requestParameters. Per ricostruire la catena, si filtrano gli eventi per l'identità sospetta usando AWS CLI (open source):

aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=suspicious-user --start-time 2022-06-01 --end-time 2022-12-31

La sequenza forense da cercare è: CreateSnapshot → RegisterImage o CreateImage → RunInstances → AuthorizeSecurityGroupIngress (apertura porte) → eventuale AttachVolume. Ogni passaggio ha un timestamp preciso che costruisce la timeline.

Un dettaglio spesso trascurato è il campo userAgent nell'evento CloudTrail: un attaccante che usa AWS CLI da una macchina personale avrà uno user-agent diverso rispetto ai tool di automazione dell'organizzazione. Confrontare lo user-agent con la baseline aziendale può confermare l'anomalia.

Ricostruzione su Azure

Su Azure, il log attività registra operazioni analoghe. Il campo caller identifica l'utente o il service principal, mentre operationName distingue le azioni. Lo strumento Azure Resource Graph (gratuito, integrato nel portale Azure) consente query retroattive sulle risorse create:

az graph query -q "Resources | where type == 'microsoft.compute/virtualmachines' | where properties.timeCreated > datetime(2022-06-01)"

Per la campagna C0027, dove Scattered Spider ha creato Azure VM nei tenant delle vittime telco e BPO tra giugno e dicembre 2022, la correlazione chiave è tra gli eventi di creazione VM e le modifiche ai Conditional Access Policy o ai ruoli IAM avvenute nelle ore precedenti. Il pattern tipico è: compromissione credenziali via social engineering → escalation dei permessi → creazione VM → esfiltrazione.

Artefatti digitali da preservare

La checklist di acquisizione forense include:

• Export completo dei log CloudTrail o Azure Activity per il periodo sospetto
• Snapshot dei volumi montati sull'istanza malevola (prima di terminarla)
• Configurazione del security group o NSG associato all'istanza
• Record IAM: policy, ruoli e permission boundary dell'account utilizzato
• Eventuali log di VPC Flow Logs o NSG Flow Logs per il traffico di rete dell'istanza

Lo strumento Prowler (open source) è utile per generare un report post-incident che evidenzia le deviazioni di configurazione introdotte dall'attaccante rispetto alle baseline CIS dell'organizzazione.

Il panorama degli attori che sfruttano la creazione di istanze cloud come tecnica di evasione è compatto ma altamente significativo. Due gruppi con profili distinti ma convergenti nella preferenza per ambienti cloud ibridi compongono il quadro.

LAPSUS$ (G1004) è un gruppo a motivazione finanziaria e reputazionale noto per un modus operandi ad alta visibilità. La loro applicazione di T1578.002 è documentata come creazione di nuove VM all'interno dell'ambiente cloud del target dopo aver ottenuto accesso alle credenziali cloud. Il gruppo predilige l'accesso iniziale tramite insider recruitment e credential theft, e utilizza l'infrastruttura cloud della vittima stessa come piattaforma operativa — un pattern che elimina la necessità di infrastruttura C2 esterna e complica enormemente l'attribuzione.

Scattered Spider (G1015) presenta un profilo più strutturato e operativamente maturo. La loro creazione di istanze Amazon EC2 nell'ambiente vittima è specificamente documentata, e la campagna C0027 fornisce un contesto operativo dettagliato: tra giugno e dicembre 2022, il gruppo ha colpito aziende di telecomunicazioni e BPO con un approccio multi-vettore che combinava social engineering, SIM swapping e abuso dell'accesso cloud. Durante C0027, Scattered Spider ha creato Azure VM nel tenant delle vittime, dimostrando versatilità cross-cloud (sia AWS che Azure).

Pattern convergenti e implicazioni analitiche

Entrambi i gruppi condividono tratti che definiscono un cluster comportamentale emergente. Primo: la motivazione finanziaria, che li distingue dai gruppi state-sponsored ma non li rende meno pericolosi. Secondo: la preferenza per il "living off the cloud" — l'uso delle risorse della vittima anziché di infrastruttura propria. Terzo: l'accesso iniziale basato su social engineering e furto di credenziali, che rende le difese perimetrali tradizionali inefficaci.

Il settore telco e BPO emerge come target prioritario dalla campagna C0027, ma la tecnica è applicabile ovunque esistano ambienti cloud con permessi IAM eccessivi. L'analista TI dovrebbe monitorare con attenzione i report su gruppi che combinano social engineering con abuso di API cloud, e correlare qualsiasi segnale di insider threat o credential compromise con successiva attività di provisioning anomalo nell'ambiente cloud. La creazione di istanze non autorizzate rappresenta spesso un indicatore intermedio nella catena d'attacco: segnala che l'avversario ha già superato l'accesso iniziale e sta preparando il terreno per la raccolta dati o lo staging.

Framework MITRE ATT&CK v16: tecnica T1578.002 (Create Cloud Instance), tattica TA0005 (Defense Evasion), campagna C0027 (Scattered Spider, 2022). Detection basata su AWS CloudTrail e Azure Activity Log. Mitigazioni M1047 (Audit), M1018 (User Account Management). Tool di detection e simulazione: Pacu, ScoutSuite, Stratus Red Team, Prowler. Integrato con conoscenza professionale per tool e procedure operative.