DAT.1 - Coleta de Logs de Endpoints

Nota do grupo DAT (Coleta de Dados e Telemetria) da seção 15 do Framework CTH.
Deriva do Capítulo 6 do PDF de referência e do controle DAT.1 do modelo CIS Controls v8.
Define a base de telemetria de host que sustenta detecção, threat hunting e resposta em todo o programa integrado de CTI e Threat Hunting.

1. Contexto e Posicionamento no Framework CTH

O endpoint é o território onde o adversário realmente opera: é nele que payloads são executados, credenciais são coletadas, a movimentação lateral se inicia e os dados são preparados para exfiltração. Sem telemetria de endpoint, a organização fica cega diante de ataques baseados em host, mesmo que possua firewalls, IDS e proxies bem configurados. Um adversário que evita a rede e trabalha inteiramente no host, usando técnicas Living-off-the-Land com PowerShell, WMI ou ferramentas nativas do sistema, só pode ser observado por meio dos logs locais.

Dentro do Framework CTH, DAT.1 é o primeiro elo da cadeia de coleta e alimenta diretamente DAT.4 (centralização em SIEM) e DAT.5 (qualidade e retenção). As hipóteses de hunting elaboradas no grupo TH dependem de eventos de processo, linha de comando, imagem carregada e acesso a arquivos estarem disponíveis para consulta. A ausência dessa telemetria invalida a maioria das hipóteses orientadas a técnica do MITRE ATT&CK e reduz o trabalho de detecção a alertas de superfície.

Este controle orienta a construção da coleta em camadas: primeiro os logs nativos do sistema operacional, depois ferramentas especializadas de auditoria como Sysmon e auditd, e por fim a camada de EDR quando o orçamento permitir. A lógica é evoluir do básico para o avançado sem comprometer o desempenho dos hosts nem estourar o custo de ingestão discutido em DAT.4.

2. Papel da Telemetria de Endpoint como Fonte Primária de Detecção e Hunting

A telemetria de endpoint é considerada fonte primária porque captura o momento exato da execução, que é o evento mais rico para atribuir comportamento a uma técnica ATT&CK. Logs de rede mostram que houve conexão, mas o log de criação de processo mostra quem conectou, com qual linha de comando, sob qual usuário e a partir de qual processo pai. Essa cadeia de ancestralidade de processos é o que permite diferenciar um administrador legítimo de um invasor usando as mesmas ferramentas.

Para threat hunting, o valor da telemetria de endpoint está na possibilidade de formular e testar hipóteses retrospectivas sobre grandes volumes de dados históricos. Um hunter pode, por exemplo, procurar todas as execuções de regsvr32.exe com URL na linha de comando, ou todos os eventos em que cmd.exe é filho de winword.exe, sem depender de alertas pré-existentes. Essas buscas só são possíveis quando os eventos relevantes foram coletados de forma contínua e normalizada.

A telemetria de endpoint também serve como fonte de verdade para investigação forense: ela permite reconstruir a linha do tempo do comprometimento com precisão de segundos. Quando o CTI identifica uma nova TTP associada a um grupo de ameaça, é a base de endpoint que responde à pergunta "isso já aconteceu aqui antes?". Essa interrogação retroativa da base histórica é um dos pilares do modelo de maturidade proposto pelo Framework CTH.

3. Windows: Sysmon e Eventos de Segurança Essenciais

No Windows, a combinação recomendada é o Event Logging nativo mais o Sysmon com uma configuração endurecida. A configuração padrão de fábrica do Sysmon é insuficiente; a recomendação de mercado é partir de bases comunitárias reconhecidas e ajustar por ambiente, com filtros que reduzem ruído sem esconder técnica. Os eventos mínimos esperados são: criação de processo com linha de comando (Event ID 1), carregamento de imagem e driver (Event IDs 6, 7 e 22), conexão de rede (Event ID 3), modificação de registro (Event IDs 12, 13 e 14) e criação de arquivos em caminhos críticos (Event ID 11).

Um trecho ilustrativo de configuração do Sysmon, com filtro por exclude para reduzir ruído, segue abaixo:

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <ProcessCreate onmatch="exclude">
      <Image condition="is">C:\Windows\System32\conhost.exe</Image>
    </ProcessCreate>
    <ProcessCreate onmatch="include">
      <CommandLine condition="contains">-enc</CommandLine>
      <CommandLine condition="contains">FromBase64String</CommandLine>
    </ProcessCreate>
    <NetworkConnect onmatch="exclude">
      <Image condition="end with">chrome.exe</Image>
    </NetworkConnect>
    <ImageLoad onmatch="include">
      <ImageLoaded condition="contains">\Temp\</ImageLoaded>
    </ImageLoad>
  </EventFiltering>
</Sysmon>

Além do Sysmon, o log de Segurança do Windows deve ter políticas de auditoria avançadas habilitadas, incluindo auditoria de linha de comando no evento 4688 via política de grupo. A tabela abaixo resume os eventos essenciais e o que cada um revela em investigação e hunting:

Em conjunto, esses eventos permitem reconstruir a tríade execução, persistência e acesso a dados que domina os relatórios de incidente. É recomendável incluir também os eventos 4728 e 4732, de adição em grupos globais e locais, para capturar escalonamento por associação a grupo.

4. Linux: auditd e journald com Regras Essenciais

No Linux, o subsistema auditd é a fonte de maior fidelidade para chamadas de sistema, e o journald complementa com logs de serviço e do kernel. O auditd deve auditar execução de binários via execve, modificações em arquivos críticos como /etc/passwd e /etc/shadow, alterações em crontabs e uso de chamadas sensíveis como ptrace. Regras de watch devem cobrir diretórios sensíveis como /etc, /var/log, /tmp e /home, com chaves que facilitem a busca posterior no SIEM.

Um exemplo de regras essenciais para /etc/audit/rules.d/hunting.rules:

-a always,exit -F arch=b64 -S execve -k exec_audit
-w /etc/passwd -p wa -k identity_change
-w /etc/shadow -p wa -k identity_change
-w /etc/crontab -p wa -k cron_change
-w /etc/sudoers -p wa -k sudoers_change
-w /tmp -p wa -k tmp_watch
-a always,exit -F arch=b64 -S connect -k net_connect

Essas regras devem ser combinadas com encaminhamento do journal via journald ou syslog-ng para o agregador central. Sem o encaminhamento, o log local pode ser apagado pelo próprio adversário após comprometer o host, o que destrói a evidência. A configuração do auditd deve incluir também a definição de max_log_file_action = keep_logs para evitar perda por rotação agressiva.

O journald deve ser configurado com persistência em disco, criando o diretório /var/log/journal, pois o modo volátil padrão perde tudo em reinicialização. Serviços expostos, como SSH, merecem atenção específica: os logs de autenticação do SSH alimentam as detecções de força bruta e movimentação lateral no Linux, na mesma posição que os eventos 4624 e 4625 ocupam no Windows.

5. macOS de Forma Breve

No macOS, a prioridade é habilitar o logging unificado e coletar os logs de TCC, autenticação e execução de aplicativos não assinados. Ferramentas open source de telemetria multiplataforma, como agentes baseados em osquery, oferecem consultas SQL sobre estado do sistema, processos e rede, e são uma alternativa pragmática quando o volume de Macs é pequeno. A coleta em macOS costuma ser menos madura que em Windows e Linux, mas não pode ser simplesmente ignorada em ambientes corporativos que tenham essa população.

6. osquery e Telemetria de Estado

Além dos logs de eventos, a telemetria de estado complementa a visibilidade do endpoint respondendo a perguntas que o log não guarda, como quais usuários possuem shell válido, quais regras de firewall estão ativas e quais binários possuem SUID no filesystem. O osquery expõe esse inventário como tabelas consultáveis em SQL e pode operar em modo agendado, transformando consultas em diffs de estado encaminhados ao SIEM. Essa fonte é valiosa para hunting de persistência incomum, como jobs agendados criados fora da janela de mudanças aprovadas.

A combinação entre eventos e estado também serve à verificação de cobertura: se um modelo de host esperado não reporta estado por um ciclo, existe problema de agente a investigar. O gerenciamento central das consultas, via fleet de osquery ou ferramenta equivalente, deve seguir o mesmo controle de versão aplicado às configurações do Sysmon e do auditd.

7. EDR como Fonte Complementar e Mais Rica

A plataforma de EDR agrega camadas que os logs nativos não entregam: telemetria de memória, desencadeamento de injeção de processo, reputação de binário, mutação de arquivo em tempo real e resposta remota. Em ambientes reais, o EDR tende a ser a fonte mais rica de telemetria de endpoint, com visualização de árvores de processo e correlação automática de sinais. A recomendação do Framework CTH é tratar EDR como complemento e não como substituto: os logs nativos permanecem necessários para forense profunda, para cobertura de servidores sem licença e para independência de fornecedor.

O equilíbrio entre cobertura, custo de licença e volume é uma decisão de engenharia, não um detalhe. Licenças de EDR e ingestão de SIEM são cobradas por host ou por volume, e a alternativa pragmática é posicionar EDR em estações de trabalho e servidores críticos, enquanto Sysmon e auditd cobrem a cauda longa. Essa combinação em camadas maximiza a visibilidade por real gasto e evita o cenário comum de cortar fontes críticas por pressão de custo.

A tabela abaixo ilustra uma distribuição típica de camadas por criticidade de host:

8. Orientação da Coleta por Técnicas ATT&CK Prioritárias

A escolha do que coletar deve partir das técnicas ATT&CK prioritárias definidas pelo trabalho de CTI nos grupos CTI.x e do perfil de ameaça da organização. Para priorizar credenciais e execução, os eventos 4688, 4104 e 1 do Sysmon são obrigatórios; para priorizar persistência, entram 7045, 12, 13 e 14 do Sysmon e as watches do auditd em crontabs; para priorizar exfiltração, os eventos de acesso a arquivo 4663 e conexões de rede 3 do Sysmon ganham peso. Essa orientação inversa, da técnica para o evento, evita a coleta genérica de tudo.

Um exercício prático eficaz é mapear as dez técnicas mais usadas pelos grupos de ameaça relevantes e verificar, para cada uma, qual evento a evidenciaria. Se nenhuma fonte existente gera o evento necessário, existe uma lacuna de coleta que deve entrar no backlog do DAT.1. Esse mapeamento deve ser revisado a cada ciclo de inteligência, pois o comportamento dos adversários muda.

Um exemplo de consulta de hunting alimentada por essa telemetria, procurando execução suspeita via PowerShell encodado:

event.code = 1 AND process.name = "powershell.exe"
AND process.command_line contains "-enc"
| stats count, values(host.name) by user.name, process.parent_name

9. Implementação Prática e Salvaguardas por Nível

O controle DAT.1 se materializa em salvaguardas numeradas, com complexidade crescente, que devem ser adotadas conforme a maturidade do time:

A implantação deve ser feita em ondas piloto, começando por servidores de identidade e estações de administradores, que concentram o maior risco. Cada onda precisa validar impacto de desempenho com métricas de CPU, disco e latência antes da expansão. Configurações devem ser gerenciadas por código, via GPO, Ansible ou ferramenta equivalente, para garantir consistência e reprodutibilidade.

Em nuvem, a salvaguarda avançada exige correlacionar a auditoria da plataforma com a telemetria das instâncias, pois ações como criação de snapshot, inserção de chave SSH via metadados ou desativação de log podem sinalizar abuso de plano de controle. Essa correlação dá visibilidade unificada entre plano de controle e plano de execução.

10. Erros Comuns e Pontos de Atenção

O erro mais frequente é coletar tudo sem parse, gerando montanhas de texto cru que ninguém consegue consultar com eficiência. Sem normalização de campos, a busca por process.command_line ou source.ip não funciona de forma uniforme, e o hunting fica lento e incompleto. Volume sem estrutura custa caro em ingestão e entrega pouco valor analítico, como aprofundado em DAT.4 e DAT.5.

Outro erro crítico é usar a configuração Sysmon padrão de fábrica, que deixa de fora linha de comando, hash e eventos de imagem, justamente os campos mais valiosos. Também é comum habilitar 4688 sem ativar a auditoria de linha de comando na política avançada, perdendo o dado mais importante do evento. Em Linux, depender apenas do journald local sem regras de auditd deixa de fora a granularidade de syscall que as hipóteses de hunting exigem.

Completam a lista de erros recorrentes: coleta sem teste de impacto de desempenho, que gera pressão para desligar a telemetria; logs de endpoint retidos apenas no host, onde o adversário pode apagá-los; e ausência de revisão periódica da configuração, permitindo que filtros antigos escondam técnicas novas. Cada um desses pontos deve ser tratado como lacuna de visibilidade formal e acompanhado até a correção.

11. Integração com Outros Controles do Framework CTH

DAT.1 alimenta DAT.4, que centraliza e normaliza esses dados para busca e correlação em escala, e depende de DAT.5 para garantir que timestamps e completude sejam confiáveis. Os dados de endpoint sustentam as regras de detecção do grupo DET e as hipóteses de hunting do grupo TH, além de fornecer evidências para os playbooks de resposta do grupo IR. Com o grupo MAP, os eventos de endpoint são ancorados em técnicas ATT&CK, criando o vínculo entre telemetria e inteligência de ameaças.

A recomendação operacional é revisar o plano de coleta de endpoint a cada trimestre, confrontando as técnicas prioritárias de CTI com os eventos efetivamente disponíveis na base. Cada lacuna identificada deve gerar tarefa com responsável, prazo e validação por teste sintético, no mesmo espírito do controle DAT.5. Assim, a coleta de endpoint deixa de ser um projeto estático e passa a ser um processo vivo, guiado por inteligência.