Ruoli Kubernetes Aggiuntivi: Additional Container Cluster Roles (T1098.006)

Un red teamer che vuole simulare T1098.006 parte dalla premessa di aver già ottenuto credenziali o un token di service account con permessi sufficienti per creare binding. Il primo passo è enumerare i propri diritti effettivi con kubectl (open source):

kubectl auth can-i --list

Se l'output mostra la capacità create sulle risorse rolebindings o clusterrolebindings nel apiGroup rbac.authorization.k8s.io, la tecnica è praticabile. Utile anche verificare la possibilità di creare serviceaccounts e leggere secrets, per costruire una catena completa.

Per la ricognizione dei ruoli esistenti e delle loro capacità, rbac-lookup e rbac-tool di Insights (entrambi open source) permettono di mappare rapidamente chi può fare cosa. Un comando tipico:

rbac-tool policy-rules -e '.'*

restituisce la matrice completa dei permessi effettivi nel cluster. Per identificare percorsi di escalation, kubiscan (open source) evidenzia service account con token montati in pod e privilegi eccessivi.

La creazione del binding malevolo avviene applicando un manifest YAML che lega un ClusterRole esistente come cluster-admin a un service account controllato. Il pattern operativo prevede kubectl apply -f binding.yaml dove il file definisce un oggetto ClusterRoleBinding con roleRef verso cluster-admin e subjects verso il service account bersaglio. In alternativa, per operare in modo meno rumoroso, è possibile creare un ClusterRole custom con permessi mirati (solo secrets e pods/exec, ad esempio) e legarlo con un nome che si mimetizzi con quelli di sistema come system:controller:custom-metrics.

Per la fase di validazione, il token del service account promosso viene estratto dal Secret associato (nei cluster pre-1.24) o generato con kubectl create token nelle versioni successive. Il token permette l'accesso via API server usando kubectl con un kubeconfig alternativo oppure direttamente via curl con header Authorization: Bearer.

Per catene d'attacco end-to-end in laboratorio, kube-hunter (open source) di Aqua Security individua misconfigurazioni sfruttabili come punto d'ingresso, mentre peirates (open source) di InGuardians automatizza post-exploitation da dentro un pod compromesso, inclusa la ricerca di token privilegiati e la creazione di binding. Ambienti di test come kind o minikube (entrambi open source) permettono di replicare scenari EKS/GKE senza costi cloud, mentre kubernetes-goat (open source) fornisce scenari didattici deliberatamente vulnerabili.

La detection di T1098.006 dipende quasi interamente dagli audit log di Kubernetes, che devono essere abilitati esplicitamente attraverso una audit policy configurata nel kube-apiserver. Senza questa configurazione, la creazione di un ClusterRoleBinding è invisibile. Il primo controllo che un SOC deve effettuare è verificare che la audit policy catturi eventi di livello RequestResponse per le risorse del apiGroup rbac.authorization.k8s.io.

La regola di detection DET0572 (analitica AN1579) descrive esattamente il pattern da monitorare: assegnazione di ruoli ad alto privilegio via RoleBinding o ClusterRoleBinding, particolarmente al di fuori dei flussi CI/CD attesi o da IP sconosciuti. La sorgente log è kubernetes:audit.

Gli eventi rilevanti nell'audit log hanno objectRef.resource pari a rolebindings o clusterrolebindings e verb uguale a create, update o patch. Nel campo requestObject.roleRef.name si trova il ruolo assegnato: alert immediato su valori come cluster-admin, admin, edit, o su qualsiasi ClusterRole che concede * su *. Il campo user.username identifica chi ha eseguito l'azione, mentre sourceIPs fornisce l'origine di rete.

Il tuning richiesto per ridurre i falsi positivi è sostanziale. Le pipeline CI/CD legittime (ArgoCD, Flux, Helm operator) creano regolarmente binding e vanno inserite in allowlist tramite user.username o userAgent. Gli operatori Kubernetes installati via Helm chart spesso creano ClusterRoleBinding come parte del deployment, quindi correlare temporalmente con eventi di installazione di chart aiuta a discriminare. Alert aggiuntivi vanno impostati su binding creati fuori dagli orari lavorativi o da IP non appartenenti ai range noti dei runner CI/CD.

Strumenti che facilitano questa detection includono Falco (open source) della CNCF, che dispone di regole preconfezionate per RBAC changes nel ruleset k8s_audit_rules.yaml, e Kubescape (open source) di ARMO per audit continuo delle configurazioni RBAC. Le piattaforme commerciali di Cloud Workload Protection come Sysdig Secure, Aqua CSP, Prisma Cloud e Wiz (tutte a pagamento) integrano queste analitiche con contesto di postura.

Dal punto di vista D3FEND, le tecniche difensive rilevanti sono User Account Permissions (hardening) e Administrative Network Activity Analysis (detect). L'artefatto digitale centrale è il User Account e la sua Access Control Configuration. Un controllo preventivo essenziale è l'admission control tramite OPA Gatekeeper o Kyverno (entrambi open source), che possono bloccare la creazione di binding verso ruoli critici se non provengono da namespace o service account autorizzati.

L'analisi forense di un incidente che coinvolge T1098.006 ruota attorno agli audit log del kube-apiserver come fonte primaria di verità. La ricostruzione della timeline richiede l'esportazione completa degli eventi audit del periodo di interesse, tipicamente conservati come file JSON strutturati sul control plane o inoltrati a un backend centralizzato (Elasticsearch, Loki, CloudWatch, Azure Monitor).

Per ogni evento rilevante, i campi da estrarre sono requestReceivedTimestamp (istante dell'operazione), user.username e user.groups (identità dell'attore), sourceIPs (origine di rete), userAgent (client utilizzato, spesso rivelatore: kubectl/v1.28, Go-http-client, o stringhe custom di tool offensivi), objectRef (risorsa target) e requestObject (contenuto completo del binding creato, inclusi roleRef e subjects). L'auditID permette di correlare la request con la response.

La timeline forense tipica intreccia più eventi: autenticazione iniziale del principal compromesso (visibile come TokenReview o eventi di autenticazione del cloud provider), enumerazione dei permessi (chiamate a SelfSubjectAccessReview o SelfSubjectRulesReview), creazione eventuale di un service account fittizio, creazione del ClusterRoleBinding malevolo, e infine utilizzo dei nuovi privilegi (accesso a secrets, esecuzione di pods/exec, deployment di workload). Ricostruire questa sequenza permette di distinguere un compromise reale da un'anomalia benigna.

Nei cluster gestiti dai cloud provider gli audit log Kubernetes si affiancano a log del piano IAM. Su EKS gli audit log fluiscono in CloudWatch Logs nel log group /aws/eks//cluster se il control plane logging è abilitato, e vanno correlati con CloudTrail per catturare l'uso delle credenziali IAM sottostanti. Su GKE i log arrivano in Cloud Logging sotto la risorsa k8s_cluster, correlabili con Cloud Audit Logs per attività IAM. Su AKS l'integrazione avviene con Azure Monitor e i log di Entra ID.

Gli artefatti secondari includono lo stato corrente del cluster: kubectl get clusterrolebindings -o yaml e kubectl get rolebindings --all-namespaces -o yaml forniscono lo snapshot delle configurazioni RBAC al momento dell'acquisizione. Confrontare questo snapshot con backup precedenti o con manifest gestiti via GitOps (repository ArgoCD/Flux) permette di identificare binding aggiunti fuori dai canali autorizzati. Anche i Secret contenenti token di service account vanno inventariati: la loro data di creazione, visibile in metadata.creationTimestamp, aiuta a delimitare finestre temporali sospette.

Per analisi offline, kube-forensics (open source) e kubectl-neat (open source) facilitano l'esportazione pulita degli oggetti cluster. Sigma rules (open source) per Kubernetes audit forniscono pattern riutilizzabili in fase di hunting retroattivo.

Nei dati MITRE ATT&CK forniti per T1098.006 non risultano gruppi APT, software o campagne attribuiti in modo specifico a questa sotto-tecnica. L'assenza di attribuzione formale non riflette una scarsa rilevanza operativa, quanto piuttosto la relativa giovinezza del vettore container nel corpus di threat intelligence pubblico e la difficoltà di attribuzione precisa quando l'attività avviene interamente dentro il piano di controllo Kubernetes.

Dal punto di vista dell'analisi di trend, la manipolazione RBAC in cluster Kubernetes appartiene a una famiglia più ampia di tecniche di account manipulation in ambienti cloud-native, che comprende T1098.003 (Additional Cloud Roles) e T1136.003 (Create Cloud Account). Gli attori che dimostrano capacità in questa area combinano generalmente conoscenza di API cloud e Kubernetes, competenze non universali nel panorama threat.

Il profilo di attore più coerente con lo sfruttamento di T1098.006 include tre archetipi. Il primo è rappresentato da gruppi orientati al cryptojacking che compromettono cluster esposti per il mining, dove la persistenza via RBAC binding garantisce ridistribuzione dei workload di mining anche dopo pulizia parziale. Il secondo è costituito da attori ransomware che negli ultimi anni hanno esteso il target da endpoint tradizionali a infrastrutture cloud e container, dove il controllo del cluster consente accesso simultaneo a decine di applicazioni e ai loro dati persistenti. Il terzo è quello dei gruppi di cyberspionaggio state-sponsored che vedono nei cluster Kubernetes un'infrastruttura di alto valore per accedere a codice sorgente, pipeline CI/CD e segreti applicativi.

Il pattern operativo osservato in incidenti pubblici — pur non formalmente attribuito nei dati MITRE forniti per questa sotto-tecnica — segue tipicamente una catena che parte da esposizione del kubelet o dell'API server senza autenticazione, prosegue con compromissione di credenziali cloud che concedono accesso al cluster (via aws eks update-kubeconfig o equivalenti), e culmina nella creazione di binding privilegiati per garantire persistenza indipendente dalla credenziale originale.

Dal punto di vista della postura difensiva prioritaria, la threat intelligence suggerisce di trattare qualsiasi ClusterRoleBinding verso cluster-admin creato fuori da pipeline GitOps come incidente ad alta priorità. Le due mitigazioni MITRE censite — M1018 (User Account Management) e M1032 (Multi-factor Authentication) — vanno interpretate estensivamente: M1018 include la disciplina RBAC del principio di minimo privilegio, mentre M1032 si applica sia agli utenti umani che accedono al cluster sia, indirettamente, ai flussi di autenticazione OIDC/SAML integrati con il cluster.

Il trend generale mostra crescita continua dell'interesse offensivo verso Kubernetes, parallelamente all'adozione enterprise della tecnologia, con probabile aumento futuro di attribuzioni formali a gruppi APT per tecniche di questa famiglia.

MITRE ATT&CK: tecnica T1098.006 (Additional Container Cluster Roles), tattiche TA0003 e TA0004, mitigazioni M1018 e M1032, detection DET0572 con analitica AN1579. MITRE D3FEND per mappatura tecniche difensive su artefatto User Account. Il contenuto operativo su comandi kubectl, tool open source (Falco, Kubescape, kube-hunter, peirates, rbac-tool, kubiscan, OPA Gatekeeper, Kyverno) e procedure forensi deriva da conoscenza professionale di sicurezza cloud-native e documentazione ufficiale dei progetti citati.