Categoría: Wordpress

Publicado el

Usuarios admin desconocidos en WordPress: qué hacer y cómo eliminarlos sin reinfección

Usuarios admin desconocidos en WordPress

Si entraste a tu WordPress y viste un administrador que no reconoces, no lo trates como “algo raro” sin más: normalmente significa una de dos cosas: alguien ya tuvo acceso o todavía lo tiene. Y cuando hay un admin intruso, el problema no es solo ese usuario… es lo que pudo haber hecho: crear puertas traseras, cambiar correos, inyectar código, o dejar algo programado para volver.

Lo que vas a lograr hoy:

  • Contener el incidente para que el intruso no siga actuando.
  • Recuperar control aunque te hayan cambiado permisos o datos.
  • Dejar el sitio listo para eliminar al admin intruso de forma segura (sin que reaparezca).

Importante: si tu web tiene WooCommerce o formularios con datos, actúa con prioridad alta. Un admin intruso puede añadir scripts sin que tú lo notes.

Señales de que no es un “error”, sino acceso real

  • Apareció un usuario con rol Administrador que tú no creaste.
  • Tu usuario perdió permisos (te bajaron a “Editor” o algo similar).
  • Cambios de correo, nombre del sitio, plugins instalados sin explicación.
  • Reaparecen usuarios aunque los borres (señal de puerta trasera).
  • Hay redirecciones, SEO spam o archivos modificados recientemente.

Si además viste redirecciones o spam en Google, te conviene tener a mano estas guías:

Plan de emergencia (primeros 10–15 minutos): corta el acceso del intruso

Antes de borrar nada, tu prioridad es detener el daño. Piensa como si hubieras encontrado una puerta abierta en tu casa: primero la cierras, luego investigas.

1) Si todavía puedes entrar al wp-admin: activa modo mantenimiento

Si tu sitio está infectado o hay comportamientos raros, ponerlo en mantenimiento temporalmente reduce el riesgo de que:

  • más usuarios caigan en redirecciones
  • Google marque tu sitio como peligroso
  • se sigan ejecutando cambios mientras limpias

2) Haz un backup “de evidencia” (no para restaurar a ciegas)

Guarda una copia de archivos y base de datos. No porque quieras restaurar ese estado, sino porque te sirve para:

  • comparar qué cambió
  • recuperar información si algo sale mal
  • tener una referencia del momento en que detectaste el problema

3) Crea un admin seguro temporal (si no estás 100% seguro de tu acceso)

Esto suena contraintuitivo, pero es una jugada defensiva: si tu cuenta actual está comprometida o te cambian permisos, puedes quedarte fuera. Crea un admin nuevo con:

  • correo que controlas y que esté protegido
  • contraseña única y fuerte
  • nombre que tú reconozcas (para identificarlo luego)

Ojo: este admin es “de emergencia”. Más adelante dejaremos solo los admins necesarios.

4) Cambia accesos críticos (no solo WordPress)

Este paso es el que más evita que vuelvan a entrar. Cambia, en este orden:

  • Hosting/cPanel (si tienen esto, pueden volver aunque borres usuarios)
  • SFTP/FTP
  • Contraseñas de WordPress (todos los administradores)

Tip realista: muchas personas cambian la clave de WordPress y se quedan tranquilos… pero el atacante sigue entrando por hosting/FTP y re-crea el admin en minutos.

5) Cierra sesiones activas (cuando sea posible)

Si el intruso está dentro ahora mismo, cambiar la contraseña ayuda, pero cerrar sesiones es el golpe final. Además, en el refuerzo final conviene rotar llaves internas de WordPress para invalidar cookies antiguas.

Qué NO hacer todavía (errores que hacen que el intruso vuelva)

  • No borres al admin intruso sin asegurar hosting/FTP primero. Si tiene acceso al servidor, lo recrea.
  • No instales plugins “limpiadores” desconocidos por desesperación. Algunos empeoran el problema.
  • No te confíes si “ya no lo ves” en la lista: puede quedar un backdoor que lo crea de nuevo.
  • No uses themes/plugins nulled (piratas): son una causa común de admins intrusos.

¿Por qué aparece un admin desconocido? (la causa real casi siempre está aquí)

En WordPress, este escenario suele venir de:

  • Plugin vulnerable o desactualizado.
  • Theme/plugin nulled (con puerta trasera incluida).
  • Contraseña reutilizada (filtrada en otra web).
  • Acceso al hosting/FTP (no entraron por wp-admin, entraron por el servidor).
  • Contagio cruzado: otra web del mismo hosting estaba infectada y saltó a la tuya.

En el siguiente paso vamos a eliminar al usuario intruso de forma segura, revisar roles/capabilities, y buscar la “puerta” que permitió que aparezca. Si lo hacemos bien, esto no se repite.

Lecturas internas recomendadas

Cómo eliminar el admin intruso sin romper tu web (y sin que reaparezca)

Aquí es donde mucha gente comete el error clásico: ve el usuario raro, lo borra… y a los días vuelve a aparecer. Eso pasa cuando el atacante todavía tiene otra puerta (hosting/FTP, plugin vulnerable, backdoor). Por eso, antes de tocar “Eliminar”, asegúrate de que ya hiciste lo básico: cambié accesos críticos, tengo un admin seguro y guardé un backup de evidencia.

Objetivo: eliminar el administrador desconocido, recuperar control total y dejar señales claras de si hay persistencia (backdoor/reinfección).

1) Confirma que el “admin desconocido” realmente es intruso

Antes de borrar, valida esto rápido para no eliminar algo legítimo por error:

  • Correo: ¿es tuyo o de alguien del equipo? Si no lo reconoces, mala señal.
  • Fecha de registro: si se creó justo antes de que aparezcan redirecciones/spam, casi confirmado.
  • Nombre/usuario raro: combinaciones extrañas, números, nombres genéricos (“support”, “admin2”, “wpservice”).
  • Actividad reciente: cambios en plugins, themes, settings, usuarios nuevos.

Tip realista: a veces el intruso se crea como “Editor” o “Autor” y luego se sube a Admin cambiando capacidades. Si ves roles raros o permisos que no cuadran, trátalo como compromiso.

2) Asegura tu “punto de retorno” antes de eliminar

Esto te evita quedarte fuera si algo sale mal:

  • Confirma que existe un admin seguro que controlas.
  • Confirma que puedes entrar al hosting (cPanel/panel) y al SFTP/FTP.
  • Ten a mano el backup de evidencia.

Si todavía no estás seguro del estado general del sitio, apóyate con:

3) Elimina el usuario intruso (sin perder contenido importante)

Cuando eliminas un usuario en WordPress, te preguntará qué hacer con su contenido. Haz esto:

  • Si el intruso publicó páginas/posts: reasigna el contenido a tu admin seguro para poder revisar luego qué hizo.
  • Luego sí: elimina el usuario.

Por qué reasignar: a veces el atacante crea páginas de SEO spam o modifica contenido. Reasignar te permite auditar y borrar lo malo con control.

4) Si el admin vuelve a aparecer: asume backdoor o acceso al servidor

Si lo borras y vuelve, no es un “bug”. Es señal fuerte de:

  • acceso al hosting/FTP (te recrean usuarios desde fuera)
  • backdoor en mu-plugins, uploads, theme, o plugin
  • plugin vulnerable aún activo

Estos artículos satélite son los que más ayudan cuando hay persistencia:

5) Audita “la puerta” más común: plugins y themes

En la práctica, el 80% de casos se explica así: un plugin vulnerable o nulled permitió ejecutar código y crear un admin.

Checklist rápido:

  • Elimina plugins que no uses (no solo desactivar).
  • Actualiza plugins activos (y el core).
  • Si hay plugins “premium gratis / nulled”: elíminalos. Aunque “funcionen”.
  • Revisa si hay plugins que tú no instalaste (especialmente seguridad/SEO raros).

Si no quieres adivinar, la guía oficial de endurecimiento de WordPress te marca buenas prácticas:

6) Revisa los 4 escondites típicos de backdoors (los que casi nadie mira)

No necesitas “leer todo el código”. Solo revisa con intención:

A) mu-plugins

Si existe wp-content/mu-plugins/ y tú nunca lo usaste, revisa. Allí se cargan cosas automáticamente.

B) uploads

Busca si hay archivos .php dentro de uploads. Eso casi nunca debería existir.

C) theme (functions.php / header.php / footer.php)

Si ves scripts extraños, cadenas gigantes, o funciones ofuscadas, mala señal.

D) wp-config.php

El wp-config debería tener configuración, no “lógica” extra. Si ves includes raros o código largo, sospecha.

Para profundizar según lo que encuentres:

7) Rota “llaves internas” para invalidar sesiones antiguas

Esto es un golpe fuerte contra accesos persistentes (cookies/sesiones). Después de eliminar al intruso y asegurar accesos, rota las security keys para invalidar sesiones existentes.

8) Validación en 24–48 horas (señales de que realmente quedó resuelto)

En las siguientes 24–48 horas, revisa:

  • No aparece de nuevo el admin intruso.
  • No se crean usuarios nuevos solos.
  • No reaparecen redirecciones ni scripts raros.
  • No se vuelven a modificar archivos críticos sin explicación.

Si algo de esto falla, no pierdas tiempo repitiendo lo mismo: ya es un caso de persistencia. Ve directo a:

Blindaje definitivo: evita que vuelvan a crear admins y endurece tu WordPress

Eliminar al administrador intruso es solo la mitad del trabajo. Lo que te protege de verdad es cerrar la causa (la “puerta”) y montar un sistema simple para enterarte rápido si algo vuelve a pasar. Aquí tienes un plan práctico, sin rodeos, para que tu WordPress no quede vulnerable otra vez.

Reduce el riesgo con el principio “menos cosas = menos ataques”

1) Elimina plugins y themes que no uses (no solo desactivar)

Desactivado no significa fuera. Un plugin viejo en el servidor sigue siendo una superficie de ataque si tiene vulnerabilidades. Haz una limpieza real:

  • borra plugins que no aporten valor
  • borra themes que no uses (deja solo el activo y uno de respaldo)
  • evita plugins duplicados que hacen lo mismo

2) Actualiza con disciplina (especialmente seguridad)

La reinfección suele llegar por el mismo plugin desactualizado. Tu regla mínima:

  • revisar actualizaciones al menos 1 vez por semana
  • si hay actualización de seguridad, aplicar cuanto antes

Para buenas prácticas generales, WordPress mantiene una guía oficial:

Refuerza cuentas y sesiones (lo que más frena “vuelvo a entrar”)

3) Contraseñas únicas + 2FA para administradores

Si una contraseña se reutiliza, no se “adivina”, se filtra. Asegura al menos a todos los administradores con:

  • contraseñas únicas (no repetidas en otras webs)
  • 2FA en los accesos críticos

4) Rota llaves internas de WordPress cuando hay incidente

Esto invalida sesiones y cookies antiguas. Es especialmente útil si sospechas que el intruso seguía “logueado” aunque cambies contraseñas.

5) Minimiza administradores (mínimo privilegio)

Muchos sitios tienen 3–5 admins por costumbre. Deja admin solo a quien configura el sitio. El resto, roles menores. Menos admins = menos riesgo de toma total.

Evita que el acceso vuelva por “afuera” (hosting/FTP/DNS)

6) Asegura hosting y FTP/SFTP como si fueran la puerta principal

Si el atacante tuvo acceso al hosting, puede recrear usuarios aunque tú los borres desde WordPress. Por eso, además de WP:

  • cambia contraseña de panel de hosting
  • cambia credenciales de SFTP/FTP
  • elimina usuarios FTP que no uses

7) Si tu dominio o DNS se ven raros, revisa “DNS hijacking”

Cuando el sitio apunta a otro servidor o te aparece una web diferente aunque “WordPress esté bien”, puede ser tema de DNS.

Monitoreo simple: detecta la reaparición antes de que te haga daño

8) Señales que debes revisar cada 2–3 días durante 2 semanas

  • lista de usuarios: ¿aparecen nuevos admins?
  • plugins instalados: ¿apareció alguno que no pusiste?
  • archivos: ¿se modifican wp-config.php, functions.php o mu-plugins?
  • comportamiento: ¿redirige solo en móvil o desde Google?

9) Si tu síntoma fue SEO spam o redirecciones, vigila Google

Cuando te atacan con spam, a veces el sitio “se ve bien” pero Google sigue indexando basura. Te conviene complementar con:

Si vuelve a pasar (o si el admin reaparece): no repitas, escala el enfoque

Si reaparece el admin, si vuelven archivos solos o si notas reinfección, la prioridad es buscar persistencia (backdoor) y cerrar el agujero real. En ese caso, ve directo a:

Checklist final (si cumples esto, estás en zona segura)

  • Solo admins necesarios, el resto con roles menores.
  • Contraseñas únicas + 2FA en cuentas críticas.
  • Plugins y themes no usados eliminados.
  • Core, plugins y themes actualizados.
  • Hosting/FTP asegurados (sin usuarios sobrantes).
  • Llaves internas rotadas tras el incidente.
  • Sin .php sospechosos en uploads, sin mu-plugins raros.
Publicado el

Virus en WordPress: señales, cómo eliminarlo y evitar reinfección

Virus en WordPress

Si estás aquí, probablemente ya viste una señal que no se siente “normal”: tu web redirige a páginas raras, aparece spam en Google, se crearon usuarios admin desconocidos, o tu hosting te avisó de malware. En WordPress, cuando algo se infecta, lo peor no es el susto: es perder tiempo haciendo “limpiezas” que no cierran la puerta real y a los días vuelve todo.

Lo que vas a lograr hoy (sin tutorial con capturas, directo a resultados):

  • Confirmar si realmente hay virus/malware en WordPress y qué tipo de infección parece.
  • Aplicar un plan de contención para que el daño no siga creciendo (redirecciones, spam, robo de tarjetas, etc.).
  • Dejar listo el terreno para limpiar bien (en el siguiente bloque), sin caer en errores comunes.

Importante: si tu sitio procesa pagos (WooCommerce), trata esto como prioridad máxima. No es paranoia: existen infecciones tipo skimmer que intentan capturar datos de pago.

Señales claras de virus/malware en WordPress (las que casi nunca son “casualidad”)

1) Redirecciones a páginas raras (solo en móvil o desde Google)

Una de las señales más típicas: tu web se ve “normal” para ti, pero usuarios reportan que los manda a casinos, premios, APKs o páginas con publicidad agresiva. A veces solo ocurre:

  • cuando entran desde Google
  • cuando navegan desde móvil
  • cuando llegan por ciertos países

Esto suele ser inyección de código (JS/PHP) o reglas escondidas para “filtrar víctimas”. Si este es tu síntoma principal, luego enlazaremos a:
WordPress redirige a páginas raras.

2) “SEO spam” (títulos raros indexados: casino, japonés, farmacia, etc.)

Cuando de pronto aparecen páginas que tú no creaste (o resultados extraños en Google), normalmente es SEO spam: el atacante inyecta URLs o contenido para posicionar palabras basura en tu dominio.

Relacionado para profundizar:
SEO spam en WordPress.

3) Usuarios admin desconocidos o cambios de contraseña que no hiciste

Si aparece un “administrador” que no reconoces, ya no es solo “virus”, es control. Muchos atacantes primero crean su usuario, luego dejan una puerta trasera (backdoor) para volver aunque limpies.

Cuando publiques este, será un gran enlace interno:
Usuarios admin desconocidos en WordPress.

4) Archivos modificados sin explicación (wp-config.php, functions.php, plugins raros)

Si notas archivos tocados “ayer” cuando tú no hiciste cambios, o ves cosas como:

  • cadenas largas tipo base64
  • scripts incrustados en functions.php
  • archivos en wp-content/mu-plugins que tú no creaste

Eso suele ser inyección. Algunos atacantes esconden el malware donde casi nadie mira.

Luego enlazaremos a:
Malware en wp-config.php y
Base64 JavaScript sospechoso.

5) Tu web se puso lenta de golpe (picos de CPU, disco, tráfico raro)

Cuando hay un pico fuerte sin explicación, pueden ser bots, spam o incluso procesos maliciosos. No siempre es virus, pero si coincide con otras señales, suma puntos.

Qué NO hacer (porque casi garantiza reinfección)

  • No restaures un backup sin saber de qué fecha es el “último limpio”. Si restauras uno infectado, vuelves al mismo lugar.
  • No borres archivos al azar porque “se ven raros”. Puedes romper el sitio y dejar el backdoor vivo.
  • No instales themes/plugins nulled (piratas). Muchos vienen con puertas traseras y son una de las causas #1 de reinfección.
  • No confíes solo en “limpiadores mágicos”. Si no cierras la vulnerabilidad real (plugin, credenciales, permisos), vuelve.

Plan de emergencia (primeros 20 minutos): contén el daño antes de limpiar

Piensa en esto como “apagar el incendio” para que no se siga propagando mientras limpias.

1) Pon el sitio en modo mantenimiento (si puedes)

Si tu sitio está redirigiendo o mostrando contenido peligroso, lo más responsable es activar mantenimiento temporalmente. No es para siempre: es para evitar que más usuarios caigan o que Google te marque como “peligroso”.

2) Haz un backup, pero con una regla

Haz backup del sitio y base de datos, pero considéralo un “snapshot de evidencia”, no un backup para restaurar sin revisar. Te sirve para:

  • comparar archivos luego
  • revisar qué se modificó
  • no perder datos si algo sale mal

3) Cambia accesos críticos (para cortar al intruso)

Este es el cierre de puertas más directo. Cambia, al menos:

  • WordPress admin (y todos los admins)
  • Hosting/cPanel
  • FTP/SFTP
  • Base de datos (si sabes hacerlo o lo hará tu técnico)

Tip realista: muchos ataques se mantienen porque el atacante ya tiene acceso al hosting o FTP. Si solo cambias WordPress, vuelven a entrar por fuera.

4) Revisa si hay admin desconocidos y congela el acceso

Si detectas usuarios admin que no reconoces, no te quedes “mirando”. Ese usuario es el ancla del atacante. En la limpieza profunda se elimina bien y se revisan permisos, pero desde ya:

  • anota su nombre/correo
  • revisa fecha de creación si puedes
  • prepara la eliminación para cuando limpies

5) Si usas WooCommerce, asume riesgo hasta demostrar lo contrario

No para asustarte, sino para actuar con cabeza: si hubo infección, revisaremos en el siguiente bloque señales de skimmer (inyección de JS en checkout). Este tema se conecta con:
Credit card skimmer en WooCommerce.

Cómo saber “por dónde” entró (la pista que define si vuelve o no)

En WordPress casi siempre entra por una de estas puertas:

  • plugin o theme desactualizado
  • credenciales reutilizadas o filtradas
  • plugins/themes nulled
  • permisos de archivos inseguros
  • hosting con otra web infectada (contagio cruzado)

En el siguiente bloque haremos la limpieza con dos rutas: una rápida (si tienes backup limpio) y una profunda (si necesitas eliminar inyecciones/backdoors), y dejaremos un checklist para que la reinfección no te vuelva a golpear.

Lecturas internas recomendadas

Cómo eliminar el virus en WordPress: ruta rápida vs limpieza profunda (sin capturas)

Aquí viene la parte que define si esto se resuelve “de verdad” o si vuelve en 7 días. En WordPress, la mayoría de reinfecciones pasan por una razón simple: se limpia el síntoma (redirige, spam, popup) pero no se elimina la puerta trasera ni la vulnerabilidad que permitió entrar.

Elige tu ruta según tu situación:

  • Ruta rápida: tienes un backup reciente que estás casi seguro que estaba limpio.
  • Limpieza profunda: no confías en backups, hay señales de backdoor, o el sitio sigue reinfectándose.

Ruta rápida (si tienes un backup realmente limpio)

Esta ruta es la más efectiva cuando el backup es anterior al problema y proviene de una fuente confiable (hosting, plugin de backups serio, o export controlado). El objetivo es restaurar y luego cerrar la entrada para que no vuelva.

1) Restaura el backup limpio (archivos + base de datos)

  • Restaura archivos del sitio.
  • Restaura base de datos del mismo punto en el tiempo.

Advertencia realista: restaurar solo archivos o solo base de datos deja “mitades” que a veces reactivan la infección.

2) Actualiza todo inmediatamente (core + plugins + themes)

Si restauras y no actualizas, puedes estar dejando abierta la misma vulnerabilidad. Lo mínimo:

  • WordPress core a versión actual
  • Plugins actualizados (o eliminados si no son esenciales)
  • Theme actualizado

3) Cambia credenciales y claves (esto evita el “vuelvo por FTP”)

  • Contraseñas de WordPress (todos los administradores)
  • Hosting/cPanel
  • SFTP/FTP
  • Base de datos (si está a tu alcance)

4) Revisa usuarios admin y elimina lo sospechoso

Si aparece un administrador que no creaste, no lo dejes “para después”. En muchos casos, ese usuario es el seguro del atacante.

Si este punto te pasó, te conviene publicar luego este satélite:
Usuarios admin desconocidos en WordPress.

5) Observa 24–48 horas

Si después de restaurar + actualizar + cambiar accesos, el sitio vuelve a redirigir o reaparece spam, no es mala suerte: es señal de puerta trasera o de contagio cruzado en el hosting. En ese caso, salta a la limpieza profunda.

Limpieza profunda (cuando no confías en backups o hay reinfección)

Esta ruta es más técnica, pero es la que de verdad corta reinfecciones. La idea no es “buscar cualquier archivo raro”, sino seguir un método: comparar, identificar, eliminar, validar y blindar.

1) Congela el estado actual (backup de evidencia)

Antes de borrar nada, guarda un snapshot. Esto te salva si:

  • rompes algo por error
  • necesitas comparar qué cambió
  • tu hosting te pide evidencia

2) Reinstala el core de WordPress desde fuente oficial

La forma más limpia (sin jugar a “borrar archivos”) es reemplazar el core por uno oficial:

  • Descarga WordPress desde la fuente oficial: wordpress.org/download
  • Reemplaza carpetas del core (wp-admin, wp-includes) por las oficiales.

No toques wp-content todavía (ahí vive el 80% de infecciones).

3) Audita wp-content con enfoque (donde se esconden de verdad)

En vez de “revisar todo”, empieza por los lugares más comunes:

  • wp-content/mu-plugins/ (muchos ni saben que existe; ideal para backdoors)
  • wp-content/plugins/ (plugins abandonados o nulled)
  • wp-content/themes/ (inyecciones en functions.php, header.php, footer.php)
  • wp-content/uploads/ (sí: a veces suben PHP camuflado como imagen o archivo)

Patrones típicos sospechosos:

  • archivos .php dentro de uploads (no deberían estar)
  • código ofuscado (bloques enormes ilegibles)
  • funciones raras con cadenas largas y decodificación
  • scripts JS inyectados en header/footer

Si detectas cadenas tipo base64 o scripts raros, este satélite te encaja perfecto:
Base64 JavaScript sospechoso.

4) Revisa el wp-config.php y “cosas que no deberían estar”

wp-config.php debería tener configuración, no “lógica extra”. Señales típicas:

  • líneas enormes añadidas arriba o abajo
  • includes a archivos externos/desconocidos
  • código que ejecuta cosas “en silencio”

Relacionado:
Malware en wp-config.php.

5) Revisa la base de datos: reinfección silenciosa

Muchos limpian archivos y se olvidan que la base de datos puede volver a inyectar código. ¿Dónde mirar primero?

  • wp_options: valores que cargan scripts o redirecciones
  • posts/postmeta: contenido con iframes o scripts ocultos
  • usuarios y capacidades (roles con permisos extraños)

Señal típica: limpias archivos, pero el sitio vuelve a inyectar scripts al recargar.

6) Validación: confirma que ya no hay comportamiento malicioso

  • Prueba el sitio en móvil y escritorio.
  • Prueba entrando desde Google (si antes redirigía “solo desde buscador”).
  • Revisa que no aparezcan nuevos admins.
  • Confirma que no existan tareas raras o comportamientos automáticos.

Blindaje mínimo para que no vuelva (lo que casi nadie hace completo)

1) Elimina plugins/themes que no uses (menos superficie = menos riesgo)

Si no lo usas, no debería existir en el servidor. Muchos ataques entran por un plugin olvidado.

2) Actualizaciones + contraseñas únicas + 2FA

Esto no es “consejo genérico”: en WordPress es literalmente la diferencia entre un incidente único y una reinfección mensual.

3) WAF/Firewall (si tu web recibe mucho tráfico o ataques)

Un WAF (por ejemplo, a nivel de CDN) puede frenar muchísimos intentos automáticos. Si ya estás en Cloudflare, este concepto te encaja con tu contenido:
WAF Cloudflare.

4) Checklist de 48 horas post-limpieza

  • Revisar usuarios admin (que no reaparezca ninguno raro).
  • Monitorear redirecciones y scripts inyectados.
  • Verificar que no se creen archivos nuevos “solos” en wp-content.
  • Confirmar que Search Console/hosting ya no marque malware (si aplicaba).

Lecturas internas recomendadas

Cuando me confirmes, el siguiente paso natural para este tema es crear un tercer bloque opcional (solo si lo quieres) con un checklist de hardening más técnico: permisos recomendados, bloqueo de endpoints comunes, limpieza de tareas programadas, y señales finas de backdoor/reinfección que los plugins a veces no detectan.

Refuerzo final: cómo blindar tu WordPress para que no vuelva el malware

Si ya limpiaste el sitio (o restauraste un backup limpio), este paso es el que marca la diferencia entre “lo resolví” y “me volvió a pasar”. La mayoría de infecciones repetidas no son magia: es la misma puerta abierta (plugin vulnerable, credenciales filtradas, permisos inseguros o una configuración que facilita el acceso).

Meta de este refuerzo: que aunque vuelvan a intentar entrar, el impacto sea mínimo y tú te enteres rápido.

1) Cambia llaves internas de WordPress (corta sesiones antiguas)

Además de cambiar contraseñas, WordPress tiene claves internas (AUTH/SECURE_AUTH, etc.) que, al rotarlas, invalidan cookies y sesiones antiguas. Es un golpe directo contra accesos “pegados”.

Tip práctico: rota estas llaves después de la limpieza, y luego obliga a todos los admins a cambiar su contraseña.

2) Revisa permisos y “lugares raros” donde se esconden

Si un atacante pudo escribir archivos en tu servidor, pudo dejar algo para volver. Estos son los puntos donde más se esconden porque casi nadie mira:

  • wp-content/mu-plugins/ (carga automática; ideal para persistencia)
  • wp-content/uploads/ (PHP camuflado)
  • wp-content/themes/ (inyecciones en header/footer/functions)

Si encuentras cadenas ofuscadas o base64, revisa esto:

3) Desactiva la edición de archivos desde el panel (reduce daño si roban una cuenta)

Si alguien entra al admin, lo primero que intenta es editar theme/plugin para inyectar código. Una práctica común es deshabilitar la edición desde el panel para limitar el daño.

Beneficio real: aunque alguien logre entrar, le cuesta mucho más convertirlo en malware persistente.

4) Limpia usuarios y aplica “mínimo privilegio”

Muchos sitios tienen 2–3 administradores “porque sí”. Eso aumenta el riesgo. Deja como admin solo a quien realmente lo necesita y convierte el resto a roles menores.

Si viste un admin raro o reaparecen, este artículo satélite es clave:

5) Actualizaciones con criterio (lo que más evita reinfección)

Esto no es “consejo genérico”: el malware en WordPress entra muchas veces por plugins viejos. Define una rutina simple:

  • Actualiza WordPress core y plugins cada semana o apenas salga un parche crítico.
  • Elimina plugins que no uses (desactivar no es suficiente).
  • Evita themes/plugins “nulled”. Si no hay presupuesto, usa alternativas gratuitas oficiales antes que piratas.

6) Protege el login y corta ataques automáticos

Muchos ataques no son “personas”, son bots probando contraseñas. Medidas útiles:

  • Contraseñas únicas + 2FA para administradores.
  • Limitación de intentos de login (plugin reputado o capa del hosting/WAF).
  • Si tu hosting lo permite: reglas para bloquear patrones obvios de fuerza bruta.

Si ya usas una capa de protección externa, esto lo complementa:

7) Revisa tareas programadas y reinfección silenciosa

Un truco común es dejar algo programado para “volver a inyectar” aunque limpies. Señales:

  • archivos que reaparecen
  • cambios nocturnos sin actividad humana
  • scripts que se insertan solos en el header/footer

Cuando publiques estos satélites, encajan perfecto aquí:

8) Si tienes WooCommerce: revisa el checkout (skimmer)

Si tu sitio vende, no te quedes solo con “ya no redirige”. Hay infecciones que solo atacan el checkout. Señales típicas:

  • scripts nuevos cargando en la página de pago
  • código extraño en theme o plugins relacionados al checkout
  • alertas del navegador o del proveedor de pagos

Checklist de 10 minutos (para saber si quedaste “limpio y firme”)

  • No hay usuarios admin desconocidos.
  • No hay archivos PHP en uploads ni mu-plugins raros.
  • Claves internas (salts) rotadas y contraseñas nuevas para admins.
  • Plugins no usados eliminados.
  • 2FA activo para administradores.
  • Capas anti-bot (limitación de intentos / WAF / hosting) aplicadas.
  • Monitor de cambios o alertas del hosting activas (si existe).

Si tu síntoma principal fueron redirecciones o spam en Google, refuerza con estos temas:

Publicado el

WordPress redirige a páginas raras: causas reales y cómo detectar si es hack o configuración

wordpress redirige a paginas

Que tu WordPress te mande a páginas raras (casino, “tu iPhone tiene virus”, premios falsos, descargas extrañas) no es “un bug cualquiera”. Casi siempre es una de estas 3 cosas: inyección en tu sitio (tema/plugin/JS), reglas en el servidor (.htaccess) o problema fuera de WordPress (DNS/Cloudflare).

En este bloque vas a lograr algo concreto: identificar el patrón exacto de la redirección y con eso saber en qué capa está el problema. Eso te ahorra horas y evita el típico error de “borré algo y volvió”.

Lo que vas a aprender a hacer en 10 minutos:

  • Confirmar cuándo ocurre la redirección (móvil, Google, incógnito, visitantes nuevos).
  • Distinguir si es un redirect de servidor (301/302) o un “salto” por JavaScript.
  • Definir la ruta correcta de solución sin romper tu web.

Alerta rápida: si un “soporte” te dice que instales un script, pegues código raro o pagues para “desbloquear” tu web, desconfía. Las redirecciones maliciosas viven de la urgencia.

Primero: confirma el patrón (esto define la causa)

Responde estas preguntas con total honestidad. No necesitas herramientas avanzadas; solo observar bien el comportamiento:

1) ¿Pasa solo en móvil o también en PC?

  • Solo móvil: suele ser inyección JavaScript que detecta el navegador móvil, o scripts de anuncios maliciosos.
  • En móvil y PC: puede ser .htaccess, plugin/tema comprometido o DNS si es global.

2) ¿Pasa solo en incógnito o a “visitas nuevas”?

  • Solo incógnito / visitas nuevas: típico de inyecciones que se activan 1 vez por sesión (para que tú no lo notes fácil).
  • Siempre, sin excepción: suele ser redirección de servidor (.htaccess/DNS) o un plugin muy agresivo.

3) ¿Pasa solo cuando entras desde Google (no desde acceso directo)?

  • Solo desde Google: suena a cloaking o SEO spam (el sitio se comporta “normal” si entras directo, pero “malo” si vienes de buscador).
  • También entrando directo: más probable .htaccess/JS/plugin.

4) ¿Pasa en todo el sitio o solo en algunas URLs?

  • Todo el sitio redirige: piensa primero en .htaccess, configuración del servidor o DNS.
  • Solo algunas páginas: suele ser tema/plantilla, un plugin específico, o contenido inyectado en una página/post.

5) ¿La redirección ocurre “instantáneo” o después de 1–2 segundos?

  • Instantáneo (apenas cargas): más probable redirect de servidor (301/302) o DNS.
  • Después de 1–2 segundos: muchas veces es JavaScript inyectado (carga tu web y luego “salta”).

Matriz rápida: síntoma → causa probable → dónde mirar después

  • Solo móvil → JavaScript/ads injection → revisar tema (header/footer) y plugins recientes.
  • Solo desde Google → cloaking/SEO spam → revisar plugins, tema y señales de URLs spam.
  • Toda URL redirige → .htaccess o DNS → mirar .htaccess y configuración de DNS/Cloudflare.
  • Solo algunas URLs → plantilla/post/plugin → revisar plugins y contenido inyectado en esas páginas.
  • Solo incógnito / visitas nuevas → malware “selectivo” → revisar JS, plugins y archivos sospechosos.

Con esto ya deberías tener una sospecha fuerte de la capa responsable. Ahora vamos a confirmarlo con 3 pruebas simples.

Diagnóstico rápido: 3 pruebas simples para confirmar el origen

Prueba 1: incógnito + cambia de red (Wi-Fi vs datos móviles)

Abre tu web en incógnito y prueba:

  • En tu Wi-Fi
  • Con datos móviles (o desde el celular compartiendo internet)

Cómo interpretar:

  • Si cambia según la red, puede haber cache/CDN o incluso algo a nivel DNS/ISP (menos común, pero pasa).
  • Si es igual en todas, el problema está en tu sitio (tema/plugin/.htaccess) o DNS global.

Prueba 2: ¿es un redirect “real” (servidor) o un “salto” por JavaScript?

Observa el comportamiento:

  • Redirect de servidor: la página rara abre casi al instante, sin que veas tu web “cargar”.
  • Redirect por JavaScript: ves tu web cargar 1–2 segundos y luego te manda a otro sitio.

Por qué importa: si es servidor, casi seguro miras .htaccess / reglas / DNS. Si es JS, miras tema, plugins y scripts.

Prueba 3: desactiva “lo que más suele mentir”: caché y optimización (temporal)

Muchos hacks se esconden “detrás” de cachés o minificadores. Si tienes plugins de caché/optimización, el diagnóstico suele mejorar si los desactivas temporalmente (solo para probar).

  • Si al desactivar caché/optimización el problema desaparece o cambia, puede haber inyección en scripts minificados o cacheados.
  • Si no cambia nada, apunta más a .htaccess, plugin/tema comprometido o DNS.

Nota: no es la solución final; es una prueba para acotar la causa.

Qué NO hacer (porque empeora o tapa el problema)

  • No restaures cualquier backup “a ciegas”. Si no cierras la puerta (plugin vulnerable/credenciales), vuelve.
  • No borres archivos al azar. Puedes romper el sitio y el backdoor seguir vivo.
  • No instales 5 plugins de seguridad desesperado. A veces solo agregas complejidad y conflictos.
  • No asumas que “si a mí no me redirige, ya está bien”. Mucho malware es selectivo (móvil, visitas nuevas, desde Google).

Idea clave: tu misión no es “parchar un síntoma”. Tu misión es descubrir qué capa está empujando la redirección. En el siguiente bloque pasamos a soluciones por escenario (servidor/.htaccess, JS/tema, plugins, cloaking y el caso DNS).

Lecturas relacionadas (para completar el cluster)

Soluciones por escenario: cómo detener las redirecciones sin romper tu WordPress

Ya con el patrón identificado, ahora sí puedes ir directo a la capa correcta. Este bloque está armado para que avances como “árbol de decisión”: si tu síntoma coincide, haces ese bloque y validas. Si no coincide, pasas al siguiente.

Meta realista: dejar tu sitio sin redirecciones y sin “puertas abiertas”. Si solo quitas el síntoma pero no el origen, suele volver.

Escenario A: toda la web redirige (o redirige instantáneo)

Cuando todas las URLs redirigen o el salto es inmediato, normalmente es:

  • .htaccess alterado (Apache/LiteSpeed), o
  • reglas del servidor (Nginx), o
  • un cambio en DNS/Cloudflare (lo cubrimos como escenario D).

A1) Revisa y “desinfecta” .htaccess (si existe)

En muchos hostings, el archivo .htaccess está en la raíz del sitio (donde está wp-config.php). Lo que buscas son señales como:

  • Bloques enormes con texto raro que no reconoces
  • Reglas de redirección a dominios extraños
  • Código ofuscado o líneas muy largas sin explicación

Acción segura: no borres todo a lo loco. Haz esto:

  • Renombra el archivo a .htaccess.bak (así puedes volver atrás).
  • Genera uno limpio guardando los enlaces permanentes desde WordPress (si puedes entrar) o restaurando el bloque estándar.

Validación: prueba en incógnito y desde móvil. Si el redirect desaparece, el problema estaba en reglas a nivel servidor.

Si tu web se rompe sin .htaccess: significa que sí dependías de reglas válidas (permalinks). En ese caso, restaura lo básico y elimina solo lo sospechoso.

Escenario B: redirige después de 1–2 segundos (parece “salto”)

Este es el patrón más típico de JavaScript inyectado. La web carga normal, y luego te manda a otro lado (muchas veces solo a móviles o visitas nuevas).

B1) Entra por el lado más probable: tema (header/footer/functions)

La inyección suele vivir en:

  • header.php y footer.php
  • functions.php
  • un archivo script agregado recientemente

Qué buscar:

  • Scripts que cargan desde dominios que no conoces
  • Cadenas largas raras, texto ofuscado, llamadas a eval o base64_decode
  • Scripts insertados “al final” del footer

Acción segura: si sospechas del tema:

  • Temporalmente cambia a un tema estándar (si tienes acceso) para probar.
  • Si el redirect desaparece al cambiar de tema, el problema está en el tema (o en un child theme).

Consejo: si usas un tema nulled/pirata, asume que es culpable hasta demostrar lo contrario. Es una de las causas más repetidas.

B2) Revisa plugins que inyectan scripts

Muchos redirects vienen de plugins de:

  • popups / publicidad / monetización
  • optimización/minificación
  • scripts de header/footer
  • “security scanners” dudosos

Prueba rápida: desactiva temporalmente los plugins más relacionados con scripts/caché. Si desaparece, reactiva uno por uno hasta encontrar el culpable.

Validación: siempre prueba en móvil + incógnito. Muchos hacks están diseñados para no afectarte a ti “todo el tiempo”.

Escenario C: redirige solo en algunas páginas (no en todo el sitio)

Cuando el redirect ocurre solo en ciertas URLs, normalmente es:

  • contenido inyectado en esa página/post
  • una plantilla específica del tema
  • un plugin que afecta solo cierto tipo de contenido

C1) Revisa si hay scripts “pegados” en el contenido

Esto pasa más de lo que parece, sobre todo si el sitio fue comprometido vía credenciales y el atacante editó páginas.

  • Revisa el editor de la página afectada (incluyendo widgets/HTML personalizado si usas constructor).
  • Busca bloques HTML extraños, iframes ocultos o scripts insertados.

Tip: si el ataque es “SEO spam”, a veces crean páginas nuevas y tú ni te enteras. Por eso conviene revisar la lista de páginas recientemente modificadas.

C2) Revisa la plantilla que usa esa página

Si solo falla un tipo de página (por ejemplo, productos o posts), puede ser una plantilla específica (single.php, page.php, templates del builder, etc.).

Acción práctica: cambia temporalmente a un tema estándar para confirmar si el problema es del tema. Si desaparece, ya acotaste el origen.

Escenario D: tu WordPress “se ve limpio” pero igual redirige (DNS/Cloudflare)

Este caso confunde a cualquiera: revisas WordPress, desactivas plugins, cambias tema… y aun así redirige. Aquí debes pensar en DNS hijacking o cambios en el proxy/CDN.

D1) Señales de DNS/Cloudflare comprometido

  • La redirección pasa incluso con un HTML simple
  • El hosting dice “todo ok”, pero los visitantes siguen redirigiendo
  • La redirección cambia según la región/red

Qué hacer en simple: verifica que tus DNS apunten al hosting correcto y que nadie haya cambiado tu zona. Este tema lo cubrimos a fondo en:

Regla: si tienes Cloudflare, revisa acceso a la cuenta y cambia contraseñas/2FA. Muchos ataques no tocan WordPress: tocan la capa DNS/CDN.

Checklist final de limpieza (para que no vuelva)

Una vez que el redirect se detuvo, haz este cierre:

  • Actualiza WordPress core, plugins y tema (todo lo que se quedó atrás es riesgo).
  • Elimina plugins/temas que no uses (incluso inactivos).
  • Cambia contraseñas otra vez si encontraste admin desconocidos o backdoors (porque pudieron copiar credenciales).
  • Revisa uploads: archivos .php dentro de wp-content/uploads son sospechosos en la mayoría de sitios.
  • Activa medidas de hardening básicas (2FA admin, deshabilitar editor, limitar intentos).

Si tu caso fue más amplio (SEO spam, backdoors, reinfección), conviene complementar con:

Lecturas relacionadas (para reforzar el cluster)

Cuando el problema no está “dentro” de WordPress: DNS, Cloudflare y verificación final

Si ya desactivaste plugins, cambiaste de tema, revisaste .htaccess y aun así hay redirecciones… muchas veces el atacante no tocó WordPress: tocó la capa de dominio/DNS o la cuenta de Cloudflare. Este escenario es más común de lo que parece porque, cuando controlan DNS, pueden redirigir tráfico sin dejar “huellas” claras en tus archivos.

En esta sección vas a lograr:

  • Detectar si el redirect viene por DNS/Cloudflare.
  • Asegurar tu dominio para que no lo vuelvan a tomar.
  • Hacer una verificación final que realmente confirme que quedó limpio.

Señales fuertes de DNS hijacking o Cloudflare comprometido

  • La redirección ocurre incluso si subes una página HTML simple (sin WordPress) al hosting.
  • A ti te funciona “a veces”, pero a visitantes nuevos o desde otra red los manda a otro sitio.
  • El hosting te dice que no ve malware, pero el problema persiste.
  • Usas Cloudflare y ves reglas/redirects que no recuerdas haber creado.

Idea clave: cuando DNS/Cloudflare está comprometido, puedes limpiar WordPress 10 veces… y seguirá pasando.

Checklist de rescate en DNS (sin pasos con capturas)

1) Asegura el correo dueño del dominio (primero)

Muchos “robos” de dominio empiezan por el correo del dueño. Si el atacante controla el email, puede resetear accesos del registrador y Cloudflare.

  • Cambia la contraseña del correo.
  • Activa 2FA (siempre).
  • Revisa sesiones/dispositivos desconocidos.

2) Entra al registrador del dominio y revisa cambios recientes

  • Verifica que el dominio siga en tu cuenta (y que el email sea el tuyo).
  • Revisa si cambiaron DNS (nameservers) o registros (A, CNAME, etc.).
  • Activa 2FA del registrador y cambia contraseña.

Si ves nameservers que no reconoces, eso explica casi cualquier redirección “fantasma”. Devuélvelos a los correctos y refuerza seguridad.

3) Si usas Cloudflare: revisa 3 zonas “típicas de ataque”

En Cloudflare, los atacantes suelen tocar:

  • Rules / Redirect Rules: reglas que envían visitantes a otro dominio.
  • DNS: A/CNAME apuntando a otro servidor.
  • Workers: scripts que interceptan tráfico (si tu plan lo permite).

Acción práctica: si encuentras una regla o Worker que no configuraste, desactívalo y cambia credenciales + activa 2FA.

Referencia oficial (Cloudflare WAF/seguridad en general):

Verificación final: cómo confirmar que realmente quedó resuelto

No te quedes con “parece que ya no redirige”. Los ataques modernos son selectivos (solo móvil, solo visitas nuevas, solo desde Google). Haz estas comprobaciones:

1) Prueba cruzada en 4 condiciones

  • Móvil con datos (sin Wi-Fi)
  • PC en incógnito
  • Otra red (por ejemplo, desde el teléfono de un familiar)
  • Entrando desde Google (si tu sitio está indexado)

Si falla en una sola condición, todavía hay una capa comprometida (JS selectivo, caché/CDN, DNS o cloaking).

2) Si tu sitio aparece “peligroso” en navegadores o Google

Cuando ya limpiaste, revisa el reporte de seguridad en Search Console. Si había advertencias, ahí verás el estado.

Tip importante: si el hack fue SEO spam, además de limpiar, debes asegurarte de que las URLs falsas devuelvan 404/410 y no se sigan generando.

3) Limpia cachés después de corregir (para no “perseguir fantasmas”)

  • Caché de tu plugin (si usas)
  • Caché del servidor/hosting (si aplica)
  • Caché/CDN (Cloudflare)

Esto evita que tú veas “una versión vieja” mientras los visitantes ven otra.

Prevención para que no vuelva (lo mínimo que sí marca diferencia)

1) Hardening básico en WordPress

Guía oficial recomendada:


Hardening WordPress (oficial)

  • 2FA para administradores
  • Eliminar plugins/temas que no uses
  • Actualizar todo (core/plugins/tema) con disciplina
  • Evitar temas/plugins nulled

2) Seguridad del dominio (la capa que más duele si cae)

  • 2FA en el registrador
  • Contraseña única y fuerte
  • Correo del dominio con 2FA
  • Revisar accesos y cambios periódicamente

Una frase que te ahorra problemas: si el atacante controla tu dominio, controla tu tráfico. Por eso esta capa vale oro.

Lecturas relacionadas (para completar el cluster)

Publicado el

WordPress hackeado: qué hacer para recuperarlo, limpiarlo y evitar que se reinfecte

WordPress hackeado

Si tu web en WordPress empezó a redirigir a páginas raras, aparecen URLs tipo casino/medicinas en Google, ves usuarios admin que no creaste o tu hosting te avisó de malware, lo más probable es que tu sitio esté comprometido. Y aquí va la verdad incómoda: en WordPress el problema casi nunca es “un archivo suelto”, sino una puerta abierta (plugin vulnerable, credenciales filtradas, tema nulled, acceso FTP expuesto) que permite reinfección.

En este bloque vas a lograr 3 cosas concretas:

  • Confirmar si realmente es un hack (y qué tipo).
  • Cortar el acceso del atacante antes de “limpiar”.
  • Preparar el terreno para una limpieza segura sin romper tu sitio.

Importante: no te apures a instalar “plugins milagro” ni a borrar archivos al azar. La mayoría de reinfecciones ocurren porque la gente limpia “por encima” sin cerrar la vía de entrada.

Señales típicas de un WordPress hackeado (y qué significan)

Estas son las señales más comunes, con la interpretación más probable:

  • Redirecciones (solo a veces, o solo desde celular): suele ser inyección en JavaScript, .htaccess alterado o malware que detecta el user-agent.
  • SEO spam (URLs raras indexadas que tú no creaste): casi siempre hay páginas generadas o código inyectado que sirve contenido spam a Google.
  • Usuarios admin desconocidos o cambios de permisos: indica acceso a wp-admin o creación de cuentas vía backdoor.
  • Archivos modificados (wp-config.php, index.php, functions.php): típico de backdoors y persistencia.
  • Alertas del hosting, bloqueo o “malware detected”: el servidor encontró patrones (a veces reales, a veces falsos positivos, pero hay que revisar).
  • Sitio marcado como peligroso en navegadores: puede ser malware real o inyección que dispara listas de seguridad.

Si tienes 2 o más de estas señales, lo correcto es asumir “compromiso” y ejecutar el plan de contención.

Antes de limpiar: contención urgente (para que no te sigan metiendo cosas)

Este paso es el que más gente se salta… y por eso el malware “vuelve” aunque creas que lo quitaste. La limpieza sirve de poco si el atacante sigue con acceso.

1) Pon el sitio en modo mantenimiento (temporal)

No necesitas complicarte: la idea es reducir daño y evitar que Google rastree contenido infectado mientras trabajas.

  • Si tienes un plugin de mantenimiento confiable ya instalado, úsalo.
  • Si no, lo mínimo es mostrar una página simple (aunque sea desde el hosting) mientras resuelves.

Tip práctico: si el hack está generando spam o redirecciones, no conviene dejar el sitio “vivo” horas mientras haces pruebas.

2) Cambia contraseñas críticas (en este orden)

Si el atacante entró por credenciales robadas, esto le corta el camino de vuelta.

  • Hosting/cPanel (o panel del proveedor)
  • FTP/SFTP
  • Base de datos (usuario DB)
  • WordPress Admin (todos los administradores reales)
  • Email asociado al dominio (muy importante: con esto resetean todo)

Regla: contraseñas largas y únicas. Si usas la misma en varios sitios, el problema se propaga.

3) Revisa usuarios administradores y elimina los desconocidos

Ve a Usuarios en WordPress (si puedes entrar) y busca:

  • Admins que no reconoces
  • Usuarios con nombres raros o correos desconocidos
  • Roles cambiados (un editor que ahora es admin)

Muy importante: antes de borrar, toma nota del usuario/correo para evidencia. A veces sirve para entender cómo entraron.

4) Revoca accesos “invisibles” (el clásico: llaves guardadas)

Si compartiste accesos con freelancers/agencias en el pasado, o usaste plugins de acceso remoto, asume que una credencial pudo filtrarse.

  • Cambia credenciales y elimina cuentas que ya no deberían existir.
  • Si hay cuentas FTP antiguas, bórralas o desactívalas.

Haz un respaldo “para evidencia” antes de tocar archivos

Suena raro, pero es clave: antes de limpiar, guarda una copia del estado actual. ¿Por qué?

  • Si rompes algo, puedes comparar y recuperar archivos críticos.
  • Si hay reinfección, puedes identificar qué volvió a aparecer.
  • Si necesitas soporte del hosting, ayuda tener evidencia.

Qué respaldar como mínimo:

  • La carpeta wp-content completa (plugins, themes, uploads).
  • La base de datos.
  • Archivos raíz: wp-config.php y .htaccess (si existen).

Consejo: guarda el backup fuera del servidor (tu PC o almacenamiento externo). Si lo dejas en el mismo hosting, no es “respaldo”, es otra copia vulnerable.

Identifica el “tipo de hack” (te ahorra horas en la limpieza)

Sin capturas y sin herramientas raras, puedes hacer un diagnóstico rápido:

  • Si hay redirecciones: sospecha de .htaccess, inyección en header/footer del tema, o scripts inyectados.
  • Si hay SEO spam indexado: sospecha de páginas/plantillas generadas y contenido servido a bots (a veces solo Google lo WordPress muestra).
  • Si hay admin desconocido: sospecha de credenciales filtradas, plugin vulnerable o backdoor.
  • Si el hosting detectó malware: puede estar en uploads, en plugins nulled, o en archivos de tema.

Deja esto listo porque en el siguiente bloque vamos a limpiar por capas (core, plugins/temas, uploads, backdoors) y luego a cerrar la puerta para que no vuelva.

Lecturas relacionadas para seguir (cluster WordPress)

Limpieza segura por capas (sin romper tu sitio)

Ahora sí: limpiar. La idea es hacerlo por capas para que no te quedes con “sensación de limpieza” mientras el backdoor sigue vivo. Si en algún punto encuentras algo demasiado raro, no borres a ciegas: primero renombra (por ejemplo, archivo.php → archivo.php.bak) y valida si el sitio vuelve a la normalidad.

Capa 1: WordPress core limpio (wp-admin y wp-includes)

Una forma muy efectiva de eliminar modificaciones al núcleo es reemplazar los archivos core por una copia limpia, manteniendo tu contenido y configuración.

  • Qué se reemplaza: carpetas wp-admin y wp-includes por versiones limpias.
  • Qué NO se toca: wp-content (tus temas, plugins, uploads) y wp-config.php.

Este enfoque se recomienda con frecuencia en soporte de WordPress (re-subir core limpio y reemplazar archivos raíz como wp-login.php excepto wp-config.php y .htaccess si lo usas).
Referencia (WordPress.org Support)

Por qué funciona: si te inyectaron cosas en archivos del core, se van de inmediato. Pero ojo: si la entrada fue por plugin vulnerable o credenciales, igual debes cerrar esas puertas (y ya lo hiciste en el bloque anterior).

Capa 2: Plugins y temas (la causa #1 real)

En la práctica, la mayoría de hacks de WordPress vienen por:

  • Plugins desactualizados con vulnerabilidades conocidas
  • Temas o plugins “nulled” (piratas) que traen backdoors
  • Plugins abandonados/inactivos que quedaron instalados

Plan rápido:

  • Elimina plugins/temas que no uses (incluso si están inactivos).
  • Actualiza todo lo que sí uses (core + plugins + tema).
  • Reinstala desde fuente oficial los plugins/temas críticos (descarga limpio y reemplaza).

Señal de que ibas por buen camino: al borrar un plugin “sospechoso”, desaparecen redirecciones, ventanas raras o scripts inyectados.

Capa 3: Backdoors escondidos (donde casi siempre se reinfecta)

Cuando un sitio “vuelve a infectarse” a los días, normalmente quedó un backdoor en uno de estos lugares:

  • wp-content/uploads/ con archivos .php camuflados (muy común).
  • mu-plugins (plugins “must-use”) si existe esa carpeta.
  • Archivos del tema: functions.php, header.php, footer.php.
  • Archivos raíz raros con nombres aleatorios (ej: wp-old.php, cache1.php).

Qué buscar (patrones típicos): textos como base64_decode, eval, cadenas largas ofuscadas, llamadas externas raras, y scripts que se “inyectan” en el HTML.

Ojo: no todo base64 es malware, pero en hacks reales suele aparecer junto con ofuscación y comportamiento extraño.

Capa 4: Redirecciones y “SEO spam” (si Google indexó basura)

Si tu problema es que WordPress redirige o se ven URLs spam en Google, revisa estos puntos clave:

  • .htaccess (si lo usas): busca reglas desconocidas, redirects raros o bloques enormes que no recuerdas.
  • Inyección JS en tema o plugins: scripts que cargan cosas externas o detectan bots.
  • Contenido servido solo a Google: a veces el spam no se ve cuando tú visitas normal, pero sí cuando rastrea un bot.

Después de limpiar, entra a Search Console y revisa el Security issues report (si Google detectó hack/malware):
Security issues report (Google Search Console)

Si quedaron URLs spam indexadas, puedes usar el reporte de Removals (ocultación temporal mientras arreglas definitivamente):
Removals report (Google)

Regla SEO importante: esas URLs spam deben terminar dando 404 o 410 o desaparecer de verdad; el removal ayuda, pero no reemplaza la limpieza real.

El punto crítico: evitar reinfección (la diferencia entre “arreglé” y “se arregló”)

Este es el tramo que define si tu web queda estable o si en 7 días vuelves al infierno.

1) Asegura el panel de WordPress (hardening básico)

WordPress tiene una guía oficial de hardening con prácticas recomendadas:
Hardening WordPress (oficial)

Acciones que suelen dar el mayor impacto con el menor esfuerzo:

  • Desactiva el editor de archivos desde el panel (evita que un intruso edite plugins/temas desde wp-admin).

En wp-config.php (idealmente cerca de otras constantes), añade:

define('DISALLOW_FILE_EDIT', true);
  • Activa 2FA para administradores (si usas plugin confiable).
  • Limita intentos de login (reduce brute force).

2) Revisa permisos de archivos y elimina “sobras”

  • Elimina plugins/temas que no uses.
  • Evita dejar backups viejos como .zip en la raíz del sitio (son un regalo para atacantes).
  • Si encuentras .php dentro de uploads sin razón clara, es altamente sospechoso.

3) Añade una capa WAF/CDN (cuando quieres dormir tranquilo)

Una capa WAF puede bloquear patrones de ataque comunes y ayudar a frenar explotación automática de vulnerabilidades.

Referencia general:
Cloudflare WAF (overview)
y documentación:
Cloudflare WAF Docs

Nota realista: un WAF no reemplaza actualizar plugins ni arreglar credenciales, pero sí reduce el “ruido” y ataques automáticos.

Validación final: cómo saber si quedó limpio

  • Tu sitio ya no redirige (prueba desde celular y modo incógnito).
  • No aparecen usuarios admin extraños.
  • No hay filtros raros de reenvío (si tienes emails asociados) ni cambios de configuración inesperados.
  • Search Console deja de mostrar alertas de seguridad (si existían).
  • El hosting deja de detectar malware (si te avisaba).

Consejo práctico: si limpiaste pero el hack regresa, no lo tomes como “mala suerte”: casi siempre quedó un backdoor o hay un plugin vulnerable que volvió a abrir la puerta.

Lecturas relacionadas (para profundizar sin canibalizar)