Immagini Interne Compromesse: Implant Internal Image (T1525)

In un ingaggio red team la simulazione di questa tecnica parte sempre dopo aver ottenuto un foothold con permessi sufficienti a leggere e modificare immagini o registry. L'obiettivo è dimostrare la propagazione del backdoor attraverso la pipeline di provisioning, non solo l'iniezione isolata.

Sul fronte container Docker, il flusso lab-safe più didattico è pull, modifica e re-push verso un registry interno controllato. Si scarica l'immagine base con docker pull /:, la si personalizza aggiungendo un layer con una web shell o un reverse shell di test, quindi si ricostruisce con docker build -t /: . e si ripubblica con docker push /:. Un approccio alternativo, più stealth, è docker commit su un container in esecuzione modificato, che preserva il tag originale e riduce le tracce nel Dockerfile.

Per la generazione automatica di layer malevoli esistono strumenti di ricerca dedicati; a scopo di laboratorio è preferibile usare payload noti e controllati come quelli generati da msfvenom (open source, parte di Metasploit Framework) o web shell minimali scritte a mano, così da mantenere il controllo completo sull'artefatto.

In ambiente AWS la catena tipica è: enumerazione con aws ec2 describe-images --owners self, avvio di un'istanza dall'AMI base, modifica del filesystem introducendo un meccanismo di persistenza (cron job, unit systemd o account aggiuntivo), poi creazione della nuova AMI backdoored con aws ec2 create-image --instance-id --name . Se il template di launch o l'Auto Scaling Group punta all'ultima AMI per tag, ogni scale-out replicherà il backdoor. Su GCP l'operazione equivalente sfrutta gcloud compute images create, su Azure la creazione di immagini gestite tramite la CLI az image create.

Un laboratorio realistico si costruisce con:

• Docker e un registry locale come Harbor (open source) o il registry di riferimento;
• Trivy (open source) per verificare cosa un difensore vedrebbe nella scansione;
• Pacu (open source) per l'enumerazione dei permessi IAM che abilitano l'attacco su AWS.

Il punto chiave da evidenziare al cliente è la combinazione permessi eccessivi più provisioning automatico: senza controllo su chi può registrare immagini, un singolo push contamina l'intera flotta.

La detection di questa tecnica è quasi interamente comportamentale, perché l'azione malevola riusa API e flussi legittimi. Il segnale non è "un'immagine viene creata", ma chi, quando e con quale scarto temporale rispetto al deploy.

Per l'ambiente container, le fonti primarie sono i log del docker:daemon e del docker:registry. La strategia di rilevamento AN0946 si concentra sull'iniezione di codice in un'immagine seguita da push nel registry e uso immediato in nuovi deployment. Tre parametri di tuning guidano gli alert:

• TimeWindow: uno scarto molto breve tra creazione dell'immagine e suo utilizzo in deployment è anomalo — l'attività legittima passa da build, test e review, quella avversaria è rapida.
• UserContext: definire gli utenti o service account che normalmente eseguono push; un push da un'identità inattesa è un forte indicatore.
• RegistryNameRegex: modellare i pattern di naming dei registry fidati per far emergere destinazioni non conformi.

Sul versante IaaS, la strategia AN0947 monitora la creazione o modifica di immagini VM (AMI, immagini custom) con meccanismi di persistenza, seguita da provisioning che le utilizza. La fonte cardine è AWS:CloudTrail, dove eventi come CreateImage, RegisterImage e CopyImage vanno correlati con i successivi RunInstances. I tuning rilevanti sono l'IAMRole autorizzato (che deve essere ristretto), l'ImageTagRegex dei nomi attesi come 'golden-image' o 'base-image', e la LaunchWindow, l'intervallo tra creazione immagine e avvio istanza.

Sul piano preventivo, le mitigazioni MITRE offrono controlli concreti. Il Code Signing (M1045) sfrutta i content trust model dei provider cloud che richiedono immagini firmate da sorgenti fidate: un'immagine non firmata o firmata da chiave non attesa diventa immediatamente sospetta. Il Privileged Account Management (M1026) limita chi può registrare o modificare immagini secondo il minimo privilegio, riducendo la superficie. L'Audit (M1047) impone verifiche periodiche di integrità di immagini e container.

Sul fronte dei falsi positivi, le pipeline CI/CD legittime generano naturalmente creazioni frequenti di immagini e deploy rapidi: senza una baseline di service account e registry fidati, gli alert su TimeWindow diventano rumore. La chiave è correlare l'identità che effettua il push con la sua storia comportamentale e con l'assenza di firma valida. Integrare gli eventi CloudTrail e i log Docker in un SIEM come Splunk o QRadar consente di costruire regole di correlazione tra fase di iniezione e fase di utilizzo.

L'analisi forense di un'immagine interna compromessa lavora su due livelli: l'artefatto immagine in sé e le tracce che ne documentano creazione e utilizzo lungo la timeline.

Nell'ecosistema container, il primo elemento è la struttura a layer dell'immagine Docker. Ogni layer è un filesystem incrementale e conserva metadati preziosi: docker history rivela la sequenza dei comandi che l'hanno costruita, mentre docker inspect espone il manifest, gli hash dei layer, le variabili d'ambiente, l'entrypoint e i timestamp. Un layer aggiunto fuori dalla pipeline ufficiale, con un timestamp che non combacia con la build attesa o che introduce binari e web shell, è il reperto centrale. L'estrazione con docker save -o .tar consente di sezionare offline i singoli layer e ricercarvi payload. La correlazione va fatta con i log del daemon e del registry, che datano il push e ne identificano l'origine.

Sul lato IaaS AWS, la timeline si ricostruisce dagli eventi AWS:CloudTrail. Gli eventi CreateImage, RegisterImage e CopyImage forniscono l'identità IAM che ha generato l'immagine, l'IP sorgente, lo user agent e il timestamp; correlandoli con i successivi RunInstances si misura la LaunchWindow e si dimostra la propagazione del backdoor. La firma delle immagini, se presente, permette di distinguere artefatti fidati da quelli iniettati.

Dentro le istanze o i container derivati dall'immagine compromessa, gli artefatti di persistenza classici confermano la catena:

• su Linux, unit systemd anomale, job in /etc/cron., chiavi in ~/.ssh/authorized_keys, account aggiunti in /etc/passwd;
• su Windows, chiavi Run nel registro, servizi e scheduled task inseriti nell'immagine base;
• web shell depositate nelle directory servite dal web server.

Un tassello spesso decisivo è il confronto di integrità. Recuperando l'immagine golden originale da backup o da una copia fidata e confrontandone gli hash dei layer con quella in produzione, si isola con precisione la modifica illecita. Questo riflette la mitigazione Audit (M1047), che raccomanda verifiche periodiche di integrità proprio per rilevare immagini alterate. Per l'analisi statica dei layer estratti sono utili scanner come Trivy (open source) e, per l'ispezione layer-by-layer, dive (open source), che evidenzia file aggiunti o modificati rispetto alla base attesa, accelerando l'individuazione del reperto malevolo.

Per la tecnica T1525 – Implant Internal Image i dati MITRE ATT&CK non riportano gruppi APT, software o campagne formalmente associati. Questo vuoto documentale è di per sé un dato di intelligence significativo e va interpretato, non riempito con attribuzioni non supportate.

L'assenza di attori censiti non implica assenza di rischio. Piuttosto, riflette la natura della tecnica: è un'azione di persistenza profonda che opera dentro il perimetro già compromesso, difficile da osservare dall'esterno e raramente isolabile come firma di un singolo gruppo. Le contaminazioni di immagini interne tendono a emergere come fase di intrusioni più ampie, dove l'attribuzione viene assegnata a tecniche di accesso iniziale o di esfiltrazione più visibili, lasciando l'impianto dell'immagine come dettaglio tecnico non attribuito.

Dal punto di vista del trend, la superficie d'attacco cresce con l'adozione di infrastrutture immutabili e provisioning automatizzato. La logica "usa sempre l'ultima immagine" — pensata per la manutenibilità — è esattamente il moltiplicatore che rende questa tecnica attraente: un singolo artefatto contaminato si propaga senza ulteriore intervento. Gli ambienti a più alto rischio sono quelli che combinano permessi IAM ampi sulla registrazione di immagini con pipeline CI/CD che non impongono firma o verifica di integrità.

MITRE segnala l'esistenza di un tool sviluppato specificamente per facilitare l'inserimento di backdoor in immagini container cloud, elemento che abbassa la barriera d'ingresso e rende la tecnica accessibile anche ad attori meno sofisticati una volta ottenuto il foothold. Lo scenario di riferimento citato — accesso a un'istanza AWS compromessa, permessi di enumerazione delle immagini e impianto di una web shell — descrive un percorso operativo replicabile su larga scala.

Per un Threat Intelligence Officer la priorità è quindi la modellazione del rischio più che il tracking di attori specifici. Raccomandazioni operative:

• monitorare le identità che possono creare o modificare immagini come asset critici;
• trattare le immagini golden come parte della supply chain interna, applicando content trust e firma;
• correlare gli indicatori di questa tecnica con altre fasi della kill chain, poiché comparirà quasi sempre in combinazione con accesso privilegiato e movimento laterale.

In sintesi, la mancanza di profili APT dedicati va comunicata al management come un problema di visibilità e sotto-reporting, non come indice di bassa minaccia.

MITRE ATT&CK: tecnica T1525 (Implant Internal Image), tattica TA0003 (Persistence). Mitigazioni M1026 (Privileged Account Management), M1045 (Code Signing), M1047 (Audit). Strategia di detection DET0334 con analitiche AN0946 (Containers) e AN0947 (IaaS). Tool di detection e analisi citati: Trivy, dive, Pacu, Harbor, Metasploit/msfvenom, Splunk, QRadar. Per comandi operativi, artefatti forensi e procedure di laboratorio è stata integrata conoscenza professionale di cybersecurity basata su strumenti e sintassi verificabili.