IOA - Indicadores de Ataque

Nota do capítulo 03 (Indicadores de Ameaças: IOC, IOA, IOB, IOE), complementar à subpasta de IOCs.
Define o IOA (Indicator of Attack), contrasta com o IOC, liga o conceito ao MITRE ATT&CK e mostra detecção antes do impacto.
Prepara o terreno para a nota de IOB, que generaliza a ideia para sequências comportamentais completas.

1. Contexto e Posicionamento na Biblioteca

O IOC responde à pergunta sobre o que o adversário deixou no ambiente; o IOA (Indicator of Attack, indicador de ataque) responde à pergunta sobre o que o adversário está fazendo enquanto faz. Um IOC de hash só dispara depois de o payload estar no disco, com o comprometimento já consumado. Um IOA de processo do Office invocando PowerShell dispara durante a fase de execução, antes do roubo de dados, e funciona mesmo que o payload daquele dia seja um binário que ninguém nunca viu. Essa mudança de ponto no tempo é o valor central do conceito: detectar a técnica em curso reduz o dwell time e custa ao adversário uma mudança de procedimento, que é bem mais dolorosa que a troca de infraestrutura.

Na biblioteca, esta nota cobre o papel do IOA na visão do capítulo 03 e prepara a transição para o IOB, que trata sequências completas de comportamento. Os controles TH.10 da seção 15, sobre hunting baseado em IOC e IOA, e SIM.4, sobre teste de detecção de IOCs e IOAs, executam na prática o que aqui é definido conceitualmente. A Pirâmide de Dor do capítulo 04 é a moldura estratégica: quanto mais a detecção sobe da infraestrutura para as ferramentas e TTPs, mais custoso é o contorno.

2. Definição de IOA e Diferença para IOC

Um IOA é um sinal observável, geralmente uma ação ou uma combinação de ações no ambiente, que indica a intenção e a progressão de um ataque antes do impacto final. Ele nasce da análise de como o adversário opera: quais processos ele usa, quais combinações de eventos ele precisa produzir, que ordem ele é obrigado a seguir para alcançar o objetivo. A comparação abaixo contrasta os dois conceitos nos eixos que importam na operação.

A tabela esconde um detalhe importante: IOC e IOA não competem, e sim cobrem janelas diferentes do mesmo ataque. A operação madura mantém as duas camadas, com o IOC cobrindo o conhecido a custo baixo e o IOA cobrindo o desconhecido a custo analítico maior. O erro inverso, descartar IOCs porque IOAs são superiores, deixa de bloquear barato o que já é conhecido e sobrecarrega a camada comportamental com volume que seria filtrado antes.

A implantação prática do IOA depende de telemetria de processo e de identidade, mais do que de telemetria de rede. O evento de criação de processo com pai, linha de comando e hash é o insumo mais produtivo, seguido dos eventos de acesso a processo, de registro e de autenticação. Em ambientes Windows, isso significa Sysmon 1, 3, 7, 10, 11, 13 e 22, além dos eventos de segurança 4688, 4624 e 4720, conforme o detalhamento do controle DAT.1 da seção 15. Onde esses eventos não existem, a primeira tarefa não é escrever regra, e sim corrigir a coleta.

3. Relação com MITRE ATT&CK e a Pirâmide de Dor

O MITRE ATT&CK é o vocabulário natural do IOA, porque cada técnica mapeia um comportamento observável do adversário e a telemetria que o revela. Um IOA bem construído é, na prática, uma tradução executável de uma técnica: a regra Sigma que detecta criação de tarefa agendada por processo do Office é a materialização de T1053.005 com pai T1566 ou T1204. A vinculação a ATT&CK traz três ganhos operacionais: a cobertura passa a ser medida por técnica, as lacunas ficam explícitas no Navigator, e a comunicação com a diretoria ganha uma referência estável de cenário.

A Pirâmide de Dor explica por que o esforço vale. Hashes e IPs, na base, são baratos de trocar; ferramentas e TTPs, no topo, obrigam o adversário a reconstruir parte da operação. O IOA opera nas camadas altas da pirâmide, e por isso sobrevive à rotação de infraestrutura que mata a maioria dos IOCs de rede em poucos dias. A leitura estratégica correta é: cada IOA maduro em produção é um degrau conquistado na pirâmide, e o portfólio de detecção deve ser medido por quantos degraus a organização ocupa, tema dos controles MAP da seção 15.

A modelagem ATT&CK também define o que o IOA não é. Uma regra que detecta o nome de ferramenta específica, por exemplo um binário de hacking com assinatura fixa, opera mais perto de IOC do que de IOA, porque se sustenta em artefato e não em comportamento. A crítica correta ao construir regras é perguntar: se o adversário trocar a ferramenta por outra equivalente, a regra ainda aciona? Quando a resposta é não, a regra atende à camada de indicadores, e a biblioteca deve classificá-la assim para não inflar a cobertura comportamental reportada.

4. Detecção Antes do Impacto

A cadeia de ataque tem uma ordem, e a posição da detecção nessa ordem define o resultado. Detectar na entrega permite conter com um clique isolado; detectar na exfiltração permite conter o dano, mas o dado já saiu; detectar no impacto, por exemplo na criptografia do ransomware, resta a recuperação. O IOA desloca a detecção para o início da cadeia porque monitora ações obrigatórias: para transformar acesso inicial em controle, o adversário quase sempre precisa executar código, persistir, escalar e mover lateralmente, e cada uma dessas transições deixa telemetria.

Um exemplo concreto mostra a diferença de ponto no tempo. Na cadeia de phishing com macro, o usuário abre o documento, a macro invoca PowerShell, o PowerShell baixa o loader e o loader instala a persistência. Um IOC de hash do loader cobre o último elo e exige que o binário esteja catalogado. O IOA da transição documento para PowerShell cobre o segundo elo, que o adversário pode variar pouco sem quebrar a técnica. A consulta abaixo detecta exatamente essa transição, com processo pai do Office invocando intérprete de script, em telemetria de processo.

DeviceProcessEvents
| where Timestamp > ago(1d)
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "powerpnt.exe")
| where FileName in~ ("powershell.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "certutil.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName,
    FileName, ProcessCommandLine, InitiatingProcessCommandLine
| order by Timestamp desc

A consulta é intencionalmente larga, porque o objetivo do hunt é medir a prevalência da transição no ambiente antes de apertar a regra. Em ambientes onde macros são raras, qualquer acionamento é alta prioridade; em ambientes com ferramentas que legitimamente usam Office como pai, o tuning inclui escopo por linha de comando, como exigir presença de parâmetros de download ou codificação em base64 no comando do PowerShell.

O ganho de tempo é mensurável e deve ser comunicado com números, porque é ele que sustenta o investimento em detecção comportamental. Numa cadeia típica de acesso inicial, a diferença entre detectar na execução da macro e detectar na exfiltração pode ser de horas a dias de dwell time, e o custo de contenção muda de um host isolado para dezenas de contas e servidores. O controle IR.5 da seção 15 trata a redução de dwell time como objetivo central, e a biblioteca de IOAs é um dos instrumentos diretos para movê-lo.

5. Exemplos de IOAs por Tática

A tabela abaixo organiza IOAs representativos por tática ATT&CK, com a telemetria mínima para detectar cada um. A leitura por linha mostra o padrão comum: o IOA nasce da transição ou da combinação, raramente de um evento isolado.

A escolha de quais IOAs construir primeiro deve seguir o perfil de ameaça da organização e a telemetria disponível, na ordem do perfil para a técnica e da técnica para a regra. Construir na direção inversa, copiando regras populares sem telemetria, produz biblioteca decorativa que aciona pouco e cansa o SOC.

6. Construindo uma Biblioteca de IOAs

Uma biblioteca de IOAs é um ativo de engenharia de detecção com ciclo próprio: seleção por perfil de ameaça, implementação em formato padrão, teste adversário controlado, versionamento e revisão por acionamento. O fluxo recomendado é o seguinte, com cada etapa gerando artefato verificável.

• Selecionar técnicas a partir do perfil de ameaça e dos grupos relevantes ao setor, usando o ATT&CK Navigator para visualizar a cobertura atual e as lacunas.
• Verificar telemetria por técnica, confirmando que o evento necessário está coletado, com volume e campos úteis, antes de escrever qualquer regra.
• Implementar em Sigma ou no formato nativo do SIEM, com tags ATT&CK, severidade justificada e campos normalizados.
• Testar com emulação controlada, por exemplo Atomic Red Team para a técnica alvo, registrando acionamento e ajustando falsos positivos.
• Versionar em repositório com revisão de código, e atrelar cada mudança de regra a um motivo, como novo acionamento ou novo comportamento do adversário.
• Revisar trimestralmente por acionamento real, aposentando regras mortas e promovendo para bloqueio as que provaram precisão.

O exemplo abaixo é uma regra Sigma para o IOA de persistência por tarefa agendada criada por processo do Office, com mapeamento ATT&CK explícito. O formato neutro permite compilar para o backend do SIEM sem reescrever a lógica.

title: Tarefa agendada criada por processo do Office
id: 5b8f6a52-1d4e-4f7b-9c31-0e2b0c8a9d11
status: stable
description: Detecta persistencia por schtasks com processo pai do Office, IOA de T1053.005
logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 1
        ParentImage|endswith: '\WINWORD.EXE'
        Image|endswith: '\schtasks.exe'
        CommandLine|contains: '/create'
    condition: selection
tags:
    - attack.execution
    - attack.persistence
    - attack.t1053.005
level: high

A organização do repositório de regras é parte do ativo, e um layout mínimo por tática facilita revisão, teste e métrica. A estrutura abaixo, que espelha táticas ATT&CK em pastas, com manifesto de metadados por regra, atende equipes de qualquer tamanho.

deteccoes/
  acesso-inicial/
    t1204-office-spawn-script.yml
  execucao/
    t1059.001-powershell-base64-download.yml
  persistencia/
    t1053.005-schtasks-from-office.yml
  credenciais/
    t1003.001-lsass-access-non-system.yml
manifesto.yaml   # dono, data, técnicas cobertas, estado de teste

7. Erros Comuns e Pontos de Atenção

A operação de IOAs tropeça em padrões conhecidos, e a correção de todos passa por medir antes de apertar.

• Copiar regras de repositórios públicos sem verificar telemetria local, acumulando detecções que nunca podem acionar; correção: matriz de telemetria por técnica antes da adoção.
• Apertar demais a regra no primeiro falso positivo, matando a cobertura que ela tinha; correção: escopo por campo específico, como linha de comando, em vez de excluir o processo pai inteiro.
• Ignorar a prevalência do comportamento benigno no ambiente, tratando como IOA algo que a operação faz todo dia; correção: medir prevalência em 30 dias antes de publicar.
• Construir IOAs que exigem eventos não coletados, gerando regra teoricamente perfeita e operacionalmente cega; correção: validar coleta com teste de emulação.
• Medir biblioteca por quantidade de regras, incentivando volume sem valor; correção: medir por técnicas ATT&CK cobertas e testadas, como no controle MAP.
• Tratar o IOA como substituto do IOC e desligar a camada de indicadores, perdendo o bloqueio barato do conhecido; correção: manter as duas camadas com política de ação distinta.

8. Integração com o Restante da Biblioteca

O IOA desta nota é a ponte entre o capítulo de indicadores e os capítulos de detecção e hunting. Para baixo, ele consome a telemetria definida no capítulo 02 e traduz o perfil de ameaça do capítulo 01 em regras executáveis. Para cima, ele alimenta o IOB, que trata de sequências completas de comportamento e aproxima a detecção do nível de TTPs da Pirâmide de Dor. Na seção 15, o TH.10 executa hunts com esses indicadores, o SIM.4 testa se eles acionam em emulação controlada, o MAP mede a cobertura por técnica e o AUT.3 orquestra a entrega contínua das regras ao SIEM. A leitura recomendada após esta nota é a de IOB, porque o comportamento é o passo seguinte natural: onde o IOA olha uma transição crítica, o IOB olha a coreografia inteira do adversário no ambiente.