Immagini Malevole: Malicious Image (T1204.003)

Quando un avversario prepara un'immagine container o cloud con codice malevolo incorporato e la pubblica su un registry pubblico, sta scommettendo su un singolo fattore: la fiducia implicita dell'operatore nel repository da cui scarica. La tecnica T1204.003 — Malicious Image si colloca nella fase di Execution (TA0002), perché l'obiettivo è ottenere l'esecuzione di codice controllato dall'attaccante sfruttando il momento in cui un utente avvia un'istanza VM o un container basato sull'immagine compromessa.

Il vettore è trasversale: riguarda le Amazon Machine Image (AMI) su AWS, le GCP Image su Google Cloud, le Azure Image e i runtime container come Docker, containerd e Kubernetes. L'immagine può contenere backdoor, cryptominer o agent C2 che si attivano automaticamente al primo avvio senza che l'operatore se ne accorga. In molti casi gli attaccanti scelgono nomi deliberatamente simili a immagini legittime — una tecnica di typosquatting applicata ai registry — per massimizzare la probabilità di deployment accidentale.

L'ecosistema MITRE documenta 1 gruppo APT associato, 4 mitigazioni e nessuna campagna o software dedicato, il che suggerisce che la tecnica viva soprattutto nell'underground criminale legato al cryptojacking più che nelle operazioni di spionaggio tradizionale.

La simulazione di T1204.003 in laboratorio richiede un registry privato e un cluster container isolato. L'obiettivo è dimostrare al cliente quanto sia semplice eseguire codice arbitrario attraverso un'immagine apparentemente innocua.

Il primo passo è costruire un'immagine Docker con un payload embedded. Parti da un Dockerfile minimale che usi un'immagine base legittima e aggiunga un entrypoint malevolo. In un contesto di red team, il payload può essere un semplice reverse shell o un simulatore di cryptominer:

docker build -t internal-registry.lab/nginx-app:latest -f Dockerfile.backdoor .

L'immagine va poi pubblicata sul registry del laboratorio. In ambiente reale, gli attaccanti usano Docker Hub o registri cloud pubblici; in laboratorio, un registry locale è sufficiente:

docker push internal-registry.lab/nginx-app:latest

Il Dockerfile di test può essere estremamente semplice: un'immagine alpine che al primo avvio scarica ed esegue uno script. All'interno dell'entrypoint, inserisci comandi come wget verso un server C2 controllato, oppure avvia un processo che simula mining con output su stdout. Il nome dell'immagine deve imitare un componente legittimo — qui entra in gioco il typosquatting sui nomi delle immagini: nginx-app, redis-cache, node-api sono tutti nomi plausibili.

Per il versante IaaS, la simulazione su AWS prevede la creazione di un'AMI custom con un servizio systemd malevolo che si attiva al boot. Usa Packer (open source) di HashiCorp per automatizzare la build:

packer build -var 'region=eu-west-1' malicious-ami.pkr.hcl

Una volta che l'AMI è disponibile, lancia un'istanza EC2 e verifica che il payload si attivi automaticamente al primo boot tramite cloud-init o user-data. Strumenti come Stratus Red Team (open source) di DataDog permettono di simulare scenari offensivi su AWS, GCP e Azure con tecniche mappate direttamente sulle TTP.

Sul fronte Kubernetes, puoi deployare l'immagine malevola con un manifest YAML standard e osservare l'esecuzione tramite i log del kubelet. Per il rilevamento, usa Falco (open source) della CNCF, che intercetta le syscall anomale all'interno dei container e genera alert in tempo reale. Configurare Falco prima della simulazione permette di validare contestualmente le regole di detection.

Un aspetto spesso trascurato: verifica anche che Docker Content Trust (integrato in Docker) blocchi effettivamente il pull di immagini non firmate impostando la variabile d'ambiente DOCKER_CONTENT_TRUST=1. Questo è il controllo che un'organizzazione dovrebbe avere attivo e che il tuo test deve provare a bypassare o validare.

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto fin dal primo passo