Job di Orchestrazione Container: Container Orchestration Job (T1053.007)

Sul fronte offensivo, la simulazione lab-safe richiede un cluster di test — un minikube o kind (entrambi open source) isolato da qualsiasi ambiente di produzione. Il presupposto è disporre di credenziali con permessi create sull'oggetto CronJob nel namespace target, condizione che in un red team nasce tipicamente da un service account token esfiltrato o da RBAC eccessivamente permissivo.

La catena tipica parte dalla ricognizione dei permessi. Con kubectl (open source) si verifica cosa è consentito:

kubectl auth can-i create cronjobs --namespace default

Se la risposta è affermativa, si può dichiarare un manifest YAML che definisce un CronJob con schedule (ad esempio "@hourly" o una crontab espressa nei cinque campi standard), un'immagine e un comando arbitrario nel campo command. L'applicazione avviene con:

kubectl apply -f cronjob.yaml

Un payload dimostrativo può limitarsi a un container leggero che apre una reverse shell verso un listener di laboratorio, oppure che monta risorse del nodo per validare il salto di contesto. Per verificare l'esecuzione:

kubectl get jobs --watch

e l'ispezione dei log del pod generato con kubectl logs.

La fase di escalation si concentra sui service account: enumerare i token montati automaticamente in /var/run/secrets/kubernetes.io/serviceaccount/, testare l'accesso all'API server e cercare CronJob eseguiti come root o con securityContext.privileged: true, che consentono di raggiungere il filesystem del nodo.

Per automatizzare l'assessment sono utili tool consolidati. kube-hunter (open source) individua superfici d'attacco e configurazioni deboli; kube-bench (open source) verifica la conformità ai CIS Benchmark, evidenziando RBAC lassista e Pod Security assenti. Peirates (open source) è specifico per pentest Kubernetes e include moduli per abusare di service account e schedulare carichi. Per l'analisi dei permessi RBAC, rbac-tool e kubectl-who-can (entrambi open source) mappano chi può creare oggetti sensibili.

In un engagement realistico, la persistenza va documentata mostrando come il CronJob sopravviva alla cancellazione dei pod figli: eliminando il singolo pod, l'oggetto padre lo ricrea alla schedulazione successiva. Questo comportamento va sempre replicato in ambiente controllato, con cleanup finale via kubectl delete cronjob per non lasciare artefatti residui nel cluster di test.

La detection di questa tecnica è puramente cloud-native e ruota attorno agli oggetti Kubernetes, non ai log di sistema tradizionali. La detection DET0206 indica come sorgenti primarie l'audit log dell'API server (kubernetes:apiserver), gli eventi del cluster (kubernetes:events) e i log del proxy container (container:proxy).

Il segnale di partenza è la creazione o modifica di oggetti CronJob e Job. Nell'audit log dell'API server, un SOC deve monitorare le richieste con verb uguale a create o update e resource di tipo cronjobs o jobs, correlando l'identità del chiamante nel campo user.username e il service account d'origine. Ogni creazione di CronJob da parte di utenti o service account che non appartengono alla pipeline CI/CD legittima è un candidato ad alert.

Il tuning suggerito dalla detection offre quattro leve concrete. Il NamespaceScope consente di restringere l'attenzione ai namespace effettivamente destinati a carichi schedulati, riducendo il rumore nei namespace applicativi noti. L'ImageRepository permette di allertare quando un Job estrae immagini da registry non presenti nella allow-list aziendale. Lo ScheduleWindow evidenzia schedulazioni anomale — job pianificati a orari insoliti o con frequenze aggressive come "@hourly" meritano ispezione. Infine l'ExecutionCommand analizza l'entrypoint o il command del container: la presenza di interpreti di shell, curl, wget o interpreti di scripting inattesi è un forte indicatore.

Sul piano dei controlli preventivi, l'allineamento con le mitigazioni M1018 e M1026 è diretto. Applicare RBAC secondo il principio del minimo privilegio limita quali identità possono creare oggetti schedulati; le Pod Security Standards in modalità restricted impediscono container privilegiati o in esecuzione come root, riducendo il valore della tecnica per l'escalation. L'adozione di un admission controller — ad esempio OPA Gatekeeper o Kyverno (entrambi open source) — permette di bloccare in ingresso i manifest che violano le policy su registry, securityContext e namespace.

Sul fronte runtime, Falco (open source) genera alert comportamentali quando un pod appena creato lancia una shell o effettua connessioni di rete sospette, offrendo una seconda linea difensiva indipendente dall'audit log.

I falsi positivi derivano soprattutto da automazioni legittime: pipeline GitOps come ArgoCD o Flux, operatori che creano Job di manutenzione, backup schedulati. Costruire una baseline dei CronJob attesi per namespace è il passo che rende gli alert gestibili.

L'analisi forense di un incidente legato a T1053.007 si svolge quasi interamente sul piano di controllo di Kubernetes e sullo stato dichiarativo del cluster, integrato dagli artefatti dei nodi worker coinvolti.

Il punto di partenza è l'audit log dell'API server, che rappresenta la fonte autoritativa della timeline. Ogni richiesta è registrata con timestamp, identità del chiamante, service account, indirizzo sorgente e corpo dell'oggetto. Ricostruire la sequenza create cronjob seguita dai successivi create job e create pod consente di stabilire il momento esatto dell'impianto della persistenza e la cadenza delle esecuzioni. È fondamentale correlare il campo responseObject per recuperare la definizione completa del CronJob: schedule, immagine, comando e securityContext.

Sullo stato vivo del cluster, l'analista raccoglie gli oggetti ancora presenti. Comandi come kubectl get cronjob -A -o yaml e kubectl describe job estraggono la configurazione persistente e le relazioni parent-child tra CronJob, Job e pod. Il campo creationTimestamp di ciascun oggetto contribuisce alla timeline, così come le annotazioni last-schedule-time che indicano l'ultima attivazione. Gli eventi del cluster documentano il ciclo di vita dei pod: scheduling, pull dell'immagine, avvio e terminazione.

Sul nodo worker dove i pod sono stati eseguiti, gli artefatti runtime completano il quadro. I log del container runtime (containerd o CRI-O) e i layer del filesystem sotto /var/lib/containerd o /var/lib/docker conservano tracce dei container terminati. L'immagine effettivamente eseguita va estratta e analizzata: hash dei layer, entrypoint e binari inseriti. Se il container era privilegiato o montava percorsi del nodo, occorre verificare modifiche persistenti sull'host — file in /etc, unit systemd, chiavi SSH aggiunte — che rappresentano un salto di contesto dal pod al nodo.

Gli artefatti di rete a supporto includono i log del kube-proxy e le connessioni in uscita generate dai pod schedulati, utili a identificare canali C2 o esfiltrazione. La correlazione tra l'orario di schedulazione del CronJob e i picchi di traffico rafforza l'attribuzione dell'attività.

Per l'acquisizione, tool come kube-forensics e la raccolta strutturata via Sysdig Inspect (open source) permettono di catturare lo stato di pod e cluster in formato analizzabile. In assenza di audit log — scenario purtroppo comune quando l'audit policy non è configurata — l'analista deve ripiegare sugli eventi residui, sui log del runtime dei nodi e sullo stato etcd, ricordando che gli oggetti transitori come i pod completati vengono spesso raccolti dal garbage collector, riducendo la finestra di analisi.

I dati MITRE ATT&CK associati a questa tecnica non riportano gruppi APT, software o campagne formalmente attribuiti a T1053.007. Questa assenza di attribuzione codificata è di per sé un elemento di intelligence significativo e va interpretata con attenzione dal punto di vista di un analista di threat intelligence.

La mancanza di profili documentati non indica assenza di rischio, ma riflette piuttosto la relativa novità della superficie d'attacco cloud-native rispetto alle tecniche tradizionali su endpoint Windows e Linux. L'orchestrazione container è entrata nel radar dei framework di attribuzione più tardi, e la telemetria necessaria a legare un CronJob malevolo a un attore specifico — audit log dell'API server correttamente configurati e conservati — è storicamente carente in molti ambienti, il che ostacola l'attribuzione a posteriori.

Dal punto di vista dei pattern operativi, la tecnica si colloca naturalmente nella fase post-compromissione. Un attore che l'adotta ha già ottenuto credenziali o token di service account con permessi sufficienti sull'API server, il che la rende tipicamente successiva a fasi di Initial Access basate su applicazioni esposte, secret trapelati o cluster con dashboard non autenticate. Il profilo di attore più coerente con questa capacità è duplice: da un lato gruppi orientati al cryptojacking, che sfruttano la schedulazione automatica per garantire la persistenza dei miner e la ricreazione dei container terminati; dall'altro attori più sofisticati interessati alla persistenza silenziosa in ambienti ad alto valore.

Il valore strategico della tecnica per un attaccante risiede in tre proprietà. La persistenza automatizzata, poiché il cluster stesso ricrea il carico malevolo senza intervento; la scalabilità laterale, dato che un Job può distribuire codice su più nodi; e la bassa visibilità, perché l'attività vive in oggetti dichiarativi legittimi anziché in binari sospetti sul disco.

Sul piano dei trend, l'adozione crescente di Kubernetes in produzione amplia costantemente la superficie esposta, e la convergenza tra tecniche di persistenza cloud-native e abuso di RBAC rende plausibile un aumento futuro delle attribuzioni. Un programma di intelligence maturo dovrebbe presidiare in via prioritaria l'igiene dei service account e la correlazione tra creazione di oggetti schedulati e identità anomale, trattando ogni CronJob non censito come potenziale segnale di compromissione in attesa di attribuzione. In assenza di IOC pubblici consolidati, la difesa deve basarsi su indicatori comportamentali e su una solida baseline del cluster.

MITRE ATT&CK: tecnica T1053.007 (Container Orchestration Job), tattiche TA0002, TA0003, TA0004; mitigazioni M1018 e M1026; detection DET0206 con analitica AN0582 (log kubernetes:apiserver, kubernetes:events, container:proxy). Tool di detection e testing citati: kube-hunter, kube-bench, Peirates, Falco, OPA Gatekeeper, Kyverno, rbac-tool. Per comandi, tool operativi e artefatti forensi è stata integrata conoscenza professionale di cybersecurity basata su documentazione ufficiale Kubernetes e repository pubblici dei rispettivi progetti.