Cibersegurança e segurança da informação

Análise de DNS Malicioso: Tunneling, DGA e Anomalias de Domínio

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre análise de DNS malicioso na área de Monitorização de Segurança de Rede

Resposta rápida

A análise de DNS malicioso é realizada mapeando o Flow, tempos, protocolos, DNS/TLS/HTTP e o contexto do ativo. Um único Packet ou conexão é uma evidência parcial, portanto, constrói-se uma sequência e verifica-se com fontes adicionais.

O tráfego de rede oferece uma perspetiva que não depende apenas do endpoint. Permite identificar quem comunicou com quem, qual protocolo, em que ordem e com que volume, mas requer uma compreensão dos limites da visibilidade e da encriptação. Este artigo foca-se na análise de DNS malicioso e destina-se a analistas de SOC e analistas de rede. O objetivo é fornecer um método de trabalho que possa ser aplicado em prática, numa entrevista profissional e num ambiente de trabalho, sem se contentar com uma definição de dicionário.

O principal desafio é que os dados estão quase sempre incompletos. O query name, response code, TTL podem indicar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Portanto, construiremos o teste em torno de uma questão de investigação, evidências necessárias e um critério claro para a conclusão.

O cenário prático no artigo é: Análise de um Dataset simulado de Queries. Todos os exemplos são dados de laboratório ou descrições de processos. Quando se trata de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização explícita, Scope definido e capacidade de interromper o teste.

DNS como Superfície de Investigação

A investigação da análise de DNS malicioso começa com a formulação de uma Hipótese: qual comportamento explica a descoberta e quais evidências a confirmarão ou refutarão. Em seguida, estende-se a janela de tempo, verifica-se as entidades e procura-se uma sequência antes e depois do evento.

Uma boa correlação combina pelo menos dois tipos de informação de query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, resolver context. Para cada descoberta, indica-se o que prova, o que não prova e qual é o próximo passo. Se os dados não forem suficientes, marca-se como Unknown e não se transforma a ausência de evidência em evidência de ausência.

Sinais de Tunneling

O tópico 'Sinais de Tunneling' é uma parte central do trabalho na análise de DNS malicioso. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas evitam o uso automático de uma ferramenta sem a compreensão do objetivo.

Na prática, registe o query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Sinais de DGA

O tópico 'Sinais de DGA' é uma parte central do trabalho na análise de DNS malicioso. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas evitam o uso automático de uma ferramenta sem a compreensão do objetivo.

Linha de Base e Anomalias

O tópico 'Linha de Base e Anomalias' é uma parte central do trabalho na análise de DNS malicioso. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas evitam o uso automático de uma ferramenta sem a compreensão do objetivo.

Verificação com Endpoint e Threat Intel

Para entender a diferença no contexto da análise de DNS malicioso, é importante comparar objetivos e não apenas ferramentas. Uma opção oferece amplitude ou velocidade, e outra oferece verificação profunda ou contexto. A escolha certa depende da pergunta: é necessária descoberta, investigação, prova de impacto, contenção ou relatório.

Uma tabela de comparação profissional deve incluir pelo menos: tipo de entrada, nível de certeza, custo operacional, impacto potencial, limitações e continuação necessária. Em caso de dúvida, usa-se a abordagem menos invasiva e adiciona-se uma fonte complementar em vez de tirar uma conclusão muito ampla.

Pontos de Verificação Únicos

Neste tópico, é recomendável construir antecipadamente um mapa focado nas evidências. Os principais pontos de verificação são: query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, resolver context. A lista não é um Checklist automático; cada item é escolhido porque pode ligar uma entidade, uma ação e um tempo, ou explicar um comportamento legítimo.

query name: Defina o valor esperado, o que seria considerado anómalo e qual fonte adicional verificaria a descoberta.
response code: Defina o valor esperado, o que seria considerado anómalo e qual fonte adicional verificaria a descoberta.
TTL: Defina o valor esperado, o que seria considerado anómalo e qual fonte adicional verificaria a descoberta.
subdomain entropy: Defina o valor esperado, o que seria considerado anómalo e qual fonte adicional verificaria a descoberta.
NXDOMAIN ratio: Defina o valor esperado, o que seria considerado anómalo e qual fonte adicional verificaria a descoberta.
resolver context: Defina o valor esperado, o que seria considerado anómalo e qual fonte adicional verificaria a descoberta.

Quando um dos focos não está disponível, deve-se documentar a lacuna e escolher uma alternativa. Por exemplo, se o Process identifier não for estável, pode-se usar tempo, Host, User e Parent; se o Payload estiver encriptado, usa-se Metadata, volume, frequência e TLS/DNS context.

Processo de Trabalho Recomendado

Defina o Scope e uma questão de trabalho sobre a análise de DNS malicioso.
Registe as fontes de dados e evidências necessárias: query name, response code, TTL, subdomain entropy.
Crie uma linha de base curta de comportamento normal ou resultado esperado.
Realize o teste mínimo num ambiente de laboratório e guarde tempo, entrada e saída.
Construa uma Timeline ou tabela de comparação e separe facto de interpretação.
Faça um Pivot para uma fonte adicional para verificar ou refutar a explicação inicial.
Resuma a decisão, limitações, ação recomendada e critério de Retest.

Cenário Prático

O cenário escolhido é a análise de um Dataset simulado de Queries. O objetivo do exercício não é provar a capacidade de ataque, mas sim praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, definem-se dados simulados, janela de tempo e resultado esperado.

Ao final do exercício, deve-se apresentar um produto que outro analista ou testador possa criticar: uma captura de ecrã ou Export da evidência, uma Timeline curta, uma hipótese inicial, uma evidência de verificação, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Etapa	O que se faz	Produto
Preparação	Defina Scope, tempo e objetivo. Registe quais campos ou evidências de query name, response code, TTL são esperados.	Plano de teste curto
Criação de Dados	Realize uma operação segura e simulada relacionada com a análise de DNS malicioso, sem informações reais ou impacto num sistema de produção.	Evento/Request/Flow controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique o Time zone, identificadores e integridade.	Duas evidências ligadas
Análise	Escreva o que cada evidência prova, o que não prova e qual é a possível explicação legítima.	Conclusão intermédia
Conclusão	Escolha fechar, escalar, Finding ou Tuning; adicione uma recomendação e Retest.	Produto documentado

Checklist Prático

Verifique e documente: os cinco componentes do Flow.
Verifique e documente: hora de início, duração e volume.
Verifique e documente: DNS name e metadados TLS.
Verifique e documente: método HTTP, host e URI quando visíveis.
Verifique e documente: flags TCP e stream.
Verifique e documente: ligação ao Host e ao Process.
Indique Time zone, versão da ferramenta e hora de recolha.
Guarde os dados brutos antes da filtragem ou modificação.
Escreva o que a descoberta prova e o que ainda é desconhecido.
Defina proprietário e ação de acompanhamento com prazo.

Erros Comuns

Confundir Capture Filter com Display Filter.
Inferir conteúdo quando o tráfego está encriptado.
Analisar IP sem contexto DNS/TLS.
Ignorar NAT ou Proxy.
Focar-se num único Packet.
Não guardar o Capture original.

Resumo e CTA

Análise de DNS Malicioso: Tunneling, DGA e Anomalias de Domínio é um tópico que conecta conhecimento técnico à disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, mantenha o contexto e o tempo, e escolha uma ação que possa ser justificada e verificada novamente.

No percurso Cybersecurity & AI da HPI, estes princípios são praticados usando sistemas, logs e laboratórios. Uma continuação natural é passar para os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portfólio profissional.

Perguntas frequentes

A análise de DNS malicioso sozinha prova um ataque ou vulnerabilidade?

Não. Fornece um sinal ou uma descoberta que precisa de contexto, validação e uma fonte adicional. Uma conclusão profissional baseia-se numa sequência de evidências e na conformidade com o comportamento esperado.

O que fazer quando faltam alguns dados?

Documenta-se a falta, verifica-se uma fonte alternativa e reduz-se o nível de confiança. Não se devem preencher campos com suposições ou apresentar Unknown como normal.

Quanto tempo as evidências devem ser mantidas?

O tempo depende da política, regulamentação, custo e tipo de evento. É importante definir previamente Retention, Legal hold e a capacidade de exportar evidências num formato verificável.

Como praticar sem comprometer um sistema real?

Utilizam-se máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, definem-se Scope, Stop conditions e backup antes de iniciar o trabalho.