DNS Passivo e Histórico de Resolução

Primeira nota da subpasta de Análise de Infraestrutura do capítulo 03: o DNS passivo transforma cada resolução observada na internet em um registro histórico consultável.
É a base do pivoting entre domínios, endereços e servidores de nome, e da identificação de padrões como fast flux, DGA e sinkhole.
Dialoga com as notas de WHOIS e RDAP e de ASN e BGP da mesma subpasta, e alimenta o pivoting de infraestrutura do Diamond Model no capítulo 04.

1. Contexto e Posicionamento na Biblioteca

A infraestrutura do adversário conversa com o mundo antes de qualquer exploit ser disparado, e a maior parte dessa conversa passa pelo DNS. O DNS passivo captura essa conversa: em vez de perguntar ao servidor autoritativo o que ele responde hoje, como faz a enumeração ativa, ele observa as respostas que realmente circularam na internet e as guarda com data. O resultado é uma linha do tempo de qual domínio resolveu para qual endereço, quando, com qual TTL e por quanto tempo, exatamente o material de que a análise de infraestrutura precisa para reconstruir e antecipar operações.

Na biblioteca, esta nota abre a subpasta de análise de infraestrutura e estabelece o método de pivoting que as notas seguintes ampliam para registro de domínio e roteamento. Ela é insumo direto da nota de IOC, porque o histórico de resolução valida e contextualiza indicadores de rede, e do comparativo de indicadores, porque o artefato de resolução está no meio da pirâmide de dor. O domínio que hoje é um IOC anônimo vira, com DNS passivo, um conjunto de relacionamentos consultáveis.

O valor do histórico fica evidente no movimento mais comum do adversário: derrubar a própria infraestrutura. Quando o domínio de C2 é suspenso pelo registrador, a resolução atual morre, mas a linha do tempo permanece, e é ela que permite descobrir com quem a infraestrutura conviveu, que endereços ela usou antes e que padrão de rotação adotou. Investigar apenas o presente do DNS é investigar o que o adversário decidiu deixar visível hoje.

2. O Conceito de DNS Passivo

DNS passivo é a observação passiva de respostas DNS reais, coletadas por sensores instalados em resolvedores de grande escala, agregadas em bases de dados indexadas por registro e por tempo. Cada observação guarda o nome consultado, o tipo de registro, o valor retornado, o TTL informado e o carimbo de tempo, com contadores de primeira e última observação. A diferença conceitual para o DNS ativo é decisiva: o ativo pergunta o que o servidor diz agora e depende do adversário para responder; o passivo guarda o que a internet viu no passado, inclusive respostas que o servidor atual jamais devolveria de novo.

O conceito tem origem na comunidade de segurança de meados dos anos 2000, com a proposta de compartilhar observações de resolvedores para enxergar infraestrutura além do próprio perímetro, e hoje existe formato padronizado de intercâmbio para bases de pDNS, o que facilita integração entre fontes. O conjunto típico cobre os registros A e AAAA, que dominam a análise, mas os registros NS, MX, CNAME e TXT frequentemente são os mais reveladores, porque descrevem a arquitetura da infraestrutura e sobrevivem à troca dos endereços de frente.

A unidade de agregação usual é o RRset, o conjunto de respostas do mesmo nome e tipo devolvidas em uma resolução, com o mesmo TTL. Trabalhar por RRset preserva a semântica do que o servidor autoritativo realmente anunciou e evita a ilusão de rotinação que surge quando cada endereço de um conjunto é contado como evento separado. Para o analista, a consequência prática é que dezenas de endereços em um único RRset de CDN são um fato benigno, enquanto três RRsets de um único endereço em uma semana são o fast flux que a seção de padrões descreve.

3. Fontes de Dados e a Fonte Própria

A fonte própria é a única que responde uma pergunta que nenhuma base comercial responde: o que os hosts desta organização consultaram, incluindo as consultas que falharam. O dns.log do Zeek expõe os campos essenciais para essa construção.

# Campos mais úteis do dns.log do Zeek para a base interna de pDNS
id.orig_h     # host que fez a pergunta
query         # nome consultado
qtype_name    # tipo de registro (A, AAAA, NS, TXT)
answers       # valores retornados
TTLs          # tempos de vida informados
rcode_name    # NOERROR, NXDOMAIN, SERVFAIL

A agregação mínima dessa telemetria produz a tabela interna de pDNS: domínio, endereço, primeira e última observação, contagem de ocorrências e lista de hosts que consultaram. Com retenção adequada, essa tabela vale mais que qualquer assinatura pronta, porque descreve o comportamento real da organização contra a infraestrutura de todos os adversários que a tocaram.

A construção da fonte própria segue quatro passos simples de pipeline:

• Coleta: habilitar captura de consultas no resolvedor corporativo ou instalar Zeek no ponto de inspeção, com relógio sincronizado por NTP.
• Normalização: padronizar nomes em minúsculas, remover ponto final inconsistente e separar o tipo de registro em campo próprio.
• Agregação: consolidar por par de domínio e endereço, mantendo primeira e última observação e o conjunto de hosts que consultaram.
• Retenção: guardar sucesso com prazo maior e falha de resolução com prazo próprio, porque o NXDOMAIN é matéria-prima da detecção de DGA.

4. Padrões Investigados com DNS Passivo

O fast flux merece leitura cuidadosa, porque a rotação de endereços também é comportamento de CDN legítima. A distinção fica nos detalhes: a CDN rotaciona dentro de um conjunto grande e estável de ASNs conhecidos, com organização consistente no registro, enquanto o fast flux salta entre redes de hospedagem barata com pouca coerência de operadora e certificados trocados com frequência. O fast flux de dois níveis, em que os próprios servidores de nome também rotacionam, é sinal ainda mais forte, porque multiplica o custo de derrubada para o defensor e é raro fora de operações criminosas.

Os domínios gerados por algoritmo aparecem no pDNS como assinatura de tempo: períodos de tentativa com falha quase total, um sucesso curto e depois novo ciclo. Essa janela de sucesso, cruzada com a resolução real do domínio gerado, é o que permite antecipar a próxima rodada e preparar bloqueio, e é também o que explica por que a retenção de NXDOMAIN nas fontes comerciais e internas é um tema estratégico, e não um detalhe técnico.

O abuso de DNS dinâmico merece regra própria, porque o custo de registro é zero e a operação sobrevive à derrubada do endereço. Subdomínios sob provedores de DDNS gratuito, como os domínios de serviços conhecidos de DDNS, hospedam painéis de RAT e de stealer com frequência desproporcional ao volume benigno que compartilham a mesma zona. A resposta operacional é dupla: monitorar consultas internas a essas zonas, que quase sempre têm uso legítimo mínimo em ambiente corporativo, e tratar a co-hospedagem de subdomínio como sinal fraco que precisa de confirmação por outro pivô, porque a mesma zona abriga impressoras domésticas de funcionários e servidores de jogo ao lado do C2.

5. Pivoting por Registro

O pivoting é o uso do relacionamento revelado por um registro para descobrir mais infraestrutura do mesmo operador. As direções clássicas partem do domínio suspeito para o endereço histórico, do endereço para os domínios co-hospedados na mesma janela de tempo, do servidor de nome para os demais domínios que o usam e do registro MX para a mesma máquina de entrega de e-mail reutilizada em campanhas distintas. Cada direção tem custo e risco de ruído próprios, e a regra de qualidade é sempre cruzar a janela temporal: co-hospedagem simultânea na mesma semana é pista forte, co-hospedagem em anos diferentes é coincidência estatística.

A leitura do histórico acima conta uma história coerente de infraestrutura descartável: três endereços distintos em uma semana com TTL desabando para sessenta segundos, seguidos de servidores de nome sob provedor de DNS dinâmico. O pivoting seguinte é direto: consultar no pDNS que outros domínios apontaram para os mesmos endereços na mesma janela e que outros nomes usam o mesmo servidor de nome, e verificar no WHOIS a idade de cada novo domínio descoberto.

Cada direção de pivô tem armadilha conhecida e vale fixar antes da análise:

• Pivô por endereço: exigir sobreposição temporal estrita e confirmar por SNI ou certificado quando a rede for de hospedagem compartilhada ou CDN.
• Pivô por servidor de nome: forte para infraestrutura descartável, fraco para provedores grandes, onde milhares de domínios benignos compartilham o mesmo NS.
• Pivô por MX: revela reuso da máquina de entrega de e-mail entre campanhas, e costuma sobreviver à troca do site de phishing.
• Pivô por TXT e SPF: o registro de política de e-mail cita endereços e inclusões que sobrevivem a redesign, e quase nunca é verificado pelo adversário apressado.

Todo pivô executado gera um produto registrável, e não apenas uma impressão: o conjunto de domínios co-hospedados com a janela que os une, o grafo de nomes sob o mesmo servidor de nome e a lista de idades verificadas no registro de domínio. Registrar esses produtos com o caminho de pivots que os produziu é o que permite a outro analista reproduzir, auditar e estender a análise semanas depois, quando o domínio original já não resolve.

6. Exemplo de Triagem Completa

DOM="portal-atualizacoes.com"
dig +short "$DOM" A
dig +short "$DOM" NS
dig +short "$DOM" MX
# Historico consultado na base de pDNS comercial:
# 23 enderecos distintos em 40 dias, TTL medio de 60 segundos
# Co-hospedados na janela: 14 dominios, 12 registrados no mesmo mes

DnsEvents
| where TimeGenerated > ago(30d)
| where Name =~ "portal-atualizacoes.com" or IPAddresses has "203.0.113.44"
| summarize consultas = count(), clientes = dcount(ClientIP),
            primeiro = min(TimeGenerated), ultimo = max(TimeGenerated)
    by ClientIP, Name

A triagem completa encadeia três camadas. A resolução atual mostra o estado de hoje, que pode já estar derrubado; o histórico de pDNS mostra o padrão de vida da infraestrutura, que sobrevive à derrubada; e a consulta interna mostra se e quando a organização interagiu com ela, transformando a análise externa em investigação de exposição real. O resultado da camada interna define a gravidade: domínio conhecido sem interação interna é item de bloqueio preventivo, domínio com consultas de poucos hosts é caso de contenção, e domínio com consultas persistentes de muitos hosts é suspeita de campanha em curso.

A mesma telemetria interna alimenta a detecção de DGA sem qualquer indicador prévio, com uma consulta que mede rajadas de falha de resolução por host.

DnsEvents
| where TimeGenerated > ago(1d)
| where ResultCode =~ "NXDOMAIN"
| summarize falhas = count(), nomes = dcount(Name)
    by ClientIP, bin(TimeGenerated, 10m)
| where falhas > 50 and nomes > 20
| project TimeGenerated, ClientIP, falhas, nomes

Um host que acumula dezenas de nomes inexistentes em janela de minutos está, na prática, perguntando por domínios que ninguém registrou, e esse é o retrato operacional de um algoritmo de geração de domínios. A consulta não conhece o adversário, não depende de feed e sobrevive à troca completa da infraestrutura dele, que é exatamente o perfil de detecção que o topo da pirâmide de dor recomenda.

7. Limitações e Erros Comuns

• Viés da rede de sensores: a base comercial cobre o que os sensores veem, e não o que a internet resolve; ausência de registro não é prova de ausência de resolução, e a comparação entre fontes é parte do método.
• Caching distorce a linha do tempo: resolvedores guardam respostas pelo TTL, então observações são amostras, e a interpretação de primeira e última observação precisa considerar esse recorte.
• Co-hospedagem enganosa: CDN, nuvem e hospedagem compartilhada colocam domínios benignos no mesmo endereço do adversário; o pivoting por endereço exige janela temporal estreita e confirmação por SNI ou certificado.
• Timestamps com significados diferentes: uma fonte registra a primeira vez que o sensor viu, outra registra o primeiro dia de resolução confirmada; misturar as duas sem ler a documentação produz datas falsas de criação.
• Retenção variável de NXDOMAIN: a falha de resolução é a metade mais valiosa do DNS passivo para DGA, e nem toda fonte a guarda, nem pelo mesmo prazo.
• Uso interno sem cuidado com privacidade: a base interna de pDNS contém consultas por usuário e por host, e o acesso deve seguir a mesma governança de qualquer telemetria sensível do ambiente.
• Pivô em cadeia sem controle: cada rodada de pivô multiplica ruído, e sem registro do caminho percorrido a análise se perde; o grafo de pivots com motivo de cada salto é a defesa padrão.

8. Integração com o Restante da Biblioteca

O DNS passivo é o tecido conjuntivo da subpasta de infraestrutura: as datas de registro consultadas no WHOIS e RDAP dão a idade dos domínios descobertos no pivoting, e a leitura de ASN e BGP explica em que redes o histórico de resolução viveu. No capítulo 04, o Diamond Model usa cada resolução como aresta entre infraestrutura e vítima, e o pivoting por registro é o movimento canônico entre vértices. No capítulo 25, a reconstituição de campanhas parte da linha do tempo de resolução para datar cada fase da operação.

A vantagem competitiva mais subestimada deste tema é a diferença entre novo para todos e novo para nós. Quando um domínio tem meses de histórico em bases comerciais e não aparece uma única vez na base interna, ele é infraestrutura nova usada por outros e ainda não contra a organização, o que justifica bloqueio preventivo barato; quando o histórico comercial é curto e a base interna já registra consultas, a campanha começou aqui, e a prioridade muda de escala. Somada a isso, a retenção interna de falhas de resolução, os NXDOMAIN dos hosts da organização, entrega a detecção precoce de DGA que nenhuma fonte externa substitui, porque o domínio gerado que o malware tentou resolver só existe, como evidência, na telemetria interna.

As conexões operacionais diretas com o restante da biblioteca:

• Capítulo 02: DNS passivo comercial e telemetria de resolvedor são fontes de coleta catalogadas, com custo e cobertura próprios.
• Capítulo 04: cada resolução é aresta do Diamond Model, e o pivô por registro é o movimento entre vértices de infraestrutura.
• Capítulo 08: padrões de fast flux e DGA viram hipóteses de hunting com as consultas desta nota.
• Seção 15: DAT cobre a coleta do dns.log, e o AUT.3 versiona as regras de detecção derivadas da análise.