DNS Forensics no Wireshark: anomalias e tunneling

DNS forensics no Wireshark começa pela comparação entre comportamentos, não por uma lista de domínios suspeitos. Consultas com nomes extensos, muitas respostas NXDOMAIN e registros TXT podem acompanhar um canal de comunicação clandestino. Também aparecem em autenticação de e-mail, descoberta de serviços, CDNs e aplicações legítimas. A investigação precisa relacionar quem perguntou, o que perguntou, quando perguntou e qual resposta recebeu.

Neste laboratório original da NetCatTest, construímos 105 transações DNS e 210 pacotes. O conjunto combina navegação simulada, nomes de CDN com aparência aleatória, consultas TXT periódicas e erros de resolução. A leitura foi validada no Wireshark 4.6.9 instalado no computador. Os endereços pertencem a faixas de documentação e os nomes usam .test. Nenhuma interface pessoal foi capturada e nenhum dado real foi transmitido.

O cenário: três clientes, três padrões de resolução

O arquivo 19-dns-forensics.pcap apresenta o resolvedor fictício 192.0.2.53. O cliente 192.0.2.10 consulta portal, API e CDN. O endereço 192.0.2.11 funciona como controle: inclui oito nomes de CDN com rótulos hexadecimais e um TXT legítimo de SPF. O terceiro cliente, 192.0.2.99, produz 24 consultas TXT sob telemetria.aurora.test.

Os rótulos desse terceiro cliente têm 52 caracteres base32. Seu conteúdo deriva de hashes de mensagens públicas geradas para a experiência. Não contém arquivo roubado, credencial ou informação do computador. A forma do tráfego imita um transporte em pequenos blocos; a procedência é totalmente sintética e conhecida.

Primeiro filtro: separar consulta, resposta e tipo

Abra o PCAP pelo menu de arquivos. Use dns para a visão geral. A lista mostra as 210 mensagens, mas isso não significa 210 resoluções distintas: cada transação tem consulta e resposta. Para analisar comportamento do cliente sem duplicar a contagem, filtre somente as consultas.

dns.flags.response == 0
dns.flags.response == 0 && dns.qry.type == 16
dns.flags.response == 0 && ip.src == 192.0.2.99
dns.flags.rcode == 3

O segundo filtro retorna 25 consultas TXT: 24 da telemetria e uma do controle SPF. O último retorna 12 respostas NXDOMAIN. Esses números são referências de validação do arquivo, não limites universais de detecção. Se uma reprodução apresentar outra contagem, verifique o nome do arquivo, o filtro e a preferência de reassembly antes de comparar conclusões.

Print do Wireshark 4.6.9. O tráfego é sintético; o filtro permite comparar o grupo de telemetria com um TXT legítimo.

Ler o nome como uma estrutura de transporte

Selecione o frame 137, primeira consulta do grupo periódico. Expanda DNS e a seção Queries. O nome reúne um bloco base32, um contador de três dígitos e o domínio fixo. Observe separadamente cada rótulo. O tamanho total do nome e o tamanho de um rótulo são medidas diferentes; misturá-las produz alertas inconsistentes.

Uma sequência de nomes únicos pode impedir a reutilização de respostas em cache. No laboratório, todos os blocos diferem, embora o domínio de destino permaneça constante. Isso aumenta a relação entre consultas novas e consultas totais. Em produção, uma CDN pode produzir efeito semelhante. O controle com oito rótulos hexadecimais foi incluído justamente para impedir a conclusão automática de que qualquer nome aleatório representa tunneling.

A RFC 1035 descreve o enquadramento DNS, os rótulos e os registros. Essa estrutura ajuda a distinguir campos do protocolo de escolhas feitas pela aplicação. O contador usado aqui é uma característica do nosso gerador e não um requisito DNS.

Entropia, repetição e intervalo precisam aparecer juntos

Uma boa tabela de investigação pode incluir cliente, domínio registrável, tipo, comprimento médio do primeiro rótulo, quantidade de nomes únicos, proporção de erros e intervalo entre consultas. Examine também mediana e dispersão: uma média isolada pode esconder uma explosão curta de consultas.

No conjunto periódico, o intervalo do gerador entre consultas inclui uma pequena variação deliberada. As respostas também consomem tempo. Portanto, medir apenas o parâmetro configurado no gerador não equivale a medir a distância entre timestamps das consultas no PCAP. Use os pacotes como evidência e o código como explicação da causa conhecida.

tshark -n -r 19-dns-forensics.pcap -Y "dns.flags.response == 0" -T fields -e frame.time_relative -e ip.src -e dns.qry.name -e dns.qry.type
tshark -n -r 19-dns-forensics.pcap -Y "dns.flags.rcode == 3" -T fields -e frame.number -e ip.dst -e dns.qry.name

Esses comandos apenas leem o arquivo local. A opção -n evita resolução de nomes durante a análise. O resultado pode ser levado a uma planilha ou script para calcular métricas, sem gerar novas consultas contra os nomes do laboratório.

Medidas obtidas no PCAP publicado

A estimativa de entropia usa a frequência dos caracteres em cada primeiro rótulo: H = -Σ p(c) log2 p(c). A tabela depois calcula a média entre os rótulos do cliente. Ela não mede a informação do payload decodificado e não fornece um limiar universal. O controle de CDN também tem 100% de nomes únicos, tornando visível por que unicidade sozinha não distingue a finalidade.

A mediana do intervalo entre consultas do cliente periódico é 0,933727 segundo no arquivo. Esse valor inclui o espaçamento e as respostas inseridas pelo gerador. É uma medida do conjunto sintético, não a periodicidade de um malware real. O pacote inclui as métricas e o procedimento para recalculá-las.

NXDOMAIN: sinal útil, interpretação contextual

As respostas NXDOMAIN começam no frame 186. O frame 185 é a consulta correspondente. A diferença parece pequena, mas importa em relatórios que precisam apontar exatamente onde um erro foi observado. A mensagem da consulta não contém o código de erro da resposta futura.

Erros concentrados podem acompanhar geração de domínios, configurações quebradas, sufixos de busca ou descoberta de serviços. No nosso PCAP, as consultas problemáticas vêm do cliente de navegação, enquanto a telemetria recebe respostas TXT positivas. Assim, a presença de NXDOMAIN na captura inteira não comprova que o grupo de telemetria está falhando. Agrupar tudo por arquivo apagaria essa distinção.

As respostas NXDOMAIN pertencem a um controle separado. Elas não devem ser atribuídas automaticamente ao cliente que produziu as consultas TXT.

EDNS e tamanho: não confundir anúncio com vazamento

As consultas incluem OPT com anúncio de 1.232 bytes. A presença desse valor não informa que a consulta carregou 1.232 bytes nem que o cliente transferiu essa quantidade. É necessário medir o comprimento efetivo do pacote e o tamanho de cada campo.

A RFC 6891 explica as extensões EDNS e o papel do pseudo-registro OPT. Em uma investigação, o ganho prático é separar capacidade anunciada, conteúdo realmente observado e resposta recebida. Volumes de dados devem ser calculados a partir dos bytes capturados, evitando estimativas infladas.

Como formular uma hipótese de tunneling defensável

Uma hipótese ganha força quando vários elementos convergem: nomes únicos, estrutura estável de fragmentos, repetição sob o mesmo domínio, cadência consistente e respostas que parecem confirmar os blocos. Mesmo assim, é preciso vincular a atividade a um processo, uma aplicação ou um experimento conhecido.

Neste caso, a hipótese pode ser confirmada apenas no sentido do laboratório: o gerador construiu intencionalmente um canal simulado. Na rede de uma empresa, a mesma aparência exigiria contexto adicional, como logs do resolvedor, inventário do endpoint e justificativa da aplicação. Não se deve declarar exfiltração de informação sem identificar quais dados saíram e por qual mecanismo.

Limites da captura e próximos dados necessários

Um PCAP visto do cliente e outro visto do resolvedor podem apresentar conjuntos diferentes. Cache local, retransmissões, retransmissão para outro servidor e captura unilateral alteram as métricas. Declare onde a observação aconteceu. O nosso arquivo é offline e não corresponde a uma interface física, portanto não permite medir perda de um enlace real.

DNS criptografado também muda o alcance da inspeção. Se a consulta estiver dentro de TLS ou HTTPS, nomes e respostas podem não estar visíveis sem material de sessão autorizado. A ausência de consultas DNS em claro não demonstra ausência de resolução. Na série, o laboratório de TLS explica essa diferença sem recorrer a interceptação de terceiros.

Um exercício de classificação com controle cego

Antes de consultar o manifesto, escolha os clientes 192.0.2.11 e 192.0.2.99 e descreva apenas diferenças observáveis. Registre tipos de consulta, repetição de domínio, tamanho dos rótulos e estrutura das respostas. Em seguida, confira a causa de cada grupo no gerador. Esse procedimento mostra quais inferências vieram dos pacotes e quais só ficaram possíveis porque a finalidade do cenário foi revelada.

O cliente de controle possui nomes com aparência aleatória e um TXT legítimo. O grupo periódico tem uma estrutura estável de blocos e confirmações. Se a regra inicial marcou os dois grupos igualmente, ela pode estar usando um sinal muito amplo. Refine a hipótese com contexto, sem remover do relatório os exemplos que contradizem a regra.

Uma avaliação profissional pode medir precisão sobre casos rotulados, mas os 105 exemplos deste arquivo não representam a diversidade de uma empresa. Use o conjunto para conferir funcionamento dos filtros e raciocínio; não publique uma taxa de eficácia comercial a partir dele. O dado que falta para generalização é uma base representativa, com aplicações legítimas e condições de captura variadas.

Checklist para uma conclusão reproduzível

1. Preserve o PCAP original e registre seu SHA-256.
2. Separe consultas de respostas e conte transações, não apenas pacotes.
3. Agrupe por cliente e domínio antes de calcular proporções.
4. Compare comprimento, unicidade e cadência com um controle legítimo.
5. Documente frames, filtros e hipóteses alternativas.
6. Relacione o tráfego ao processo responsável antes de classificar um incidente.

Baixe o pacote de laboratórios da série para reproduzir as contagens. A referência de filtros DNS do Wireshark ajuda a conferir os nomes dos campos na versão instalada. A conclusão deste exercício é um método de investigação: sinais combinados e evidência contextual são mais úteis que um rótulo isolado de “DNS suspeito”.

Escrito por

Daniel Felipe

Daniel Felipe é criador do NetCatTest e produz conteúdos sobre cibersegurança, privacidade digital, OSINT, laboratórios autorizados e ferramentas para estudo técnico responsável.

Perfil e publicações [email protected] YouTube GitHub LinkedIn