## Técnica Pai
[[t1098-account-manipulation|T1098 - Manipulação de Conta]]
## Descrição
Adversários com permissões suficientes em um cluster Kubernetes adicionam **funções (roles) ou permissões extras** a contas de usuário ou de serviço sob seu controle, garantindo acesso persistente e privilegiado ao ambiente de orquestração de contêineres.
A técnica se manifesta de duas formas principais no Kubernetes:
**1. RBAC - Role-Based Access Control:**
O adversário cria um `RoleBinding` (escopo de namespace) ou `ClusterRoleBinding` (escopo global do cluster) vinculando uma `Role` ou `ClusterRole` - inclusive funções com permissões amplas como `cluster-admin` - à conta comprometida ou criada pelo atacante. Isso garante que a conta passe a ter os mesmos poderes que a role vinculada.
**2. ABAC - Attribute-Based Access Control:**
Em clusters que utilizam ABAC (modelo mais antigo), o adversário com acesso ao arquivo de política pode modificar diretamente as entradas para conceder permissões adicionais à conta alvo, sem precisar recriar bindings.
Esta modificação de conta frequentemente ocorre logo após [[t1136-create-account|T1136 - Criar Conta]] ou imediatamente após comprometer [[t1078-valid-accounts|T1078 - Contas Válidas]] já existentes no cluster. Em ambientes Kubernetes hospedados em nuvem - como Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) e Azure Kubernetes Service (AKS) - o adversário pode combinar permissões locais do cluster com atribuições de roles na camada de nuvem ([[t1098-003-additional-cloud-roles|T1098.003 - Additional Cloud Roles]]), ampliando ainda mais o impacto.
O objetivo final é garantir que mesmo que as credenciais originais de acesso sejam revogadas ou rotacionadas, a conta backdoor mantenha acesso privilegiado ao cluster - viabilizando exfiltração de segredos, execução de workloads maliciosos ou movimentação lateral para outros serviços da nuvem.
## Contexto Brasil/LATAM
A adoção de Kubernetes e arquiteturas de contêineres cresceu significativamente no Brasil e na LATAM nos últimos anos, especialmente em fintechs, plataformas de e-commerce e empresas de [[technology|tecnologia]]. Startups do ecossistema brasileiro (São Paulo, Campinas, Florianópolis) frequentemente operam clusters gerenciados no [[aws|Amazon EKS]] ou no [[gcp|Google GKE]] com práticas de RBAC imaturas: service accounts com permissões excessivas, ausência de auditoria de bindings e falta de controles de admissão como OPA/Gatekeeper são comuns em ambientes de crescimento acelerado.
Em incidentes de comprometimento de supply chain de software no Brasil - onde dependências maliciosas ou pipelines de CI/CD infectados são pontos de entrada frequentes - adversários com acesso a ambientes de build podem criar `ClusterRoleBinding` silenciosos vinculando service accounts de CI a roles privilegiadas, garantindo persistência mesmo após a contenção do incidente inicial. Essa técnica foi observada em campanhas de cryptojacking direcionadas a clusters Kubernetes expostos na internet, um padrão recorrente na região LATAM onde clusters de teste são frequentemente deixados sem autenticação adequada.
Grupos como o [[g0139-teamtnt|TeamTNT]], que historicamente mira infraestrutura de nuvem e contêineres para mineração de criptomoedas, frequentemente abusam de permissões de RBAC mal configuradas para escalar privilégios e garantir persistência em clusters comprometidos - padrão observado em infraestruturas de provedores de nuvem com presença na LATAM.
## Attack Flow
```mermaid
graph TB
A([Acesso Inicial ao Cluster]) --> B{Origem do acesso}
B --> C[Credenciais de service account comprometidas]
B --> D[Token de usuário roubado via phishing/vazamento]
C --> E[Verificar permissões atuais com kubectl auth can-i]
D --> E
E --> F{Permissão de criar RoleBinding?}
F --> G[Criar ClusterRoleBinding para conta backdoor]
F --> H[Modificar política ABAC existente]
G --> I[Conta backdoor recebe cluster-admin ou role ampla]
H --> I
I --> J[Acesso persistente ao cluster mesmo após rotação de credenciais]
J --> K([Persistência no cluster Kubernetes])
K --> L[Exfiltrar Secrets / ConfigMaps]
K --> M[Executar workloads maliciosos]
K --> N[Movimentação lateral para serviços de nuvem]
```
## Como Funciona
**1. Reconhecimento de permissões**
Após obter acesso inicial, o adversário verifica o que a conta atual pode fazer:
```
kubectl auth can-i creaté clusterrolebindings --all-namespaces
kubectl auth can-i creaté rolebindings -n kube-system
```
**2. Criação de ClusterRoleBinding malicioso**
Se a conta possuir permissão suficiente, o adversário cria um binding que eleva uma conta de serviço controlada por ele para `cluster-admin`:
```yaml
# Exemplo de manifesto malicioso (apenas referência conceitual)
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: backdoor-admin
subjects:
- kind: ServiceAccount
name: compromised-sa
namespace: default
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
```
**3. Uso em ambientes de nuvem gerenciados**
Em GKE, EKS e AKS, o adversário pode combinar `ClusterRoleBinding` locais com atribuições de roles IAM na camada de nuvem ([[t1098-003-additional-cloud-roles|T1098.003]]), criando redundância de acesso difícil de detectar e revogar completamente.
**4. Persistência robusta**
Mesmo que as credenciais originalmente comprometidas sejam revogadas, os bindings permanecem ativos até serem explicitamente removidos. Bindings com nomes genéricos (`system:controller:*`, `default-binding`) se misturam ao ruído de objetos legítimos do cluster.
**5. Exfiltração de Secrets**
Com permissões de `cluster-admin`, o adversário pode acessar todos os `Secrets` do cluster - incluindo tokens de outras service accounts, credenciais de registries de imagem e certificados TLS - viabilizando movimentação lateral ampla.
## Detecção
**Monitoramento recomendado:**
- Criação de `RoleBinding` ou `ClusterRoleBinding` por contas que não sejam operadores do cluster ou ferramentas de CI/CD conhecidas
- Bindings vinculando roles de alto privilégio (`cluster-admin`, `admin`, `edit`) a service accounts em namespaces inesperados
- Modificações no arquivo de política ABAC fora de jánelas de manutenção planejadas
- Auditoria dos logs da API do Kubernetes para verbos `creaté` e `updaté` em recursos `rolebindings` e `clusterrolebindings`
**Regra Sigma - ClusterRoleBinding privilegiado suspeito:**
```yaml
title: Suspicious Privileged ClusterRoleBinding Creation
id: d4e7b2f3-8c5a-4d1e-b9f6-2a0c3e5d7f9b
status: experimental
description: >
Detecta criação de ClusterRoleBinding vinculando roles de alto privilégio
a service accounts ou usuários fora do processo de provisionamento esperado.
logsource:
product: kubernetes
service: audit
detection:
selection:
verb: 'creaté'
objectRef.resource: 'clusterrolebindings'
responseStatus.code: 201
filter_priv_roles:
requestObject.roleRef.name:
- 'cluster-admin'
- 'admin'
- 'edit'
filter_legitimate:
user.username|contains:
- 'system:serviceaccount:kube-system'
- 'system:masters'
condition: selection and filter_priv_roles and not filter_legitimate
falsepositives:
- Ferramentas de provisionamento de cluster (Helm, ArgoCD, Terraform)
- Operadores de plataforma durante onboarding de novos serviços
level: high
tags:
- attack.persistence
- attack.privilege_escalation
- attack.t1098.006
```
## Mitigação
| ID | Mitigação | Descrição |
|---|-----------|-----------|
| M1032 | [[m1032-multi-factor-authentication\|M1032 - Multi-factor Authentication]] | Exigir MFA para acesso ao plano de controle do Kubernetes e às consoles de nuvem (GKE, EKS, AKS). Reduz o risco de comprometimento inicial de credenciais que viabilizam a técnica. |
| M1018 | [[m1018-user-account-management\|M1018 - User Account Management]] | Aplicar o princípio do menor privilégio em todas as service accounts e usuários do cluster. Auditar regularmente os `RoleBindings` e `ClusterRoleBindings` existentes. Remover permissões desnecessárias e limitar quem pode criar bindings de roles privilegiadas. |
## Referências
*Fonte: [MITRE ATT&CK - T1098.006](https://attack.mitre.org/techniques/T1098/006)*