Nos hackearon un WordPress cliente: qué pasó de verdad

Esta semana un cliente amaneció con su servidor bloqueado por su proveedor de hosting. El motivo: su WordPress estaba atacando a un tercero. 22.000 paquetes por segundo saliendo de su propia infraestructura, sin que nadie se hubiera dado cuenta. Cuando alguien piensa en «me han hackeado la web», suele imaginarse una pantalla negra con una calavera o el típico aviso de «hackeado por» en la portada. La realidad casi nunca es tan vistosa, y por eso es más peligrosa: durante días, todo seguía funcionando en apariencia normal mientras alguien tenía el control por debajo.

Contamos lo que pasó porque es exactamente el tipo de caso que casi nunca se cuenta en público, y creemos que verlo con detalle sirve más que cualquier checklist genérico de «10 consejos para proteger tu WordPress».

La entrada no fue la que todo el mundo asume

Al revisar los registros pudimos reconstruir la cronología casi al minuto. Dos días antes del ataque apareció una cuenta de administrador que nadie del equipo había creado. Al día siguiente, otra más. Con acceso de administrador ya no hace falta explotar nada raro: se puede instalar cualquier cosa desde el propio panel, como si fueras el dueño legítimo. Y eso fue justo lo que pasó — dos plugins falsos, disfrazados con nombres genéricos tipo «Protect Uploads», y un par de puertas traseras escondidas en sitios donde nadie mira.

Hasta aquí, el diagnóstico habitual sería: contraseña débil o filtrada, se cierra la cuenta, se cambia la clave, caso resuelto. Limpiamos todo, rotamos credenciales, reforzamos el panel de acceso con doble factor. Todo apuntaba a que el problema estaba cerrado.

No lo estaba.

El verdadero fallo no tenía nada que ver con WordPress

Al día siguiente el sitio volvió a caer. Esta vez sin usuarios raros, sin contraseñas de por medio. Repasando los registros del servidor encontramos algo que no cuadraba: una petición que, en menos de un segundo, intentaba escribir un archivo en veinte carpetas distintas del servidor a la vez. Subidas, plugins, temas, caché, la propia raíz del sitio. Como quien prueba todas las cerraduras de un edificio a la vez para ver cuál cede.

Y una cedió. No por un plugin desactualizado ni por una contraseña floja, sino por una pieza de PHP que casi nadie revisa porque casi nadie sabe que existe: una herramienta de línea de comandos que viene instalada por defecto en la imagen del servidor y que, mal configurada, deja que una petición web normal se comporte como si fuera un comando ejecutado directamente en el sistema. Ni WordPress, ni ningún plugin, ni ninguna contraseña tenían nada que ver. El problema estaba un nivel por debajo, en el propio PHP.

Esa es la parte que casi nunca sale en los artículos de «cómo proteger tu web»: arreglar lo que ves no es lo mismo que arreglar lo que falla. Puedes cambiar todas las contraseñas del mundo y seguir teniendo la puerta trasera abierta si nunca miras un nivel más abajo.

Cómo lo cerramos de verdad

Quitar el archivo problemático del servidor frena el ataque en caliente, pero no es una solución permanente: en cuanto el contenedor se reinicia, vuelve a aparecer, porque viene de la propia imagen base y no de nada que hayamos tocado nosotros. La solución de verdad fue construir una imagen propia del servidor sin esa pieza, y desplegarla en todos los sitios que compartían la misma base — no solo en el que había sido atacado, sino en cualquier otro con la misma exposición, aunque todavía no le hubiera tocado.

Y aquí va la parte que de verdad nos importa contar: no dimos el problema por cerrado hasta reproducir el ataque exacto contra el servidor ya corregido y comprobar con nuestros propios ojos que ya no funcionaba. Es la diferencia entre «creo que esto ya está arreglado» y «lo sé porque lo he intentado atacar yo mismo y no ha colado».

Lo que nos llevamos de este caso

Ninguna web está «protegida» porque tenga un plugin de seguridad instalado o porque nadie haya entrado nunca. Está protegida cuando alguien ha mirado más allá de lo obvio — cuando se revisan los registros de verdad en lugar de asumir la causa más probable, y cuando cada arreglo se verifica en lugar de darlo por bueno.

Si gestionas una web y no sabrías responder con seguridad a «¿quién tiene acceso de administrador ahora mismo y desde cuándo?», probablemente sea un buen momento para revisarlo. No hace falta esperar a que tu proveedor de hosting te llame para contártelo.

Pide tu auditoría gratuita y lo revisamos juntos.