Immagini Malevole: Malicious Image (T1204.003)

In un esercizio red team autorizzato la simulazione di T1204.003 richiede un ambiente lab isolato (account cloud dedicato, cluster Kubernetes di test) e la costruzione di immagini che riproducano il comportamento senza causare danni reali.

Sul fronte Docker, la catena tipica parte da un Dockerfile che aggiunge un payload benigno (es. uno script che scrive un file marker e apre una connessione verso un listener controllato). La build e la pubblicazione seguono il flusso standard:

docker build -t testorg/nginx-hardened:latest .

docker push testorg/nginx-hardened:latest

Per massimizzare la verosimiglianza dello scenario, il nome del repository può richiamare progetti popolari (typosquatting), sfruttando la logica di Match Legitimate Resource Name. Tool come dockerscan (open source) e Dockle (open source) permettono di ispezionare e comprendere quali layer contengono modifiche sospette, utili per pianificare sia l'attacco sia le contromisure.

Su AWS, la simulazione di una AMI compromessa passa per la creazione di un'immagine da un'istanza in cui è stato pre-installato un agente di test, seguita dalla condivisione con altri account del lab:

aws ec2 create-image --instance-id i-0123456789abcdef0 --name "amzn2-hardened-lab" --description "lab image"

aws ec2 modify-image-attribute --image-id ami-xxxxxxxx --launch-permission "Add=[{UserId=222222222222}]"

L'iniezione del payload avviene tipicamente via user-data o tramite servizi systemd che si attivano al primo boot. Il payload di test dovrebbe limitarsi a un beacon HTTP verso un C2 controllato (ad esempio un semplice listener costruito con http.server di Python) e a registrare le proprie azioni.

Per Kubernetes, l'attaccante può caricare l'immagine su un registry pubblico e distribuire un manifest che la referenzia con tag mutabile (:latest), sfruttando policy di imagePullPolicy: Always per garantire la propagazione degli aggiornamenti malevoli. Strumenti come kube-hunter (open source) e kube-bench (open source) aiutano a mappare quali cluster accetterebbero image pull da registry non approvati.

Per la fase di analisi post-esecuzione lato red team, Trivy (open source) e Grype (open source) permettono di scansionare l'immagine costruita per verificare quali indicatori sarebbero rilevabili da una supply chain security pipeline. Il gruppo TeamTNT ha storicamente adottato questo pattern con immagini Docker orientate al cryptomining, ed è il riferimento realistico per costruire uno scenario di simulazione.

La detection di T1204.003 richiede la correlazione tra eventi di image pull, container/instance start e comportamento anomalo nei primi minuti di vita del workload. Le analytics AN0691 (container) e AN0692 (IaaS) forniscono lo scheletro logico: pull da registry non approvato → creazione → start → esecuzione di utility inattese o traffico outbound atipico, il tutto entro una finestra breve (≤15 minuti per container, ≤30 minuti per VM al primo boot).

Le log source primarie per l'ecosistema container includono containerd:events, kubernetes:audit e kubernetes:events, integrate con auditd:SYSCALL sul nodo per catturare esecuzione di processi come bash, sh, curl, wget, nc o python all'interno di container applicativi che non dovrebbero mai spawnare shell interattive. Il flusso NSM completa il quadro rilevando connessioni verso CIDR o domini non presenti nella baseline del namespace.

Sul versante IaaS, gli eventi chiave sono AWS:CloudTrail (in particolare RunInstances, CreateImage, ModifyImageAttribute, ImportImage) e azure:activity per operazioni analoghe. La correlazione con WinEventLog:Sysmon al primo boot permette di intercettare ProcessCreate anomali (Event ID 1) e connessioni di rete (Event ID 3) generati da script cloud-init o user-data.

Gli alert più efficaci sono quelli che incrociano più dimensioni. Un pull da un registry pubblico non incluso nell'ImageRegistryAllowList (limitato a ECR/GCR/ACR organizzativi) è di per sé un weak signal, ma diventa forte quando seguito entro pochi minuti dallo spawn di curl o wget dentro un container che espone un servizio web. Analogamente, la creazione di un'istanza da un'AMI il cui owner non è nell'ApprovedImageCatalog, combinata con userData contenente direttive di download o exec, giustifica un alert prioritario.

Sul piano preventivo, l'ecosistema difensivo si appoggia a controlli come Docker Content Trust per la verifica delle firme, admission controller Kubernetes tipo Kyverno (open source) o OPA Gatekeeper (open source) per bloccare deployment da registry non autorizzati, e scanner di immagini come Trivy (open source) o Clair (open source) integrati nella pipeline CI/CD.

I falsi positivi principali derivano da attività DevOps legittime: rebuild automatici, test di nuove immagini in staging, aggiornamenti di base image. La riduzione del rumore passa per la segmentazione degli alert per namespace (produzione vs sviluppo), l'esclusione di service account CI/CD noti e la tuning della finestra temporale in base al tipo di workload. Un container che nel proprio contratto operativo deve effettivamente scaricare dati non dovrebbe generare alert quando lo fa verso destinazioni whitelisted.

L'indagine forense su un incidente T1204.003 parte dalla ricostruzione della catena di provenienza dell'immagine. Il primo obiettivo è identificare il digest esatto (SHA256) dell'immagine incriminata, che permette di distinguerla da versioni legittime con lo stesso tag e di correlare eventi tra nodi diversi.

Su Docker/containerd, gli artefatti chiave si trovano in /var/lib/docker/ o /var/lib/containerd/, con particolare attenzione ai file di metadata degli image layer e ai log di dockerd. Il comando docker image inspect restituisce digest, history dei layer, comandi CMD/ENTRYPOINT e variabili d'ambiente iniettate. Su Kubernetes, l'audit log del control plane (tipicamente in /var/log/kubernetes/audit.log o esposto via API server) conserva le richieste di create pod con il riferimento completo all'immagine, l'identità del service account chiamante e il timestamp.

La timeline ideale ricostruisce quattro fasi: pull dell'immagine, creazione del container/istanza, avvio del processo iniziale, prima azione anomala. Per la fase di pull, containerd:events e i log del registry (quando accessibili) forniscono l'IP di origine e le credenziali utilizzate. Per la fase di esecuzione, auditd configurato con regole su execve cattura ogni processo generato dentro il namespace, mentre Sysmon for Linux (open source) offre un livello di dettaglio superiore su file, rete e processi.

Su AWS, gli eventi CloudTrail rilevanti includono RunInstances (con il campo imageId), DescribeImages, CreateImage e SharedSnapshotVolumePermissionModified. L'analisi delle EBS snapshot dell'istanza compromessa permette di ricostruire lo stato del filesystem al momento della compromissione. I log di VPC Flow correlati all'eni-id dell'istanza rivelano le destinazioni contattate nei primi minuti dopo il boot, spesso il tratto più significativo per identificare pool di mining o infrastruttura C2.

Per le immagini stesse, l'estrazione forense può avvenire con docker save seguito da un'analisi layer-per-layer con dive (open source), che espone quali file sono stati aggiunti in ciascuno step del Dockerfile. Trivy (open source) e Syft (open source) generano SBOM che aiutano a identificare componenti non previsti, mentre Grype (open source) correla contro database di vulnerabilità e malware noti.

Sul fronte delle attribuzioni, il gruppo TeamTNT è documentato per l'uso sistematico di immagini Docker malevole distribuite via Docker Hub, tipicamente con payload di cryptomining basati su XMRig, scanner di credenziali AWS e worm che si propagano verso API Docker esposte. Gli artefatti caratteristici includono script di init che disabilitano security tool, credential harvesting da file ~/.aws/credentials e /root/.docker/config.json, e connessioni verso pool Monero.

Il panorama degli attori che sfruttano T1204.003 è dominato quantitativamente da gruppi orientati al cryptojacking cloud-native, con TeamTNT (G0139) come riferimento canonico documentato da MITRE. Il gruppo si è specializzato nell'abuso di container e ambienti cloud, distribuendo immagini Docker malevole che gli utenti scaricano ed eseguono ignari, senza necessità di sfruttare vulnerabilità o credenziali compromesse. La scelta di questo vettore è pragmatica: elimina la necessità di attaccare l'infrastruttura del bersaglio, spostando l'onere sull'utente finale che accetta di deployare un'immagine di fiducia apparente.

Il pattern operativo di TeamTNT documentato evidenzia diverse costanti. Le immagini vengono ospitate su repository pubblici, spesso con nomi che richiamano progetti legittimi (nginx, mysql, ubuntu con varianti minime nel naming). Il payload iniziale è quasi sempre orientato al mining Monero, ma i componenti secondari includono routine di credential harvesting che cercano token cloud, chiavi SSH e credenziali Docker/Kubernetes. Il gruppo ha mostrato una capacità evolutiva costante, integrando funzionalità worm che estendono la compromissione ad altri host Docker esposti su Internet.

Sul piano strategico, il vettore delle malicious image si allinea perfettamente con la superficie di attacco moderna: adozione massiva di container, dipendenza da registry pubblici, pipeline CI/CD che pull-ano automaticamente immagini aggiornate. La tecnica si presta particolarmente bene ad attacchi opportunistici su larga scala, dove il ROI non richiede un target specifico ma la compromissione statistica di una frazione degli utenti che scaricano l'immagine.

Le implicazioni per il threat modeling organizzativo sono significative. Un attore che riesce a compromettere anche solo temporaneamente un account su un registry popolare, o a pubblicare un typosquat convincente, può raggiungere un numero di vittime ordini di grandezza superiore rispetto a tecniche di Initial Access tradizionali. Il fatto che MITRE elenchi un solo gruppo formalmente associato riflette probabilmente una sottorappresentazione: molte campagne di cryptojacking cloud non vengono attribuite formalmente perché il livello di sofisticazione tecnica è basso e l'attribuzione richiede telemetria che raramente viene condivisa.

La traiettoria di lungo periodo suggerisce un'espansione oltre il cryptomining verso payload più impattanti: backdoor persistenti in workload di produzione, esfiltrazione di dati sensibili da container che processano informazioni riservate, e uso di immagini malevole come initial foothold per attacchi supply chain più articolati contro clienti downstream. La distinzione tra attori financially-motivated e attori state-sponsored su questo vettore tenderà probabilmente a sfumare, man mano che la maturità difensiva dei registry pubblici si rivela strutturalmente inferiore a quella degli endpoint tradizionali.

Dati tecnici da MITRE ATT&CK per T1204.003 (Malicious Image), gruppo G0139 (TeamTNT), mitigazioni M1017, M1031, M1045, M1047 e detection analytics AN0691, AN0692. Riferimenti difensivi cross-mappati con MITRE D3FEND. Per comandi, tool di scansione (Trivy, Grype, Dive, Syft, Dockle) e admission controller (Kyverno, OPA Gatekeeper) è stata integrata conoscenza professionale di cybersecurity basata su documentazione ufficiale e repository open source pubblici.