Divisão de Defense Evasion em Stealth e Defense Impairment

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK. Explica a maior
reestruturação da v19 de abril de 2026: a aposentadoria da tática Defense Evasion
e sua divisão em Stealth (TA0005) e Defense Impairment (TA0112), com o destino de
cada técnica. Dialoga com as notas de heatmap do grupo MAP e com a nota de
Hunting por Defesa Evasiva do capítulo 8.

1. Contexto e Posicionamento na Biblioteca

A v19 do ATT&CK, publicada em 28 de abril de 2026, aposentou a tática Defense Evasion e dividiu seu território em duas táticas novas para o Enterprise: Stealth, que herdou o identificador TA0005, e Defense Impairment, que estreou como TA0112. Com isso, o Enterprise passou a ter 15 táticas, e centenas de técnicas e sub-técnicas receberam novas táticas, novas versões e, em alguns casos, novos identificadores. A mudança foi anunciada com um post de rationale em março de 2026 e acompanha um guia de transição publicado junto com as release notes.

Na biblioteca, esta nota é o coração do bloco da v19. Ela corrige um entendimento intuitivo e errado de que stealth e evasão seriam sinônimos: esconder-se não é o mesmo que desligar a defesa do adversário. O assunto conecta-se diretamente ao MAP.2, que usa heatmaps por tática, e à nota de Hunting por Defesa Evasiva do capítulo 8, cujas hipóteses precisam ser relidas sob a nova semântica. Sem esta nota, qualquer análise de cobertura por tática baseada em TA0005 produz resultados inconsistentes entre versões.

2. Por Que o ATT&CK Dividiu a Tática

Defense Evasion sempre foi a tática mais populosa e mais heterogênea do Enterprise. Nela conviviam comportamentos de naturezas opostas: um adversário que renomeia binários e usa extensões duplas está tentando não ser percebido, enquanto um adversário que desinstala o agente de EDR e limpa logs do Windows está atacando ativamente os instrumentos de defesa. Tratar as duas famílias como uma só tática produzia distorções analíticas conhecidas: heatmaps com colunas gigantes de TA0005, métricas de cobertura infladas por técnicas de ocultação simples e relatórios que sugeriam, incorretamente, que detectar masquerading significava deter manipulação de agentes.

A divisão seguiu a lógica do próprio nome. Stealth reúne o que o adversário faz para permanecer oculto e parece legítimo, preservando a paisagem do ambiente. Defense Impairment reúne o que o adversário faz para reduzir, burlar ou desligar as defesas presentes, alterando o estado do ambiente. A separação melhora a semântica dos relatórios de CTI, permite prioridades distintas, já que impairment costuma exigir resposta mais rápida, e alinha o ATT&CK com a forma como os times de resposta já raciocinavam na prática. O custo é a quebra de continuidade histórica em todos os mapeamentos que usavam TA0005.

A dimensão do trabalho aumenta quando se olham os números oficiais da v19: o Enterprise fechou a versão com 15 táticas, 222 técnicas e 475 sub-técnicas, e parte considerável das mudanças de versão maior, de 1.x para 2.0, é consequência direta da reatribuição de tática. Ou seja, a divisão não foi um retoque cosmético em meia dúzia de páginas, foi uma revisão estrutural que tocou centenas de objetos, inclusive detection strategies descontinuadas por perderem coerência com a nova taxonomia. Qualquer plano de migração que ignore essa escala vai estourar o prazo.

3. As Novas Táticas e o Destino dos Identificadores

A divisão preservou o identificador TA0005 para Stealth, o que significa que heatmap baseado em TA0005 continua existindo, porém com significado mais restrito. A tática Defense Impairment recebeu o novo TA0112. A técnica-pivô da mudança foi Impair Defenses (T1562), que foi revogada: seus filhos foram elevados a técnicas de topo sob Defense Impairment, recebendo identificadores novos. A tabela abaixo consolida as conversões centrais, verificáveis nas release notes e no bundle STIX da v19.

Vale notar que o modelo também cresceu internamente. Disable or Modify Tools (T1685) recebeu sub-técnicas próprias na v19, como Disable or Modify Windows Event Log (T1685.001), Disable or Modify Cloud Log (T1685.002), Modify or Spoof Tool UI (T1685.003), Disable or Modify Linux Audit System Log (T1685.004), Clear Windows Event Logs (T1685.005), Clear Linux or Mac System Logs (T1685.006) e Impair Autonomous Defenses (T1685.007). Disable or Modify System Firewall (T1686) ganhou Cloud Firewall (T1686.001), Network Device Firewall (T1686.002) e Windows Host Firewall (T1686.003). Essa granularidade nova é mais fiel ao que o operador de SOC realmente precisa detectar.

4. Quais Comportamentos Ficaram em Cada Tática

A regra prática de triagem é simples de aplicar durante a revisão de mapeamentos. Se a técnica serve para o adversário não ser visto ou parecer benigno, ela pertence a Stealth. Se a técnica desativa, engana ou sabota um mecanismo de defesa, ela pertence a Defense Impairment. O quadro abaixo organiza as famílias principais após a divisão e ajuda a revisar rapidamente heatmaps e planilhas antigas.

Além das conversões, a v19 trouxe técnicas novas que ilustram o recorte das duas táticas. No lado de Stealth entraram Safe Mode Boot, Prevent Command History Logging e Obfuscated Files or Information: Invisible Unicode. No lado de Defense Impairment e de reconhecimento de ferramentas entraram técnicas associadas a ambientes com IA, como Generate Content (T1683), com sub-técnicas Written Content (T1683.001) e Audio-Visual Content (T1683.002), Query Public AI Services (T1682) e Social Engineering (T1684), que são discutidas em detalhe na nota de ATLAS deste capítulo.

5. Telemetria e Detecção por Tática

A divisão também muda o desenho de detecção, porque as duas táticas pedem telemetria e lógicas diferentes. Stealth é um problema de comparação com baseline e de correlação de contexto, enquanto Defense Impairment é um problema de monitorar os próprios instrumentos de defesa e seus pontos de configuração. A tabela abaixo orienta a revisão da matriz de cobertura por tática nova, com exemplos de telemetria e de lógica típica.

Para o lado de Defense Impairment, uma detecção de valor alto é monitorar a manipulação do próprio agente de EDR. A consulta abaixo, em KQL sobre telemetria de endpoint, caça terminações e modificações do serviço de proteção iniciadas por processos que não fazem parte do inventário de administração conhecido, comportamento típico das técnicas agora abrigadas em T1685.

DeviceProcessEvents
| where Timestamp > ago(1d)
| where FileName in~ ("powershell.exe", "sc.exe", "taskkill.exe", "net.exe")
| where ProcessCommandLine has_any ("Stop-Service", "sc stop", "sc config",
        "taskkill /f", "net stop")
| where InitiatingProcessFileName !in~ ("mssense.exe", "MsSense.exe", "configmgr")
| where ProcessCommandLine has_any ("Sense", "EDR", "Defender", "CrowdStrike",
        "CarbonBlack", "Sentinel")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
          InitiatingProcessFileName
| order by Timestamp desc

Os times devem lembrar que as release notes da v19 registraram também a descontinuação de duas Detection Strategies da família Impair Defenses, a estratégia multiplataforma de Impair Defenses e a estratégia de Indicator Blocking, substituídas por estratégias alinhadas às técnicas novas T1685 e T1686. Inventários que consumiam aqueles DETs precisam realinhar as referências, o que reforça a recomendação de guardar o identificador AN e DET em metadados, e não apenas o texto da regra.

6. Impacto em Heatmaps, Métricas e Cobertura

O impacto imediato é a invalidação de comparações históricas de heatmap por tática. Uma camada do Navigator que pintava TA0005 na v17 mede outra coisa na v19, porque TA0005 agora é Stealth, sem as técnicas de impairment. Relatórios que diziam que a organização cobre X por cento de Defense Evasion precisam ser refeitos com dois numeradores novos, e a meta de cobertura deve ser redefinida por tática, com prioridade para Defense Impairment onde o risco de danificação de agentes é alto. A tática Defense Impairment nasce com poucas técnicas de topo, mas com sub-técnicas numerosas e de alto valor, o que a torna ótimo alvo para cobertura rápida e mensurável.

Para o CTH, o efeito prático é que MAP.2 precisa de uma revisão de camada e MAP.4 de reclassificação de lacunas. Um gap registrado em "Impair Defenses: Disable Cloud Log" na v18 migra para "Disable or Modify Cloud Log (T1685.002)" na v19, e a revisão é mecânica se o inventário tiver os identificadores anotados. Já o heatmap de Stealth tende a encolher numericamente, sem perda real de cobertura, e essa mudança óptica deve ser explicada no relatório para a liderança, evitando a leitura equivocada de que a organização regrediu.

A atualização de camadas de Navigator pode ser feita por script sobre o JSON da camada, trocando os vetores de técnicas conforme a tabela de conversão e reavaliando os scores. O fragmento abaixo ilustra a troca pontual de um item de camada que cita a técnica revogada.

{
  "techniqueID": "T1685",
  "tactic": "defense-impairment",
  "color": "#ff6666",
  "comment": "Migrado de T1562.001 na revisao para ATT&CK v19"
}

7. Migração Prática de Mapeamentos

A migração recomendada usa o relacionamento revoked-by do bundle STIX, que aponta cada objeto revogado para o seu sucessor. O script abaixo resolve automaticamente a maior parte do trabalho: para cada técnica revogada no inventário, imprime o sucessor declarado pelo ATT&CK, permitindo gerar uma tabela de conversão auditável.

from stix2 import MemoryStore

src = MemoryStore()
src.load_from_file("enterprise-attack-19.json")
objs = {o["id"]: o for o in src.query("type = 'attack-pattern'")}

inventario = ["T1562", "T1562.001", "T1562.004", "T1562.010", "T1211"]
for o in src.query("type = 'relationship'"):
    if o.get("relationship_type") == "revoked-by":
        velho = objs.get(o["source_ref"], {})
        novo = objs.get(o["target_ref"], {})
        id_velho = velho.get("external_references", [{}])[0].get("external_id")
        id_novo = novo.get("external_references", [{}])[0].get("external_id")
        if id_velho in inventario:
            print(f"{id_velho} {velho.get('name')} vira {id_novo} {novo.get('name')}")

Depois de gerar a tabela, o passo seguinte é atualizar as camadas do Navigator e os metadados das regras, preservando o histórico de versão de cada item do inventário. A recomendação de campo é registrar pares, por exemplo v17_ref e v19_ref, em vez de sobrescrever, porque relatórios retrospectivos e exercícios de purple team frequentemente citam versões antigas. A nota de Impactos nos Mapeamentos e Ferramentas de Detecção detalha o cronograma de 30, 60 e 90 dias para esse trabalho.

8. Erros Comuns e Pontos de Atenção

O erro mais custoso é atualizar o identificador sem revisar a semântica, migrando automaticamente tudo de TA0005 para Stealth e mantendo técnicas de impairment numa tática errada. Cada item do inventário merece uma decisão consciente, guiada pela pergunta de ocultação versus sabotagem. Outro erro comum é continuar citando T1562 em regras e relatórios, já que a técnica está revogada e o ATT&CK mantém as páginas revogadas apenas para referência histórica; citar T1562 em produção sinaliza inventário desatualizado em auditorias.

Cuidado também com a suposição de que todo o conteúdo antigo de Defense Evasion migrou integralmente para uma das duas novas táticas. Alguns comportamentos ganharam recortes melhores na v19, e algumas técnicas mudaram de escopo além da tática, como indica a onda de mudanças de versão maior, de 1.x para 2.0, que atingiu centenas de técnicas na transição. Por fim, exercícios de BAS e emulação que usam ATT&CK versões antigas como referência precisam ser reprocessados, caso contrário o purple team valida detecções contra taxonomia que o banco atual não reconhece.

9. Integração com o Restante da Biblioteca

Esta nota recalibra o vocabulário de toda a biblioteca que fala em defesa evasiva. A nota de Hunting por Defesa Evasiva do capítulo 8 deve ser lida em sequência, com a distinção de caças para stealth e caças para impairment, e o grupo MAP usa as duas táticas novas como colunas distintas em MAP.2 e MAP.4. As notas PLT.2 e PLT.4, que gerenciam TIPs e fontes, precisam garantir que objetos revogados e seus sucessores sejam tratados corretamente pelos conectores.

A leitura complementar recomendada é a nota de Mudanças em Técnicas e Subtécnicas, que detalha o restante da v19 além da divisão, e a nota de Impactos nos Mapeamentos e Ferramentas de Detecção, que transforma o aprendizado desta nota em processo de migração com cronograma. Juntas, as três notas formam o bloco essencial de adaptação à v19.