Se lo dijo su antivirus.
El propio cliente entró en su web y su antivirus le avisó de que sus cookies podían haber sido robadas. No fue un pentester quien dio la alarma: fue el aviso que cualquiera de sus visitantes podía estar viendo también.
Caso real · 2026
Malware en WordPress: por qué hizo falta volver a verificar
Nadie encargó una auditoría. Saltó el antivirus del propio cliente al entrar en su web, avisando de que sus cookies podían haber sido robadas. Detrás había un backdoor activo desde septiembre de 2025: administrador oculto, canal de mando y control y código que se auto-replicaba. Esto es lo que encontramos, cómo lo cerramos y qué pasó tres meses después.
El cliente
Una empresa industrial, sin equipo técnico.
Pyme industrial en Bizkaia, menos de diez personas, sin nadie dedicado a informática. Una web corporativa en WordPress con un tema comercial, alojada en un hosting compartido. El perfil más común que existe, y por eso mismo el más atacado.
Nadie lo iba a ver.
El malware estaba diseñado para no aparecer: se instalaba como must-use plugin, que no sale en la lista de plugins, y se ocultaba también de la lista de usuarios. Funcionó siete meses.
No era personal.
La inteligencia sobre los dominios mostró una campaña automatizada masiva que infecta miles de WordPress a través de plugins y temas desactualizados o pirateados. No era un ataque dirigido: era estar en la lista.
Y el aviso tenía fundamento. Uno de los hallazgos confirmados era una inyección de JavaScript
en todas las páginas del sitio: el malware añadía un <script> codificado que se
ejecutaba en el navegador de cada visitante. Por eso saltaba el antivirus. Un sitio comprometido deja
de ser un problema interno en el momento en que empieza a servir código a sus propios clientes, y ahí el daño
ya no es técnico: es de reputación y, según el sector, de responsabilidad.
Los hallazgos
Qué había dentro.
Cada fichero se confirmó con criterio estricto: canal de mando y control decodificado, cabecera de plugin con autor falso, creación oculta de usuario o cargador ofuscado. Ninguno se dio por malicioso «por si acaso».
| Ref | Hallazgo | Severidad | Estado |
|---|---|---|---|
| F-001 | Backdoor auto-replicante en mu-plugins (3 ficheros) | Crítica | Verified closed |
| F-002 | Copias fuente del backdoor en plugins falsos (3) | Crítica | Verified closed |
| F-003 | Plugins falsos con canal C2 (7 ficheros) | Alta | Verified closed |
| F-004 | Administrador oculto con rol completo | Crítica | Verified closed |
| F-005 | Opciones inyectadas en base de datos | Media | Verified closed |
| F-006 | Inyección de JavaScript a los visitantes | Alta | Verified closed |
| F-007 | Cargador ofuscado escondido en el tema | Crítica | Verified closed |
Hallazgos7
Requerían acción7
Verificados7
Closure Rate100 %
Qué hacía el backdoor. Mantenía un administrador oculto y lo regeneraba solo, hablaba con un servidor externo enviando datos del sitio, aceptaba órdenes por una URL secreta, inyectaba JavaScript a todos los visitantes y copiaba su propio código a otros ficheros PHP para sobrevivir a una limpieza parcial.
Lo que pasó después
Limpiamos, y aun así uno sobrevivió.
Esta es la parte del caso que podríamos no contar. La contamos porque es exactamente la razón por la que existe InmunoSec.
Junio de 2026
- Hallazgo14 ficheros confirmados, 3 familias, un administrador oculto.
- InformeCon plan de limpieza paso a paso, incluida la instrucción de reinstalar el tema entero.
- LimpiezaSe aplicó, y el sitio se migró a un servidor nuevo.
Se dio por cerrado
Septiembre de 2026 · al re-verificar
- Retest completoSe repitieron todas las firmas del informe sobre producción, no sobre el entorno local.
- Un hallazgo seguía abiertoEl cargador escondido en el tema había viajado en la migración: el tema se copió en vez de reinstalarse.
- Cuarentena y cierreFichero aislado como evidencia y ruta bloqueada a nivel de servidor.
- VerificaciónNúcleo de WordPress contrastado contra los checksums oficiales: cero ficheros alterados.
Verificado cerrado · 3 sep 2026
La lección, dicha sin rodeos. Un informe correcto, una limpieza real y aun así un hallazgo crítico siguió abierto tres meses, porque entre el informe y la producción se cuela siempre algo: una migración, una prisa, un paso que se salta. No es negligencia de nadie, es lo normal. Por eso no damos un hallazgo por cerrado hasta volver a probarlo sobre el sistema real, y por eso el retest va incluido en el ciclo en lugar de venderse aparte.
Endurecimiento
Y para que no vuelva a entrar.
- Ejecución de PHP bloqueada en las carpetas de subidas y en los recursos del tema, que es justo donde se plantó el cargador.
- Fichero de configuración inaccesible desde la web.
- Rotación de claves de sesión y de contraseñas, lo que invalida cualquier acceso que el atacante conservara.
- Auditoría de administradores: sólo queda el legítimo.
Qué recibió el cliente
- Informe técnico con evidencia por hallazgo y hashes de cada fichero.
- Inteligencia sobre los ocho dominios del atacante y la cronología del ataque.
- Plan de limpieza en orden de ejecución, no una lista suelta.
- Retest posterior sobre producción y confirmación de cierre.
Caso publicado de forma anonimizada, con las cifras reales del trabajo. No se incluye el nombre del cliente, ni dominios, ni rutas completas, ni ningún dato que permita identificar la organización o reproducir el ataque.
Para seguir avanzando
Cómo medimos el cierre
Fórmula, alcance y límites de la tasa de cierre verificado.
Verificar las correcciones
Pruebas sobre los hallazgos y el entorno acordados.
Security Closure
Auditoría, acompañamiento en la corrección y retest con alcance acordado.
¿Cuándo fue la última vez que alguien lo comprobó?
Si tu web lleva años funcionando sin que nadie la mire, este caso es más común de lo que parece. Media hora de conversación y te decimos por dónde empezaríamos.
Respondemos en menos de 24 horas laborables. Primera conversación sin coste y sin compromiso.