Resultado en una frase
Un sitio WordPress comprometido no se recupera solo restaurando archivos. Se recupera identificando la vía de entrada, restaurando desde un respaldo limpio y endureciendo la instalación para que el problema no vuelva a pasar a los pocos días.
La alerta inicial
Por confidencialidad no publicamos el nombre del cliente ni el dominio. Lo importante es el patrón. Se trataba de un sitio corporativo en WordPress, alojado en un entorno tradicional con panel, donde la mantención de seguridad llevaba retraso y se asumía que el hosting iba a cubrir más de lo que realmente cubría.
Cuando entramos, el problema ya no era teórico. El sitio estaba indisponible y la carpeta pública había quedado sin contenido operativo. En ese punto, la pregunta no era solo cómo levantarlo de nuevo, sino qué había pasado exactamente y cómo evitar que la misma vía siguiera abierta.
Qué encontramos en la investigación
Lo primero fue revisar el rastro técnico. Los logs mostraban semanas de ruido antes del incidente final:
intentos repetidos contra /wp-login.php, exploración de rutas PHP y señales claras de que el
sitio llevaba rato siendo tanteado desde fuera.
El punto crítico apareció después. La intrusión no fue un simple problema de permisos ni un error de configuración del servidor. El patrón calzaba con explotación de un plugin vulnerable en WordPress, ejecución remota de archivos y carga de scripts PHP maliciosos. A partir de ahí, el atacante obtuvo el control necesario para dejar el sitio fuera de operación.
Línea de tiempo de la intrusión
- Primeros intentos repetidos sobre el acceso de WordPress.
Se observan solicitudes tipo POST contra
/wp-login.php, consistentes con fuerza bruta o prueba de credenciales. - Exploración de rutas y archivos expuestos.
El tráfico incluye búsqueda de scripts y endpoints que no deberían usarse en un sitio sano, una señal típica de reconocimiento previo.
- Ejecución directa del componente vulnerable.
La revisión apunta al acceso sobre
/wp-content/plugins/hellopress/wp_filemanager.php, que funcionó como punto de entrada. - Carga y ejecución de webshells.
Se detectan archivos PHP maliciosos con nombres como
xex.php,great.php,gloomed.phpyzc-639.php. - Sitio fuera de servicio y contenido público eliminado.
El resultado visible fue un sitio inoperativo y una carpeta pública sin el contenido que debía estar sirviendo la web.
Qué concluimos
La causa raíz no estaba en “WordPress en general”, sino en una instalación expuesta, con mantenimiento retrasado y un plugin de alto riesgo que no debió seguir activo. Esa combinación hizo posible que un ataque automatizado terminara escalando a una intrusión real.
También quedó claro algo que muchas empresas subestiman: volver a poner el sitio arriba sin corregir la vía de entrada es solo patear el problema. Si el plugin seguía ahí, si las claves no cambiaban y si el acceso seguía igual de expuesto, la reinfección era una posibilidad real.
Cómo restauramos el sitio
- Verificamos el alcance del compromiso antes de restaurar para no reinyectar archivos contaminados.
- Restauramos el sitio desde un backup anterior al incidente, usando una base conocida como limpia.
- Eliminamos el plugin vulnerable y cualquier componente que no aportara valor real a la operación.
- Actualizamos WordPress, plugins y temas para cerrar brechas evidentes que seguían abiertas.
- Rotamos contraseñas de cPanel, FTP, base de datos y administración de WordPress.
- Aplicamos medidas de hardening: restricciones de acceso, revisión de rutas críticas y una capa más seria de protección web.
- Validamos que el sitio volviera a producción sin arrastrar el mismo riesgo que tenía antes.
Qué cambió después de volver a producción
El sitio volvió a la normalidad, pero el valor del trabajo no estuvo solo en la restauración. Estuvo en la segunda mitad: dejar una instalación más controlada, con menos superficie expuesta y con un criterio más claro de qué mantener, qué eliminar y qué monitorear.
En otras palabras, no nos quedamos en “ya está arriba de nuevo”. El foco fue devolver continuidad sin seguir operando con la misma fragilidad que permitió el compromiso inicial.
La lección real: publicar no es proteger
Este caso sirve para decir algo incómodo, pero necesario. Un sitio web no queda protegido porque tenga un hosting contratado. Y tampoco porque exista un backup. La seguridad del sitio vive en otra capa: versiones al día, plugins bien elegidos, credenciales rotadas, acceso restringido y revisión continua de exposición.
- El hosting puede alojar, respaldar o ayudar a restaurar, pero eso no lo convierte en tu equipo de seguridad.
- Un plugin que “sigue funcionando” no necesariamente es un plugin que debería seguir instalado.
- Restaurar sin hardening deja el sitio operativo, pero no necesariamente seguro.