Redirect malicioso no WordPress sem arquivo infectado: como diagnosticar DNS hijack em 5 minutos antes de formatar o servidor
Publicado em 24 de abril de 2026
O sintoma: redirect para página desconhecida
A chamada chegou com urgência: um portal científico online estava redirecionando visitantes para uma página suspeita. O comportamento era consistente — qualquer acesso ao domínio resultava em redirect automático.
O primeiro impulso em casos assim é ir direto ao servidor WordPress: verificar arquivos PHP modificados, plugins com código malicioso injetado, admin criado ilegitimamente. É o caminho óbvio — e é exatamente o caminho errado quando o vetor de ataque é o DNS.
Antes de tocar no servidor, verifique o DNS. Um redirect que acontece antes do WordPress processar qualquer requisição raramente é causado pelo WordPress.
Os 5 minutos de diagnóstico
A metodologia de diagnóstico para redirect suspeito segue uma sequência específica, do mais externo para o mais interno. Começar pelo servidor é perder tempo:
Passo 1: resolver o DNS atual
# Verificar para qual IP o domínio está apontando
dig journal.example.org A +short
# Verificar também via resolver público (garante que não é cache local)
dig @8.8.8.8 journal.example.org A +short
dig @1.1.1.1 journal.example.org A +shortNesse caso, o dig retornou dois IPs: <IP_atacante_1> e <IP_atacante_2>. O IP correto do servidor era <IP_legitimo>. Os dois primeiros IPs não são do servidor onde o WordPress estava hospedado.
IPs retornados pelo DNS: <IP_atacante_1>, <IP_atacante_2>
IP real do servidor WordPress: <IP_legitimo>
Conclusão imediata: o domínio estava apontando para um servidor completamente diferente.
Passo 2: seguir o redirect com verbose
# Seguir o redirect completo e inspecionar cada etapa
curl -sv -L https://journal.example.org/ 2>&1 | head -60A resposta foi reveladora:
* Trying <IP_atacante_1>:443...
* Connected to journal.example.org (<IP_atacante_1>) port 443
* SSL certificate verify ok
< HTTP/1.1 200 OK
< Content-Type: text/html
<!DOCTYPE html><html><head>
<script>window.onload=function(){window.location.href="/lander"}</script>
</head></html>Uma página HTML mínima com um script JavaScript que redireciona para /lander imediatamente ao carregar. Zero conteúdo legítimo. O servidor que recebia as requisições servia exclusivamente esse redirect.
Passo 3: inspecionar o certificado SSL
# Verificar emissor e data de emissão do certificado
curl -sv https://journal.example.org/ 2>&1 | grep -E "issuer|expire|start|subject"O certificado revelou o detalhe mais importante:
CN: journal.example.org (correto — emitido para o domínio alvo)
Issuer: GoDaddy TLS Intermediate CA DV - R1v1 — não é o Let's Encrypt padrão do servidor real
Data de emissão: horas antes da descoberta do incidente
Um certificado SSL válido emitido pelo próprio registrador, no dia do incidente, é evidência forense direta: o atacante controlava o DNS o suficiente para emitir um certificado — e sabia que precisava de HTTPS para que o redirect parecesse legítimo.
Passo 4: verificar os nameservers
# Verificar nameservers autoritativos do domínio
dig journal.example.org NS +short
# Resultado: ns71.domaincontrol.com, ns72.domaincontrol.comdomaincontrol.com é a infraestrutura de DNS da GoDaddy. O domínio estava com nameservers na GoDaddy — e a conta GoDaddy do cliente era o ponto de comprometimento.
O diagnóstico final: DNS hijack via registrador
Com essas quatro informações, o quadro estava completo. Não havia hack no WordPress. O ataque foi:
1. Acesso não autorizado à conta GoDaddy do cliente (senha comprometida ou ausência de 2FA).
2. Alteração dos registros A do domínio para IPs de um servidor controlado pelo atacante.
3. Emissão de certificado SSL via GoDaddy para o domínio — possível porque o atacante controlava o DNS e conseguiu completar a validação DV.
4. Servidor do atacante servindo uma página com redirect JavaScript para /lander.
O servidor WordPress original ficou intacto. Nenhum arquivo foi modificado. Nenhum plugin foi comprometido. Nenhum admin foi criado. Se tivéssemos seguido o caminho convencional de 'limpar o WordPress', teríamos perdido horas — e o site continuaria fora do ar enquanto o DNS seguia apontando para o servidor errado.
Evidências consolidadas
DNS A record: <IP_atacante_1>, <IP_atacante_2> — IPs sem relação com o servidor real
IP real do servidor: <IP_legitimo> — não batia com o DNS
Emissor do certificado: GoDaddy (não Let's Encrypt) — emitido pelo atacante usando controle sobre o DNS
Data de emissão: no dia do incidente — indicador temporal do ataque
Conteúdo da página: HTML mínimo com window.location.href para /lander
Nameservers: GoDaddy — alteração feita dentro da conta do registrador
Ações de recuperação (cliente)
A recuperação seguiu uma sequência específica — ordem importa:
1. Trocar senha da conta GoDaddy imediatamente. Antes de qualquer outra ação — para garantir que o atacante não refaça a alteração.
2. Ativar 2FA na conta GoDaddy. Autenticação de dois fatores via app (não SMS, que pode ser interceptado via SIM swap).
3. Reverter os registros A do domínio para o IP correto. Com TTL baixo (60s) para propagar rapidamente.
4. Verificar outros domínios na mesma conta GoDaddy. Se uma conta foi comprometida, outros domínios gerenciados na mesma conta podem ter sido alterados.
5. Verificar o histórico de alterações de DNS no GoDaddy. Para identificar quando o ataque ocorreu e se há outros registros alterados (MX, TXT, CNAME).
6. Reportar o incidente à GoDaddy. Para investigação do acesso não autorizado e possível revogação do certificado emitido pelo atacante.
Como prevenir: duas medidas que valem mais que qualquer WAF
2FA no registrador — não opcional
O acesso ao registrador é o nível de acesso mais alto que existe para um domínio. Quem controla o registrador controla o DNS. Quem controla o DNS controla tudo que está sob aquele domínio — incluindo a capacidade de emitir certificados SSL válidos.
2FA via app autenticador (Google Authenticator, Authy) é o mínimo. Registradores como GoDaddy também oferecem opções de notificação por email para alterações de DNS — ativar essa notificação cria um alerta imediato se o DNS for alterado sem autorização.
Registry Lock: a proteção de nível ICANN
Para domínios críticos — domínios que geram receita direta, identificam uma organização ou são difíceis de recuperar em caso de comprometimento — existe o Registry Lock. É uma trava no nível do registro ICANN que impede qualquer transferência ou alteração de NS sem um processo manual de verificação com o registrador.
# Verificar o status de lock de um domínio
whois journal.example.org | grep -i "status"
# Outputs que indicam proteção ativa:
# clientDeleteProhibited
# clientTransferProhibited
# clientUpdateProhibited
# serverDeleteProhibited ← Registry Lock (nível ICANN)
# serverTransferProhibited ← Registry Lock (nível ICANN)
# serverUpdateProhibited ← Registry Lock (nível ICANN)Os status com prefixo client são definidos pelo registrador e podem ser alterados pela própria conta do cliente. Os status com prefixo server são definidos pelo registry (ICANN) e exigem processo manual — imunes a comprometimento de credenciais do registrador.
Por que o servidor nunca foi o problema
A investigação no servidor WordPress — arquivos PHP, plugins, admins, opções do banco de dados — levaria horas e não encontraria nada. Porque não havia nada para encontrar. O servidor estava intacto.
Isso é um padrão importante: quando o redirect acontece para qualquer URL do domínio, incluindo páginas que não existem no WordPress, a causa não é o WordPress. O WordPress só redireciona rotas que ele conhece. Um servidor que serve uma página HTML estática de redirect para qualquer requisição está no nível do DNS — não do aplicativo.
Limpar um WordPress por horas enquanto o DNS aponta para outro servidor é o equivalente a trocar a fechadura de uma casa enquanto o ladrão está na casa vizinha com a chave da frente. O problema estava no cartório, não no imóvel.
O diagnóstico de 5 minutos — dig, curl -sv -L, inspeção do certificado, whois dos nameservers — é suficiente para descartar comprometimento de servidor e identificar DNS hijack. Só depois de descartar o DNS faz sentido investigar o aplicativo.
