Hunting com NetFlow e IPFIX

Nota 13 do capítulo 08 (Técnicas de Hunting por TTPs), cobrindo a fonte de fluxo que escala onde a inspeção de pacote não chega.
Trata NetFlow v5, v9 e IPFIX como telemetria de volume e cadência, com amostragem, timeouts e limitações explícitas.
Estende a nota 12 para links de backbone e filiais, e prepara a leitura por protocolo da nota 14; conecta-se a DAT.2 e TH.12 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

Há pontos da rede onde Zeek e Suricata não cabe nem fiscal nem tecnicamente: backbone de operadora interna, enlaces WAN de filial, switches saturados sem porta de espelhamento e segmentos administrados por terceiros. Nesses pontos, a telemetria de fluxo é a alternativa racional, porque o roteador ou switch já vê o tráfego no caminho de encaminhamento e exporta um resumo de cada conversa: 5-tupla, contadores de pacotes e bytes, instantes de início e fim e flags TCP observadas. O fluxo não carrega conteúdo, mas carrega volume e cadência, e é exatamente isso que sustenta as hipóteses de beaconing, varredura e exfiltração desta nota.

O posicionamento na biblioteca é o de camada de cobertura. A nota 12 entrega profundidade de protocolo onde há sensor de pacote completo; esta nota entrega amplitude e retenção longa onde só há o equipamento de rede. Fluxo é barato de guardar, na ordem de bytes por registro, e permite responder em minutos a perguntas de seis meses atrás, o que o torna a fonte de referência para triagem histórica. A disciplina da nota é escrever hipóteses no nível certo de abstração: fluxo responde quando, com quem e quanto; o como fica para os logs de protocolo e o porquê fica para o endpoint.

2. Como o Dado de Fluxo Nasce: v5, v9 e IPFIX

O equipamento observa os pacotes no caminho de encaminhamento, mantém uma cache de fluxo chaveada pela 5-tupla com direção e expira registros por dois mecanismos: active timeout, que fecha o registro de uma conversa longa após o intervalo configurado, e inactive timeout, que fecha o registro após silêncio. Os valores padrão de fábrica, tipicamente 30 minutos de active e 15 segundos de inactive, servem para contabilidade, não para caça, e serão contestados na seção 3. A exportação via UDP segue para um coletor que grava arquivos rotativos. A tabela abaixo resume as três variantes que o caçador encontra em campo.

Todo registro carrega origem e destino de endereço e porta, protocolo, contadores de pacotes e bytes do lado do iniciador, instantes de início e fim, flags TCP observadas e marcações como ToS. A nuvem mais importante para caça é a direção: o registro é unidirecional e os contadores pertencem ao fluxo no sentido origem para destino, então o tráfego de retorno aparece como registro separado com origem e destino trocados. Identificar quem iniciou a conversa, pelo flag SYN, é o que permite medir upload e download com correção, e é esse detalhe que sustenta a caça de exfiltração da seção 4.

3. Amostragem, Timeouts e Limitações que Definem o Método

A amostragem de pacotes em 1:N é a opção que os operadores de rede oferecem quando o hardware não sustenta o fluxo completo, e ela muda o método de caça de forma radical. Com amostragem, fluxos pequenos desaparecem, porque nenhum pacote daquela conversa foi sorteado; os contadores sobreviventes são multiplicados por N, com erro proporcional; e a cadência de beacons de baixo volume simplesmente some, porque um fluxo por minuto depende de observar todos os pacotes. A regra prática da biblioteca: fluxo amostrado serve para volume, topologia e tendência; caça de cadência exige fluxo completo, ou sFlow em taxa alta, no segmento que realmente interessa.

Os timeouts definem a granularidade temporal do dado e merecem negociação com o time de rede. Com active timeout de 30 minutos, uma sessão de C2 de 25 minutos vira um único registro, e o ritmo interno da sessão fica invisível; em segmentos de servidores e de usuários, active de 60 segundos multiplica o volume de registros, mas devolve a resolução temporal que as hipóteses de beacon exigem. O inactive timeout de 15 segundos é adequado na maioria dos casos. Outras limitações precisam estar no contrato mental do caçador: as flags TCP refletem em geral apenas os primeiros pacotes, então SYN e SYN-ACK são confiáveis e FIN e RST nem sempre; registros são perdidos sob congestionamento do canal de exportação e sob limite de hardware quando um scan storm ou DDoS consome o orçamento de fluxo do equipamento, exatamente nos momentos mais interessantes; e a v5 não vê IPv6 nem VLAN. Monitore contadores de perda no exportador e no coletor como parte da rotina, porque queda silenciosa de cobertura invalida qualquer caça.

4. Caça por Comportamento: Beaconing, Scan e Exfiltração

4.1 Caça de beaconing

O sinal de beacon em fluxo é um par interno e externo presente em quase todas as janelas de tempo do dia, com número pequeno e estável de fluxos por janela e volume de bytes consistente. O método abaixo percorre as 24 horas do dia agregando por par e monta uma matriz de presença; um host com agente de C2 aparece com um a três fluxos em todas as horas, enquanto serviços legítimos de sincronização costumam concentrar-se em janelas específicas. Os comentários do bloco alertam para a conferência do cabeçalho csv, porque a posição das colunas varia entre versões do nfdump.

# Colunas 7, 8 e 3 correspondem a srcip, dstip e fluxos no csv do nfdump 1.6; confirme com o cabecalho impresso
rm -f cadencia.tsv
for h in $(seq -w 0 23); do
  nfdump -R /dados/flows/2025/04/15/nfcapd.20250415${h}00:nfcapd.20250415${h}55 \
    -a -A srcip,dstip -o csv 'not dst net 10.0.0.0/8' |
    awk -F, -v hora="2025-04-15 ${h}:00" '!/^#/ && NF >= 8 { print hora, $7, $8, $3 }' >> cadencia.tsv
done
python3 cadencia.py

# cadencia.py: pares presentes em todas as 24 horas com 1 a 3 fluxos por hora
import collections

presenca = collections.defaultdict(dict)
with open("cadencia.tsv") as f:
    for linha in f:
        hora, origem, destino, fluxos = linha.split()
        presenca[(origem, destino)][hora] = int(fluxos)

for (origem, destino), horas in sorted(presenca.items()):
    if len(horas) == 24 and all(1 <= v <= 3 for v in horas.values()):
        print(f"Candidato beacon: {origem} -> {destino} presente nas 24 horas do dia")

4.2 Caça de varredura

O scan em fluxo aparece como registros com SYN sem ACK, um a dois pacotes e zero bytes úteis, na vertical, muitas portas de um destino, ou na horizontal, muitos destinos de uma porta. O nfdump filtra por flags e agrega por origem e porta destino, produzindo o ranking direto do comportamento. A leitura prioriza origem interna para destino interno, que é movimento lateral em germinação, e origem interna para sub-rede crítica, enquanto tempestades de SYN vindas da internet fazem parte do ruído de fundo e entram na triagem apenas quando atingem alvos expostos.

nfdump -R /dados/flows/2025/04/15 'flags S and not flags A' -a -A srcip,dstport -o csv |
  awk -F, '!/^#/ && $3 > 100 { print $7, $8, $3 }' | sort -k3 -rn | head -20
nfdump -R /dados/flows/2025/04/15 'flags S and not flags A and dst port 445' -s srcip/flows -n 15

4.3 Caça de exfiltração

Exfiltração em fluxo é volume no sentido do iniciador interno para fora, fora do padrão do ativo. A agregação abaixo soma bytes por par e filtra pares acima de 1 GiB na janela de sete dias; a qualificação cruza cada candidato com o baseline por segmento, com janelas de backup e replicação e com a novidade do destino. Sinais de reforço são sessões longas em horário atípico, destinos sem histórico e distribuição fatiada, muitos registros de tamanho parecido em intervalos regulares, típica de ferramenta que divide o upload para escapar de limiares.

nfdump -R /dados/flows/2025/04/08/nfcapd.202504080000:nfcapd.202504142355 \
  -a -A srcip,dstip -o csv 'src net 10.30.0.0/16 and not dst net 10.0.0.0/8' |
  awk -F, '!/^#/ && $3 > 1073741824 { printf "%s %s %.2f GiB\n", $7, $8, $3/1073741824 }' |
  sort -k3 -rn | head -15

5. Ferramentas: nfcapd, nfdump, NfSen e Elastic

A suíte nfcapd e nfdump é o padrão aberto de coleção e análise de fluxo. O nfcapd escuta a exportação e grava arquivos rotativos, tipicamente de cinco minutos, nomeados nfcapd.AAAAMMDDHHMM; o nfdump consulta esses arquivos com filtros, agregações e saída csv para scripts; e o NfSen adiciona interface web e gráficos por perfil, envelhecida mas funcional para triagem rápida. No lado de busca, a pilha Elastic com ECS recebe fluxo por Filebeat ou Logstash e permite caça iterativa com KQL e agregações DSL, além de correlação com os demais logs do SIEM.

No Elastic, os campos ECS de referência são source.ip, destination.ip, source.port, destination.port, network.transport, network.bytes, network.packets, event.duration e network.direction. A agregação abaixo produz o ranking de pares com contagem de fluxos, duração média e bytes totais, e o comentário lembra a paginação por after_key quando o número de pares explode.

GET flow-*/_search
{
  "size": 0,
  "query": { "bool": { "filter": [
    { "term": { "network.direction": "outbound" } },
    { "range": { "@timestamp": { "gte": "now-7d" } } }
  ] } },
  "aggs": {
    "por_par": {
      "composite": {
        "sources": [
          { "origem": { "terms": { "field": "source.ip" } } },
          { "destino": { "terms": { "field": "destination.ip" } } }
        ]
      },
      "aggs": {
        "fluxos": { "value_count": { "field": "flow.id" } },
        "duracao_media": { "avg": { "field": "event.duration" } },
        "bytes_totais": { "sum": { "field": "network.bytes" } }
      }
    }
  }
}

6. Exemplo de Análise de Flow de Ponta a Ponta

O caso da biblioteca: 18 mil estações, fluxo completo sem amostragem no par de borda, Zeek no mesmo TAP para profundidade. A hipótese nasce do capítulo 05, de campanha de ransomware com exfiltração dupla, e pergunta se há uploads anômalos do segmento de servidores de arquivo 10.30.0.0/16. O primeiro comando da seção 4.3 já executa a pergunta em sete dias e devolve 10.30.4.21 com 1,4 GiB para 198.51.100.77, destino sem histórico e sem serviço conhecido. O drill-down abaixo olha os registros individuais do par e revela o padrão que o agregado escondia.

nfdump -r nfcapd.20250412.2300 'src ip 10.30.4.21 and dst ip 198.51.100.77' -o extended
nfdump -R /dados/flows/2025/04/12/nfcapd.202504122200:nfcapd.202504122355 \
  'src ip 10.30.4.21 and dst ip 198.51.100.77' -o csv | head -15

A leitura fecha o caso: 40 registros de aproximadamente 36 MiB cada, um por hora, entre 22h e 6h, com duração curta e SYN iniciado pelo servidor de arquivo, comportamento de ferramenta de exfiltração fatiada e não de backup, porque backup corporativo é contínuo, tem janela documentada e destino conhecido. O cruzamento com Zeek no mesmo TAP mostra server_name de armazenamento de objeto genérico e ja3 de cliente não padrão, o que consolida T1041 e T1048 no relatório. A resposta combinou bloqueio do destino, contenção do servidor, acionamento de IR e coleta de evidência, e o padrão virou detecção agendada: script nfdump semanal com o limiar de bytes por par e alerta no SIEM quando destinos novos ultrapassam 500 MiB sem baseline, com revisão trimestral das exclusões de backup, replicação e sync de nuvem.

7. Erros Comuns e Pontos de Atenção

• Usar fluxo amostrado para caça de cadência; efeito: beacon de baixo volume desaparece na amostragem e a hipótese parece refutada; correção: fluxo completo ou sFlow em taxa alta nos segmentos de interesse.
• Interpretar contadores como bidirecionais; efeito: exfiltração invisível, porque o volume que interessa está no registro iniciado pelo host interno; correção: agregar sempre pela direção do iniciador, com apoio do flag SYN.
• Manter active timeout de fábrica; efeito: sessões de C2 de dezenas de minutos colapsam em um registro e o ritmo interno some; correção: active de 60 segundos nos segmentos que alimentam caça.
• Confundir queda de volume com ambiente saudável; efeito: perda silenciosa de export sob scan storm ou DDoS vira falsa sensação de normalidade; correção: monitorar contadores de perda do exportador e do coletor.
• Caçar sem baseline por segmento; efeito: todo destino novo parece incidente e as exceções reais poluem a fila; correção: exclusões versionadas de backup, replicação e sincronização, com dono e revisão.
• Tratar nfdump 1.6 e 1.7 como intercambiáveis; efeito: filtros e formato de saída mudam entre versões e quebram scripts agendados; correção: fixar versão por ambiente e testar pipelines após upgrade.
• Deixar fluxo sem retenção fria; efeito: pergunta de seis meses atrás fica sem resposta quando o incidente aparece; correção: retenção de 12 a 24 meses em compressão, viável pelo tamanho por registro.

8. Integração com o Restante da Biblioteca

A arquitetura em camadas da nota 04 do capítulo 02 coloca o fluxo nas camadas morna e fria, e esta nota mostra por quê: é a fonte que sustenta perguntas históricas baratas enquanto os logs de protocolo vivem na quente. Com a nota 12, o fluxo forma o par profundidade e amplitude, e testar a mesma hipótese nas duas camadas é medida concreta de cobertura para o DAT.2 e para o TH.12 do capítulo 15. Os baselines por segmento que a caça exige vêm do TH.2, a cadência de execução segue o PEAK do capítulo 07, e as métricas de tempo até detecção e de cobertura alimentam o capítulo 11.

A gramática de abstração é o aprendizado que fecha a nota com valor reutilizável: fluxo responde quando, com quem e quanto; logs de protocolo respondem como; endpoint responde porquê. Escrever a hipótese no nível certo evita gastar sensor caro onde fluxo barato resolve, e o resíduo de incerteza que resta após a caça de fluxo é precisamente a especificação do próximo sensor a implantar. É assim que a telemetria de rede de um ambiente cresce por demanda de hipótese, e não por catálogo de funcionalidades.