TH.12 - Hunting de Rede

Nota do grupo HNT (Threat Hunting) do Framework CTH, seção "15 - Framework CTH - Controles".
Deriva do Capítulo 13, controle TH.12, e consome a telemetria de rede coletada em DAT.2.
Papel no programa: revelar comunicação C2, tunneling, movimentação lateral e exfiltração que
o endpoint esconde e que as assinaturas de rede automatizadas não capturam por conta da mimetização.

1. Contexto e Posicionamento no Framework CTH

O hunting de rede é o controle TH.12 do grupo HNT e complementa o TH.11 pela outra ponta do cabo: enquanto o endpoint mostra o que executou, a rede mostra para onde o
resultado foi. Muitos adversários operam com malware que não escreve em disco, que roda em host sem EDR ou que mimetiza tráfego legítimo de aplicação, e é exatamente nesse
vazio de telemetria de endpoint que a análise de fluxo e de protocolo ganha valor. O princípio central é que padrões de comunicação são difíceis de esconder: beaconing,
tunneling e fingerprints de TLS aparecem quando múltiplas conexões são correlacionadas no tempo e no espaço, mesmo quando cada conexão isolada parece inofensiva.

Este controle depende das fontes de DAT.2: logs conn, dns, http e ssl do sensor de análise de tráfego, alertas de IDS e dados de fluxo. A maturidade do baseline definido em
TH.2 e INS.5 também é pré-requisito, porque quase toda técnica desta nota compara comportamento observado contra padrão esperado por segmento. As hipóteses de rede seguem o
mesmo processo de TH.4 e TH.6, com priorização em TH.5, e os achados qualificados fluem para IR.x ou viram detecções no DET.x.

A rede tem uma vantagem operacional que o endpoint não tem: visibilidade sem agente. Servidores que não aceitam agente, IoT, impressoras e equipamentos de fornecedor não
produzem telemetria de processo, mas falam na rede. Para esse universo, o hunting de rede é frequentemente a única caça possível, e isso precisa estar refletido no inventário
de visibilidade de TH.1.

2. O que a Rede Revela que o Endpoint Esconde

O endpoint mostra a execução local, mas três classes de comportamento adversário só ficam plenamente visíveis na rede. A primeira é a comunicação de comando e controle em si,
porque o adversário precisa falar com infraestrutura que ele controla e essa infraestrutura deixa endereço, domínio, certificado e fingerprint. A segunda é a movimentação
lateral entre hosts, que gera tráfego interno de portas de gestão que a maioria das aplicações legítimas não usa. A terceira é a exfiltração volumétrica, que aparece como
upload anômalo para destino externo mesmo quando o processo que enviou é benigno na aparência.

A rede também corrige cegueiras práticas do endpoint. Um host sem EDR ou com agente desligado por política de fornecedor continua gerando fluxo observável. Malware com
anti-analysis pode falhar ao executar no sandbox, mas o tráfego real de produção não mente sobre quando, para quem e com que ritmo as comunicações acontecem. Por fim, a
perspectiva agregada de rede expõe padrões estatísticos, como baixa variância de intervalo, que nenhuma máquina isolada demonstra por si só.

3. Hunting de Beaconing

Beaconing é a comunicação periódica de malware com seu C2 para checar tarefas e reportar status. Os sinais clássicos são: intervalos regulares entre conexões com baixa
variância, volumes pequenos e repetidos, conexões de saída para destino externo sem explicação de negócio e metadados HTTP atípicos como User-Agent que não corresponde ao
software instalado no host. A métrica central é o jitter: C2 de ritmo fixo tem desvio padrão de intervalo próximo de zero, enquanto tráfego humano e serviços legítimos variam
mais.

O fluxo de análise com logs conn do Zeek segue três passos: agrupar conexões por par origem e destino, calcular os intervalos entre conexões sucessivas e medir a regularidade
desses intervalos. O exemplo abaixo calcula, por par de hosts, o número de conexões, o intervalo mediano e o coeficiente de variação, filtrando pares com muitas conexões e
ritmo quase constante.

cat conn.log | zeek-cut id.orig_h id.resp_h ts |
  awk '{print $1, $2, $3}' |
  sort -k1,1 -k2,2 -k3,3n |
  awk '{
    if ($1 != prev_src || $2 != prev_dst) { n=0; prev_src=$1; prev_dst=$2; first=$3 }
    else { gap[n++] = $3 - last }
    last = $3
    if (n >= 20) {
      sum = 0; for (i = 0; i < n; i++) sum += gap[i]
      mean = sum / n
      var = 0; for (i = 0; i < n; i++) var += (gap[i] - mean) ^ 2
      cv = sqrt(var / n) / mean
      if (cv < 0.05) print prev_src, prev_dst, n, mean, cv
      n = 0
    }
  }' > candidatos_beacon.txt

Cada par candidato precisa de qualificação antes de virar caso. Checar o User-Agent no http.log, o tamanho médio das respostas, a idade do domínio, a reputação do IP e a
existência de processo que explica a conexão no endpoint. Beaconing legítimo existe: agentes de inventário que batem no servidor a cada 60 segundos, sincronização de clock,
health check de proxy. A diferença costuma estar no User-Agent estável e documentado, no destino corporativo conhecido e no baseline de TH.2 que já esperava esse padrão.

3.1 Separando beacon legítimo de C2

A decisão de escalar um candidato passa por comparar as dimensões do padrão observado com o que o ambiente documenta como esperado. A tabela abaixo concentra os critérios que
separam os dois lados na prática.

Nenhum critério isolado fecha o caso, e a combinação de três ou mais colunas da direita em um mesmo par de hosts justifica abertura de investigação com prioridade alta. O
registro da decisão, com o porquê de cada critério, mantém a caça auditável e acelera a próxima execução.

4. Tunneling DNS

O tunneling DNS encapsula dados de exfiltração ou comandos de C2 dentro de consultas DNS, explorando o fato de que o DNS quase sempre atravessa o perímetro sem inspeção. Os
sinais de caça são: subdomínios longos com alta entropia, alto volume de consultas TXT ou NULL para o mesmo domínio, registros de resposta grandes demais para a função do
domínio e frequência de consulta que não condiz com navegação humana. O método mais simples de agregação mede o comprimento médio do qname por domínio e compara contra o
padrão de consultas do ambiente.

cat dns.log | zeek-cut id.orig_h query qtype_name |
  awk '$3 == "TXT" { print $2 }' |
  sort | uniq -c | sort -rn |
  head -20

A segunda agregação foca no subdomínio em si, procurando rótulos com mais de 40 caracteres e mistura de maiúsculas, minúsculas e dígitos, padrão típico de ferramentas de
tunneling como dnscat e iodine.

cat dns.log | zeek-cut id.orig_h query qtype_name |
  awk '{
    n = split($2, labels, ".")
    if (n >= 3 && length(labels[1]) >= 40) print $1, $2
  }' |
  sort | uniq -c | sort -rn | head -20

A qualificação cruza o host consultante com o endpoint: processo que originou a consulta, volume de bytes por sessão DNS e existência de ferramenta legal de tunneling no
ambiente. Falsos positivos clássicos são serviços de telemetria que usam TXT para configuração e antispam que consulta SPF com respostas grandes. A mitigação estrutural é
restrição de resolução recursiva por segmento, coberta em PRT.x, mas o hunt continua sendo a rede de segurança quando a restrição falha.

5. TLS Anômalo

Análise de TLS começa pelo fingerprint JA3, que resume versão, ciphersuites e extensões do handshake em um hash estável por biblioteca cliente. Um host de estação de trabalho
cujo tráfego passa a apresentar JA3 que nunca apareceu no baseline sugere nova ferramenta, malware ou cliente HTTP não padrão. O segundo sinal é o SNI divergente do destino
real: quando o destino do IP pertence a uma gama de hosting e o SNI não corresponde a nada conhecido, a comunicação merece investigação. O terceiro é o certificado em si:
autoassinado em serviço que nunca teve TLS próprio, validade muito longa, emissor sem reputação e domínios recém-registrados.

cat ssl.log | zeek-cut id.orig_h id.resp_h server_name ja3 validation_status |
  awk '$5 == "self signed certificate" { print }' |
  sort | uniq -c | sort -rn | head -30

A leitura dos resultados precisa de contexto por ativo: certificado autoassinado em appliance de laboratório é comum, em servidor de aplicação de produção que historicamente
usava certificado corporativo é mudança de configuração ou de software. Correlacionar JA3 novo com o processo que originou a conexão, via Sysmon 3 no endpoint, converte o
achado de rede em cadeia de evidência completa. Essa ponte para o TH.11 é o que separa o achado interessante da evidência acionável.

6. Destinos Novos por Segmento e Comunicação Inter-segmento

Baseline de comunicação por segmento é o fundamento estatístico deste controle. O método é construir, por segmento, o conjunto de destinos externos e internos esperados, com
frequência e volume típicos, e caçar o que escapa: destino externo novo em segmento de servidores, comunicação de estação de trabalho diretamente para segmento de servidores
sem passar pelo caminho de aplicação, e conexões para portas de gestão como 445, 3389, 5985 e 135 vindas de origens que não têm função de administração. O RITA automatiza
parte desse raciocínio, com módulos de beacon, long connections e DNS, e serve de contraprova para hunts manuais.

A tabela abaixo resume as ferramentas e o papel de cada uma na rotina de caça de rede.

6.1 Caça de movimentação lateral entre hosts

A movimentação lateral é o padrão de rede de mais alto valor para caçar em ambiente Windows, porque toda técnica de execução remota passa por portas de gestão e deixa fluxo
interno observável. O método é fixar o conjunto de serviços remotos legítimos por segmento, como ferramenta de gestão aprovada, e caçar conexões para 445, 3389, 5985 e 135 que
não pertencem a esse conjunto. O exemplo abaixo isola pares internos de origem e destino nessas portas para revisão manual contra o baseline.

cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p service |
  awk '$3 == 445 || $3 == 3389 || $3 == 5985 || $3 == 135 { print }' |
  sort | uniq -c | sort -rn | head -30

O resultado precisa ser cruzado com a autenticação do Windows para fechar o sentido: conexão para 5985 com logon type 3 da mesma origem no mesmo minuto indica execução remota
via WinRM, enquanto conexão para 3389 com logon type 10 indica sessão interativa remota. Origens que são estações de usuário alcançando servidores por SMB merecem atenção
dupla, porque a função de estação não justifica acesso direto a compartilhamentos administrativos. Cada exceção legítima encontrada, como ferramenta de inventário ou processo
de backup, deve entrar no baseline por segmento para que a próxima execução da caça produza menos ruído e mais sinal.

7. Correlação Rede mais Endpoint para Qualificar

O achado de rede vira evidência quando o endpoint explica a origem e o contexto explica a intenção. O roteiro padrão de qualificação segue quatro perguntas: qual processo
originou a conexão, o destino tem presença histórica no baseline, o volume e o horário são compatíveis com a função do host e existe evento de arquivo ou autenticação que
conecte a comunicação a uma ação observável. Um beacon candidato sem processo correspondente em host com EDR ativo indica host fora de cobertura, e o hunt termina em lacuna de
telemetria para o TH.1 registrar.

Quando a correlação fecha, o resultado é mais forte do que qualquer fonte isolada: processo de Office executando rundll32, conexão periódica de baixa variância para domínio
recém-registrado, escrita de DLL em AppData e autenticação de conta de usuário em host que nunca acessou. Esse encadeamento é o que justifica abertura de caso no IR.x e a
conversão do padrão em detecção permanente. Quando não fecha, o registro do hunt documentando o porquê é igualmente valioso, porque afina o baseline e evita retrabalho.

8. Salvaguardas por Nível de Maturidade

As salvaguardas seguem o padrão de subcontroles do framework e definem o compromisso mínimo de cada patamar de maturidade.

9. Erros Comuns e Pontos de Atenção

O erro mais custoso é ignorar serviços de nuvem legítimos que produzem padrão parecido com beacon. Sincronização de agente de SaaS, telemetria de aplicação e CDN de
atualização falam em intervalos regulares com destinos externos, e caçar sem whitelist construída a partir do baseline gera fila de falsos positivos que esgota o analista. A
contramedida é documentar esses serviços como exceções versionadas, com domínio, User-Agent e intervalo esperado, e revisar a lista a cada ciclo de hunting.

O segundo erro é caçar rede sem baseline por segmento. Sem a referência de TH.2, todo destino parece novo e toda regularidade parece suspeita, porque não existe contexto de
normalidade. O terceiro é depender de amostragem de NetFlow para análise de beaconing, já que amostra destrói a regularidade temporal que é o próprio sinal; fluxo amostrado
serve para volume e topologia, não para ritmo. Por fim, fechar o hunt no momento em que o IP é limpo em reputação é armadilha clássica, porque infraestrutura adversária é
renovada e a reputação acompanha com atraso; o que qualifica o achado é o padrão, não o veredito momentâneo de uma base externa. A integração natural deste controle é com
TH.11 para a ponta de processo, com DAT.2 para a qualidade das fontes e com DET.x para a conversão de padrão confirmado em regra permanente.