Has limpiado el malware de WordPress. Has cambiado contraseñas. Has actualizado los plugins. El escáner ya no encuentra nada.
Durante unas horas o unos días parece que el problema está resuelto.
Y entonces vuelve a aparecer un archivo extraño, una redirección, un usuario administrador que nadie reconoce, páginas de spam o cualquier otro síntoma que creías haber eliminado.
Cuando una web WordPress vuelve a infectarse después de limpiarla, seguir borrando una y otra vez los mismos archivos rara vez resuelve el problema de fondo.
La cuestión ya no es únicamente qué malware había.
Hay que averiguar qué permitió el compromiso, qué acceso sigue abierto o qué parte de la instalación no quedó realmente limpia.
Esto también explica por qué una web puede sufrir un incidente aunque hoy WordPress, sus plugins y el tema aparezcan completamente actualizados.
Una limpieza puede eliminar los síntomas visibles y aun así dejar pendiente la causa del incidente.
Hay que separar dos problemas diferentes:
1. Qué se ha modificado o introducido en la web.
Aquí entran los archivos maliciosos, usuarios desconocidos, redirecciones, spam, modificaciones no autorizadas o cualquier otro elemento introducido durante el compromiso.
2. Qué permitió que ocurriera.
Puede tratarse de una vulnerabilidad que existía en el momento del ataque, unas credenciales comprometidas, un acceso que no se había revocado, un componente que no quedó correctamente saneado u otro problema del entorno.
Eliminar lo primero no garantiza haber solucionado lo segundo.
La propia documentación de WordPress para sitios hackeados insiste en revisar los diferentes puntos de acceso, cambiar las credenciales relevantes, invalidar sesiones y posteriormente analizar cómo pudo producirse el compromiso.
Si estás todavía en la fase de localizar y retirar archivos maliciosos, primero conviene seguir un procedimiento de limpieza ordenado. En nuestra guía sobre cómo eliminar malware en WordPress sin romper la web explicamos ese proceso con más detalle.
Aquí nos centraremos en la siguiente pregunta:
¿Por qué vuelve el malware después de haber limpiado WordPress?
No existe una única explicación.
Una reinfección es un síntoma. Para saber qué está ocurriendo hay que investigar la instalación y su entorno.
Estas son algunas de las situaciones que merece la pena comprobar.
Encontrar un archivo sospechoso no significa necesariamente haber encontrado todo el compromiso.
Una instalación WordPress contiene el núcleo, plugins, temas, archivos de configuración, contenido subido por los usuarios y una base de datos. Además, existen archivos y configuraciones del servidor fuera de lo que normalmente vemos desde el escritorio de WordPress.
Por eso borrar el archivo que provoca una redirección puede eliminar el síntoma sin garantizar que no exista otra modificación relacionada.
La documentación oficial de WordPress recomienda revisar cuidadosamente la instalación después de un hackeo y presta atención específica a archivos y directorios que pueden haber sido modificados.
La solución no debería consistir en decidir si un archivo es bueno o malo simplemente por su nombre.
Hay que determinar qué archivos deberían existir, cuáles han cambiado y cuáles pueden sustituirse de forma segura por copias legítimas.
Supongamos que una vulnerabilidad en un componente permitió comprometer la web.
Puedes limpiar todos los archivos infectados correctamente.
Pero si ese componente continúa expuesto, la web puede volver a ser comprometida.
Lo mismo ocurre si el problema estaba relacionado con unas credenciales que siguen siendo válidas.
Por eso una recuperación debe responder a dos preguntas:
¿Está limpia ahora la instalación?
y
¿se ha corregido lo que permitió comprometerla?
Hasta que no puedas responder razonablemente a ambas, el incidente no debería darse por cerrado.
Esta es una de las confusiones más importantes cuando se investiga un WordPress comprometido.
Imagina que descubres malware hoy.
Entras en el escritorio y compruebas:
Eso describe el estado de la web hoy.
No demuestra qué versiones estaban instaladas cuando ocurrió el acceso inicial.
Entre ambos momentos puede haberse aplicado una actualización manual o automática. El atacante también puede haber conseguido acceso antes de que se instalara una corrección.
Por tanto, decir:
«No puede haber sido una vulnerabilidad porque ahora está todo actualizado»
no sería una conclusión suficiente.
Cuando sea posible hay que reconstruir la cronología del incidente.
Interesa saber cuándo aparecieron los primeros síntomas, qué versiones estaban instaladas aproximadamente entonces, qué componentes se actualizaron y qué información conservan los registros disponibles.
Que una web actualizada pueda ser comprometida no significa que las actualizaciones no sirvan.
Significa algo diferente.
Actualizar reduce riesgo, pero no constituye por sí solo toda la estrategia de seguridad.
WordPress recomienda utilizar versiones actuales y mantener adecuadamente la instalación. Su documentación de seguridad también plantea la protección como un sistema de capas: actualizaciones, accesos, permisos, copias, monitorización y capacidad de recuperación.
Si tu problema es que la web acumula actualizaciones pendientes y no sabes si aplicarlas puede romper algo, hemos tratado por separado cómo actualizar WordPress de forma segura.
Después de un incidente de seguridad, sin embargo, no conviene limitarse a pulsar “Actualizar todo” y considerar solucionado el problema.
Primero hay que entender qué ha ocurrido.
Cuando alguien descubre que su web ha sido comprometida, una de las primeras sospechas suele ser:
«Han entrado en mi wp-admin».
Es posible, pero no es la única vía que hay que considerar.
WordPress recomienda revisar todos los accesos relacionados con el entorno, no únicamente la cuenta del administrador.
Dependiendo de la instalación, pueden existir accesos a:
La documentación oficial sobre recuperación tras un hackeo menciona expresamente la necesidad de cambiar las credenciales de los distintos puntos de acceso y revisar todos los usuarios con capacidad para entrar en el entorno.
Por eso cambiar únicamente tu contraseña de WordPress puede ser insuficiente.
Si además nadie en la empresa sabe quién controla el hosting, dominio o las cuentas administrativas, merece la pena revisar también qué accesos de WordPress debería controlar una empresa.
Si después de una limpieza reaparecen los síntomas, no empieces otra vez borrando archivos al azar.
Conviene trabajar de forma ordenada.
Primero distingue entre un problema nuevo y un síntoma antiguo que todavía permanece visible.
Por ejemplo, una caché puede seguir mostrando contenido anterior. Los resultados de Google también pueden tardar en reflejar la limpieza de páginas spam.
En cambio, señales como estas justifican continuar investigando:
Documenta qué reaparece y cuándo.
El momento de la reaparición puede resultar útil para reconstruir lo sucedido.
Cuando el negocio está siendo perjudicado, la prioridad puede ser contener el incidente.
Pero, siempre que sea posible y seguro, conviene conservar información antes de borrar o sustituir archivos.
Una copia del estado comprometido puede ayudar posteriormente a comparar archivos, estudiar fechas y entender qué había cambiado.
Esa copia debe tratarse como potencialmente comprometida.
No debería confundirse con una copia limpia preparada para restaurar la web.
WordPress recomienda conservar un snapshot antes de avanzar con determinadas fases de la limpieza precisamente porque puede resultar útil durante el análisis posterior.
Comprueba los usuarios de WordPress, especialmente aquellos con permisos elevados.
Pregunta:
Haz la misma reflexión fuera de WordPress.
Una empresa debería saber quién controla el alojamiento y los demás accesos capaces de modificar la web.
Después de un compromiso, las contraseñas relevantes deberían ser largas, únicas y no reutilizadas entre servicios. WordPress recomienda además utilizar autenticación en dos pasos cuando sea posible.
Cambiar una contraseña es importante, pero durante una recuperación también interesa evitar que permanezcan válidas determinadas sesiones existentes.
La documentación oficial de WordPress recomienda regenerar las claves secretas de autenticación de wp-config.php como parte de la recuperación de un sitio hackeado, lo que fuerza el cierre de sesiones existentes.
No edites wp-config.php directamente si no sabes trabajar con este archivo.
Un error puede impedir que WordPress funcione correctamente.
Si administras la web como propietario y no como técnico, este es un buen punto para delegar la intervención.
Otra pregunta fundamental es:
¿los archivos instalados coinciden con los que deberían existir?
WP-CLI dispone de una función oficial para comparar los archivos del núcleo de WordPress con los checksums publicados para esa versión. También permite verificar plugins distribuidos desde WordPress.org.
Esto puede ayudar a localizar archivos modificados, aunque tiene limitaciones.
Por ejemplo, verificar correctamente el núcleo no demuestra que todo wp-content esté limpio, y un plugin premium o personalizado puede no disponer de checksums en WordPress.org.
La documentación oficial advierte precisamente de estas diferencias.
Para un propietario de una pyme la conclusión práctica no es que deba aprender WP-CLI.
Es que una limpieza seria debería poder distinguir los archivos legítimos de los que han sido modificados, en vez de basarse únicamente en que un escáner ya no muestra avisos.
Haz inventario.
Necesitas saber:
No atribuyas automáticamente el ataque a un plugin simplemente porque alguna vez haya tenido una vulnerabilidad.
Para relacionar una vulnerabilidad concreta con el incidente habría que comprobar al menos la versión afectada, la versión corregida, las fechas y las condiciones de explotación.
Una vulnerabilidad publicada hace años en otra versión del mismo plugin no demuestra qué ocurrió en tu web.
Si el malware continúa reapareciendo después de limpiar la aplicación, también hay que considerar el entorno.
La web funciona dentro de una cuenta de hosting y un servidor.
En determinadas configuraciones puede haber más de una instalación o dominio dentro del mismo alojamiento. Si existen varios sitios y no se conoce el alcance del incidente, analizar únicamente una carpeta puede dejar parte del problema sin revisar.
La documentación de seguridad de WordPress insiste en que el alojamiento, los permisos, el servidor y la monitorización forman parte de la seguridad general de la instalación.
Si no sabes dónde termina una web y empieza otra dentro de tu alojamiento, no conviene borrar directorios ni modificar permisos a ciegas.
No necesariamente.
Un escáner limpio es una buena señal.
Pero existen dos afirmaciones muy diferentes:
«La herramienta no detecta malware en este momento».
y
«Sabemos qué ocurrió, la instalación está limpia y hemos corregido la vía que permitió el compromiso».
La segunda es bastante más exigente.
Antes de cerrar el incidente deberías poder responder razonablemente a cuestiones como:
WordPress considera la monitorización una capa importante de seguridad porque permite reaccionar antes y disponer de información sobre cambios producidos en archivos o registros.
Depende.
Una copia limpia anterior al incidente puede ser extremadamente útil.
Pero restaurar una copia no responde automáticamente a la pregunta de cómo entraron.
Imagina este escenario.
Tu web fue comprometida el lunes debido a un problema que todavía no has corregido.
El viernes detectas el malware.
Restauras un backup limpio del domingo anterior.
La web vuelve a funcionar.
Pero la condición que permitió el acceso sigue existiendo.
Has recuperado el estado de la web, pero no necesariamente has eliminado la causa del incidente.
Por otro lado, también existe el problema contrario: pensar que una copia es limpia cuando en realidad ya contiene modificaciones relacionadas con un compromiso anterior.
Por eso antes de restaurar interesa saber:
de qué fecha es la copia, qué contiene y qué sabemos sobre el momento aproximado del ataque.
En nuestra guía sobre copias de seguridad de WordPress explicamos por qué una copia almacenada no equivale automáticamente a una recuperación fiable.
Precaución: restaurar una copia puede sobrescribir pedidos, formularios, usuarios, reservas o cambios realizados después de la fecha del backup. En una web empresarial no debería restaurarse producción sin entender previamente qué información se perderá.
No existe una respuesta universal.
Restaurar puede ser razonable cuando dispones de un punto limpio fiable y sabes exactamente qué datos tendrás que recuperar posteriormente.
Limpiar la instalación existente puede ser necesario cuando no existe un backup adecuado o cuando el contenido posterior al incidente tiene especial importancia.
En ambos casos hay una condición común:
hay que cerrar la vía que permitió el compromiso.
Restaurar sin corregirla puede terminar en otra infección.
Limpiar sin corregirla también.
Si necesitas una visión más amplia del proceso, consulta cómo recuperar y reforzar un WordPress tras un hackeo.
Y si acabas de descubrir el incidente y todavía no has comenzado ninguna intervención, es preferible empezar por nuestro plan de emergencia para un WordPress hackeado.
El objetivo no es simplemente conseguir que la portada vuelva a cargar.
Una recuperación debería terminar con una web que:
Además, conviene vigilar especialmente los días posteriores a la limpieza.
La aparición de nuevos archivos, cuentas, redirecciones o cambios inesperados es una señal de que el incidente necesita seguir investigándose.
No todos los problemas de WordPress requieren un especialista.
Pero una reinfección cambia el escenario.
Conviene detener las reparaciones improvisadas cuando:
En esos casos el objetivo no debería ser eliminar rápidamente el siguiente archivo que aparezca.
Hay que diagnosticar la instalación completa.
Una vez controlado el incidente, empieza una etapa diferente.
La seguridad no debería depender de recordar de vez en cuando que hay plugins pendientes.
Una web empresarial necesita mantenimiento continuo: actualizaciones controladas, copias recuperables, revisión de accesos y capacidad para detectar incidencias.
En nuestra guía de seguridad WordPress para empresas explicamos qué decisiones debería controlar una empresa aunque delegue toda la parte técnica.
Y si nadie está supervisando regularmente actualizaciones, copias, seguridad y funcionamiento, también conviene revisar qué debería incluir un servicio de mantenimiento WordPress para empresas.
La idea no es instalar más herramientas por instalar.
Es conseguir que, si algo vuelve a cambiar sin autorización, no tengas que esperar a que un cliente o Google te avisen.
Si tu WordPress vuelve a infectarse después de haberlo limpiado, considera la reaparición como información importante.
Te está diciendo que la recuperación anterior no ha cerrado completamente el incidente.
Puede quedar malware sin detectar.
Puede seguir existiendo un acceso válido.
Puede no haberse corregido la condición que permitió el compromiso inicial.
O puede ser necesario ampliar el análisis al alojamiento y al resto del entorno.
Por eso el criterio para considerar recuperada una web no debería ser simplemente:
«El escáner está verde».
La pregunta realmente útil es:
«¿Sabemos razonablemente qué ocurrió, hemos limpiado la instalación y hemos corregido aquello que podía permitir que volviera a pasar?»
Hasta que esa respuesta no sea afirmativa, merece la pena seguir investigando.
Para la actualización de este artículo se han utilizado principalmente la documentación oficial de WordPress sobre recuperación de sitios hackeados y endurecimiento de instalaciones, junto con la documentación de WP-CLI sobre verificación de integridad mediante checksums.
