IOB - Indicadores de Comportamento

Nota do capítulo 03 (Indicadores de Ameaças: IOC, IOA, IOB, IOE), completando a família de indicadores aberta com IOC e IOA.
Define o IOB (Indicator of Behavior) como descrição de sequências de ações, sustentada por baselines e UEBA, e mostra como operacionalizar comportamento em analytics permanente.
Dialoga com as notas de IOA e IOE e com o comparativo de indicadores do capítulo, e prepara os controles de hunting comportamental e de UEBA da seção 15.

1. Contexto e Posicionamento na Biblioteca

O IOC captura o artefato que o adversário deixou para trás e o IOA captura a ação executada em um momento crítico da cadeia; o IOB (Indicator of Behavior, indicador de comportamento) captura a coreografia inteira: a sequência de ações, com ordem, timing e relações entre entidades, que caracteriza a forma de operar de um adversário ou o desvio de uma entidade em relação à sua linha de base. Uma conexão para a internet é um evento; trinta conexões com intervalo quase constante, emitidas por um processo que nunca conversou com a rede, para um destino sem histórico, é um comportamento. A diferença não é acadêmica: o comportamento é o que sobra para detectar quando o adversário troca hash, endereço, domínio e até ferramenta, porque a forma de agir é a parte mais cara de mudar.

Na biblioteca, esta nota fecha o conjunto de famílias de indicadores e faz duas pontes importantes. Para o capítulo 04, ela antecipa a Pirâmide de Dor, que explica por que o nível comportamental causa mais dor ao adversário que qualquer artefato da base. Para a seção 15, ela alimenta o TH.15 de UEBA e detecção comportamental, a caça orientada por comportamento do controle 17/02 e depende da telemetria garantida pelos controles DAT.1 e DAT.2. O objetivo prático é que o leitor saia daqui capaz de definir um IOB, diferenciá-lo de IOC e IOA, escolher o baseline correto e converter uma hipótese comportamental em consulta executável no SIEM.

2. Definição e a Natureza Sequencial do Comportamento

Um IOB é a descrição de uma sequência observável de ações, dentro de uma janela temporal definida, que indica a presença de uma forma de operar específica ou de um desvio relevante do funcionamento normal do ambiente. Três elementos o distinguem de um indicador simples. O primeiro é a ordem: não basta o adversário acessar a memória de um processo, criar um arquivo e abrir conexão de saída; é a progressão nessa ordem, dentro de uma janela curta, que caracteriza o dump de credenciais seguido de exfiltração. O segundo é o tempo: o IOB existe em uma janela, e eventos idênticos espalhados por semanas não compõem o mesmo comportamento. O terceiro é a relação entre entidades: muitos IOBs só fazem sentido cruzando identidade, host, processo e rede, porque o sinal está em quem fez o quê, e não em cada fato isolado.

A relação entre IOB e TTP merece precisão. O TTP é o vocabulário: descreve, no MITRE ATT&CK, como o adversário opera em termos canônicos. O IOB é a instanciação executável: a consulta, o escore ou o grafo que reconhece esse jeito de operar na telemetria específica da organização. Um IOB maduro frequentemente cruza várias técnicas, porque a coreografia do adversário atravessa táticas: o acesso a credenciais, a transferência da coleção e a evasão de log formam um único padrão reconhecível. Por isso o IOB vive naturalmente no topo da Pirâmide de Dor, junto de ferramentas e TTPs, e não na base ocupada por hashes e endereços.

3. Diferenças entre IOC, IOA e IOB

A tabela abaixo contrasta as três famílias nos eixos que importam na operação diária. A leitura por linha mostra que não se trata de hierarquia de qualidade, e sim de três respostas distintas a três perguntas distintas sobre o mesmo adversário.

A última linha merece destaque, porque é a limitação estrutural do IOB: um IOC viaja pela comunidade intacto, enquanto um IOB fica amarrado aos baselines e à telemetria de quem o produziu. O que se compartilha de um IOB é a descrição do comportamento e a hipótese analítica, e não a consulta pronta, que cada organização precisa adaptar à sua coleta e ao seu funcionamento normal. Essa adaptação é trabalho real, e é o motivo pelo qual IOB custa mais que IOC em qualquer dimensão de esforço.

4. Baselines e UEBA como Fundamento do IOB

Baseline é a descrição quantificada do funcionamento normal, e é dela que o IOB deriva seu poder de sinal: comportamento só é indicador quando existe um normal contra o qual comparar. Há três bases de comparação complementares. O baseline por entidade compara o usuário ou o host consigo mesmo ao longo do tempo, e revela, por exemplo, um funcionário que nunca tocou o sistema financeiro iniciando exportações em massa. O baseline por grupo de pares compara entidades equivalentes, e revela o servidor que passou a conversar com faixas de rede que nenhum par dele toca. O baseline por sazonalidade compara cada período com o mesmo período de ciclos anteriores, e evita que a rotina legítima de fechamento mensal dispare alerta inútil.

O UEBA (User and Entity Behavior Analytics) é a categoria de plataforma que industrializa essa comparação: constrói perfis por entidade, calcula escores de anomalia sobre os desvios e entrega o resultado como alerta priorizado. Operar UEBA com disciplina exige um ciclo próprio, e não apenas a compra da ferramenta, porque perfis mal construídos produzem ruído caro.

A qualidade do baseline depende de três insumos que precisam existir antes de qualquer perfil: o mapeamento entre contas e pessoas, porque anomalia de conta sem saber quem a usa não gera investigação; a classificação das contas de serviço, porque automação é a maior fonte de falsos positivos comportamentais; e a definição de papel funcional por host, porque o comportamento esperado de um servidor de banco difere do de uma estação de trabalho. Sem esses insumos, a plataforma perfila ruído com precisão estatística, e o resultado é alerta abundante e análise impossível.

• Definir primeiro o escopo de entidades com valor analítico, normalmente contas privilegiadas, servidores de identidade e ativos que guardam dados sensíveis, em vez de perfilar tudo de uma vez.
• Medir prevalência por pelo menos um ciclo de negócio antes de gerar alerta, separando desvio real de rotina desconhecida pelo time de segurança.
• Configurar janelas e sazonalidade conforme o padrão de uso real, porque backup noturno e batelada contábil são normais nas suas janelas e anômalos em qualquer outra.
• Tratar o escore de anomalia como triagem, e nunca como veredito, mantendo o analista no circuito de confirmação nos primeiros meses de operação.
• Revalidar os perfis após mudanças estruturais, como migração para nuvem ou reorganização de áreas, porque o normal antigo vira ruído instantâneo depois da mudança.

5. Exemplos de IOBs Operáveis

A tabela abaixo resume três IOBs de alto valor, detalhados nas subseções seguintes com consultas reais. O critério de escolha foi o mesmo do hunting maduro: comportamentos que atravessam táticas, usam telemetria comumente disponível e resistem à rotação de artefatos.

O beaconing é o IOB de rede mais produtivo, e o jitter é justamente o que o denuncia. O C2 (Command and Control) precisa chamar casa em intervalos configuráveis, e para parecer humano adiciona aleatoriedade controlada ao intervalo. O resultado é um padrão com média estável e dispersão baixa, o oposto do tráfego humano, que tem média instável e dispersão alta. A consulta abaixo mede exatamente isso.

DeviceNetworkEvents
| where Timestamp > ago(2d)
| where RemotePort in (80, 443, 8080, 8443)
| where InitiatingProcessFileName !in~ ("chrome.exe", "msedge.exe", "outlook.exe", "teams.exe")
| extend ticks = tolong(Timestamp)
| summarize chamadas = count(), primeiro = min(Timestamp), ultimo = max(Timestamp),
            desvio_s = stdev(ticks) / 10000000.0
    by DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort
| extend intervalo_medio_s = datetime_diff('second', ultimo, primeiro) / chamadas
| where chamadas >= 20 and intervalo_medio_s between (20 .. 900)
| order by desvio_s asc

A leitura correta é relacional: intervalo médio estável com desvio baixo, processo incomum e destino sem histórico compõem o comportamento. Nenhum campo isolado prova nada, e é essa combinação que define o IOB.

O dump de credenciais clássico segue uma progressão obrigatória: acesso à memória do lsass, criação de arquivo com a coleção e, em seguida, tráfego de saída incomum. Cada etapa isolada tem falsos positivos conhecidos, do gerenciador de tarefas ao dump de diagnóstico do próprio Windows; a sequência em janela curta é o comportamento. A consulta abaixo encadeia as três etapas considerando o Sysmon já centralizado no SIEM.

let janela = 15m;
// Etapa 1: acesso a processo com alvo lsass.exe (Sysmon 10)
let acesso_lsass = Event
| where TimeGenerated > ago(1d) and EventID == 10
| where EventData has "lsass.exe"
| extend host = tostring(Computer), t1 = TimeGenerated;
// Etapa 2: arquivo criado em pasta de usuario (Sysmon 11)
let colecao = Event
| where TimeGenerated > ago(1d) and EventID == 11
| where EventData has_any ("Temp", "AppData") and EventData has ".dmp"
| extend host = tostring(Computer), t2 = TimeGenerated;
// Etapa 3: conexao de saida do mesmo host (Sysmon 3)
let saida = Event
| where TimeGenerated > ago(1d) and EventID == 3
| extend host = tostring(Computer), t3 = TimeGenerated;
acesso_lsass
| join kind=inner colecao on host | join kind=inner saida on host
| where t2 between (t1 .. t1 + janela) and t3 between (t2 .. t2 + janela)
| project host, t1, t2, t3

O WMI é o transporte lateral favorito porque usa processos legítimos do Windows e deixa poucos vestígios de rede tradicional. A assinatura comportamental é clara: conexão ao destino na porta 135, seguida de processo filho de WmiPrvSE.exe no host de destino, com intérprete de script na linha de comando, e registros do log WMI-Activity com IDs 5857, 5860 e 5861 na mesma janela.

DeviceProcessEvents
| where Timestamp > ago(1d)
| where InitiatingProcessFileName =~ "wmiprvse.exe"
| where FileName in~ ("cmd.exe", "powershell.exe", "rundll32.exe", "mshta.exe")
| where ProcessCommandLine has_any ("/c", "/enc", "IEX", "DownloadString", "FromBase64String")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine,
    InitiatingProcessAccountName
| order by Timestamp desc

Administradores usam WMI legitimamente todos os dias, por isso o refinamento comportamental é cruzar a conta com a rareza: a conta que nunca executou WMI naquele host e agora o faz, precedida de conexão remota na 135, é o padrão de T1021.006 em operação.

6. Operacionalizando IOBs em Analytics

Converter IOB em analytics permanente é um ciclo com quatro famílias de lógica, cada uma adequada a um tipo de comportamento. A agregação com limiar reconhece volume em janela, como a rajada de falhas de resolução de uma DGA. A sequência temporal reconhece ordem, como o dump de credenciais da seção anterior. O escore combinado soma desvios pequenos e independentes, como login de ASN novo somado a host novo e volume anômalo de download, e é a forma típica de operar UEBA. A análise de grafo reconhece arestas raras, como uma conta que aparece pela primeira vez chamando WMI em um servidor que jamais administrou.

Cada analytics maduro precisa de um registro de catálogo, porque IOB sem governança decai em ruído. Os campos mínimos do catálogo são: identificador, hipótese de origem, fontes de dados exigidas, janela temporal, prevalência medida no ambiente, precisão real após acionamentos, dono responsável e estado no ciclo de vida. O estado mais importante é a transição de hunt para detecção: um IOB nasce como consulta de hunting, ganha prevalência e precisão medidas, e só então vira regra permanente, seguindo o fluxo do TH.10 e o teste controlado do SIM.4. Essa graduação é o que separa biblioteca viva de acervo de consultas.

Quando o IOB de sequência amadurece, vale traduzi-lo para o formato Sigma com correlação temporal, que documenta a lógica de forma portável entre plataformas e obriga o autor a declarar janela e agrupamento. O exemplo abaixo formaliza o IOB de credential dumping da seção anterior como regra de correlação que referencia três regras parciais.

title: Sequencia de dump de credenciais
id: 7c2f4a91-3b8d-4e52-9a10-6f5d2c81b3e7
status: stable
description: IOB com acesso a lsass, arquivo de colecao e saida de rede na mesma janela
correlation:
    type: temporal
    rules:
        - 5d1c8f0a-1111-4e52-9a10-6f5d2c81b3e7  # acesso a lsass
        - 3e9a1c27-2222-4b9f-8c31-0e2b0c8a9d11  # arquivo .dmp em pasta de usuario
        - 2b6d4f8e-3333-4a17-9f52-71c9d4a0e6b2  # conexao de saida do mesmo host
    timespan: 15m
    group-by:
        - Computer
tags:
    - attack.credential_access
    - attack.t1003.001
level: high

A declaração de group-by é a parte que carrega o comportamento: a correlação exige que as três regras acionem no mesmo host dentro da janela, e sem ela o produto casaria eventos de hosts diferentes e viraria ruído. Essa disciplina de agrupamento é o equivalente, em regra, do que a consulta KQL fazia com o join por host.

7. Limitações e Custo

O primeiro custo do IOB é de telemetria: comportamento só existe nos dados que a organização coleta, e um IOB que cruza processo, rede e identidade exige três pipelines saudáveis com relógios sincronizados e retenção suficiente para construir baseline. O segundo custo é computacional: agregar, janelar e cruzar fontes a cada minuto é ordens de magnitude mais caro que casar um hash em watchlist, e por isso a priorização por coroa de joias, tema do TH.1, não é opcional. O terceiro custo é de precisão: administradores, ferramentas de backup e agentes de gerência executam sequências idênticas às do adversário, e cada falso positivo consome confiança que o programa precisa recuperar com dados.

Há ainda duas limitações estruturais que o programa precisa aceitar explicitamente. A primeira é o compartilhamento limitado: diferente do IOC, o IOB não é portável entre organizações, e a comunidade troca a descrição do comportamento, nunca o analytics pronto. A segunda é a cegueira gradual: um adversário com presença prolongada aprende o normal do ambiente e se mistura a ele, por isso o IOB comportamental precisa ser combinado com hunting orientado por inteligência, que traz a forma de operar conhecida de fora e cruza com o observado internamente.

8. Erros Comuns e Pontos de Atenção

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

• Publicar IOB sem medir prevalência no ambiente, gerando alertas para rotina legítima; correção: rodar a consulta em modo observação por um ciclo de negócio antes de gerar alerta.
• Tratar o escore de UEBA como veredito automático, encerrando investigação sem confirmação humana; correção: escore é triagem, e a precisão do conjunto só se conhece com feedback dos analistas.
• Construir sequência sobre eventos que a coleta não produz, deixando analytics cego; correção: validar a cadeia completa com emulação controlada, conforme o SIM.4.
• Usar janelas fixas que ignoram sazonalidade, como fechamento mensal e janelas de backup; correção: configurar baseline por ciclo e revisar após cada mudança estrutural.
• Confundir IOB com TTP e chamar de indicador o que é apenas descrição de técnica; correção: IOB é a instanciação executável, com janela, fontes e limiares próprios do ambiente.
• Copiar consulta de outra organização sem adaptar ao baseline local, herdando limiares que não significam nada aqui; correção: a consulta é ponto de partida, a prevalência local é o contrato.
• Medir o programa por quantidade de IOBs no catálogo, incentivando volume sem valor; correção: medir por precisão média, tempo médio de confirmação e cobertura de técnicas testadas.

9. Integração com o Restante da Biblioteca

O IOB é o topo da família de indicadores do capítulo 03 e o insumo natural do capítulo 04: a Pirâmide de Dor posiciona o comportamento no nível de maior custo de contorno, e o comparativo de indicadores desta mesma pasta formaliza a diferença entre as famílias. Na seção 15, o TH.15 executa a detecção comportamental com UEBA, o controle 17/02 organiza a caça orientada por comportamento, os controles DAT garantem a telemetria que sustenta os baselines, e o SIM.4 valida cada analytics antes da produção. O ciclo IOC, IOA e IOB também organiza o orçamento de detecção: bloqueio barato na base, correlação no meio, hunting caro no topo.

A conversão mais valiosa que esta nota propõe é a graduação de hunt em detecção com dados. Quando um IOB de beaconing nasce como consulta de hunting e acumula três meses de prevalência e precisão medidas, ele se torna uma regra permanente com severidade justificada, e a equipe libera atenção analítica para o comportamento seguinte, ainda não maduro. Repetir esse ciclo trimestre após trimestre é, na prática, o mecanismo pelo qual a organização sobe na Pirâmide de Dor sem abandonar a base, porque cada analytics promovido no topo libera a camada inferior para automação.