Cómo saber si tu web Joomla ha sido hackeada (síntomas y verificación)

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Antes de limpiar nada, hay que confirmar el diagnóstico. Muchos administradores borran archivos a ciegas, reinstalan por encima y creen haber resuelto el problema, mientras la puerta trasera sigue abierta. Aprender a comprobar si tu Joomla está hackeado con método —y no por intuición— es lo que separa una limpieza real de un parche cosmético. Esta guía forma parte de nuestro radar sobre seguridad de e-commerce y multi-CMS y va directa a los síntomas y a la verificación.

Síntomas que indican que debes comprobar si tu Joomla está hackeado

Un compromiso rara vez avisa con un cartel. Se manifiesta en detalles que, sueltos, parecen fallos menores, pero que juntos dibujan un patrón:

• Redirecciones condicionales: la web se ve normal para ti, pero los visitantes que llegan desde Google acaban en una página de dudosa reputación. Es el síntoma clásico del spam SEO inyectado.
• Avisos del navegador o de Google Search Console: «Este sitio puede dañar tu equipo» o notificaciones de contenido pirateado.
• Consumo de recursos anómalo: picos de CPU o de tráfico saliente sin campaña que los explique, típicos de envío de spam o minería.
• Correo del hosting: suspensiones o avisos de abuso por envío masivo desde tu cuenta.
• Cambios que no hiciste: enlaces ocultos en el pie, un artículo nuevo, o un administrador que no reconoces.

Verificación 1: usuarios administradores

Entra en Usuarios y ordena por fecha de registro. Busca cuentas con privilegios de Super Usuario creadas fuera de tu conocimiento, nombres genéricos o direcciones de correo que no controlas. Un administrador rogue es la firma más habitual tras una inyección SQL o un robo de credenciales. No lo borres todavía: anótalo, porque es evidencia.

Verificación 2: integridad de archivos

El núcleo de Joomla tiene un conjunto de archivos conocido. Compara tu instalación contra una copia limpia de la misma versión y presta atención a:

• Archivos PHP en carpetas que solo deberían contener imágenes o documentos (/images/, /tmp/, /cache/).
• Ficheros con nombres aleatorios o con doble extensión.
• Fechas de modificación agrupadas en un mismo instante: suele ser el momento del ataque.
• Código ofuscado con eval(), base64_decode(), gzinflate() o cadenas hexadecimales largas.

Verificación 3: base de datos

Revisa la tabla de sesiones y la de usuarios en busca de anomalías, y examina los artículos y módulos por si hay scripts insertados en el contenido. Un XSS almacenado o una inyección de spam vive muchas veces en la base de datos, no en el disco, y sobrevive a cualquier reinstalación de archivos.

Verificación 4: archivos de configuración y tareas programadas

Comprueba configuration.php por parámetros alterados (rutas de log, servidor de correo cambiado) y revisa las tareas cron del hosting. Un atacante persistente deja un mecanismo de reinfección programado que reintroduce la puerta trasera aunque limpies el resto.

Qué hacer y qué no hacer al confirmarlo

Si la verificación confirma el compromiso, el orden importa:

• Preserva evidencia primero: haz una copia completa (archivos + base de datos) antes de tocar nada. Si el caso escala a un incidente reportable, esa copia es la línea temporal.
• No reinstales por encima sin limpiar la base de datos: es el error más común y deja intacta la mitad de las puertas traseras.
• Rota todas las credenciales: Joomla, base de datos, FTP/SSH y panel de hosting. Asume que todas están comprometidas.
• Identifica el vector: si no encuentras cómo entraron, volverán. Las técnicas de skimming que documentamos en Magento y las RCE tipo Drupalgeddon comparten un patrón: un componente sin parchear expuesto sin autenticación.

Para contrastar avisos oficiales de tu versión, el Joomla! Security Centre es la fuente de referencia. Si tu Joomla procesa pagos, el PCI Security Standards Council marca las obligaciones tras un incidente con datos de tarjeta, y la documentación de seguridad de PrestaShop ofrece un buen contraste de buenas prácticas entre plataformas de comercio.

En incidentes exigentes —banca, tiendas con datos de tarjeta— la verificación no es opcional: determina el alcance de la brecha y las obligaciones legales. En PathSentinel abordamos la comprobación con enfoque forense, para que sepas no solo que entraron, sino por dónde y qué se llevaron. Si necesitas una segunda mirada, escríbenos desde contacto.