WHOIS, RDAP e Registro de Domínios

Nota da seção "06 - Análise de Infraestrutura" do capítulo 03 (Indicadores de Ameaças: IOC, IOA, IOB, IOE).
Trata o registro de domínio como fonte de inteligência: WHOIS clássico, transição para RDAP, campos úteis, privacidade e redaction, idade do domínio e padrões de registro de campanha.
Dialoga com o DNS Passivo da mesma seção, com a nota de Pivoting e Correlação e com a Pirâmide de Dor do capítulo 04.

1. Contexto e Posicionamento na Biblioteca

O domínio é a face pública da infraestrutura do adversário, e o registro é a formalidade que o cria: alguém, em algum momento, pagou por aquele nome em algum registrador. O WHOIS e seu sucessor, o RDAP (Registration Data Access Protocol), expõem essa formalidade e transformam cada domínio em um documento com datas, estado e responsáveis. Para o analista de CTI, esse documento responde perguntas que nenhuma resolução de DNS responde: quando a infraestrutura nasceu, em qual mercado de registradores ela foi comprada, em que estado operacional ela está hoje e qual é o canal formal de derrubada. O DNS passivo mostra a vida da resolução; o registro mostra o nascimento e a identidade contratual do nome.

Na biblioteca, esta nota é o segundo passo da subpasta de análise de infraestrutura. As datas consultadas aqui são insumo direto da nota de Pivoting e Correlação de Infraestrutura, onde a idade entra como fator de confiança dos clusters, e do pipeline de enriquecimento do CTI.5 na seção 15. O tema dialoga ainda com a nota de Domínios, Subdomínios e Agrupamento de Ativos, porque o padrão de registro em lote é um dos agrupamentos mais produtivos na análise de campanhas, e com a nota de EASM do capítulo 04, porque o monitor de marca que detecta typosquat consulta exatamente a fonte ensinada aqui.

2. WHOIS Clássico e a Transição para RDAP

O WHOIS é um protocolo textual sobre TCP na porta 43, herdado dos primórdios da internet, no qual o cliente envia o nome consultado e o servidor responde com texto livre. Essa liberdade de formato é também a sua fraqueza operacional: cada registrador e cada ccTLD escolhe seus rótulos, suas seções e sua linguagem, o que torna o parsing automático um trabalho de manutenção permanente. O RDAP substitui o protocolo por requisições HTTPS com resposta em JSON padronizado, definido no conjunto de RFCs 7480 a 7484, com códigos de erro HTTP previsíveis, estrutura de entidades e eventos uniformes e mecanismo de descoberta de servidor por meio do bootstrap da IANA e do redirecionador público rdap.org.

A transição não é cosmética, e sim um reordenamento do acesso aos dados. Para os gTLDs, a ICANN tornou o RDAP obrigatório aos registradores desde 2019 e conduz a desativação gradual do serviço WHOIS nesses registros, enquanto os ccTLDs avançam em ritmos desiguais: o registro.br oferece RDAP próprio, outros ccTLDs ainda operam apenas na porta 43. A consequência prática para a equipe é uma política simples: automação nova nasce em RDAP; WHOIS fica para ccTLDs sem RDAP, para consultas ad hoc do analista e como interface para bases históricas comerciais que preservam respostas antigas.

3. Campos Úteis para CTI

O valor analítico do registro está concentrado em poucos campos, e dominá-los transforma a consulta em instrumento de decisão. A tabela abaixo relaciona cada campo à pergunta que ele responde e ao uso típico na operação.

Os códigos de status merecem leitura própria, porque contam o estado do ciclo de vida sem ambiguidade. A tabela abaixo organiza os códigos que aparecem com frequência na triagem, com o significado e a leitura operacional correta.

Um domínio em clientHold parou de resolver porque o registrador suspendeu, o que em contexto de campanha costuma significar derrubada por abuso e encerra a janela de coleta ativa. Domínios em redemptionPeriod ou pendingDelete estão a dias de voltar ao mercado, e essa janela é monitorada por operadores que compram nomes com reputação residual, o que exige atenção redobrada quando um domínio conhecido reaparece com infraestrutura nova. Os servidores de nome, por sua vez, merecem tratamento de pivô: o NS contratado sobrevive à troca de endereços e às vezes à troca de domínio, e a nota de DNS Passivo mostra como cruzá-lo com a co-hospedagem temporal.

4. Privacy Proxy e Redaction

Antes de 2018, o WHOIS de gTLD expunha o nome, o e-mail e o telefone do registrante, e a atribuição por contato repetido era o pivô mais produtivo da análise de infraestrutura. A entrada em vigor do GDPR e a especificação transitória da ICANN mudaram o cenário: os registros passaram a aplicar redaction sistêmica, exibindo o lugar do contato frases como REDACTED FOR PRIVACY, e serviços de privacidade e de proxy passaram a interpor entidades genéricas entre o cliente e o registro. Para domínios novos, a atribuição direta pelo registrante simplesmente acabou, e qualquer relatório que trate o contato mascarado como identidade do operador está fabricando evidência.

O que sobra, porém, continua valioso e define a técnica atual. As datas de registro, o registrador, os servidores de nome e os códigos de status permanecem visíveis, e são eles que sustentam o pivô contemporâneo: agrupar por padrão contratual em vez de por nome de pessoa. As bases históricas de WHOIS, que arquivam respostas anteriores a 2018, recuperam contatos de domínios maduros e permitem vincular operações antigas a operações novas que reutilizam a mesma organização de fachada. Para derrubada, o canal correto deixou de ser o contato do registrante e passou a ser o contato de abuso do registrador, campo que o RDAP expõe de forma padronizada na entidade com papel de registrar.

5. Registradores, Abuso e Idade do Domínio

O mercado de registradores não é homogêneo, e o adversário o conhece bem. Registradores com preço baixo, registro automatizado e resposta lenta a notificações de abuso concentram desproporcionalmente campanhas de phishing e de distribuição de malware, e relatórios do setor mantêm essa cartografia viva. Para o analista, dois usos práticos decorrem disso: a concentração de uma campanha inteira em um único registrador barato é em si um sinal de registro automatizado, e o histórico de troca de registrador após derrubadas sucessivas indica um operador profissional gerenciando risco, não um praticante amador.

A idade do domínio é o sinal de registro mais barato e mais usado na triagem, e por isso é também o mais mal calibrado. A leitura madura reconhece três faixas com tratamentos diferentes. Domínios com poucos dias de vida distribuindo páginas de login ou anexos merecem prioridade máxima, porque o ciclo típico de phishing vai do registro à entrega em horas. Domínios maduros com mudança recente de infraestrutura, verificável no DNS passivo da nota anterior, indicam compra ou sequestro de reputação e exigem investigação do que mudou. Domínios antigos sem alteração relevante têm o menor risco associado, embora nada na idade autorize descartar um indicador por si só.

A combinação que rende é temporal, e não pontual: idade do registro, primeira resolução na base de DNS passivo e emissão de certificado nos logs de CT, lidas como sequência. Registro e certificado no mesmo dia com primeira resolução no dia seguinte é o retrato de infraestrutura nascida pronta para campanha; registro antigo com certificado novo e resolução em provedor diferente é o retrato de domínio recém-comprado; e registro antigo com histórico contínuo é o único perfil em que a idade, sozinha, reduz risco de forma defensável.

6. Padrões de Registro de Campanha e Typosquats

Campanhas com orçamento registram domínios em lote, e o lote deixa assinatura. Os padrões mais produtivos para o agrupamento são: criação de vários nomes no mesmo dia ou em janela de minutos; concentração no mesmo registrador e nos mesmos servidores de nome; nomes sequenciais ou gerados por template, como marca-plus-palavra-chave repetida em variações; e emissão de certificado TLS imediatamente após o registro, visível nos logs de Certificate Transparency da nota seguinte da subpasta. Cada padrão isolado é fraco; a coocorrência de três ou mais deles na mesma janela temporal configura cluster de campanha com confiança alta para o pivô formalizado na nota de Pivoting.

Os typosquats seguem um catálogo de transformações que vale automatizar como gerador de candidatos a monitorar. A tabela abaixo organiza as classes com exemplos genéricos aplicáveis a qualquer marca monitorada pela organização.

A classe de homoglifo merece atenção especial, porque escapa da comparação textual comum: os caracteres cirílicos que se parecem com latinos geram domínios com punycode, e o navegador exibe o nome que a vítima acha que leu. A defesa técnica é normalizar todo nome observado para a forma punycode antes de qualquer comparação, e a defesa registral é registrar preventivamente as variantes mais perigosas da marca, decisão de custo pequeno que a área de negócio precisa tomar com dados da CTI.

Para monitores de marca em escala, a fonte estruturada é o arquivo de zona do TLD, acessível por meio do programa CZDS (Centralized Zone Data Service) mediante credenciamento. Com a zona diária em mãos, o monitor compara os nomes novos com o gerador de candidatos e enfileira os que casam, sem depender de varreduras de descoberta, e é essa fila que alimenta a esteira de domínios recém-nascidos descrita na integração desta nota.

7. Consultas Práticas

O fluxo mínimo de triagem de um domínio suspeito consulta WHOIS ou RDAP, extrai datas, status e registrador e calcula a idade. O bloco abaixo cobre as três variantes que a operação encontra: gTLD por RDAP, ccTLD .br por RDAP próprio e WHOIS clássico como reserva.

DOM="entrada-segura-banco.com"

# WHOIS classico na porta 43, com filtro nos campos-chave
whois "$DOM" | grep -Ei 'registrar:|creation date:|registry expiry|name server|domain status|abuse'

# RDAP pelo redirecionador publico: status do dominio e eventos datados
curl -s -H 'Accept: application/rdap+json' "https://rdap.org/domain/$DOM" \
  | jq -r '.status[]'
curl -s -H 'Accept: application/rdap+json' "https://rdap.org/domain/$DOM" \
  | jq -r '.events[] | "\(.eventAction): \(.eventDate)"'

# ccTLD .br possui RDAP proprio no registro.br
curl -s "https://rdap.registro.br/domain/banco-exemplo.com.br" \
  | jq -r '.events[] | "\(.eventAction): \(.eventDate)"'

Para automação, o trecho abaixo consulta RDAP, calcula idade em dias e recupera o registrador. O campo fn do vCard é o nome formal da entidade com papel de registrar, e é ele que alimenta a análise de concentração por registrador descrita na seção anterior.

Duas observações de operação completam o bloco. O redirecionador rdap.org devolve o servidor correto por TLD, e pipelines sérios guardam o servidor final descoberto para uso direto, poupando um salto por consulta. E servidores WHOIS de ccTLD costumam aplicar limites agressivos por origem, de modo que a varredura em lote deve usar bases comerciais ou espelhamento autorizado, reservando a consulta direta para casos individuais de investigação.

import requests
from datetime import datetime, timezone

dom = "entrada-segura-banco.com"
dados = requests.get(f"https://rdap.org/domain/{dom}",
                     headers={"Accept": "application/rdap+json"},
                     timeout=15).json()

eventos = {e["eventAction"]: e["eventDate"] for e in dados.get("events", [])}
criacao = datetime.fromisoformat(eventos["registration"].replace("Z", "+00:00"))
idade = (datetime.now(timezone.utc) - criacao).days

registrar = next((e for e in dados.get("entities", [])
                  if "registrar" in e.get("roles", [])), None)
nome_registrar = registrar["vcardArray"][1][1][3] if registrar else "indisponivel"
print("idade em dias:", idade)
print("expira em:", eventos.get("expiration"))
print("status:", ", ".join(dados.get("status", [])))
print("registrador:", nome_registrar)

8. Limitações e Erros Comuns

• Parsing frágil do texto livre do WHOIS: rótulos mudam entre registradores e quebram automação; correção: construir automação nova em RDAP e reservar WHOIS para fontes sem alternativa.
• Tratar contato de proxy como identidade do operador: a entidade de privacidade é um escudo contratual, e não uma pessoa; correção: agrupar por datas, registrador e servidores de nome.
• Usar idade como prova isolada: lançamentos legítimos de produto registram domínios novos, e operadores maduros mantêm domínios velhos; correção: idade entra como fator ponderado, nunca como veredito.
• Ignorar datas inconsistentes entre fontes: transferência de registrador altera alguns campos, e caches de bases comerciais atrasam atualização; correção: registrar a fonte e a data da consulta junto ao achado.
• Consultar servidores WHOIS em volume sem controle de ritmo: bloqueios por excesso interrompem pipelines inteiros; correção: limitar taxa, distribuir janelas e preferir bases comerciais para varredura em lote.
• Assumir cobertura RDAP universal: ccTLDs variam de completude, e alguns exigem consulta direta ao registro nacional; correção: mapa de cobertura por TLD mantido pela equipe.
• Confundir data de registro com data de primeira observação em bases históricas: são conceitos diferentes, e a mistura produz datas falsas de criação; correção: registrar qual conceito cada fonte entrega e comparar apenas conceitos iguais.
• Ler clientTransferProhibited como abuso: o travamento de transferência é proteção comum e legítima; correção: focar nos status de suspensão e de ciclo de queda.

9. Integração com o Restante da Biblioteca

Esta nota completa o par de fontes históricas da subpasta de infraestrutura: o DNS passivo da nota anterior descreve a vida da resolução, e o registro descreve o nascimento contratual do nome, e é a junção das duas linhas do tempo que datam cada fase de uma campanha. A idade e o padrão de lote alimentam a pontuação de qualidade da nota de Pontuação de Qualidade da subpasta de IOCs, na qual confiabilidade e idade ponderam a confiança do indicador, e alimentam o catálogo de pivôs da nota de Pivoting e Correlação, onde o registrador e o servidor de nome aparecem como arestas de robustez média com exigência de janela temporal. No capítulo 04, o nível de domínio da Pirâmide de Dor explica por que essa camada de indicador é barata para o adversário trocar, e por isso o uso correto aqui é triagem e agrupamento, e não bloqueio definitivo.

O padrão de automação que fecha o ciclo é a esteira de domínios recém-nascidos: um job diário cruza os logs de Certificate Transparency da marca, os monitores de registro de domínios novos e a primeira aparição de cada nome na base interna de DNS, e enfileira para triagem todo nome com menos de uma semana de vida, certificado emitido e padrão de nomenclatura compatível com o gerador de typosquats. Essa fila alimenta diretamente o monitoramento de exposição do INS.4 e a integração EASM com CTI descrita no capítulo 04, transformando a formalidade do registro em vantagem temporal: a campanha é vista no dia em que compra o nome, e não no primeiro clique da vítima.