Redirecciones maliciosas en WordPress: por qué tú no las ves, pero Google o los móviles sí

Tu web parece funcionar con normalidad. Entras desde el ordenador, navegas por varias páginas y no ocurre nada extraño. Sin embargo, un cliente asegura que ha terminado en una web de apuestas, Google muestra una dirección que no reconoces o alguien te envía una captura tomada desde el móvil.

Esta diferencia no invalida el aviso. Algunas redirecciones maliciosas están preparadas para activarse solo cuando se cumplen condiciones concretas. Pueden afectar a usuarios móviles, visitas procedentes de un buscador, determinadas ubicaciones o navegadores que todavía no tienen una cookie. El propietario, que entra todos los días desde el mismo equipo y suele tener la sesión de WordPress abierta, puede no verlas nunca.

Google reconoce que una web comprometida puede redirigir exclusivamente a usuarios móviles y recomienda comprobarla desde un teléfono entrando desde los resultados de búsqueda, no solo escribiendo la dirección directamente.[2]

Cuando una redirección aparece de forma intermitente, el objetivo no debe ser recargar la portada hasta que ocurra. Hay que conservar evidencias, reproducir las condiciones y localizar en qué capa se toma la decisión de enviar al visitante a otro sitio.

No todas las redirecciones son maliciosas

Una redirección es una función normal de una web. Se utiliza, por ejemplo, cuando cambia la dirección de una página, se fuerza HTTPS, se unifica el dominio con o sin www o se lleva al usuario a la versión correcta de un contenido.

Una redirección legítima suele tener tres características:

• Conduce a una dirección conocida y relacionada con la web.
• Responde a una regla documentada o a una configuración reconocible.
• Se comporta de forma consistente para los visitantes a los que debe afectar.

La sospecha aparece cuando el destino no tiene relación con la actividad del sitio, el salto solo sucede algunas veces o el comportamiento cambia según el dispositivo, la procedencia o el usuario.

También hay que diferenciar una redirección real de otros problemas parecidos. Un anuncio, un popup o un enlace modificado puede abrir otra pestaña sin que el servidor haya redirigido la página original. Un error de DNS puede llevar el dominio completo a una infraestructura equivocada. Una extensión instalada en el navegador puede alterar la navegación únicamente en un equipo. El diagnóstico cambia en cada caso.

Por qué tú puedes no ver la redirección

El código malicioso intenta permanecer activo el mayor tiempo posible. Si redirigiese a todos los visitantes en cada acceso, el propietario y el proveedor de alojamiento detectarían el problema enseguida. Por eso es habitual que introduzca condiciones.

Solo afecta a móviles

El código puede analizar el navegador o el tamaño del dispositivo y actuar únicamente ante teléfonos. Google ha documentado casos en los que una intrusión o un elemento publicitario de terceros provocaba redirecciones exclusivas para usuarios móviles.[2]

Esto explica por qué la revisión desde el ordenador de la oficina puede parecer correcta mientras los clientes siguen informando del problema.

Solo se activa al llegar desde Google

La petición puede incluir información sobre la página de procedencia. Una inyección puede aprovecharla para redirigir a quienes llegan desde un resultado de búsqueda, pero no a quien escribe el dominio directamente o utiliza un marcador.

Por eso conviene pedir a la persona afectada que explique el recorrido completo: qué buscó, qué resultado pulsó, qué URL esperaba abrir y cuál fue el destino final.

Solo ocurre una vez

Después del primer salto, el código puede guardar una cookie o algún dato en el navegador. El visitante no vuelve a ser redirigido durante unas horas o unos días, lo que dificulta repetir el síntoma mediante recargas.

Probar en una ventana privada puede ayudar, pero no es una prueba definitiva. También pueden intervenir la dirección IP, la sesión, la caché o reglas externas al navegador.

Cambia según la IP o la ubicación

Una redirección puede dirigirse solo a determinados países, redes móviles o rangos de direcciones. Si el propietario y la persona afectada se conectan desde lugares distintos, pueden recibir respuestas diferentes.

Cambiar el user-agent no reproduce este escenario. Tampoco basta con utilizar el modo móvil de las herramientas del navegador si la condición real depende de la red desde la que se hace la petición.

Evita a los administradores

El malware puede comprobar si existe una sesión iniciada en WordPress y no actuar ante usuarios autenticados. Revisar siempre la web mientras se está conectado al panel puede ocultar el problema.

Se ejecuta de forma aleatoria o por intervalos

Algunas inyecciones redirigen solo un porcentaje de las visitas o consultan un servidor externo antes de decidir. Si ese servidor no responde, ha bloqueado temporalmente la campaña o ya reconoce la IP, la web puede parecer limpia durante la comprobación.

La primera tarea es conservar evidencias

Antes de actualizar, borrar archivos o vaciar todas las cachés, conviene recopilar información. Esos cambios pueden detener temporalmente el síntoma y, al mismo tiempo, eliminar pistas sobre su origen.

Pide a la persona afectada, si es posible:

• La URL exacta que intentó abrir.
• La dirección final a la que llegó.
• La fecha y la hora aproximadas.
• Una grabación o varias capturas del proceso.
• El dispositivo, navegador y tipo de conexión.
• Si llegó desde Google, una red social, un correo o un enlace directo.
• Si era la primera visita o ya había entrado antes.
• Cualquier aviso mostrado por el navegador.

No es recomendable volver a visitar deliberadamente el dominio de destino desde un equipo de trabajo. Puede contener publicidad fraudulenta, intentos de descarga o nuevas cadenas de redirección. La URL escrita en una captura o copiada como texto suele ser suficiente para empezar.

También deben conservarse, antes de que roten o se sobrescriban, los registros disponibles del servidor, del proxy, del CDN y del cortafuegos.

Cómo intentar reproducirla sin limitarse a recargar la portada

La comprobación debe repetir condiciones, no solo peticiones.

1. Prueba la URL denunciada, no únicamente la página de inicio. La inyección puede afectar a una plantilla, una entrada concreta o una dirección creada para spam.
2. Entra desde el resultado del buscador. Esto permite conservar la procedencia que podría activar el código.
3. Utiliza un móvil real y datos móviles. Después compara el resultado con la misma prueba mediante wifi.
4. Cierra la sesión de WordPress. Haz la comprobación sin cookies administrativas y también en una ventana privada.
5. Registra la cadena completa. Las herramientas de red del navegador permiten conservar las solicitudes y comprobar si existe una respuesta HTTP de redirección o si el salto se inicia mediante JavaScript.
6. Repite desde más de una red. Si solo se reproduce fuera de la oficina, la IP o la ubicación pueden formar parte de la condición.

Una consulta de cabeceras puede descubrir una redirección realizada por el servidor:

curl -I https://ejemplo.com/pagina/

Para seguir los saltos y ver los destinos intermedios:

curl -I -L https://ejemplo.com/pagina/

También se puede comparar la respuesta declarando otro navegador o una procedencia concreta. Sin embargo, estas pruebas tienen límites: curl no ejecuta JavaScript y declarar un user-agent de Google no convierte la petición en una visita real de Google.

Google explica que el cloaking puede mostrar al propietario una página vacía o un error 404 mientras redirige a quienes llegan desde los resultados y presenta otro contenido a los rastreadores.[3] Por eso una única respuesta correcta no demuestra que el problema haya desaparecido.

Averigua qué capa produce el salto

La cadena de navegación ayuda a reducir el área de búsqueda.

Redirección HTTP antes de cargar WordPress

Si la primera respuesta ya contiene un estado 301, 302, 307 o 308 hacia un dominio sospechoso, hay que revisar las capas que actúan antes de generar la página:

• Reglas de Apache en .htaccess.
• Configuración de Nginx.
• Panel de redirecciones del alojamiento.
• Proxy inverso o CDN.
• Reglas del cortafuegos.
• Código PHP ejecutado al inicio de WordPress.
• Plugins obligatorios o mu-plugins.

No toda regla desconocida es necesariamente maliciosa. Conviene compararla con la configuración esperada y documentar cualquier cambio antes de eliminarla.

Redirección mediante JavaScript

Si la página carga y después cambia de dirección, el salto puede proceder del HTML o de un script. En ese caso deben revisarse:

• El tema activo y sus plantillas.
• Plugins activos, inactivos y abandonados.
• Scripts insertados por plugins de analítica, anuncios o consentimiento.
• Gestores de etiquetas.
• Widgets, bloques reutilizables y opciones de la base de datos.
• Código añadido en cabeceras y pies de página.
• Recursos JavaScript cargados desde dominios externos.
• Service workers y cachés del navegador.

Google recomienda auditar los scripts y elementos de terceros cuando una redirección móvil no procede de una intrusión evidente, retirándolos de forma controlada hasta identificar el responsable.[2]

Contenido distinto según el visitante

Si el servidor devuelve HTML diferente para varias condiciones, hay que buscar código que examine cookies, cabeceras, IP, país, dispositivo o procedencia. Puede estar dentro de un archivo aparentemente legítimo, una opción serializada de la base de datos o un componente que descargue instrucciones de otro servidor.

En este punto no basta con buscar la URL de destino. El dominio puede cambiar continuamente o llegar cifrado u ofuscado. Resulta más útil identificar las funciones que construyen la condición, realizan la consulta externa o generan la respuesta.

El problema está fuera de WordPress

WordPress puede estar intacto y la redirección producirse en otra capa:

• DNS modificado.
• Cuenta del CDN comprometida.
• Regla creada en el panel de hosting.
• Etiqueta alterada en un gestor externo.
• Script publicitario de un tercero.
• Navegador o equipo del visitante infectado.

Por eso instalar un plugin de seguridad y lanzar un análisis no cubre todo el recorrido de una petición.

Qué revisar dentro de WordPress

Una revisión técnica debe relacionar el momento y las condiciones de la redirección con los cambios encontrados. Entre los puntos habituales están:

• Archivos modificados recientemente.
• Diferencias entre el núcleo instalado y la versión oficial.
• Plugins y temas que no proceden de una fuente conocida.
• Extensiones que ya no se utilizan.
• Código PHP en wp-content/uploads u otros directorios inesperados.
• Wp-config.php, .htaccess y archivos de arranque.
• Mu-plugins y drop-ins de caché.
• Usuarios administradores y sesiones activas.
• Tareas programadas de WP-Cron.
• Opciones, widgets y contenido con scripts insertados.
• Permisos y propietarios de archivos.
• Registros de acceso y errores.

La documentación oficial de WordPress presenta la seguridad como una reducción del riesgo, no como un estado perfecto alcanzado con una única medida, y recomienda mantener WordPress actualizado, limitar accesos y utilizar componentes de fuentes confiables.[4]

Si ya has localizado un archivo que provoca el salto, evita concluir que ese archivo fue también la vía de entrada. Puede ser únicamente la parte visible. En por qué WordPress vuelve a infectarse explicamos cómo una puerta trasera, una credencial válida o una tarea programada pueden regenerar el problema después de una limpieza superficial.

Search Console, resultados de Google y registros

Google Search Console puede aportar información aunque tú no consigas reproducir la redirección. El informe de problemas de seguridad muestra páginas comprometidas identificadas por Google y ofrece indicaciones para corregirlas.[1]

También conviene revisar:

• Avisos y mensajes recientes.
• Páginas indexadas que no reconoces.
• Consultas o URLs con cambios inesperados.
• Sitemaps enviados.
• Usuarios y propietarios de la propiedad.

Una búsqueda site:tudominio.com puede revelar contenidos o direcciones desconocidas. Google recomienda utilizar periódicamente este operador y vigilar en los registros parámetros extraños o aumentos de tráfico hacia URLs de redirección.[1]

Si el problema incluye resultados falsos, páginas de apuestas o contenidos que no existen al navegar normalmente, consulta también qué revisar cuando Google muestra páginas de spam en WordPress.

Los logs del servidor pueden confirmar qué URL se solicitó, a qué hora, desde qué agente y qué código de respuesta se devolvió. No siempre contienen el destino cuando el salto ocurre en JavaScript, pero permiten correlacionar la visita con archivos, peticiones o procesos ejecutados en el mismo intervalo.

Qué no conviene hacer

• Vaciar todas las cachés antes de recopilar datos. Puede eliminar una respuesta que ayudaba a reproducir el incidente.
• Borrar el primer archivo sospechoso y dar el caso por cerrado. La redirección visible y el mecanismo de persistencia pueden estar separados.
• Restaurar una copia sin comprobarla. El backup puede contener ya la infección y no corregir la vía de acceso.
• Instalar varios plugins de seguridad a la vez. Añade cambios, ruido y posibles conflictos sin garantizar una investigación completa.
• Bloquear solo el dominio de destino. La campaña puede sustituirlo por otro mientras el código original continúa activo.
• Probar únicamente como administrador. La sesión iniciada puede ser precisamente lo que impide ver el comportamiento.
• Actualizarlo todo antes de preservar evidencias. Actualizar es importante, pero hacerlo sin orden modifica fechas y archivos que podrían ser relevantes.

Si necesitas medidas inmediatas para reducir daños, documenta primero el estado y valora poner la web en mantenimiento, bloquear temporalmente la regla identificada o aislar la instalación. La actuación concreta dependerá de si la web está sirviendo contenido peligroso, si afecta a todas las visitas y de cuánto control se conserve sobre el servidor.

Después de eliminar la redirección

La recuperación no termina cuando el navegador deja de saltar a otra página.

Hay que comprobar de nuevo todas las condiciones con las que se reproducía el problema, revisar que no existan otros mecanismos de acceso y cerrar el punto de entrada probable. Esto puede incluir actualizar o retirar componentes, renovar credenciales, invalidar sesiones, regenerar claves, revisar usuarios y corregir permisos.

Después conviene:

1. Comparar de nuevo archivos y configuración.
2. Repetir las pruebas desde móvil, buscador, ventana privada y otra red.
3. Comprobar varias URLs, no solo la portada.
4. Revisar Search Console y solicitar una revisión si existe un aviso de seguridad.
5. Vigilar durante los días siguientes los logs, los cambios de archivos y las tareas programadas.
6. Conservar un informe de lo encontrado y de las medidas aplicadas.

No prometas que una web está limpia solo porque la redirección ya no aparece. La conclusión debe apoyarse en las pruebas realizadas, la revisión del entorno y un periodo razonable de vigilancia.

Una redirección intermitente sigue siendo una incidencia real

Que el propietario no consiga verla no convierte la redirección en un falso positivo. Cuando distintos visitantes reciben respuestas diferentes, esa diferencia es parte de la evidencia.

El diagnóstico correcto consiste en reconstruir las condiciones, identificar la capa que toma la decisión y revisar el alcance completo de la posible intrusión. Si además aparecen archivos desconocidos, usuarios nuevos, páginas de spam o avisos de Google, es recomendable tratarlo como un incidente de seguridad y no como un simple problema de caché.

Puedes empezar por nuestra guía sobre qué hacer cuando un WordPress ha sido hackeado. Si necesitas una revisión técnica, en WP Seguridad podemos analizar y desinfectar tu WordPress, localizar el origen de las redirecciones y comprobar si quedan mecanismos de persistencia.

Fuentes

1. Preventing malware infection — Google Search Central
2. Detect and get rid of unwanted sneaky mobile redirects — Google Search Central
3. #NoHacked: Identifying and diagnosing injected URL hacking — Google Search Central
4. Hardening WordPress — WordPress Developer Resources