Mi blog de WordPress fue comprometido: recuperación y una posible relación con wp2shell
Llevo muchos años manteniendo garaged.org. Como ocurre con muchos proyectos personales, con el tiempo el blog ha acumulado artículos, plugins, cambios de configuración y bastante historia técnica.
Recientemente, mientras realizaba algunas mejoras en el servidor, encontré algo que definitivamente no esperaba: el servidor había sido comprometido y alguien había instalado un mecanismo para mantener acceso remoto como root.
Lo que comenzó como una tarea de mantenimiento terminó convirtiéndose en un pequeño ejercicio de respuesta a incidentes y recuperación.
Lo que encontré
La primera señal importante fue un script sospechoso llamado /etc/c2beacon.sh, configurado en el crontab de root:
@reboot /etc/c2beacon.sh
*/15 * * * * /etc/c2beacon.shEl script decodificaba una llave pública SSH almacenada en Base64, la copiaba a /root/.ssh/authorized_keys y se aseguraba de que el servicio SSH estuviera habilitado y funcionando.
En otras palabras, alguien había preparado el servidor para restablecer su acceso SSH cada 15 minutos y después de cada reinicio.
Esto ya no era solamente un problema de WordPress. La existencia de un mecanismo de persistencia con privilegios de root significaba que no podía seguir confiando en el sistema operativo.
Reconstruyendo la cronología
Conservé la base de datos y comencé a investigar las cuentas y otros archivos que habían quedado en el servidor.
Encontré dos cuentas de administrador de WordPress que no reconocía:
| Fecha | Hallazgo |
|---|---|
| 17 de julio de 2026 | Divulgación pública de las vulnerabilidades conocidas como wp2shell |
| 20 de julio de 2026 | Creación de w2s_fc25ca466087 |
| 23 de julio de 2026 | Creación de cacheopsafb140 |
| 10 de agosto de 2026 | Creación del script de persistencia SSH, según las marcas de tiempo del sistema de archivos |
| 11 de noviembre de 2026 | Descubrimiento del compromiso |
La primera cuenta me llamó particularmente la atención porque su correo utilizaba el dominio wp2shell.local.
La coincidencia temporal es notable. Apenas tres días antes se había divulgado públicamente wp2shell, una cadena de vulnerabilidades de WordPress identificadas como CVE-2026-63030 y CVE-2026-60137, que permitían ejecutar código de forma remota en instalaciones vulnerables sin autenticación.
¿Fue wp2shell el punto de entrada?
Es posible. Las fechas y el nombre de la cuenta sugieren una relación. Sin embargo, no cuento con suficientes registros históricos para demostrar cómo ocurrió la explotación inicial, así que prefiero considerarlo una hipótesis y no una causa confirmada.
Otro problema: cientos de miles de cuentas falsas
Al revisar la base de datos encontré que el blog había acumulado más de 612 mil cuentas de WordPress, prácticamente todas con el rol de suscriptor.
También había miles de comentarios de spam y una cantidad considerable de metadatos asociados.
Los resultados de la limpieza fueron importantes:
| Elemento | Antes | Después |
|---|---|---|
| Usuarios de WordPress | 612,318 | 1 |
| Registros de metadatos de usuarios | 9,879,875 | 51 |
| Comentarios | 7,778 | 415 |
| Comentarios clasificados como spam | 7,363 | 0 |
Después de limpiar y optimizar las tablas, además de retirar datos históricos innecesarios, la base de datos de pruebas quedó en aproximadamente 81 MB, incluyendo algunas tablas temporales de recuperación.
Afortunadamente, pude conservar los artículos, las imágenes, las categorías y los comentarios legítimos.
Reconstruir en lugar de simplemente limpiar
Debido al nivel de acceso que representaba el mecanismo de persistencia SSH, decidí no intentar reparar el servidor comprometido.
En su lugar, preparé un entorno completamente nuevo:
- Un servidor Linux limpio con Nginx, PHP-FPM y MariaDB.
- Una instalación nueva de WordPress con únicamente los plugins necesarios.
- Una base de datos restaurada después de revisarla y limpiarla en un entorno aislado.
- Contraseñas, credenciales y claves de autenticación nuevas.
- Archivos del tema revisados y contenido multimedia recuperado.
- Restricciones para SSH, MariaDB y los permisos del sistema de archivos.
- Protección mediante Cloudflare y certificados HTTPS de Let’s Encrypt.
También aproveché para eliminar integraciones antiguas y plugins que ya no necesitaba.
El sitio recuperado pasó las pruebas funcionales: diseño personalizado, artículos históricos, enlaces permanentes, navegación, paginación, imágenes, comentarios y acceso administrativo.
Todavía quedan algunas tareas de endurecimiento, especialmente los respaldos cifrados fuera del servidor, las pruebas de restauración y el monitoreo de integridad.
Lo que aprendí
La lección más importante fue que un sitio web puede funcionar aparentemente bien mientras el servidor que lo hospeda ya no es confiable.
También me quedaron varias conclusiones:
- Mantener WordPress y sus dependencias actualizados, especialmente ante vulnerabilidades críticas que ya están siendo explotadas.
- Investigar cualquier cuenta administrativa que no reconozcamos.
- No asumir que eliminar un archivo malicioso significa haber eliminado el compromiso.
- Conservar evidencia antes de realizar cambios destructivos.
- Probar las restauraciones y limpiezas de datos fuera de producción.
- Reducir los plugins y servicios innecesarios.
- Mantener respaldos protegidos de forma independiente.
- Monitorear tanto WordPress como el sistema operativo.
Otra lección importante fue descubrir cuánto facilita la recuperación mantener una separación clara entre el contenido, el software y la infraestructura.
Reflexiones finales
No puedo asegurar cuál fue el mecanismo inicial de entrada, si las cuentas sospechosas y el script de root pertenecían al mismo atacante, ni si hubo extracción de información.
Lo que sí pude comprobar es que existían cuentas administrativas no autorizadas, que se había instalado un mecanismo de persistencia por SSH y que el entorno original ya no era confiable.
Hoy el blog funciona sobre un servidor reconstruido desde cero, con su contenido histórico recuperado y los controles de acceso más importantes verificados.
No era el mantenimiento que tenía planeado, pero terminó siendo un buen recordatorio de que la seguridad no consiste únicamente en prevenir incidentes. También implica tener la capacidad de investigarlos, recuperarse y construir algo mejor después.
Ya tenía buen rato que no hacía un ejercicio de estos ! 😀