DAT.2 - Coleta de Telemetria de Rede

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.2 do modelo CIS Controls v8.
Estabelece a visibilidade em nível de rede que complementa o endpoint e sustenta detecção de C2, movimentação lateral e exfiltração.

1. Contexto e Posicionamento no Framework CTH

A visibilidade em nível de rede é indispensável para detectar comunicações de comando e controle, movimentação lateral entre segmentos, exfiltração de dados e atividade de reconhecimento. Muitas técnicas adversárias são difíceis de observar no endpoint, mas deixam rastros claros na rede, como beaconing periódico para servidores C2, transferências volumosas para destinos incomuns e varreduras internas de portas. Além disso, a rede é o único ponto que oferece visibilidade sobre dispositivos que não comportam agentes, como equipamentos IoT, impressoras, switches e roteadores.

Dentro do Framework CTH, DAT.2 é a contraparte de rede do controle DAT.1 e responde por uma camada independente de evidência. Quando o adversário compromete o host e apaga os logs locais, o sensor de rede preserva o histórico das comunicações, o que torna essa fonte essencial para forense e para hunting retroativo. Os dados gerados aqui alimentam DAT.4 para centralização e o grupo DET para correlação com alertas de endpoint.

A lógica de construção deste controle é evolutiva: começa pelos logs de firewall e DNS, avança para sensores de análise de protocolo no ponto de saída, depois para segmentos internos críticos e, por fim, para capacidades seletivas de captura completa. Cada camada adicionada deve ser justificada pelas técnicas ATT&CK prioritárias e pelo custo de armazenamento definido em DAT.5.

2. Camadas de Visibilidade de Rede

A telemetria de rede se organiza em quatro camadas complementares, cada uma com custo e granularidade distintos. Na base estão os logs de equipamentos, como firewall, proxy e DNS recursivo, que resumem conexões e requisições; eles são baratos, mas pobres em detalhe de protocolo. Acima deles ficam os metadados de fluxo, gerados por NetFlow e IPFIX, que oferecem escala em enlaces grandes sem registrar payload.

A terceira camada é a análise profunda de protocolo, feita por sensores como Zeek e Suricata, que dissecam transações completas de DNS, HTTP e TLS e produzem logs estruturados ricos. No topo está a captura completa de pacotes, o recurso mais fiel e mais custoso, reservado para uso pontual. Um programa maduro opera todas as camadas simultaneamente, porque cada uma responde a perguntas diferentes durante uma investigação.

A tabela abaixo resume as camadas e seu papel em hunting:

3. Zeek e Seus Logs Principais

O Zeek é o sensor de análise de tráfego de referência e produz logs estruturados por protocolo, cada um habilitando classes específicas de hipótese de hunting. O log conn registra todas as conexões com bytes transmitidos, duração e estado, e permite caçar beaconing por regularidade de intervalo e volume, além de exfiltração por volume de upload anômalo. O log dns captura consultas e respostas, viabilizando detecção de tunelamento por tamanho e frequência de rótulos, uso de domínios recém-registrados e resoluções para infraestrutura de C2.

O log http expõe métodos, URIs, user agents e cabeçalhos de requisições em texto plano, habilitando hunting de execução via webshell, download de payloads e comunicação C2 por HTTP. O log ssl registra handshake, SNI, versão e conjunto de cifras, e sustenta buscas por clientes TLS incomuns mesmo sem descriptografia. O log files descreve transferências de arquivos extraídas dos protocolos, com hashes e tipos MIME, enquanto o log notice concentra os avisos gerados por políticas e scripts do próprio Zeek. A soma desses logs forma um dicionário comportamental sobre o tráfego que nenhuma outra fonte de rede entrega com essa estrutura, e é por isso que o sensor de análise de protocolo é considerado o pilar do hunting de rede.

Um exemplo de consulta sobre log conn para identificar candidatos a beaconing, em pseudo-KQL aplicável a bases indexadas:

conn
| where network_transport == "tcp" and network_connection_history contains "Sh"
| summarize count(), dcount(connection_state) by destination_ip, bin(timestamp, 1h)
| where count_ > 50
| sort by destination_ip asc

A recomendação operacional é rotacionar os logs do Zeek a cada 15 minutos e limitar o tamanho de cada arquivo, encaminhando tudo ao agregador central. Um exemplo de bloco de configuração da pilha de logs essenciais:

# local.zeek
@load policy/tuning/logs-to-elasticsearch
redef LogAscii::use_json = T;
redef Log::default_rotation_interval = 15 min;
@load policy/protocols/conn/known-hosts
@load policy/protocols/dns/detect-external-names
@load policy/protocols/ssl/extract-certs-pem

Scripts comunitários ampliados, como conjuntos de detecção por comportamento, devem ser avaliados e ajustados por ambiente, evitando ativar policies que geram ruído excessivo para o contexto local.

4. Suricata: Assinaturas e Protocolo em Modo EVE JSON

O Suricata atua como IDS com regras de assinatura, complementando a análise comportamental do Zeek com detecção baseada em padrões conhecidos. Sua saída deve ser configurada no modo EVE JSON, que emite um único fluxo estruturado com alertas, metadados de fluxo, DNS, HTTP, TLS e extração de arquivos, pronto para ingestão em SIEM. O uso de JSON elimina parsers frágeis e garante que novos campos sejam preservados na ingestão.

As regras devem combinar conjuntos comunitários atualizados, como Emerging Threats, com regras personalizadas derivadas da inteligência de ameaças da própria organização. A configuração típica do EVE segue este formato:

outputs:
  - eve-log:
      types:
        - alert:
            tagged-packets: yes
        - dns:
            requests: yes
            responses: yes
        - http:
            extended: yes
        - tls:
            extended: yes
        - flow
        - fileinfo

A integração com o SIEM deve correlacionar alertas do Suricata com logs conn e dns do Zeek, reduzindo falsos positivos e enriquecendo o contexto do alerta com histórico de comunicação. Essa correlação entre IDS e sensor de protocolo é exatamente o que a salvaguarda intermediária do controle exige e o que separa uma operação madura de uma pilha de ferramentas isoladas.

5. NetFlow e IPFIX para Escala em Enlaces Grandes

Em enlaces de alto tráfego, onde a inspeção profunda de pacotes é inviável, NetFlow e IPFIX fornecem metadados de fluxo a custo baixíssimo. Cada registro descreve uma conversa entre origem e destino, com portas, bytes, pacotes e duração, o que basta para baseline comportamental, mapeamento de conversações e detecção de varredura e exfiltração grosseira. A cobertura completa da malha de rede com fluxo é uma meta realista até em operações grandes.

É essencial entender o efeito da amostragem, pois roteadores de alto desempenho frequentemente amostram apenas 1 em cada 1000 ou 1 em cada 10000 pacotes. Com amostragem, volumes e contagens de fluxo são estimativas, não valores exatos, e comparações de magnitude perdem precisão para pequenas anomalias. O hunting baseado em fluxo amostrado funciona bem para padrões estatísticos e picos, mas não para contagens exatas de conexões, e essa limitação deve ser documentada no contexto de cada hipótese.

A recomendação prática é usar fluxo amostrado na borda de operadoras e busca estatística de padrões, reservando a inspeção profunda dos sensores para pontos estratégicos de menor vazão. Quando possível, configurar amostragem determinística e registrar o fator de amostragem nos metadados, para que o analista saiba interpretar os números corretamente.

6. Captura Completa de Pacotes como Recurso Pontual

A captura completa de pacotes guarda a transmissão integral, incluindo payload, e é o único recurso que permite dissecação forense total de uma sessão. Seu custo em armazenamento e sensibilidade de dados impede operação contínua em toda a malha, de modo que a prática recomendada é a captura seletiva disparada por gatilhos. Exemplos de gatilho incluem alerta de alta prioridade do IDS, comunicação com IOC conhecido ou atividade de exfiltração detectada pelo SIEM.

A retenção recomendada para PCAPs disparados é de no mínimo 30 dias, o suficiente para análise retrospectiva durante a investigação. Arquivos de captura devem ter integridade verificada, com hash calculado na criação e registro no SIEM para rastreabilidade. A captura contínua pode ser aceitável em segmentos de pequeno volume e alta sensibilidade, como o link de administração, sempre com avaliação legal prévia.

7. Visibilidade de TLS Criptografado

A criptografia quase universal do tráfego não elimina a visibilidade de rede; ela desloca o foco do conteúdo para os metadados. No handshake TLS permanecem visíveis o SNI, que revela o nome de host solicitado, o certificado do servidor, a versão do protocolo e o conjunto de cifras negociado. Esses elementos já sustentam hunting valioso, como conexões para SNI de infraestrutura recém-registrada e uso de cifras antigas por malware.

Impressões digitais de cliente elevam essa visibilidade a outro nível. O JA3 cria um hash da composição de versão, cifras e extensões do cliente TLS, e o JA3S faz o mesmo para a resposta do servidor, formando duplas que caracterizam famílias de malware e ferramentas específicas. Um host Windows que apresenta JA3 de uma família conhecida de RAT é um indicador forte de comprometimento, mesmo sem qualquer payload visível.

Hunting prático sobre metadados TLS inclui correlacionar duplas JA3 e JA3S incomuns com logs conn para mapear a infraestrutura, e comparar SNI observados com feed de domínios de risco. Para tunelamento por DNS, uma busca exemplificativa agrega o tamanho médio dos rótulos por origem:

dns
| where query_length > 60 or strlen(dns.labels) > 50
| summarize count(), avg(query_length) by source_ip, bin(timestamp, 15m)
| where count_ > 20

Como o contexto é passível de falsificação, achados por JA3 devem ser tratados como hipótese forte, a validar com telemetria de endpoint do controle DAT.1.

8. Pontos de Coleta: TAP versus SPAN, Borda, Data Center e Nuvem

A escolha de onde coletar e como acessar o tráfego determina a qualidade de toda a telemetria. TAP passivo copia fisicamente o tráfego sem impacto na rede, entregando pacotes completos inclusive com erros, e é a escolha certa para enlaces críticos. SPAN de switch é mais barato e flexível, mas pode descartar pacotes sob carga e não reproduz com fidelidade frames corruptos, o que deve ser considerado ao interpretar dados.

Na nuvem, o espelhamento de pacotes é oferecido de forma nativa pelas plataformas e deve ser direcionado a sensores Zeek ou Suricata em sub-redes dedicadas. Onde o espelhamento não é viável, os logs de fluxo de VPC e os logs de DNS da nuvem garantem uma camada mínima de metadados. Trânsito entre contas, entre assinaturas e entre regiões merece pontos de coleta próprios, pois é exatamente ali que a movimentação lateral em nuvem acontece e costuma ficar invisível.

A regra geral é coletar na borda para todo o tráfego externo e nos segmentos críticos para o interno, sempre com capacidade de processamento dimensionada para picos. O dimensionamento dos sensores deve considerar taxa de pico de pacotes, não média, e prever headroom para rajadas durante incidentes, quando a captura seletiva sobe simultaneamente em vários pontos.

9. Privacidade e Governança de Dados de Rede

A telemetria de rede captura dados pessoais de funcionários e de clientes, o que obriga alinhamento com a LGPD e com a política de uso aceitável da organização. Headers HTTP, SNI e nomes de usuário em logs de proxy podem expor comportamento individual, e por isso a coleta precisa de base legal documentada, minimização de campos e controle de acesso rigoroso ao armazenamento. Dados de PCAP, por conterem conteúdo completo, exigem restrição ainda maior e prazo de destruição definido.

A governança deve definir quem pode consultar cada camada de dado, com registro de auditoria das próprias buscas, e prever anonimização ou truncamento de identificadores quando a análise não exige identificação direta. Essas decisões devem ser tomadas junto com jurídico e privacidade, antes da expansão da coleta, e revisadas em conjunto com DAT.5, que trata da retenção.

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

As salvaguardas do controle DAT.2 seguem o padrão de complexidade crescente do Framework CTH:

A implantação deve validar primeiro a sincronização de tempo, porque correlação entre fontes sem relógio alinhado é inútil. Cada novo sensor deve passar por teste de vazamento controlado, gerando tráfego sintético para confirmar que os logs esperados chegam ao SIEM.

11. Erros Comuns e Pontos de Atenção

O erro clássico é confiar apenas no log de firewall, que registra bloqueios e conexões de forma resumida, sem detalhe de protocolo e frequentemente sem registrar tráfego permitido. Sem o sensor de protocolo, hipóteses sobre C2 em HTTP, tunelamento DNS e transferência de arquivos simplesmente não têm dados para serem testadas. O log de firewall é camada de contexto, não fonte primária de hunting.

Outro erro frequente é operar sensores sem sincronização de tempo entre todas as fontes, o que torna impossível correlacionar alerta do IDS com log de DNS e evento de endpoint. Falta de NTP estruturado invalida linhas do tempo e desacredita evidências. Também é comum esquecer a amostragem de fluxo e tratar números estimados como exatos, ou implantar sensor na borda e ignorar segmentos internos, deixando a movimentação lateral invisível.

Completam a lista: sensores dimensionados pela média de tráfego que descartam pacotes nos picos, logs de proxy coletados sem o IP de origem real atrás do NAT corporativo, e telemetria de rede guardada sem rótulo do ponto de coleta, o que impede distinguir tráfego de borda de tráfego interno na hora da investigação. Cada novo ponto de coleta deve entrar com identificação explícita nos metadados, prática que simplifica o hunting e a interpretação das camadas descritas neste controle.

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

DAT.2 fornece a camada de rede que completa DAT.1, e ambos convergem em DAT.4 para normalização e busca unificada, com DAT.5 garantindo qualidade de timestamps e retenção adequada. As hipóteses de hunting do grupo TH sobre C2, exfiltração e movimentação lateral dependem diretamente destes logs, e as regras do grupo DET se beneficiam da correlação entre assinatura e comportamento. Com o grupo INT, os indicadores de infraestrutura extraídos de DNS e TLS alimentam o ciclo de inteligência, fechando o laço entre observação operacional e produção de CTI.