LinuxParty

Después de la publicación de nuestra guía sobre la vulnerabilidad crítica de Helix Ultimate y SP Page Builder, muchos administradores nos han preguntado lo mismo:

"He actualizado el sitio... ¿pero cómo sé si el atacante ya había entrado?"

La respuesta es sencilla: actualizar elimina la vulnerabilidad, pero no elimina las modificaciones que un atacante haya realizado previamente.

Si el sitio fue comprometido antes de instalar la actualización, es posible que el atacante haya dejado puertas traseras (webshells), usuarios administradores ocultos o modificaciones en la base de datos que seguirán funcionando incluso después de instalar la versión corregida.

1. Buscar usuarios administradores sospechosos

Lo primero es revisar la tabla de usuarios de Joomla.

Tal vez sobre decirlo, pero cambia TuPrefijo por el prefijo de tu base de datos.

SELECT id, name, username, email, registerDate
FROM TuPrefijo_users
ORDER BY id DESC;

Presta especial atención a:

• usuarios creados recientemente;
• direcciones de correo extrañas;
• cuentas con nombres aparentemente legítimos pero desconocidas;
• administradores que no recuerdes haber creado.

Después verifica que esos usuarios pertenecen realmente al grupo Super Users.

SELECT *
FROM TuPrefijo_user_usergroup_map
WHERE group_id = 8;

2. Revisar los parámetros del menú

Uno de los vectores más utilizados consiste en inyectar JavaScript malicioso dentro del campo

params

de la tabla

TuPrefijo_menu

.

SELECT id,title,params
FROM TuPrefijo_menu
WHERE params <> '{}'
AND params <> '';

Busca especialmente:

• etiquetas <script>;
• funciones eval(), atob(), fromCharCode() o document.write();
• URLs hacia dominios desconocidos;
• cadenas extremadamente largas codificadas en Base64;
• código JavaScript ofuscado.

Puedes localizar rápidamente registros sospechosos buscando directamente:

SELECT id,title
FROM TuPrefijo_menu
WHERE params LIKE '%<script%'
   OR params LIKE '%eval(%'
   OR params LIKE '%atob(%'
   OR params LIKE '%http://%'
   OR params LIKE '%https://%';

También resulta muy útil localizar los registros con mayor tamaño, ya que muchos ataques almacenan cientos o miles de caracteres de JavaScript:

SELECT id,title,LENGTH(params) AS longitud
FROM TuPrefijo_menu
ORDER BY longitud DESC;

3. Revisar estilos de plantilla

SELECT id,title,params
FROM TuPrefijo_template_styles;

Muchos ataques almacenan aquí JavaScript persistente.

4. Revisar módulos

SELECT id,title,params
FROM TuPrefijo_modules;

También es frecuente encontrar payloads en módulos HTML personalizados.

5. Buscar archivos PHP recientes

En Linux:

find /var/www/vhosts -type f -name "*.php" -mtime -30

O buscar archivos creados el mismo día en que comenzó el ataque.

Si conoces aproximadamente la fecha del compromiso, puedes afinar aún más la búsqueda:

find /var/www/vhosts/TU_DOMINIO/httpdocs \
-type f \
-newermt "2026-07-15"

Muchos webshells destacan inmediatamente porque fueron creados o modificados durante el ataque.

6. Buscar archivos con nombres sospechosos

Los atacantes suelen utilizar nombres aparentemente inocentes:

tx_722f919f.php
tx_722f919f.php.json
cache.php
about.php
license.php
style.php
index_old.php
config.old.php

También es recomendable buscar:

find /var/www -name "*.php.json"
find /var/www -name "tx_*"
find /var/www -name "*.phtml"

7. Buscar funciones peligrosas

Una búsqueda rápida puede localizar muchos webshells.

grep -RniE \
"system\s*\(|exec\s*\(|shell_exec\s*\(|passthru\s*\(|proc_open\s*\(|popen\s*\(" \
/var/www/vhosts/TU_DOMINIO/httpdocs

Buscar funciones habitualmente utilizadas por los webshells:

grep -RniE \
"eval\s*\(|assert\s*\(|base64_decode\s*\(|gzinflate\s*\(|str_rot13\s*\(" \
/var/www/vhosts/TU_DOMINIO/httpdocs

Buscar archivos que permitan subir nuevos ficheros al servidor:

grep -Rni "move_uploaded_file" \
/var/www/vhosts/TU_DOMINIO/httpdocs

Buscar conexiones directas a MySQL:

grep -RniE \
"mysqli_connect|new mysqli|PDO\s*\(" \
/var/www/vhosts/TU_DOMINIO/httpdocs

Importante: encontrar funciones como base64_decode(), move_uploaded_file() o incluso exec() no implica necesariamente que exista malware. Muchos componentes legítimos las utilizan. Lo realmente sospechoso es encontrar estas funciones en archivos desconocidos, ubicados en directorios poco habituales o combinadas con código ofuscado.

No todos los resultados serán malware, pero cualquier coincidencia merece revisión.

8. Revisar los logs de Apache

Los registros de acceso suelen indicar cuándo comenzó el ataque.

Por ejemplo:

zgrep "tx_" access*

o

zgrep "php.json" access*

Si conoces el nombre del webshell:

zgrep "tx_722f919f" access*

También puedes buscar el token utilizado por el atacante.

zgrep "39206081541d" access*

Con ello podrás identificar:

• la IP de origen;
• la fecha del primer acceso;
• los comandos ejecutados;
• la frecuencia de uso.

9. Revisar el directorio images

Aunque parezca extraño, muchos atacantes almacenan allí archivos PHP porque tradicionalmente era un directorio poco vigilado.

Revisa especialmente:

images/
media/
tmp/
cache/
logs/

Además de revisar estos directorios, comprueba que no existan archivos PHP donde no deberían:

find images -name "*.php"
find media -name "*.php"
find cache -name "*.php"
find tmp -name "*.php"
find logs -name "*.php"

En una instalación estándar de Joomla rara vez deberían existir scripts PHP dentro de estos directorios.

10. Comprobar permisos

find /var/www -perm -777

y

find /var/www -type d -perm -777

Recuerda los permisos:

Cada cifra representa:

             Propietario   Grupo   Otros
chmod  5 7 7      5          7       7

Y cada número se traduce así:

0 = ---
1 = --x
2 = -w-
3 = -wx
4 = r--
5 = r-x
6 = rw-
7 = rwx

Ejemplos:

577 = r-x rwx rwx
      │   │   └── Otros: lectura, escritura y ejecución
      │   └────── Grupo: lectura, escritura y ejecución
      └────────── Propietario: lectura y ejecución

677 = rw- rwx rwx
      │   │   └── Otros: lectura, escritura y ejecución
      │   └────── Grupo: lectura, escritura y ejecución
      └────────── Propietario: lectura y escritura

777 = rwx rwx rwx
      │   │   └── Otros: todos los permisos
      │   └────── Grupo: todos los permisos
      └────────── Propietario: todos los permisos

Permisos habituales:

Número	Representación	Uso
600	rw- --- ---	Archivo privado
640	rw- r-- ---	Archivo leído por el grupo
644	rw- r-- r--	Archivo web habitual
700	rwx --- ---	Directorio privado
750	rwx r-x ---	Acceso del grupo
755	rwx r-x r-x	Directorio web habitual
775	rwx rwx r-x	Grupo con escritura
777	rwx rwx rwx	Cualquiera puede escribir

Para find, el guion cambia el significado:

find /var/www -perm 0777

Busca permisos exactamente 777.

find /var/www -perm -0577

Busca elementos que tengan, como mínimo:

Propietario: r-x
Grupo:       rwx
Otros:       rwx

Por eso -perm -0577 también puede encontrar un archivo con 677 o 777: ambos contienen todos los permisos solicitados por 577.

También es recomendable localizar archivos propiedad del usuario del servidor web (apache, www-data, nginx, etc.), especialmente si normalmente todos los archivos pertenecen al usuario de la cuenta:

find /var/www -user apache
find /var/www -user www-data

Los permisos excesivamente abiertos facilitan la persistencia del atacante.

11. Revisar tareas programadas

Comprueba que no hayan dejado procesos persistentes.

crontab -l

cat /etc/crontab

ls /etc/cron.*

12. Verificar

.htaccess

Comprueba que no existan redirecciones extrañas ni reglas que permitan ejecutar PHP donde no debería.

13. Cambiar todas las credenciales

Una vez limpio el servidor, cambia inmediatamente:

• contraseña de Joomla;
• contraseña de MySQL;
• FTP/SFTP;
• SSH;
• panel Plesk o cPanel;
• API Keys.

14. Instalar la versión corregida

Una vez verificado que no quedan puertas traseras:

• actualizar Helix Ultimate;
• actualizar Helix3;
• actualizar SP Page Builder;
• actualizar Joomla;
• revisar todas las extensiones instaladas.

Actualizar sin limpiar previamente puede dejar un atacante con acceso permanente aunque la vulnerabilidad original ya no exista. (Центр обучения Joomla)

Conclusión

Durante los últimos días hemos analizado varios servidores comprometidos y hemos observado un patrón común: el objetivo del atacante no era únicamente modificar la apariencia del sitio, sino conseguir un acceso persistente mediante webshells, usuarios administradores ocultos y código almacenado tanto en la base de datos como en archivos PHP. La actualización es imprescindible para cerrar la vulnerabilidad, pero no basta si el compromiso ya se produjo. Una revisión metódica de la base de datos, del sistema de archivos y de los registros del servidor es la única forma de tener garantías razonables de que el sitio vuelve a estar bajo tu control. (Joomill - Joomla specialist)

[ Parte 1 ]  [ Parte 2 ]