Un WordPress hackeado rara vez se arregla con una limpieza rápida. Si ya aparecen avisos de Google, alertas del hosting, redirecciones extrañas o cambios que nadie ha hecho, borrar archivos “sospechosos” puede ocultar el problema sin resolverlo. En una intrusión, cada minuto cuenta, pero también cada prueba: sin evidencia, es fácil limpiar a medias y dejar la puerta abierta.
La recuperación tras hackeo: forense y limpieza profunda consiste en aislar el sitio, preservar evidencias, identificar el vector de entrada, limpiar malware y backdoors en archivos y base de datos, revisar usuarios y cron jobs, restaurar con validación y endurecer el sitio para evitar una reinfección. Así se recupera el control real, se acota el alcance del daño y se vuelve a producción con más seguridad y menos riesgo de recaída.
Resumen del proceso
- Aísla el sitio y corta el acceso sin perder evidencias.
- Cambia contraseñas y revisa usuarios con permisos altos.
- Guarda copias de archivos, base de datos y logs antes de tocar nada.
- Localiza el vector de entrada y el alcance real del compromiso.
- Limpia archivos, base de datos, tareas programadas y archivos ocultos.
- Restaura con una copia limpia o reconstruye si no existe una fiable.
- Verifica con escaneos, Search Console e indexación antes de volver a publicar.
- Endurece el sitio para reducir la probabilidad de reinfección.
La limpieza real no se limita a borrar un archivo raro. Un atacante suele dejar varias pistas, como si escondiera llaves de repuesto en distintos cajones.
Aísla el sitio y conserva pruebas
Aísla el sitio antes de limpiar nada. Ese primer movimiento evita más daños y, al mismo tiempo, conserva la escena del incidente. Piénsalo como cerrar una tienda después de un robo antes de mover la caja registradora.
Corta el acceso sin borrar nada
Pon el sitio en mantenimiento o restringe el acceso por IP si puedes hacerlo desde el hosting. Si el proveedor permite un modo de emergencia, úsalo. Si no, cambia la página pública por una pantalla simple y evita tocar archivos del núcleo de WordPress.
Haz tres copias antes de intervenir. Guarda una copia completa de archivos, otra de la base de datos y otra de los logs del servidor. Este paso suele tardar entre 10 y 30 minutos, según el tamaño del sitio.
El error típico aquí es entrar a borrar cosas “sospechosas” por impulso. Eso rompe la cadena de pruebas y complica saber qué pasó. También deja al atacante sin rastro, que es justo lo contrario de lo que se necesita en una fase forense.
Cambia accesos críticos ya
Cambia contraseñas de WordPress, hosting, FTP/SFTP, base de datos y correo asociado. Hazlo desde un equipo limpio, no desde el mismo navegador donde se administraba el sitio comprometido. Si alguien reutiliza la misma clave en varios servicios, cámbiala en todos.
Activa autenticación en dos pasos en cuanto sea posible. Es como poner un segundo cerrojo. No frena todo, pero corta muchos accesos automáticos.
Un caso habitual: el sitio parecía limpio, pero el atacante seguía entrando por el correo del administrador. Cambiar solo WordPress no sirvió. Al cerrar el correo y el FTP, la reinfección se detuvo.
La parte forense no termina en “guardar una copia”: también importa mantener la integridad de las pruebas. Conviene registrar fecha, hora, responsable, origen de cada copia y el hash de archivos, base de datos y logs del servidor para preservar la cadena de custodia. Si después hay que escalar el caso al hosting, a un perito o a un equipo legal, esa trazabilidad evita dudas sobre si una evidencia fue alterada.
En incidentes reales, una captura de pantalla, una exportación de logs y un volcado completo con hashes SHA-256 pueden marcar la diferencia entre reconstruir bien el ataque o perder la pista del vector de entrada.
Identifica el alcance y el origen
Identifica por dónde entró y hasta dónde llegó el ataque. Sin esa respuesta, la limpieza queda coja. Es como arreglar una gotera sin mirar el tejado.
Revisa logs y señales de entrada
Empieza por los registros del servidor, del panel de control y de WordPress. Busca accesos raros, cargas de archivos en horas extrañas y peticiones repetidas a formularios, XML-RPC o wp-login.php. Si hay muchos intentos seguidos, suele haber fuerza bruta o robo de credenciales.
Los datos apuntan a que una gran parte de intrusiones en WordPress empieza por extensiones desactualizadas o contraseñas débiles. Wordfence y otros proveedores de seguridad repiten ese patrón año tras año. Wordfence publica análisis periódicos sobre estas tendencias.
Localiza el vector de entrada
Mira plugins, temas, formularios, usuarios nuevos y subidas recientes. El vector de entrada es la puerta usada para entrar. Puede ser un plugin vulnerable, una clave robada o un archivo subido por una ruta mal protegida.
La mayoría de guías dice que hay que “actualizar todo”. Lo que no mencionan es que primero hay que saber qué agujero se abrió, porque si no se corrige ese punto, el sitio se vuelve a infectar en días.
Calcula el alcance real
Comprueba si el atacante solo cambió archivos o también tocó la base de datos, los usuarios y las tareas programadas. Revisa wp-config.php, .htaccess, .user.ini y cualquier PHP raro en subcarpetas. Este paso suele llevar entre 20 y 45 minutos, pero ahorra muchas vueltas después.
En la imagen de más abajo se aprecia claramente la diferencia entre una infección superficial y una que ya ha dejado persistencia.
Cuando solo se mira la carpeta de plugins, se escapan puertas traseras escondidas en uploads, temas hijo o tablas de la base de datos.
1. Aislar
Bloquear accesos y guardar pruebas.
2. Investigar
Buscar origen, alcance y persistencia.
3. Limpiar
Quitar malware, backdoors y cambios ocultos.
4. Validar
Escanear, probar y revisar Google.
Limpia archivos, base de datos y tareas
Limpia todo lo que el atacante pudo tocar. Si solo se borran archivos visibles, el problema suele volver. Es como barrer la cocina y dejar la basura dentro del horno.
Revisa núcleo, temas y plugins
Compara los archivos del núcleo de WordPress con copias oficiales. WordPress.org publica los paquetes limpios para cada versión. Si un archivo core cambia sin motivo, suele ser mala señal.
El error más frecuente en este punto es confiar en el nombre del archivo. Un PHP con nombre normal puede contener código malicioso. También pasa al revés: un archivo raro puede ser legítimo. Por eso hay que comparar contenido y fechas, no solo nombres.
Busca también archivos nuevos en uploads, themes y subcarpetas. Un web shell pequeño puede abrir la puerta a todo el sitio. Estos scripts suelen pesar poco y esconderse bien.
Limpia la base de datos
Revisa usuarios, opciones, widgets, menús, entradas, páginas y tablas personalizadas. El malware a veces inyecta enlaces, scripts o redirecciones dentro de contenido aparentemente normal. Una base de datos infectada puede mantener la infección aunque los archivos estén limpios.
Borra cuentas admin que no reconozcas y resetea las que sí deben seguir. Comprueba correos, roles y fechas de creación. Si un usuario admin apareció justo antes del ataque, merece una revisión especial.
Revisa cron, .htaccess y permisos
Mira wp-cron, tareas del sistema y cron jobs del hosting. El atacante puede programar una reinfección cada cierto tiempo. Es una trampa clásica, y sigue funcionando porque mucha gente no mira esa parte.
Revisa .htaccess, .user.ini y permisos de carpetas. También conviene buscar PHP en directorios donde solo deberían existir imágenes o documentos. Si un directorio de subidas contiene ejecutables, hay que cortar esa vía.
Un caso habitual: se limpia el plugin infectado, pero queda una tarea programada que descarga el malware cada madrugada. Al cabo de dos días, el sitio vuelve a caer. La limpieza profunda tiene que mirar esa parte.
Restaura sin volver a contaminar
Restaura solo si la copia es fiable. Si el respaldo también estaba infectado, se restaura el problema entero. Eso pasa más de lo que parece y suele descubrirse tarde.
Usa copia limpia o reconstruye
Si existe un backup anterior al ataque y está verificado, úsalo. Si no lo está, no conviene restaurarlo a ciegas. La copia de seguridad debe venir de un punto anterior al compromiso y pasar una revisión posterior.
Si no hay backup limpio, reconstruye con una instalación nueva de WordPress, temas y plugins descargados desde fuentes oficiales. Luego importa contenido y medios con cuidado. Este camino tarda más, pero evita reintroducir código sucio.
Haz una reinstalación limpia
Instala de nuevo el núcleo desde WordPress.org, elimina archivos que no deban estar y sube solo lo imprescindible. Después reinstala plugins y temas desde sus repositorios o desde copias verificadas. Reinstalación limpia no significa “borrar todo sin mirar”. Significa rehacer la parte confiable y volver a introducir lo justo.
“Eliminar solo lo visible rara vez basta. La recuperación real pasa por localizar persistencia, cortar la entrada y validar que no queda rastro activo.”
Verifica integridad antes de abrir
Comprueba sumas, fechas y diferencias entre archivos. Si algo no encaja, vuelve atrás. Este control lleva entre 15 y 40 minutos, y evita reabrir un sitio que aún está comprometido.
Si la copia de seguridad se creó después del ataque, tratarla como limpia es un error caro.
Cuando no existe un backup limpio, la recuperación tras hackeo cambia por completo: no se trata de “restaurar lo que haya”, sino de reconstruir con una base confiable. En ese escenario, lo más seguro es instalar WordPress desde cero, importar solo el contenido necesario tras revisarlo y volver a crear usuarios, temas y plugins desde fuentes oficiales. También hay que verificar que la base de datos comprometida no conserve redirecciones, enlaces spam o tablas personalizadas infectadas.
Si el sitio tenía mucho historial o personalizaciones, una reconstrucción controlada suele ser más lenta, pero reduce muchísimo el riesgo de reinfección y de arrastrar backdoors ocultos.
Valida que la limpieza sea real
Valida el sitio con varias pruebas antes de volver a producción. No basta con que “parezca bien”. Hay que demostrar que está bien.
Escanea con varias fuentes
Usa Wordfence o Sucuri para un primer control técnico. Luego compara con el antivirus del hosting si está disponible. Dos miradas detectan cosas distintas, como dos linternas en una habitación oscura.
Busca malware, redirecciones ocultas, archivos extraños y cambios recientes. También revisa si los accesos siguen intentando explotar el mismo punto. Si eso ocurre, la amenaza sigue viva o un bot sigue golpeando la puerta.
Revisa Google y search console
Entra en Search Console y comprueba si hay avisos de seguridad, acciones manuales o problemas de indexación. Google puede seguir marcando el dominio aunque el código ya esté limpio. Eso frena ventas y confianza aunque el sitio cargue bien.
Google documenta estos procesos en su ayuda oficial sobre problemas de seguridad y remoción de contenido. Google Search Central explica cómo revisar avisos y solicitar revisión.
Prueba la persistencia
Cierra sesión, vuelve a entrar, navega por zonas clave y repite los escaneos tras unos minutos. Si la infección vuelve, hay una puerta trasera escondida. También conviene revisar las páginas más visitadas, porque a veces el malware se activa solo en ciertas rutas.
| Opción |
Cuándo usarla |
Riesgo |
| Limpiar sobre el mismo sitio |
Cuando el alcance es claro y la infección está contenida. |
Medio, si quedan backdoors ocultas. |
| Restaurar un backup verificado |
Cuando existe una copia anterior al compromiso y comprobada. |
Bajo, si la copia está limpia. |
| Reconstruir desde cero |
Cuando no hay copia fiable o el sitio está muy tocado. |
Bajo, pero requiere más tiempo. |
La validación posterior debe ir más allá de un único escaneo. Tras la limpieza de malware, conviene repetir pruebas de acceso, revisar que no reaparezcan usuarios sospechosos, comprobar cron jobs activos y monitorizar si el mismo vector de entrada vuelve a disparar peticiones anómalas. Además, si Search Console sigue mostrando avisos o Google mantiene una penalización de seguridad, hay que solicitar revisión y vigilar la indexación durante varios días.
Una web puede verse correcta en el navegador y seguir arrastrando señales de compromiso en caché, resultados de búsqueda o rutas internas, así que la verificación anti-reinfección tiene que incluir observación continuada y no solo un control puntual.
Endurece el sitio y reduce recaídas
Endurece el sitio después de limpiarlo. Si no se hace, la próxima entrada puede llegar por la misma puerta. Es como arreglar una cerradura y dejar la ventana abierta.
Activa capas básicas de defensa
Usa HTTPS con cifrado TLS, activa 2FA y limita intentos de acceso. Quita plugins y temas que no uses. Actualiza solo lo que venga de fuentes fiables y revisa cada cambio con calma.
Cloudflare y Akamai publican buenas prácticas sobre mitigación de tráfico anómalo y protección en el borde. En sitios con picos de ataques, ese refuerzo ayuda mucho. Cloudflare mantiene guías prácticas sobre protección de aplicaciones web.
Reduce privilegios y expón menos
Deja menos usuarios administradores. Revisa quién necesita acceso real y quién solo lo usa de forma puntual. Menos llaves, menos lío.
También conviene limitar XML-RPC si no se usa, vigilar subidas de archivos y controlar permisos de escritura. Un permiso mal puesto puede abrir una brecha sin hacer ruido.
Encaja seguridad y cumplimiento
Si el incidente afectó datos personales, revisa obligaciones bajo RGPD y LOPDGDD. En empresas con más exposición, también puede entrar en juego la Directiva NIS2 o el ENS. AEPD, INCIBE y CCN-CERT publican material útil para responder con orden.
La mejor decisión suele ser limpiar, validar y endurecer antes de reabrir, pero solo si el alcance está bien acotado. Si el ataque tocó usuarios, base de datos y correo, conviene ir más despacio y verificar todo dos veces. Eso ahorra más problemas de los que crea.
Vigila durante varios días
Activa alertas y revisa logs durante al menos 7 días. En sitios muy expuestos, 30 días dan una lectura más realista. Los atacantes repiten intentos, y una reinfección temprana suele delatar que algo quedó mal cerrado.
WordPress.org, Google y los principales proveedores de seguridad coinciden en la misma idea: la limpieza sin verificación deja el riesgo abierto.
Errores que arruinan el resultado
Hay varios fallos que convierten una recuperación en una recaída. El más caro es apresurarse. El segundo es confiar demasiado en una única revisión.
Restaurar sin revisar el backup
Un backup también puede estar contaminado. Restaurarlo sin comprobar fechas, archivos y base de datos es como volver a meter agua sucia en un vaso limpio. Si no existe un punto anterior al ataque, toca reconstruir.
Limpiar solo lo visible
Borrar un plugin infectado no basta si quedaron usuarios admin, tareas programadas o código en la base de datos. Ese es el error más repetido. Y también el más frustrante, porque el sitio parece volver a fallar “sin razón”.
Dar el caso por cerrado demasiado pronto
No se debe abrir el sitio sin pruebas de persistencia, Search Console, indexación y escaneo posterior. Un sitio puede verse normal y seguir comprometido por dentro. Eso engaña mucho.
⚠️ Si el hosting ya ha suspendido el sitio por riesgo de infección, reabrirlo sin validación suele empeorar el bloqueo.
Cuándo no funciona este método
Este método no aplica como solución principal si el problema es solo una actualización fallida, un error visual o una caída de rendimiento sin signos de intrusión. Tampoco sirve si la intención es solo prevenir, porque aquí se trabaja sobre un incidente ya ocurrido.
Si el sitio está completamente cifrado por ransomware, o el servidor entero está comprometido, la recuperación puede salir del marco normal de WordPress. En ese caso hay que tratar también el sistema, las cuentas del servidor y, a veces, el correo y otros servicios asociados.
Cuando no hay backup limpio y el alcance es amplio, la salida más segura suele ser reconstrucción controlada, no una restauración rápida. Eso tarda más, pero evita arrastrar el problema.
Preguntas frecuentes sobre mantenimiento WordPress
¿Cómo saber si mi WordPress ha sido hackeado?
Se nota por redirecciones raras, usuarios nuevos, archivos extraños, avisos del hosting o alertas de Google. También aparecen cambios en contenido, spam o accesos que nadie reconoce. En una recuperación tras hackeo, la señal más útil suele ser comparar lo que había ayer con lo que hay hoy.
¿Cuánto tarda en recuperarse un WordPress?
Suele tardar entre 2 y 8 horas en casos simples. Si hay base de datos alterada, varios usuarios comprometidos o falta backup limpio, puede irse a uno o dos días. El tiempo real depende más de la limpieza profunda que del borrado inicial.
¿Qué hacer si hackean mi página web?
Primero hay que aislarla y guardar pruebas. Después se cambian accesos, se revisa el alcance y se limpia todo lo que haya tocado el atacante. La prioridad no es volver rápido, sino volver limpio y sin reinfección.
¿Sirve restaurar una copia de seguridad sin más?
Solo sirve si la copia es anterior al ataque y se ha comprobado. Si no, puede devolver el malware, los backdoors o los usuarios falsos. En esos casos conviene reconstruir el sitio con una reinstalación limpia y verificar cada parte.
¿Hay que revisar también la base de datos?
Sí, siempre. Muchos ataques esconden scripts, enlaces o usuarios nuevos dentro de la base de datos. Si solo se limpian archivos, el problema puede seguir activo aunque la web parezca normal.
¿Cómo sé si Google sigue marcando mi web?
Hay que revisar Search Console, los avisos de seguridad y el estado de indexación. A veces el código ya está limpio, pero Google mantiene la alerta hasta que vuelve a comprobar el sitio. Eso afecta a la visibilidad y a la confianza del usuario.
¿Puedo limpiar solo con un plugin de seguridad?
Puede ayudar, pero no sustituye una revisión completa. Un plugin detecta mucho, aunque no siempre ve tareas programadas, cambios en la base de datos o ciertas puertas traseras. En incidentes reales, la limpieza manual y la validación posterior suelen dar mejores resultados.
Cierra la recuperación y deja el sitio estable
Cierra la recuperación con una revisión final de accesos, copias limpias, logs y alertas. Después documenta qué pasó, qué puerta se abrió y qué se cambió. Esa nota ayuda mucho si el problema vuelve o si el hosting pide explicación.
La parte más útil de todo este proceso no es solo quitar el malware. Es dejar el sitio más difícil de romper la próxima vez. Y eso, en WordPress, vale más que correr.
