El mensaje que nos llegó fue corto: no se podía completar el proceso de compra. Ni avisos de Google ni textos en chino. Un checkout que se quedaba colgado y un cliente que, con razón, quería vender.
Era un hackeo. Y es algo que he visto bastantes veces: el síntoma casi nunca se parece al problema.
Cuando a alguien le hackean el WordPress, lo normal es pedir que se lo limpien: se borra lo raro, se restaura una copia, se cambian contraseñas y la web vuelve a funcionar. Caso cerrado.
No lo está. Limpiar un WordPress hackeado sin saber por dónde entraron es dejar la puerta abierta. Para cerrarla hay que contestar cuatro preguntas. Aquí cuento cómo las contestamos en un caso real de finales de septiembre de 2026 con un agente de IA, en qué nos ayudó y qué decisiones no le dejamos tomar.
Contenidos
Las cuatro preguntas que hay que contestar antes de dar una web por limpia
Una web limpia no es lo mismo que una web investigada. Antes de restaurar nada, alguien tiene que poder responder:
- Por dónde entraron. Si no lo sabes, no sabes qué cerrar.
- Desde cuándo estaban dentro. Decide qué copia de seguridad es fiable y qué datos estuvieron expuestos.
- Qué pudieron llevarse. Pedidos, datos de clientes, claves de pago, credenciales de correo.
- Si pueden volver. Usuarios falsos, ficheros que se regeneran, contraseñas que siguen siendo válidas.
Casi todas las guías sobre WordPress hackeado van de limpiar: escanear y restaurar. Sirven, pero contestan otra cosa. Si quieres el paso a paso de la limpieza, lo tienes en cómo arreglar una web WordPress infectada.
Cómo empezó: una tienda en la que no se podía comprar
La tienda era un WooCommerce con un plugin de presupuestos B2B. Todo apunta a que el atacante entró subiendo un fichero PHP por el formulario de «solicitar presupuesto», que el plugin aceptaba sin comprobar quién lo enviaba: su primera webshell estaba en la carpeta de subidas de ese módulo. Con eso tuvo un administrador falso y, desde el panel, montó el resto.
Iba a por SEO parasitario, no a por los pagos: miles de páginas spam que imitaban una tienda grande y se servían sobre todo a buscadores y a bots de IA. En las dos horas y pico de log que miramos primero salieron 1.971 de esas páginas, casi todas hacia Googlebot, ClaudeBot, bingbot y Bytespider.
¿Y el checkout? El malware imprimía un script al principio de casi todas las respuestas de la web, incluidas las peticiones AJAX con las que WooCommerce procesa el pedido. WooCommerce esperaba datos y recibía basura. Por eso no se podía comprar.
El cliente vio un error de compra. El problema era una intrusión con persistencia.
Qué hizo la IA en la investigación
Trabajé con Claude Code, un agente de IA, conectado al servidor por SSH en modo solo lectura. Cualquier cambio en producción necesitaba que yo lo aprobara antes. Y antes de tocar nada hicimos una copia forense del servidor entero, logs incluidos. Es la misma forma de trabajar que contamos en la migración de PHP 5 a PHP 8 con IA: la herramienta lee y propone, la persona decide.
Esto es lo que hizo la herramienta:
Reconstruir la cronología. Le pedimos que cruzara las altas de usuarios con las fechas de modificación de los ficheros, y luego con los logs de acceso. El administrador falso apareció seis segundos antes de que el plugin creara su carpeta temporal de subidas. Esa coincidencia es la que señala la puerta, y encontrarla a mano entre miles de líneas lleva mucho más tiempo.
Separar lo del atacante de lo legítimo. En un servidor real hay cosas raras que no son malware: el repositorio Git de despliegue, carpetas de un proveedor, clientes normales que se registraron esos mismos días. La IA lo clasificó y nosotros revisamos la clasificación.
Verificar el resultado. Después de limpiar, comparó el núcleo de WordPress y los plugins oficiales con los checksums publicados por WordPress.org, y buscó las firmas del malware en todo el árbol de ficheros.
Medir qué hizo el atacante. Filtramos los logs por sus IPs y salió esto: 444 peticiones dinámicas, 7,97 MB en total, y la respuesta más grande de sus webshells fue de 4,5 KB. Nunca abrió pedidos, clientes, exportaciones ni los ajustes de pago. Con esos números se puede descartar un volcado de la base de datos por la web.
El primer análisis y la limpieza se hicieron el mismo día. La limpieza en sí, por SSH, fueron once minutos. Lo largo fue lo de antes: saber qué había que quitar.
Lo que el escáner del hosting no vio
Cuando entramos, el hosting ya había detectado el malware y su escáner había borrado parte de los ficheros. Sobre el papel, la web estaba limpia.
No lo estaba. Lo que seguía en disco lo dejaba bastante claro. El atacante había dejado un «guardián»: copias cifradas de su código repartidas por varias carpetas y un proceso que volvía a crear los ficheros borrados. El escáner quitaba lo que veía y el guardián lo reponía horas después. Además había código inyectado en tres plugins legítimos, un cargador en mu-plugins y un administrador falso que seguía existiendo.
Que el hosting diga que ha limpiado algo no significa que la web esté limpia. Significa que ha borrado lo que su escáner reconoce.
La copia de seguridad que no había que restaurar
En pleno incidente, lo primero que hice fue una copia de seguridad completa de la web. Es lo lógico: antes de tocar nada, guardas lo que hay.
Esa copia estaba infectada, claro. Sirve como prueba, no como punto de restauración. Restaurarla habría reinstalado el malware, el guardián incluido.
La copia buena, la que marcamos como referencia, era la de cinco días antes: la última anterior a la entrada del atacante. Pudimos saberlo porque ya teníamos contestada la segunda pregunta, desde cuándo estaban dentro. Sin cronología, «restaurar la última copia» habría sido restaurar el problema.
Lo que los logs no cuentan
Es la parte que casi nadie cuenta, y la que más le importa a quien tiene que decidir.
Los logs de acceso registran las peticiones web: qué URL, desde qué IP, qué respuesta y cuántos bytes. No registran lo que una webshell ejecuta dentro del servidor. Si el atacante hubiera mandado datos hacia fuera con una orden desde el propio servidor, no aparecería en ningún log de acceso.
Tampoco teníamos los logs del momento exacto de la entrada. La puerta la dedujimos por las fechas y por dónde estaba su primera webshell, no porque viéramos la petición.
Así que lo que le dijimos al cliente no fue «no os han robado datos». Fue: no hay exfiltración visible en los logs, y estos son los límites de lo que los logs pueden ver.
El atacante fue administrador durante unas 26 horas. En ese tiempo pudo leer los pedidos, las claves de las pasarelas de pago, las credenciales de correo y la configuración de la base de datos. No hay rastro de que lo hiciera, pero tampoco se puede demostrar que no.
Una IA tiende a dar respuestas redondas. En esta investigación, buena parte de mi trabajo fue frenarla y escribir igual de claro lo que no sabíamos.
Lo que no delegamos
La IA encontró y comprobó. Las decisiones las tomamos nosotros:
Qué cerrar y cuándo. Desactivar el plugin sospechoso en plena investigación, y después actualizarlo y dejar apagado el módulo de presupuestos. Actualizar un plugin en caliente tiene sus riesgos, y los hemos contado en otro artículo, pero con una puerta abierta no había alternativa.
Qué rotar. Regeneramos las claves de seguridad de WordPress, lo que cerró de golpe 503 sesiones abiertas. Y decidimos cuáles de las credenciales que el atacante pudo leer había que cambiar ya, empezando por las de las pasarelas de pago y el correo.
Qué copia restaurar y qué no. Por lo que hemos visto antes.
Qué contarle al cliente. Incluido lo que no podíamos descartar.
Y una que ni siquiera es nuestra: si hay que notificar la brecha. Según la AEPD, el responsable del tratamiento, que es la empresa dueña de la web y no su agencia, tiene que valorar el riesgo y notificar a la autoridad en un plazo de 72 horas desde que tiene constancia de la brecha cuando exista riesgo para las personas. Nuestro papel es darle la información para que pueda decidir dentro de plazo. Si la web ya tenía flojos los deberes de protección de datos, esto es lo que suele fallar en el cumplimiento del RGPD.
Qué pedirle a quien limpie tu WordPress
Si te han hackeado la web y alguien te dice que ya está solucionado, pide que te conteste esto por escrito:
- Por dónde entraron y qué se ha hecho para cerrar esa puerta concreta.
- Desde cuándo estaban dentro y cómo se ha determinado.
- Qué copia se ha restaurado y por qué esa es anterior a la intrusión.
- Qué pudieron ver o llevarse, y qué no se puede descartar.
- Qué credenciales se han cambiado.
- Cómo se ha comprobado que no queda nada: usuarios, ficheros que se regeneran, código inyectado en plugins legítimos.
- Qué hay que vigilar las próximas semanas, empezando por el informe de «Problemas de seguridad» de Search Console.
Si la respuesta a la primera pregunta es «no lo sabemos», la web no está cerrada. Está limpia hasta la próxima vez.
Cuando vuelve a funcionar no ha terminado
La IA ha abaratado investigar un hackeo. Leer miles de líneas de log y comparar cientos de ficheros con sus checksums es justo el trabajo donde una herramienta así rinde, y en este caso nos ahorró la parte más pesada.
Lo que no ha cambiado es quién responde. Decidir qué copia es fiable y qué hay que contarle al cliente sigue siendo trabajo de alguien que conoce la web y asume las consecuencias. Nosotros, en este caso.
Un WordPress hackeado no se cierra cuando vuelve a funcionar. Se cierra cuando sabes cómo entraron.
Fuentes y referencias
| Institución / organismo | Título / publicación | Qué sustenta | Enlace |
|---|---|---|---|
| AEPD | Notificación de brechas de datos personales a la Autoridad de Control | Responsable del tratamiento, plazo de 72 horas, herramienta Asesora Brecha | aepd.es |
| AEPD | Guía para la notificación de brechas de datos personales | Contexto sobre qué es una brecha y cómo se notifica | aepd.es |
| WordPress.org | wp core verify-checksums (WP-CLI) | Verificación del núcleo contra checksums oficiales | developer.wordpress.org |
| WordPress.org | wp plugin verify-checksums (WP-CLI) | Verificación de plugins oficiales | developer.wordpress.org |
| Resumen de los informes de Search Console | Informe «Problemas de seguridad» | support.google.com |
¿Te han limpiado la web pero nadie te ha dicho por dónde entraron?
En Èmfasi revisamos qué ha pasado en tu WordPress y cerramos la puerta por la que entraron. Y te dejamos por escrito qué sabemos y qué no. Forma parte de nuestro servicio de soporte y mantenimiento web.
Preguntas frecuentes sobre WordPress hackeado
Nosotros empezamos cruzando las altas de usuarios con las fechas de modificación de ficheros, y después contrastamos con los logs de acceso del servidor. La entrada suele aparecer como una coincidencia entre ellas, por ejemplo un usuario administrador creado justo cuando un plugin escribe un fichero. Sin los logs de acceso del día de la intrusión, la puerta de entrada suele quedar como hipótesis.
Solo si la copia es anterior a la intrusión y además se cierra la vulnerabilidad por la que entraron. Una copia hecha durante el incidente puede estar infectada, y restaurar una copia limpia sin corregir el fallo deja la web expuesta al mismo ataque.
Puede hacer gran parte del trabajo mecánico: leer logs, reconstruir cronologías, clasificar ficheros y verificar checksums. No puede decidir qué cambios hacer en producción ni qué se le comunica al cliente o a la autoridad de protección de datos. En nuestro caso trabajó en modo solo lectura y cada cambio necesitó aprobación humana.
No necesariamente. Los escáneres del hosting borran lo que reconocen, pero algunos malware dejan copias cifradas y procesos que vuelven a crear los ficheros. También pueden quedar administradores falsos o código inyectado en plugins legítimos.
Lo decide el responsable del tratamiento, es decir, la empresa dueña de la web. Si la brecha puede suponer un riesgo para las personas, hay que notificarla a la AEPD en un plazo de 72 horas desde que se tiene constancia. La AEPD ofrece una herramienta, Asesora Brecha, para ayudar a valorarlo.
