MITRE ATT&CK (Enterprise, Mobile, ICS)

Nota de abertura do capítulo 04 (Modelos e Frameworks para CTI).
Apresenta a estrutura completa do MITRE ATT&CK: matrizes, táticas, técnicas e subtécnicas, objetos complementares, ciclo de versões e os casos de uso que sustentam a ponte entre inteligência e engenharia de detecção.
Dialoga com o Diamond Model, com a Cyber Kill Chain e com a Pirâmide de Dor deste capítulo, e com os controles MAP.1 a MAP.5 da seção 15.

1. Contexto e Posicionamento na Biblioteca

O MITRE ATT&CK é o vocabulário compartilhado do comportamento do adversário. Ele descreve, em código estável, o que adversários reais fazem em ambientes reais, observado em intrusões documentadas, e não o que a teoria diz que seria possível fazer. Essa base empírica é o que fez do ATT&CK o idioma comum entre times de CTI, de detecção, de red team e de resposta: quando o relatório de inteligência diz T1566.001 e a engenharia de detecção cobre T1566.001, as duas áreas conversam sem tradução.

Para a biblioteca, o ATT&CK ocupa posição estrutural. O capítulo 03 cataloga indicadores e infraestrutura, que são os objetos que o adversário usa, e o ATT&CK cataloga o comportamento, que é o que o adversário faz com esses objetos. As notas do capítulo 04 se relacionam com ele de formas diferentes: o Diamond Model organiza os eventos, o Kill Chain organiza as fases, o VERIS organiza os incidentes e a Pirâmide de Dor organiza a dor causada, e o ATT&CK fornece o vocabulário de capacidade que atravessa todos eles. Os controles MAP.1 a MAP.5 da seção 15 aplicam o framework na prática organizacional.

Uma distinção que evita confusão comum: o ATT&CK descreve o que o adversário faz, e não o que a organização deve fazer. Mitigações e detecções existem como seções informativas das páginas de técnica, e não como requisitos; a decisão de prioridade pertence ao processo de inteligência da própria organização, que compara as técnicas observadas nos grupos relevantes com a superfície real do ambiente. O framework é, nessa leitura, um dicionário estruturado com evidência embutida, e não um padrão de conformidade.

2. Arquitetura da Matriz: Táticas, Técnicas e Subtécnicas

O ATT&CK se materializa em três matrizes principais: Enterprise, Mobile e ICS. A matriz Enterprise é a mais usada e cobre os ambientes Windows, macOS, Linux, cloud, Office 365, SaaS e redes corporativas, além de plataformas específicas adicionadas ao longo das versões, como contêineres e o hipervisor ESXi. A matriz Mobile cobre Android e iOS, com foco em malware de dispositivos e sem os passos pré-comprometimento, e a matriz ICS cobre ambientes industriais, com táticas e técnicas específicas de OT, como manipulação de processo de controle e comprometimento de histórico de dados.

As colunas das matrizes Enterprise são as táticas, o porquê técnico da ação, e as linhas são as técnicas, o como, desdobradas em subtécnicas quando aplicável. A tabela abaixo lista as quatorze táticas da matriz Enterprise com seus identificadores estáveis.

Cada técnica recebe um identificador em formato T + quatro dígitos, e as subtécnicas acrescentam um sufixo de três dígitos, como T1566.001, que é a subtécnica de phishing com anexo dentro da técnica de Phishing T1566. Esses identificadores são estáveis entre versões na prática, e mudanças relevantes são documentadas no changelog oficial, o que permite que detecções e mapeamentos sobrevivam às atualizações. Cada página de técnica traz, além da descrição, as plataformas aplicáveis, as fontes de dados que suportam detecção e exemplos documentados de uso por grupos e malware reais, material que alimenta diretamente o trabalho de hipóteses do TH.6.

A leitura da matriz em formato visual é o modo de trabalho do Navigator. A camada abaixo, em JSON reduzido, marca duas técnicas do grupo prioritário com cores distintas, e esse arquivo versionado no repositório da equipe é a unidade mínima de gestão de cobertura.

{
  "name": "Cobertura prioritaria Q3",
  "versions": { "attack": "17", "navigator": "5.1.0", "layer": "4.5" },
  "techniques": [
    {
      "techniqueID": "T1566.001",
      "color": "#ff6666",
      "comment": "Sem deteccao; prioridade do backlog"
    },
    {
      "techniqueID": "T1003.001",
      "color": "#ffd966",
      "comment": "Regra existe; nao testada por emulacao"
    }
  ],
  "legend": [
    { "label": "Coberto e testado", "color": "#8ea9db" },
    { "label": "Coberto nao testado", "color": "#ffd966" },
    { "label": "Lacuna", "color": "#ff6666" }
  ]
}

3. Os Objetos Complementares: Grupos, Software, Campanhas, Mitigações e Detecções

O ATT&CK não é só a matriz. Os grupos, com identificadores G, reúnem atividade atribuída a um mesmo conjunto de operadores, como o G0129, associado a operações de espionagem, e o objeto Software, com identificadores S, cobre tanto malware quanto ferramentas legítimas usadas em ataques, com a subdivisão entre malware e tool que o analista aprende a ler. As campanhas, objeto adicionado nas versões recentes, agrupam atividade temporalmente delimitada, e as relações entre grupos, softwares, campanhas e técnicas formam um grafo navegável que substitui boa parte da leitura de relatórios crus.

No lado defensivo, cada técnica tem seções de mitigação, com identificadores M, que mapeiam configurações, controles e boas práticas capazes de impedir ou reduzir a técnica, e seções de detecção, que descrevem os dados necessários e os sinais típicos. Essa dupla é o que conecta o ATT&CK à engenharia de detecção e à gestão de vulnerabilidades operacionais: a mitigação responde ao que remover da superfície, e a detecção responde ao que instrumentar. O ATT&CK Navigator, ferramenta web oficial, permite montar camadas com as técnicas marcadas por cores, comparar cobertura e exportar a camada em JSON versionável, e o dataset ATT&CK em STIX e TAXII, coberto pela nota de STIX da seção 05, permite ingestão automatizada na plataforma de CTI.

A tabela abaixo resume os objetos do ecossistema ATT&CK com seus prefixos de identificador e o uso analítico de cada um.

4. Versões, Atualizações e Governança do Conteúdo

O framework é atualizado em releases públicas, tradicionalmente duas por ano, com changelog detalhado de técnicas adicionadas, modificadas, deprecadas e renomeadas. As versões 17, de abril de 2025, e 17.1, de outubro de 2025, exemplificam o ritmo: a 17 ampliou a cobertura da Enterprise com a plataforma ESXi, ampliando a visibilidade de ataques a hipervisores que sustentam campanhas de ransomware, e ajustou técnicas de coleta, e a 17.1 refinou as estratégias de detecção documentadas. O número da versão deve constar em todo mapeamento produzido pela equipe, porque a cobertura declarada sem versão envelhece em silêncio.

A governança do conteúdo interno completa o ciclo. O time de CTI decide a versão de referência anual, o time de detecção sincroniza seu catálogo com ela, e a troca de versão segue um roteiro com revisão do diff oficial e impacto nos heatmaps existentes. Organizações com necessidades específicas podem usar o ATT&CKworkbench, que permite construir e publicar bases derivadas, como extensões setoriais, e o dataset aberto do MITRE fornece os mesmos objetos em STIX para automação, o que faz a troca de versão ser operação de pipeline e não de digitação.

O ecossistema do MITRE se estende além da matriz, e o analista deve conhecer os vizinhos. O MITRE Engage trabalha o engano como operação defensiva, o ATLAS cataloga técnicas contra sistemas de IA, e o D3FEND, complementar por construção, mapeia contramedidas de engenharia para cada capacidade ofensiva descrita no ATT&CK. Nenhum deles substitui a matriz; eles se acoplam a ela quando o programa amadurece, e a nota de Frameworks Emergentes da seção 23 cobre essa camada avançada.

5. Casos de Uso Principais

• Gap analysis de detecção: sobrepor as técnicas dos grupos prioritários, definidos no CTI.2, à cobertura real de regras e telemetria, com resultado visual no Navigator; as lacunas viram backlog priorizado de engenharia de detecção, método formalizado no MAP.4.
• Planejamento de red team e purple team: selecionar técnicas alinhadas à ameaça real e emular com Caldera ou planos manuais, medindo detecção por técnica, fluxo do controle SIM.5 e da nota de Purple Teaming da seção 19.
• Mapeamento de inteligência: converter relatórios de grupos e campanhas em seleções de técnicas com confiança, alimentando heatmaps de ameaça por setor, aplicação direta do MAP.3.
• Engenharia de requisitos de dados: partir da seção de detecção de cada técnica prioritária para definir quais eventos precisam ser coletados, conectando o ATT&CK ao DAT.1 e ao TH.1.
• Priorização de mitigação: usar as seções M para transformar backlog técnico em controles com efeito comprovado sobre técnicas ativas no setor, em vez de listas genéricas de boas práticas.

O caso de uso com maior retorno imediato costuma ser o primeiro: a análise de lacuna contra o grupo prioritário muda a conversa de segurança, porque substitui a pergunta indireta, do tipo se estamos protegidos, por listas nomeáveis de técnicas sem detecção e sem mitigação. O segundo em retorno é o mapeamento de inteligência, porque um relatório de campanha sem técnicas nomeadas não vira detecção, e a tradução para o ATT&CK é exatamente essa transformação.

6. Exemplo de Mapeamento: Cadeia de Phishing para Ransomware

A tabela abaixo mapeia uma cadeia típica de intrusão de ransomware iniciada por phishing, com técnica, dados de detecção e exemplo de regra. Esse é o formato de referência dos mapeamentos desta biblioteca.

A leitura do mapeamento produz duas decisões imediatas. No plano de mitigação, a etapa de execução por macro e a cópia em ADMIN$ são cortadas por configuração, com políticas de macro assinado e restrição de compartilhamentos administrativos, efeito permanente sem dependência de detecção. No plano de detecção, as etapas de LSASS e de sombra se tornam regras de prioridade máxima, porque são as que mais reduzem o dwell time quando disparadas cedo. Essa conversão de tabela em dois backlogs distintos é o que o mapeamento deve sempre entregar.

O mesmo mapeamento, escrito para o SIEM, converte as células em regras versionáveis. O fragmento abaixo mostra uma regra Sigma correspondente à etapa de execução, e a nota de Detection Engineering da seção 18 cobre o pipeline completo de conversão, teste e implantação.

title: Word iniciando interpretador de comando
logsource:
  product: windows
  service: process_creation
detection:
  selection_parent:
    ParentImage|endswith: '\\WINWORD.EXE'
  selection_child:
    Image|endswith:
      - '\\cmd.exe'
      - '\\powershell.exe'
  condition: selection_parent and selection_child
tags:
  - attack.execution
  - attack.t1204.002

7. Erros Comuns e Pontos de Atenção

• Mapear pela tática e não pela técnica: dizer que o grupo usa Persistence sem subtécnica não gera detecção nem hipótese; o valor está no nível de subtécnica sempre que a fonte permitir.
• Confundir cobertura declarada com cobertura real: a camada do Navigator com regra listada não prova que a regra dispara; teste com emulação, conforme o SIM.5, antes de pintar a célula de verde.
• Copiar mapeamentos de relatórios sem crítica: relatórios comerciais variam de rigor na atribuição de técnicas; revise a evidência citada e registre a confiança do mapeamento.
• Ignorar as matrizes Mobile e ICS: organizações com dispositivos móveis geridos ou com chão de fábrica precisam delas, e a ausência de cobertura nessas matrizes não significa ausência de risco.
• Congelar a versão: mapeamento produzido na versão 16 e revisado na 17 sem verificar o diff acumula técnicas renomeadas e deprecadas; sincronize a versão com cadência fixa.
• Usar o ATT&CK como lista de bloqueio: o framework descreve comportamento observado no mundo inteiro, e não um índice de prioridade para o seu ambiente; a prioridade vem dos grupos relevantes do CTI.2, e não da ordem das colunas.
• Tratar mitigação como oposta à detecção: as seções M e D são complementares, e a mitigação que elimina a superfície costuma ser mais durável que qualquer regra que observe a técnica sobrevivente.
• Ignorar o campo de plataformas: técnica descrita para Windows não se aplica tal como está a Linux ou a cloud, e o mapeamento cruzado de plataformas produz lacunas invisíveis na cobertura.
• Trocar o ATT&CK por modelo próprio: vocabulário interno dificulta compartilhamento e contratação de inteligência; extensões locais existem, mas partem do vocabulário padrão, e não o substituem.

8. Integração com o Restante da Biblioteca

O ATT&CK é o idioma de trabalho das notas de hunting desta biblioteca: as hipóteses estruturadas do TH.6 são formuladas sobre técnicas, o stack counting do TH.8 conta ocorrências por técnica e os heatmaps do MAP.2 traduzem cobertura em visão executiva. No capítulo 04, o Diamond Model fornece a estrutura de evento que carrega técnicas por campo, o Kill Chain oferece a leitura de fase que o ATT&CK refinou em táticas e a Pirâmide de Dor posiciona as técnicas como o nível de maior dor ao adversário. Nas notas de infraestrutura do capítulo 03, as técnicas de Resource Development são o destino natural do pivoting, que fecha a relação entre o ativo e o comportamento.

A nota seguinte do capítulo apresenta o Diamond Model, que responde à pergunta que o ATT&CK deixa aberta em casos de análise individual: como organizar cada observação de uma intrusão em uma estrutura que permita correlacionar, agrupar e pivotar sem perder a fronteira entre o que é adversário, capacidade, infraestrutura e vítima. Os dois frameworks juntos cobrem o comportamento e a estrutura do evento, e essa combinação é a base analítica do restante da biblioteca.