EDR (CrowdStrike, Defender, Carbon Black)

Nota 02 do capítulo 09 (Ferramentas e Plataformas), que trata o EDR como fonte de telemetria e como plataforma de caça ao mesmo tempo.
Compara CrowdStrike Falcon, Microsoft Defender for Endpoint e VMware Carbon Black com buscas reais, resposta ao vivo e limites de retenção.
Dialoga com as notas 01, 03 e 05 deste capítulo, com o controle DAT.1 do capítulo 15 e com as notas de endpoint do capítulo 08.

1. Contexto e Posicionamento na Biblioteca

As notas do capítulo 08 mostraram o que caçar no endpoint; esta nota mostra onde essa telemetria vive e como consultá-la de verdade. O EDR (Endpoint Detection and Response) tem papel duplo no portfólio do hunter: é a fonte mais rica de contexto de processo do ambiente, com árvore de execução, hashes, rede por processo e linha do tempo por host, e é também uma plataforma de consulta com linguagem, retenção e política de acesso próprias. Três produtos dominam a discussão de mercado e estruturam a comparação: CrowdStrike Falcon, Microsoft Defender for Endpoint e VMware Carbon Black.

A regra de leitura é a mesma da nota anterior: nada de manual de administração, o foco é extrair caça. O ponto central é que a console do EDR e o SIEM não competem sobre a mesma telemetria: a console guarda o dado mais completo por endpoint e oferece resposta ao vivo, enquanto o SIEM oferece correlação ampla e retenção negociável. Quando a hipótese exige meses de história, a exportação para data lake, tratada na seção 7, é o mecanismo que resolve a tensão entre retenção curta do produto e incubação longa da caça.

2. O que um EDR Precisa Entregar para Caça

Quatro capacidades separam um EDR caçável de um antivírus com painel bonito. A primeira é o acesso a eventos crus, além dos alertas: criação de processo, rede por processo, registro, arquivo e logon precisam existir como eventos individuais consultáveis, porque a hipótese raramente casa com a detecção pronta do fornecedor. A segunda é a árvore de processos com ancestralidade estável: o gesto analítico mais repetido em caça de endpoint é reconstruir o encadeamento pai e filho e posicioná-lo no tempo, e o hunter precisa saber como cada produto lida com reuso de PID e processos órfãos. A terceira é a linha do tempo unificada por host, que cruza processo, rede, registro e arquivo na mesma régua temporal. A quarta é a resposta ao vivo (live response), que permite coletar artefatos e executar comandos somente leitura no host suspeito sem esperar a escala formal da resposta a incidentes, tema do capítulo 13.

A disciplina de consulta também difere da rotina de alerta. Em caça, o filtro inicial é amplo de propósito e o refinamento é progressivo, o que exige linguagem que suporte expressões regulares, agregação e ordenação sobre campos brutos. O produto que só filtra por valor exato de campo força o hunter a exportar tudo para planilha, e o resultado é lento e não reprodutível. As três seções seguintes mostram, com consultas reais, como cada produto suporta esse modo de trabalho.

A tabela abaixo amarra cada capacidade ao tipo de pergunta que ela atende em caça, como referência rápida ao revisar um plano de caça do capítulo 07. A pergunta define a capacidade necessária, e não o contrário: escolher a ferramenta antes da pergunta é o caminho curto para uma caça decorativa.

3. CrowdStrike Falcon: Event Streams, Busca Avançada e RTR

O Falcon organiza a telemetria em tipos de evento como ProcessRollup2, que resume o processo com linhagem e hash, NetworkConnectIP4 e eventos de módulo e de script, e expõe três caminhos de caça que precisam ser dominados em conjunto. O Event Streams API entrega eventos crus em streaming para o pipeline da própria organização e é a base da exportação tratada na seção 7. A busca avançada do Falcon Insight roda CQL (CrowdStrike Query Language, herdada do LogScale) sobre a retenção do produto; o exemplo abaixo lista por host as execuções de ferramentas administrativas frequentemente abusadas, padrão de movimento lateral associado a T1021:

#event_simpleName=ProcessRollup2 FileName=/^(?i)(psexec|paexec|wmic)\.exe$/
| groupBy([ComputerName, FileName], function=collect([CommandLine]), limit=100)

O RTR (Real Time Response) fecha o ciclo da caça com sessões auditadas contra o host: ps, cat, get de arquivo e execução de script PowerShell em modo somente leitura, com aprovação configurável para ações ativas. O exemplo abaixo é a sequência típica de qualificação de um achado antes de abrir caso:

> ps
> cat "C:\\Users\\svc_backup\\AppData\\Roaming\\config.json"
> get "C:\\Windows\\Temp\\svchost32.dll"

A particularidade de caça no Falcon é a diferença entre detecção e telemetria. A console prioriza detecções, e a caça séria começa quando o hunter ignora o painel e consulta eventos com filtros próprios, incluindo hashes raros no parque e linhagem completa de processo. O arquivo de ações do RTR também é fonte de caça retrospectiva: revisar quais hosts receberam scripts e comandos no último trimestre revela tanto o uso operacional quanto eventuais abusos do próprio mecanismo de resposta.

O segundo exemplo em CQL implementa a caça de hash raro no parque: binários que executaram em poucos hosts, mas com recorrência, é o perfil clássico de ferramenta de adversário compilada por campanha. O filtro de contagem mínima evita os executáveis de uso único que legítimamente aparecem uma vez:

#event_simpleName=ProcessRollup2
| groupBy([SHA256HashData], function=[count(as=Execucoes), distinct(field=ComputerName, as=Hosts)])
| Hosts <= 2 AND Execucoes >= 5

O resultado desta consulta alimenta três desdobramentos imediatos: coleta do binário via RTR para verificação em sandbox, consulta reversa do hash no catálogo de software da organização e registro do hash como parâmetro de busca permanente até a classificação final. Cada desdobramento entra no catálogo de caças com data e hipótese associadas, e o hash permanece em observação até que o encerramento classifique o binário como ferramenta de administração, software corporativo ou achado.

4. Microsoft Defender for Endpoint: KQL em Advanced Hunting

O Advanced Hunting do MDE (Microsoft Defender for Endpoint) expõe o esquema unificado de tabelas DeviceProcessEvents, DeviceNetworkEvents, DeviceLogonEvents, DeviceRegistryEvents e DeviceFileEvents, consultadas com KQL, a mesma linguagem do Microsoft Sentinel. Essa continuidade é a maior força do produto para caça: a consulta desenvolvida no portal roda no Sentinel sem tradução, e as funções de série temporal do KQL, tema da nota 03, ficam disponíveis na mesma tela. A retenção de 30 dias impõe disciplina, e o operador ago(30d) aparece sempre no topo da consulta. O exemplo abaixo retoma o stack counting de execução via WMI construído na nota anterior:

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName =~ "wmiprvse.exe"
    and FileName in~ ("powershell.exe", "cmd.exe", "mshta.exe")
| summarize Execucoes = count(), UltimoUso = max(Timestamp)
    by DeviceName, ProcessCommandLine
| where Execucoes <= 5
| order by Execucoes asc

O portal entrega ainda a linha do tempo do dispositivo com árvore de processos navegável, que é o caminho rápido para entender o contexto de um achado antes de escrever a consulta seguinte. Quando o padrão da caça se confirma, a mesma consulta vira custom detection com agendamento e severidade, que é o elo direto com o capítulo 18 desta biblioteca. A limitação prática é o escopo: o Advanced Hunting cobre o parque gerenciado pelo Defender, e servidores ou sistemas legados fora do gerenciamento simplesmente não existem nas tabelas, o que precisa constar do inventário de dados do controle DAT.1.

O segundo exemplo caça persistência por Run Key com volume anômalo de valores por host, hipótese associada a T1547.001 do ATT&CK. O raciocínio de stack counting continua o mesmo, apenas trocando a tabela de processo pela de registro:

DeviceRegistryEvents
| where Timestamp > ago(30d) and ActionType == "RegistryValueSet"
| where RegistryKey has "CurrentVersion\\Run"
| summarize Valores = make_set(RegistryValueName) by DeviceName
| extend Total = array_length(Valores)
| where Total >= 6
| project DeviceName, Total, Valores

Hosts legítimos também acumulam valores nessa chave com o tempo, e por isso a leitura do resultado é comparativa: o hunter cruza a lista com o baseline do parque e investiga apenas os nomes de valor que não existem em nenhum host comparável. O mesmo critério comparativo vale para contas com novas atribuições de grupo, e a diferença entre novidade e anomalia é sempre o baseline, nunca o número absoluto.

5. VMware Carbon Black: Busca de Processos e Live Response

O Carbon Black Cloud organiza a telemetria em torno do processo, com busca por sintaxe própria de campos como process_name, cmdline, parent_name e device_name, executável no portal e pela API Investigate v7 para caça programática. A API é o diferencial prático: search jobs assíncronos permitem varrer janelas longas de telemetria sem depender do navegador, e o resultado alimenta rotinas agendadas do capítulo 07. O exemplo abaixo é a string de busca típica para interpretação codificada de PowerShell, padrão de execução indireta associado a T1059.001:

process_name:powershell.exe AND cmdline:*-enc* AND device_os:WINDOWS

O live response do Carbon Black segue o modelo das demais plataformas, com sessão interativa e comandos nativos de diagnóstico e coleta:

> ps
> netconn
> file fetch "C:\\ProgramData\\updater.exe"
> reg query HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run

Duas notas de caça específicas do produto valem registro. Primeiro, os process boards e o modproc consolidam histórico por binário, o que acelera a pergunta de quantos hosts executaram determinado hash em janela longa. Segundo, a telemetria de eventos pode ser configurada por política de sensor, e ambientes que reduziram coleta para economizar custo precisam ter essa configuração mapeada no inventário, porque o resultado da caça muda de acordo com a política aplicada a cada grupo de hosts.

A caça programática pela API Investigate v7 transforma a mesma busca em rotina agendada do capítulo 07, como no exemplo abaixo que cria um search job para o mês de novembro e depois consulta o resultado por endpoint paginado:

curl -s -X POST "https://defense.conferdeploy.net/investigate/v2/orgs/$CB_ORG_KEY/processes/search_jobs" \
  -H "X-Auth-Token: $CB_API_KEY/$CB_CONNECTOR_ID" \
  -H "Content-Type: application/json" \
  -d '{"query":"process_name:powershell.exe AND cmdline:*-enc* AND device_os:WINDOWS",
       "time_range":{"start":"2025-11-01T00:00:00Z","end":"2025-11-30T23:59:59Z"}}'

O mesmo padrão de rotina serve às três plataformas: a consulta canônica vive no repositório do time, a credencial vive no cofre conforme a nota 05 deste capítulo, e o resultado é gravado com data, hipótese e veredicto, para que a execução seguinte parta do registro anterior e não do zero. O que muda entre plataformas é o endpoint e o nome do campo; a lógica, o agendamento e o registro são os mesmos.

6. Comparação e Papel no Portfólio

A tabela abaixo resume os três produtos sob a ótica de caça. Os números de retenção variam por contrato e por versão, e por isso o texto usa o termo tipicamente: o valor válido é o do seu ambiente, verificado no portal de administração.

A leitura estratégica é que os três cumprem o mesmo ciclo com ênfases diferentes: Falcon se destaca na linhagem e na resposta auditada, Defender na linguagem de consulta e na integração com SIEM, Carbon Black na visibilidade por binário e na API de busca. Programas com mais de um EDR no parque devem padronizar a exportação para o lake, porque manter hipóteses duplicadas em três linguagens é custo sem retorno.

7. Limitações de Retenção e Exportação para Data Lake

A limitação que mais dói na caça é a retenção: 30 dias no Defender e janelas configuráveis nos demais produtos cobrem a rotina, mas não hipóteses de incubação longa, comparação sazonal ou resposta a incidente que descobre comprometimento de meses. A segunda limitação é de acesso: consoles de produto concentram consultas no navegador, sem biblioteca de consultas versionada do time e sem execução programática fluida. A terceira é de portabilidade: hipótese escrita em CQL ou em KQL própria do portal não roda em outra plataforma, o que trava o conhecimento no produto.

A exportação para data lake resolve as três limitações com um único desenho. O Falcon entrega eventos via Event Streams, o Defender via conector de streaming para Event Hubs ou via conector do Sentinel, e o Carbon Black via data forwarder; o pipeline da organização grava os eventos em parquet particionado por dia. A partir daí, as consultas ficam independentes do fornecedor, e a caça de retenção longa vira SQL sobre o lake, como no exemplo abaixo com DuckDB carregando um mês de parquet:

SELECT device_name, process_name, COUNT(*) AS execucoes
FROM read_parquet('lake/edr/ano=2025/mes=11/*.parquet')
WHERE parent_name LIKE '%wmiprvse.exe'
GROUP BY device_name, process_name
HAVING COUNT(*) <= 3
ORDER BY execucoes ASC

O desenho maduro mantém a console do EDR para a caça do dia e do contexto de resposta ao vivo, e o lake para a caça histórica e comparativa, com a mesma normalização de campos garantida por contrato de dados. O SIEM permanece como hub de correlação, e o notebook da nota 05 executa sobre o lake a estatística que nenhuma das três linguagens de console entrega com conforto.

8. Erros Comuns e Pontos de Atenção

• Caçar somente sobre detecções do produto; efeito: hipóteses originais nunca testadas porque o painel não gerou alerta; correção: toda rotina de caça consulta eventos crus com filtros próprios, e não a fila de alertas.
• Esquecer a retenção de 30 dias; efeito: hipótese desenhada para 12 meses morre no primeiro teste no portal; correção: verificar a janela real por fonte e redirecionar a caça para o lake quando necessário.
• Confiar na linhagem sem entender reuso de PID; efeito: árvore de processo costura filhos errados e o achado muda de dono; correção: validar com timestamps e campos de linhagem do produto antes de concluir encadeamento.
• Usar live response sem auditoria e sem escopo; efeito: coleta invasiva ou modificação acidental em host produtivo; correção: sessões justificadas, comandos somente leitura como padrão e aprovação para qualquer ação ativa.
• Duplicar hipóteses em cada console de EDR; efeito: manutenção tripla da mesma lógica e divergência de resultado entre plataformas; correção: exportar telemetria para o lake e manter a lógica canônica versionada, com Sigma como referência.
• Ignorar políticas de coleta por grupo de hosts; efeito: resultado de caça diferente entre servidores e estações sem explicação analítica; correção: mapear política de sensor por grupo no inventário do DAT.1.

9. Integração com o Restante da Biblioteca

Esta nota complementa a nota 01 na camada de plataforma: o SIEM centraliza e correlaciona, e o EDR entrega profundidade de endpoint com resposta ao vivo. A telemetria aqui citada é a que o controle DAT.1 obriga a inventariar, as caças de endpoint do capítulo 08 assumem essas capacidades de consulta, e a promoção de consulta confirmada em custom detection ou em regra Sigma segue o capítulo 18. A resposta ao vivo se conecta ao capítulo 13 como primeira coleta forense, e as métricas de cobertura de telemetria alimentam o capítulo 11.

Um detalhe operacional fecha a nota com ganho composto: registre no catálogo de caças, para cada consulta desta nota, a janela máxima testada, o custo de execução e a fonte de dados usada, portal ou lake. Programas maduros tratam a exportação para lake como requisito do programa de caça, e não como projeto de engenharia opcional, porque é ela que transforma hipóteses de 30 dias em hipóteses de 12 meses sem depender do contrato do fornecedor.