Algunos visitantes llegan al WordPress real mientras otros ven una copia falsa, aviso de certificado o servidor ajeno. Pueden haberse cambiado registros DNS, nameservers o el origen del CDN. Limpiar archivos no repara el tráfico que nunca llega a WordPress.
Incluye el registrador y el proveedor DNS en el alcance crítico del incidente.
Captura la resolución desde varias ubicaciones
Registra nameservers y respuestas A, AAAA y CNAME del host afectado desde varios resolvers de confianza. Incluye TTL y hora.
Compara con la configuración conocida del servidor o CDN y con el historial de zona. La propagación, DNS dividido o varios registros legítimos también pueden producir respuestas diferentes.
No consultes herramientas públicas al azar con hostnames internos privados.
Conserva zona e historial de cuenta
Exporta la zona, logs de auditoría, usuarios, tokens API y cambios recientes de nameservers o registros. Guarda el contacto del registrador y el estado de bloqueo de transferencia.
Protege esta evidencia porque revela infraestructura y pide a los proveedores que retengan logs de autenticación y cambios.
No borres cada registro desconocido: correo, verificaciones y subdominios de servicio pueden ser legítimos.
Asegura registrador y proveedor DNS
Desde un dispositivo limpio, protege el correo del propietario, revoca sesiones, usuarios y tokens desconocidos y activa MFA fuerte. Cambia credenciales y revisa contactos de recuperación.
Activa el bloqueo del dominio cuando corresponda y verifica que no exista transferencia o cambio de nameservers pendiente sin autorización.
Contacta con soporte mediante URL o teléfono verificados, no datos incluidos en emails sospechosos.
Restaura los registros autorizados
Usa una zona buena documentada o los valores del hosting o CDN. Comprueba IPv4 e IPv6: un AAAA malicioso puede desviar redes que prefieren IPv6 mientras las pruebas IPv4 parecen correctas.
Confirma comodines y comportamiento del dominio raíz y www. Coordina MX, SPF, DKIM y DMARC para no romper el correo durante la recuperación.
Bajar el TTL después de que una respuesta esté almacenada no invalida las cachés existentes.
Valida DNSSEC antes y después
Si se usa DNSSEC, compara el registro DS del registrador con la configuración de firma del proveedor activo. Cambiar nameservers o regenerar claves sin coordinar el DS puede provocar fallos de validación generalizados.
No desactives DNSSEC solo para ocultar una discrepancia. Conserva el historial de claves y DS, identifica al proveedor autorizado y sigue su procedimiento de rotación o retirada.
Después, consulta resolvers validadores y monitoriza SERVFAIL además de las respuestas A y AAAA esperadas. Documenta quién gestionará futuras rotaciones.
Revisa CDN y configuración de origen
Si Cloudflare u otro proxy es autoritativo, inspecciona direcciones de origen, Workers, redirecciones y balanceadores. Un DNS correcto aún puede enviar tráfico a un origen controlado por el atacante.
Verifica certificados TLS y, cuando sea posible, registros de emisión para detectar certificados desconocidos. Revoca o sustituye credenciales de origen afectadas.
No expongas el origen protegido durante la recuperación.
Inspecciona también WordPress y hosting
El compromiso DNS puede ser independiente o parte de un robo mayor. Revisa usuarios del panel, administradores WordPress, archivos, base, cron y correo de restablecimiento.
Si visitantes introdujeron credenciales o pagos en la copia falsa, coordina la respuesta legal, de privacidad y pagos. No presupongas que el desvío fue inocuo.
Conserva el destino malicioso como texto y no interactúes con él.
Verifica propagación y estabilidad
Monitoriza resolvers autoritativos y recursivos durante varios periodos TTL. Prueba HTTP y TLS mediante el dominio canónico y regiones relevantes.
Confirma que los logs muestran solo cambios autorizados y que las alertas están activas. Documenta la zona final y sus propietarios y programa una revisión trimestral.
Cuándo se necesita recuperación urgente
Solicita ayuda inmediata si cambiaron nameservers, se disputa la propiedad o los visitantes llegaron a una copia de credenciales o pagos. Envía dominio y evidencia DNS censurada, nunca contraseñas.
La reparación debe recuperar la autoridad, asegurar la cuenta y verificar que el tráfico llega de forma consistente al servicio de confianza.