Mudanças em Técnicas e Subtécnicas

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK. Panorama das
técnicas e sub-técnicas criadas, renomeadas, movidas e descontinuadas na v19 de
abril de 2026, além do processo de acompanhamento de changelogs e da revisão
interna de mapeamentos. Complementa a nota sobre a divisão de Defense Evasion e
alimenta o ciclo de evolução contínua do grupo MAP.

1. Contexto e Posicionamento na Biblioteca

A divisão de Defense Evasion é o título mais visível da v19, mas não é a única mudança de conteúdo. A versão publicada em 28 de abril de 2026 alterou técnicas, grupos, campanhas e software nos três domínios, adicionou sub-técnicas à matriz ICS pela primeira vez e iniciou a expansão das Detection Strategies para o domínio Mobile. Para quem mantém mapeamentos vivos, entender o conjunto completo de mudanças evita a armadilha de migrar apenas a tática renomeada e ignorar dezenas de ajustes que afetam cobertura, priorização e relatórios.

Esta nota cumpre o papel de inventário guiado das mudanças da v19 e de metodologia de acompanhamento. Ela se apoia na nota sobre a divisão de Defense Evasion, que cobre a parte estrutural, e prepara o terreno para a nota de Impactos nos Mapeamentos e Ferramentas de Detecção, que transforma o inventário de mudanças em processo com cronograma. O leitor que trabalha com priorização por ator de ameaça também deve cruzar este material com as notas MAP.3 e MAP.5 do Framework CTH.

2. Panorama das Mudanças da v19

Os números oficiais da v19 mostram a dimensão do ciclo. O Enterprise passou a ter 15 táticas, 222 técnicas, 475 sub-técnicas, 174 grupos, 821 softwares e 56 campanhas, além de 697 Detection Strategies e 1758 Analytics. O ICS ganhou 18 sub-técnicas, com o total de 79 técnicas, e o Mobile recebeu suas primeiras Detection Strategies, 124 no total, com 29 Data Components. Foram 949 softwares e 178 grupos no conjunto completo. Cada release publica, junto com as notas, um changelog detalhado legível por humanos e um changelog legível por máquina em JSON, o que permite automatizar a análise de impacto.

A expansão das Detection Strategies para o Mobile merece menção específica, porque fecha o ciclo iniciado na v18 no Enterprise. Estratégias mobile consideram as limitações de visibilidade típicas de Android e iOS, e o aumento de 17 para 29 Data Components no domínio reflete o esforço de declarar telemetria específica de dispositivo. Times que monitoram MDM e frotas móveis devem revisar as estratégias novas com o mesmo rigor que aplicaram ao Enterprise na v18.

A terminologia oficial das release notes é a linguagem correta para descrever qualquer mudança interna. Usar essa terminologia nas planilhas e tickets evita ambiguidade em revisões e auditorias, e a tabela abaixo consolida os termos com exemplos concretos da v19.

3. Categorias de Mudanças: Cloud, Containers, Identidade e IA

A leitura por categoria ajuda a distribuir a revisão entre donos de domínio. No recorte de cloud, a v19 detalhou o impairment de proteções geridas: Disable or Modify Cloud Log (T1685.002) e Cloud Firewall (T1686.001) ganharam espaço dedicado, e técnicas de elevação temporária em cloud receberam revisão de versão maior, como Temporary Elevated Cloud Access. No recorte de containers, técnicas como Build Image on Host e Deploy Container passaram por mudanças de versão maior na onda de reatribuição de tática, e a combinação com as adições da v18, como Container CLI/API (T1059.013) e Poisoned Pipeline Execution (T1677), consolida a cobertura de ambientes de execução modernos.

No recorte de identidade e tokens, houve revisão extensa: Access Token Manipulation e suas sub-técnicas, Abuse Elevation Control Mechanism e Domain or Tenant Policy Modification formam um bloco de mudanças de versão maior que refletem tanto a movimentação de tática quanto ajustes de descrição e telemetria. No recorte de IA, a v19 marcou a entrada de técnicas de ameaças com IA no corpo principal do Enterprise, com Generate Content (T1683), Query Public AI Services (T1682) e Social Engineering (T1684), assunto detalhado na nota de ATLAS deste capítulo. A tabela abaixo organiza as categorias com o que revisar em cada uma.

4. Renomeações, Revogações e a Onda de Versão Maior

Além do bloco Impair Defenses descrito na nota anterior, a v19 renomeou técnicas para alinhar nomes ao novo vocabulário e elevou sub-técnicas a técnicas de topo. O padrão a lembrar é que renomeação preserva identificador externo e muda versão maior, enquanto elevação gera identificador novo e revogação do objeto antigo. Esse padrão é a chave para automatizar a revisão: identificadores preservados exigem apenas atualização de nome e revisão de descrição, enquanto revogados exigem substituição de identificador no inventário.

A onda de versão maior tocou dezenas de famílias, entre elas Hide Artifacts, Hijack Execution Flow, Indicator Removal, Masquerading, Obfuscated Files or Information, Direct Volume Access, Execution Guardrails e BITS Jobs, entre outras. Na prática, isso significa que um inventário que registra apenas o identificador, sem a versão do objeto, perde a capacidade de saber se a técnica que ele mapeia mudou de descrição, de tática ou de telemetria recomendada. A recomendação do capítulo é registrar sempre o par identificador e x_mitre_version do bundle na data da última revisão.

Para dimensionar as técnicas novas, a lista a seguir reúne as principais adições Enterprise da v19 e a tática em que cada uma se encaixou após a reestruturação. A lista serve de checklist de avaliação: cada linha merece uma decisão consciente de implementar, monitorar ou justificar o descarte no inventário interno.

5. Sub-técnicas na Matriz ICS

A v19 foi a primeira a organizar a matriz ICS em sub-técnicas, com 18 unidades novas. A mudança concentrou-se em técnicas de manipulação de mensagens industriais: as antigas Block Command Message, Block Reporting Message, Block Serial COM, Default Credentials, Hardcoded Credentials, Module Firmware, Spoof Reporting Message, System Firmware e Unauthorized Command Message foram revogadas e substituídas por pares hierárquicos, como Block Operational Technology Message: Command Message e Reporting Message, Insecure Credentials: Default Credentials e Hardcoded Credentials, Modify Firmware: Module Firmware e System Firmware, e Unauthorized Message: Reporting Message, além de Block Communications: Serial COM.

Para times que monitoram ambientes OT, o efeito é o mesmo já descrito para o Enterprise: identificadores antigos viram referências revogadas, e o inventário OT precisa de revisão dedicada. A vantagem é que a hierarquia nova permite declarar cobertura em nível de técnica, cobrindo todas as sub-técnicas de Block Operational Technology Message de uma vez, e depois detalhar conforme a telemetria de rede industrial evolui. Matrizes de cobertura OT construídas sobre a estrutura plana antiga devem ser reprojetadas, e a nota de Hunting em OT e ICS do capítulo 8 fornece as hipóteses de caça que se beneficiam do recorte novo.

6. Como Acompanhar Changelogs e Versões

O ciclo de releases do ATT&CK é semestral, com versões maiores em abril e em outubro, e revisões pontuais intermediárias, como a v18.1 de novembro de 2025 e a v19.1 que sucedeu a v19.0. A partir de 2026, o ATT&CK também adotou o modelo de release ágil, com a v19.2 publicada em agosto de 2026, que atualiza grupos e softwares fora do ciclo semestral quando atividade de ameaça relevante emerge. O acompanhamento correto tem três fontes oficiais: a página de updates do site, que publica as release notes por mês, o changelog detalhado, legível por humanos, e o changelog em JSON, legível por máquina, cujo formato está documentado no GitHub do projeto.

A automação recomendada consome o changelog JSON a cada release e abre itens de trabalho automaticamente, classificados pela terminologia oficial. O pseudo-código abaixo mostra o esqueleto de um trabalhador de changelog que enfileira tarefas por categoria de mudança e atribui ao dono correto conforme a categoria discutida na seção 3.

import json

changelog = json.load(open("changelog-v19.json"))
novos, revogados, maiores = [], [], []

for obj in changelog.get("objects", []):
    if obj.get("type") == "attack-pattern" and obj.get("domains") == ["enterprise-attack"]:
        if obj.get("changes") == "new":
            novos.append(obj)
        elif obj.get("changes") == "revoked":
            revogados.append(obj)
        elif obj.get("version_change") and obj["version_change"].startswith(("2", "3", "4")):
            maiores.append(obj)

print("Novos:", len(novos), "| Revogados:", len(revogados), "| Versao maior:", len(maiores))

O pseudo-código é ilustrativo de estrutura, e a implementação real deve seguir o esquema publicado do JSON na release específica, já que campos podem evoluir entre versões. O princípio é permanente: nenhuma release deve ser incorporada sem que o diff seja transformado em itens de trabalho rastreáveis.

7. Processo de Revisão Interna de Mapeamentos

A revisão interna recomendada tem seis passos, executados nos primeiros 30 dias após cada release. Primeiro, gerar o diff entre a versão em produção e a nova, com base no changelog JSON. Segundo, classificar o impacto por categoria de negócio, usando a tabela da seção 3 para atribuir donos. Terceiro, atualizar o inventário de detecções, aplicando renomeações e substituindo revogados pelos sucessores declarados. Quarto, revisar hipóteses de caça que citam técnicas alteradas, atualizando a justificativa e a telemetria. Quinto, regenerar camadas de Navigator e relatórios de cobertura, comparando os números antes e depois e explicando variações. Sexto, registrar a versão consumida em todos os artefatos, fechando o ciclo de rastreabilidade.

Esse processo dialoga diretamente com MAP.5, Evolução Contínua da Cobertura, e com o modelo de maturidade do grupo GOV, porque a velocidade de incorporação de uma release é um indicador de maturidade tática. Times que incorporam a release no mesmo trimestre em que ela sai operam em nível superior aos que tratam o ATT&CK como arquivo estático.

A distribuição de trabalho por papel evita que a revisão fique concentrada em uma única pessoa e que domínios especializados fiquem sem revisor. A tabela abaixo sugere uma matriz simples de responsabilidade que pode ser adaptada ao tamanho do time.

Três regras operacionais fecham o desenho do processo e evitam as falhas mais baratas de corrigir depois. Elas devem constar no runbook de release da organização, ao lado do cronograma da nota seguinte.

• Toda alteração de mapeamento acontece em ticket com link para o changelog oficial, nunca em edição direta, para preservar rastro de decisão.
• Nenhum objeto revogado permanece em inventário ativo sem comentário explicando o sucessor adotado e a data da troca.
• Toda release encerra com relatório curto de variações de cobertura, com par antes e depois, entregue ao comitê de segurança.

8. Erros Comuns e Pontos de Atenção

O erro mais frequente é tratar a release como evento de atualização de TIP e parar por aí, sem revisar detecções, caças e relatórios que citam objetos alterados. O segundo erro é confundir revogação com deprecação: revogado tem sucessor declarado e deve ser substituído, enquanto deprecado não tem sucessor e exige decisão de arquivamento. Um terceiro erro é ignorar releases pontuais, como a v18.1, presumindo que mudanças entre versões maiores são irrelevantes, quando ajustes de descrição e de telemetria podem alterar a interpretação de um analytics.

Um quarto erro, sutil e recorrente, é atualizar o nome da técnica no relatório e esquecer o texto do comentário da regra no SIEM. Desalinho entre metadados gera confusão em auditorias de regras, porque o analista lê Impair Defenses no comentário e não encontra a técnica no ATT&CK atual. A disciplina de reescrever comentários e tags das regras no mesmo ticket que atualiza o mapeamento elimina essa classe de problema com custo próximo de zero.

Atenção também ao ICS e ao Mobile. Times que operam só no Enterprise tendem a ignorar mudanças nesses domínios e são surpreendidos quando relatam para plantas industriais ou para frota móvel com vocabulário antigo. Por fim, cuidado com bibliotecas de terceiros que fazem cache de páginas ou de bundles: o cache precisa de política de expiração amarrada às datas de release, senão o time consome taxonomia velha achando que está atualizado.

9. Integração com o Restante da Biblioteca

Esta nota fornece o inventário de mudanças que a nota de Impactos nos Mapeamentos e Ferramentas de Detecção transforma em processo operacional com cronograma, e amplia a leitura da nota sobre a divisão de Defense Evasion com as mudanças de conteúdo fora da tática renomeada. No Framework CTH, ela alimenta MAP.5 e as métricas do grupo MET, que podem medir o tempo entre release oficial e incorporação interna como KPI de maturidade.

Para hunting, o bloco de IA da v19 cria hipóteses novas que se conectam ao capítulo 17, e as revisões de identidade reforçam a nota de Hunting de Identidade e Autenticação. A recomendação de estudo é encerrar a leitura do bloco da v19 com o exercício prático de gerar o diff real entre os bundles v18.1 e v19.0, listando os dez objetos de maior impacto para a organização, o que converte a teoria desta nota em priorização concreta.