Técnicas de Ataque a Kubernetes e CI-CD

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK. Aborda a
consolidação da cobertura de Kubernetes e CI/CD que culminou na v19.2 de agosto de
2026, a primeira release ágil do ATT&CK, centrada em grupos e softwares de
ataques a pipelines. Dialoga com as notas de Hunting em Containers e Kubernetes e
com os controles PRT.4 e DAT.4 do Framework CTH.

1. Contexto e Posicionamento na Biblioteca

A cobertura de Kubernetes e de CI/CD no ATT&CK foi construída em camadas ao longo de várias versões, e a janela da v19.2, publicada em agosto de 2026, é o ponto em que essa cobertura ganhou contexto de ameaça atual. As técnicas de execução em pods, abuso de service accounts e envenenamento de pipeline já estavam catalogadas, com destaques para as adições da v18, como Poisoned Pipeline Execution (T1677) e Container CLI/API (T1059.013). O que a v19.2 trouxe foi a primeira release ágil do framework, atualizando grupos e softwares para capturar a atividade de worms de supply chain que atacam diretamente os fluxos de CI/CD de desenvolvedores.

Para a biblioteca, esta nota conecta o capítulo de atualizações do ATT&CK à prática de proteção de plataformas de execução. Ela alimenta a nota de Hunting em Containers e Kubernetes do capítulo 8, que detalha as hipóteses de caça, e dialoga com PRT.4, que trata de monitoramento de containers e cloud-native, e com DAT.4, que centraliza logs no SIEM. O leitor deve sair da nota entendendo quais técnicas já existiam, o que a v19.2 adicionou em termos de atores e softwares, e como mapear detecção concreta para as técnicas novas.

2. A v19.2 e o Modelo de Releases Ágeis

A v19.2 foi a primeira release ágil do ATT&CK, um modelo de escopo estreito que publica atualizações direcionadas de grupos, softwares e campanhas fora do cadência semestral, quando atividade de ameaça relevante emerge entre versões programadas. Nessa release, o framework adicionou ShinyHunters (G1057), grupo criminal ativo desde pelo menos 2019 que rouba credenciais e dados pessoais para revenda ou extorsão, associado a relatos públicos ao ecossistema conhecido como The Com e a colaborações descritas como Scattered Lapsus Hunters. Também entrou TeamPCP (G1056), grupo cloud-native motivado financeiramente que migrou de ransomware e roubo de criptomoedas para roubo de credenciais orientado a worms e ataques de supply chain de software contra workflows de CI/CD.

No plano de softwares, a v19.2 registrou o ecossistema dos worms associados ao TeamPCP: Shai-Hulud (S9008), Mini Shai-Hulud (S9043), CanisterWorm (S9042) e TeamPCP Cloud Stealer (S9041). Somou-se ainda Kali365 (S9044), um kit de phishing como serviço que usa iscas de copiar e colar, gera códigos de dispositivo sob demanda e rouba tokens OAuth e cookies de sessão por meio de adversary-in-the-middle. A mensagem estrutural é clara: o ATT&CK reconheceu oficialmente que pipelines de CI/CD e ambientes de desenvolvedor se tornaram alvo primário, e que a cadeia de propagação entre pacotes e repositórios é um vetor de escala industrial.

3. Técnicas de Kubernetes no Corpo do ATT&CK

A matriz de Containers do Enterprise concentra as técnicas de Kubernetes, e a combinação delas descreve o ciclo clássico de comprometimento de cluster, do acesso administrativo à fuga para o host. As técnicas abaixo formam o vocabulário mínimo para mapear telemetria de plano de controle, e todas podem ser alimentadas pelo log de auditoria do kube-apiserver, recurso detalhado na seção de telemetria.

O abuso de service accounts se materializa nesse vocabulário por dois caminhos complementares. O primeiro é o acesso ao token da service account montado dentro do pod, geralmente lido de arquivos no filesystem do container, que alimenta a enumeração de T1613 e a execução de T1609 com a identidade da conta do pod. O segundo é a manipulação de RBAC via T1098.006, em que o adversário cria papéis de cluster adicionais para o próprio usuário ou conta, perpetuando o acesso mesmo após a troca de credenciais iniciais. Detecção de ambos depende de correlacionar quem chamou a API, com qual verbo e sobre qual recurso, informação que só existe em auditoria de plano de controle.

4. CI/CD, Supply Chain e a Cadeia dos Worms

No recorte de CI/CD, a técnica central é Poisoned Pipeline Execution (T1677), introduzida na v18, que descreve o adversário manipulando pipelines de build e deploy para executar código seu em contexto privilegiado. Ela se combina com Build Image on Host (T1612), em que a imagem é construída no próprio host para evadir controles, e com padrões gerais de supply chain catalogados em Compromise Software Dependencies e Development Tools. A cadeia dos worms de 2025 e 2026, registrada na v19.2, ilustra a composição: pacote malicioso publicado em registro público, executado em máquina de desenvolvedor ou runner de CI, que varre o ambiente em busca de segredos, tokens e workflows, e se autopropaga publicando novas versões infectadas.

A tabela abaixo traduz a cadeia do worm em técnicas ATT&CK, servindo de modelo para mapear campanhas futuras do mesmo gênero. O exercício de mapeamento usa os softwares novos como âncora de inteligência e as técnicas como âncora de detecção.

5. Telemetria Necessária

Sem telemetria de plano de controle, quase nada do recorte Kubernetes é detectável. O log de auditoria do kube-apiserver é a fonte primária, com eventos de verbos get, list, create, update e delete sobre pods, secrets, roles e clusterroles, e deve ser enviado ao SIEM com retenção compatível com caças. Complementam o quadro os logs de kubelet e de runtime no nó, a telemetria de CI, incluindo logs de workflow, registros de jobs e auditoria de alterações em repositórios, e os logs de registro de imagens, que capturam push e pull de artefatos. A tabela abaixo organiza as fontes por técnica e o componente de dados equivalente no modelo novo do ATT&CK.

6. Exemplo de Mapeamento de Detecção para Técnica Nova

O exemplo seguinte mapeia uma detecção concreta para o abuso de service accounts via manipulação de RBAC, técnica T1098.006. O evento de auditoria Kubernetes relevante é a criação ou alteração de ClusterRoleBinding concedendo o verbo escalonado a uma conta que nunca o teve. O trecho abaixo mostra, simplificado, a estrutura de um evento de auditoria do kube-apiserver correspondente.

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "stage": "ResponseComplete",
  "verb": "create",
  "objectRef": {
    "resource": "clusterrolebindings",
    "name": "maintenance-admin",
    "apiGroup": "rbac.authorization.k8s.io"
  },
  "requestObject": {
    "roleRef": { "kind": "ClusterRole", "name": "cluster-admin" },
    "subjects": [
      { "kind": "ServiceAccount", "name": "ci-deployer",
        "namespace": "build" }
    ]
  },
  "user": { "username": "system:serviceaccount:build:ci-deployer" }
}

O ponto crítico do evento é a autoelevação: a própria service account do ambiente de build concede a si mesma o papel de cluster-admin, padrão típico de T1098.006 e também sinal para a cadeia de pipeline poisoning, já que runners de CI raramente deveriam administrar RBAC global. A consulta abaixo, em KQL sobre os logs de auditoria ingestados no SIEM, materializa esse raciocínio e pode virar regra de alerta ou caça agendada.

KubeAuditLogs
| where TimeGenerated > ago(1d)
| where Verb in ("create", "update", "patch")
| where ObjectRef_resource == "clusterrolebindings"
| extend Subject = tostring(requestObject.subjects[0].name),
         SubjectKind = tostring(requestObject.subjects[0].kind),
         RoleRef = tostring(requestObject.roleRef.name),
         Caller = tostring(user.username)
| where RoleRef has "admin" and SubjectKind == "ServiceAccount"
| where Caller != "system:kube-controller-manager"
| project TimeGenerated, ClusterName, Caller, Verb, ObjectRef_name,
          Subject, RoleRef
| order by TimeGenerated desc

Para a camada de CI, a detecção complementar observa o runner: execução de script pós-instalação de pacote iniciando processos de rede ou leitura de arquivos de credenciais no agente de build, mapeando T1677 e T1552. A composição das duas camadas, plano de controle e pipeline, é o que fecha o ciclo de detecção descrito pela cadeia de softwares da v19.2, e qualquer uma delas isolada deixa lacuna explorável.

O esqueleto Sigma abaixo modela o sinal de pipeline poisoning no runner, correlacionando a execução de script pós-instalação do gerenciador de pacotes com acesso a arquivos de credenciais e a conexões de saída incomuns, comportamentos que juntos caracterizam a varredura de segredos descrita pela cadeia do worm.

title: Script pos-instalacao com acesso a segredos em runner de CI
logsource:
    product: linux
    service: auditd
detection:
    process:
        comm: 'node'
        exe|endswith: '/npm/npm-cli.js'
    secret_read:
        path|startswith:
            - '/home/runner/.config'
            - '/home/runner/.kube'
    condition: process and secret_read
tags:
    - attack.execution
    - attack.t1677
    - attack.credential_access
    - attack.t1552

7. Erros Comuns e Pontos de Atenção

O erro mais comum é presumir que a v19.2 introduziu técnicas novas de Kubernetes, quando ela introduziu contexto de ameaça sobre técnicas já catalogadas; citar a v19.2 como origem de T1611, por exemplo, é erro factual que desacredita o inventário em auditoria. O segundo erro é auditar apenas o plano de controle e ignorar o nó, porque Escape to Host e abuso de runtime frequentemente deixam poucos rastros na API e muitos no host. O terceiro erro é tratar o token de service account como segredo estático e não monitorar seu uso anômalo por origem, recurso e horário, perdendo o sinal de abuso depois que a conta inicial já foi trocada.

Cuidado também com o ruído de mudança legítima: pipelines de CD criam e atualizam recursos de RBAC constantemente em ambientes bem administrados, então a detecção precisa ancorar em autoelevação e em papéis administrativos concedidos a contas de automação, e não em qualquer alteração de binding. Por fim, registre no inventário qual versão do ATT&CK foi usada no mapeamento da camada de containers, porque a área evolui rápido entre releases e a rastreabilidade evita retrabalho na próxima migração.

8. Integração com o Restante da Biblioteca

Esta nota opera o recorte de containers e CI/CD dentro do capítulo de atualizações e se apoia em três notas da biblioteca para aprofundamento: Hunting em Containers e Kubernetes, do capítulo 8, que transforma as técnicas em hipóteses de caça com consultas prontas, PRT.4, que define o monitoramento cloud-native no Framework CTH, e a nota de Integração CTI-TH-EASM em seu recorte de superfície de execução. As softwares e grupos da v19.2, especialmente Shai-Hulud e TeamPCP, entram nas camadas de priorização do MAP.3.

Para o estudo integrado, o exercício recomendado é mapear o ambiente real da organização contra a tabela de telemetria da seção 5, marcando quais fontes existem hoje, quais precisam ser habilitadas e quais técnicas ficam cegas sem elas. Esse diagnóstico alimenta DAT.1 e DAT.4 e vira roadmap de coleta no formato discutido pelo capítulo 2 da biblioteca.