LinuxParty

Auditor Web es un script Bash de auditoría de seguridad pensado para servidores Linux que alojan páginas desarrolladas en PHP. Permite buscar archivos sospechosos, código ofuscado, funciones peligrosas, modificaciones recientes, permisos inseguros y otros indicios habituales de una intrusión.

El script reconoce instalaciones de Joomla y WordPress, aunque también puede trabajar con cualquier sitio PHP en modo genérico. Está especialmente indicado para servidores administrados mediante Plesk, servidores de hosting compartido, VPS y máquinas dedicadas.

Una de sus características más útiles es que no se limita a generar un informe: después de cada análisis crea automáticamente un segundo script, específico para esa auditoría, con el que se pueden abrir uno por uno los archivos sospechosos utilizando bat, batcat o less.

De este modo resulta mucho más sencillo revisar el código encontrado, identificar una posible puerta trasera y distinguirla de una coincidencia legítima.

Importante: Auditor Web es una herramienta de detección y revisión. Una coincidencia no demuestra por sí sola que un archivo contenga malware.

¿Qué analiza Auditor Web?

El script realiza, entre otras, las siguientes comprobaciones:

• Archivos PHP modificados recientemente.
• Extensiones dobles y nombres frecuentemente utilizados por webshells.
• Ficheros PHP dentro de images, media, uploads, tmp, cache o directorios similares.
• Funciones capaces de ejecutar comandos del sistema.
• Código ofuscado mediante Base64, eval(), gzinflate() y técnicas parecidas.
• Líneas de código anormalmente largas.
• JavaScript inyectado u ofuscado.
• Descargas remotas, sockets y escritura de archivos.
• Archivos y directorios con permisos 777.
• Elementos escribibles por cualquier usuario.
• Enlaces simbólicos que salen de la raíz auditada.
• Reglas sospechosas en .htaccess, .user.ini y php.ini.
• Peticiones relacionadas con webshells en los registros de Apache o Nginx.
• Tareas programadas que utilizan curl, wget, PHP, Python o directorios temporales.
• Versiones locales de Joomla, WordPress, plugins, plantillas y extensiones.
• Usuarios administradores y determinados contenidos sospechosos almacenados en la base de datos.

El análisis del sistema de archivos se realiza en modo de solo lectura. El script no elimina ni pone en cuarentena ningún archivo automáticamente.

Requisitos

Auditor Web utiliza herramientas habituales en cualquier distribución Linux:

bash
find
grep
sed
awk
sort
stat
readlink

Para analizar la base de datos de Joomla o WordPress también debe estar disponible:

php
mariadb

o, alternativamente:

mysql

Para revisar cómodamente los archivos encontrados recomendamos instalar bat.

Debian y Ubuntu

sudo apt update
sudo apt install bat less

En algunas versiones de Debian o Ubuntu el ejecutable se instala con el nombre batcat. Auditor Web reconoce ambos nombres automáticamente.

AlmaLinux, Rocky Linux, CentOS Stream o Fedora

sudo dnf install bat less

Si bat no está instalado, el revisor utilizará automáticamente less.

Instalación de Auditor Web

Descargamos el archivo auditor-web.sh y lo instalamos en /usr/local/bin:

sudo install -m 755 auditor-web.sh /usr/local/bin/auditor-web.sh

Comprobamos la versión instalada:

auditor-web.sh --version

Y podemos consultar todas sus opciones mediante:

auditor-web.sh --help

Primera auditoría

Para analizar un sitio web solamente es necesario indicar su directorio raíz:

sudo auditor-web.sh -r /var/www/vhosts/sitioweb.com

También podemos utilizar la opción larga:

sudo auditor-web.sh --root /var/www/vhosts/sitioweb.com

En servidores Plesk, dependiendo de lo que se quiera revisar, puede indicarse el directorio completo del dominio:

sudo auditor-web.sh -r /var/www/vhosts/sitioweb.com

O únicamente su raíz pública:

sudo auditor-web.sh -r /var/www/vhosts/sitioweb.com/httpdocs

La primera opción permite abarcar más contenido perteneciente al alojamiento. La segunda limita la auditoría a los archivos publicados dentro de httpdocs.

Archivos que genera

Supongamos que ejecutamos la auditoría el 23 de julio de 2026:

sudo auditor-web.sh -r /var/www/vhosts/sitioweb.com

El programa generará tres archivos:

auditoria-web-sitioweb.com-20260723-120530.log
auditoria-web-sitioweb.com-20260723-120530.sospechosos.txt
revisar-sitioweb.com-20260723-120530.sh

Cada uno tiene una finalidad diferente.

Informe completo

auditoria-web-sitioweb.com-20260723-120530.log

Contiene el resultado completo de todas las pruebas. Se guarda como texto plano, sin secuencias de color, para que pueda buscarse, compararse, imprimirse o enviarse a otro técnico.

Podemos consultarlo con:

less auditoria-web-sitioweb.com-20260723-120530.log

Lista de archivos sospechosos

auditoria-web-sitioweb.com-20260723-120530.sospechosos.txt

Contiene las rutas de los archivos encontrados en pruebas clasificadas como ALERTA o REVISAR. Las rutas se deduplican, por lo que un mismo archivo solamente aparece una vez aunque coincida con varias reglas.

Script de revisión

revisar-sitioweb.com-20260723-120530.sh

Este archivo se genera automáticamente en cada ejecución. Es un revisor autónomo que incorpora:

• La raíz exacta que fue auditada.
• La fecha de la auditoría.
• La ubicación del informe.
• La lista concreta de archivos sospechosos encontrados.

Por tanto, cada auditoría dispone de su propio script de revisión.

Cómo revisar los archivos sospechosos

Ejecutamos el revisor generado:

sudo ./revisar-sitioweb.com-20260723-120530.sh

El programa muestra una lista numerada parecida a esta:

Revisión: 2026-07-23T12:05:30+02:00
Raíz auditada: /var/www/vhosts/sitioweb.com
Informe: /root/auditoria-web-sitioweb.com-20260723-120530.log
Ficheros sospechosos: 3

    1) /var/www/vhosts/sitioweb.com/httpdocs/images/cache.php
    2) /var/www/vhosts/sitioweb.com/httpdocs/tmp/update.phtml
    3) /var/www/vhosts/sitioweb.com/httpdocs/plugins/system/example/helper.php

Los controles disponibles son:

INTRO o n    Abrir el archivo actual y avanzar al siguiente
s             Saltar el archivo actual
a NUM         Abrir directamente el archivo indicado
l             Mostrar nuevamente la lista
q             Salir

Dentro de bat o less, pulsamos q para cerrar el visor y regresar al menú.

El revisor vuelve a validar cada ruta antes de abrirla. Si el archivo ha desaparecido, ya no es un archivo regular o se encuentra fuera de la raíz originalmente auditada, no lo abrirá.

El revisor tampoco ejecuta el archivo PHP: únicamente lo entrega como texto a bat, batcat o less.

Salida en colores

Cuando la salida se muestra en un terminal compatible:

• Los títulos y secciones aparecen diferenciados por colores.
• Las alertas de alta prioridad aparecen en rojo.
• Los elementos que requieren revisión aparecen en amarillo.
• La ruta del archivo encontrado aparece en magenta.
• La línea coincidente y el contenido del archivo permanecen en blanco.

Esta separación permite reconocer rápidamente dónde termina el nombre del archivo y dónde comienza el código que ha provocado la coincidencia.

Por ejemplo, una línea puede mostrar:

/var/www/vhosts/sitioweb.com/httpdocs/libraries/example.php:74: shell_exec($command);

La ruta example.php aparecerá resaltada, mientras que el número de línea y el fragmento de código conservarán un color neutro y legible.

Los colores solamente se aplican a la consola. El informe guardado en disco siempre permanece en texto plano.

Forzar o desactivar los colores

Para forzar su utilización:

sudo auditor-web.sh -r /var/www/vhosts/sitioweb.com --color always

Para desactivarlos:

sudo auditor-web.sh -r /var/www/vhosts/sitioweb.com --no-color

También puede utilizarse:

sudo auditor-web.sh -r /var/www/vhosts/sitioweb.com --color never

Buscar archivos modificados desde una fecha concreta

Por defecto, Auditor Web revisa los ejecutables PHP modificados durante los últimos 30 días.

Podemos cambiar el periodo:

sudo auditor-web.sh -r /var/www/vhosts/sitioweb.com --days 7

O indicar una fecha exacta:

sudo auditor-web.sh \
    -r /var/www/vhosts/sitioweb.com \
    --since 2026-07-15

Esta opción resulta especialmente útil cuando conocemos aproximadamente el día en que comenzó la intrusión.

Analizar los registros de Apache o Nginx

Auditor Web intenta localizar automáticamente los registros del dominio. En un servidor Plesk podemos indicarlos expresamente:

sudo auditor-web.sh \
    -r /var/www/vhosts/sitioweb.com/httpdocs \
    --logs /var/www/vhosts/system/sitioweb.com/logs

Si conocemos el nombre de una webshell, un usuario creado por el atacante o alguna cadena particular, podemos añadirla mediante --token:

sudo auditor-web.sh \
    -r /var/www/vhosts/sitioweb.com/httpdocs \
    --logs /var/www/vhosts/system/sitioweb.com/logs \
    --token sysupdate06hb3

Esto permite buscar la misma cadena dentro de los registros de acceso y correlacionarla con las peticiones realizadas por el atacante.

Auditoría específica de Joomla

Normalmente el CMS se detecta automáticamente si están presentes:

configuration.php
administrator/

No obstante, podemos forzar el modo Joomla:

sudo auditor-web.sh \
    -r /var/www/vhosts/sitioweb.com/httpdocs \
    --cms joomla

Además de las pruebas generales, el programa puede revisar:

• Usuarios y Super Users.
• Parámetros sospechosos en elementos de menú.
• Parámetros anormalmente grandes en estilos de plantilla.
• Módulos con scripts u ofuscación.
• Versiones instaladas de Joomla, Helix Ultimate y SP Page Builder cuando sus manifiestos están disponibles.

Las credenciales se obtienen de configuration.php sin incluir la contraseña en el informe.

Auditoría específica de WordPress

WordPress se detecta mediante:

wp-config.php
wp-includes/

También podemos forzarlo:

sudo auditor-web.sh \
    -r /var/www/vhosts/sitioweb.com/httpdocs \
    --cms wordpress

El análisis puede incluir:

• Usuarios y administradores.
• Opciones con JavaScript o código ofuscado.
• Opciones de tamaño anormal.
• URL principal, correo administrativo y rol predeterminado.
• Lista de plugins activos.
• Entradas o páginas con JavaScript potencialmente ofuscado.
• Versiones locales del núcleo, plugins y temas.

Ejecutar sin revisar la base de datos

Si solamente queremos analizar archivos, permisos, configuraciones y registros:

sudo auditor-web.sh \
    -r /var/www/vhosts/sitioweb.com/httpdocs \
    --skip-db

Esta opción también es útil cuando el servidor no dispone del cliente mariadb o mysql.

Indicar credenciales de base de datos manualmente

Cuando la contraseña no puede obtenerse como un valor literal de la configuración, puede proporcionarse temporalmente mediante una variable de entorno:

sudo CMS_DB_PASSWORD='contraseña' \
    auditor-web.sh -r /var/www/vhosts/sitioweb.com/httpdocs

También admite:

CMS_DB_HOST
CMS_DB_USER
CMS_DB_PASSWORD
CMS_DB_NAME
CMS_DB_PREFIX

Estas variables resultan útiles en configuraciones especiales o cuando las credenciales se cargan desde otro archivo.

Conviene recordar que una contraseña escrita directamente en una orden podría quedar registrada en el historial del intérprete. Es preferible asignarla de forma segura o utilizar una sesión administrativa controlada.

Limitar el número de resultados mostrados

Por defecto se muestran hasta 200 líneas por prueba. Podemos ampliar o reducir esta cantidad:

sudo auditor-web.sh \
    -r /var/www/vhosts/sitioweb.com \
    --max 500

El límite se aplica a las líneas publicadas por cada prueba tanto en la consola como en el informe, con el objetivo de evitar resultados inmanejables. La lista independiente de ficheros sospechosos se construye a partir de todas las coincidencias detectadas, antes de aplicar ese límite visual.

Guardar el informe con otro nombre

Podemos elegir manualmente el archivo de salida:

sudo auditor-web.sh \
    -r /var/www/vhosts/sitioweb.com \
    --output /root/informes/auditoria-cliente.log

El directorio debe existir previamente.

El script autónomo de revisión se creará en el mismo directorio del informe.

Interpretación de prioridades

Auditor Web utiliza tres niveles:

ALERTA

Indica una coincidencia de alta prioridad, como:

• Una extensión doble especialmente sospechosa.
• PHP dentro de un directorio de imágenes o subidas.
• Una combinación típica de webshell.
• Permisos exactamente 777.
• Reglas capaces de cargar código antes del CMS.

Estas coincidencias deben revisarse cuanto antes, pero todavía necesitan confirmación manual.

REVISAR

Se utiliza para comportamientos que pueden ser legítimos, pero también aparecen frecuentemente durante una intrusión:

• shell_exec(), system() o proc_open().
• base64_decode() o eval().
• Escritura de archivos.
• Conexiones remotas.
• PHP dentro de cachés o temporales.
• Archivos propiedad del usuario del servidor web.

Muchos CMS, plugins y bibliotecas legítimas emplean alguna de estas funciones. Por eso no deben eliminarse automáticamente.

INFO

Muestra información contextual:

• Versiones instaladas.
• Inventario de configuraciones.
• Usuarios.
• Administradores.
• Tareas programadas del usuario.

Sirve para completar la investigación y detectar elementos que no reconocemos.

Códigos de salida

El script devuelve:

0  Auditoría finalizada sin indicios de alta prioridad
1  Se encontraron indicios clasificados como ALERTA
2  Error de uso o fallo en una parte esencial

Esto permite integrarlo con cron, sistemas de monitorización u otras herramientas:

sudo auditor-web.sh -r /var/www/vhosts/sitioweb.com
resultado=$?

case "$resultado" in
    0) echo "Sin alertas de alta prioridad" ;;
    1) echo "Hay archivos o configuraciones que deben revisarse" ;;
    2) echo "La auditoría no pudo completarse correctamente" ;;
esac

¿Qué debemos buscar dentro de un archivo sospechoso?

Al abrir un archivo con el revisor debemos comprobar:

• Si pertenece realmente al CMS, plugin, componente o plantilla.
• Si su ubicación resulta coherente.
• Si tiene una fecha diferente al resto de archivos del mismo paquete.
• Si contiene grandes bloques de texto aparentemente aleatorio.
• Si decodifica Base64 y ejecuta inmediatamente el resultado.
• Si recibe comandos mediante $_GET, $_POST, $_REQUEST o cookies.
• Si crea usuarios, modifica archivos o descarga contenido remoto.
• Si utiliza nombres de variables deliberadamente confusos.
• Si intenta ocultar errores o alterar los límites de ejecución.
• Si coincide con el archivo original de la misma versión del software.

Una función como shell_exec() no demuestra que exista una webshell. Sin embargo, una expresión parecida a esta es mucho más preocupante:

<?php
shell_exec($_REQUEST['cmd']);

La prioridad aumenta cuando coinciden varios factores:

• Nombre extraño.
• Ubicación impropia.
• Modificación reciente.
• Código ofuscado.
• Entrada controlada por el visitante.
• Peticiones relacionadas en los registros de acceso.

Qué hacer si confirmamos una infección

No conviene limitarse a borrar el primer archivo encontrado. Una intrusión puede haber dejado diferentes mecanismos de persistencia.

Como procedimiento general:

1. Guardar una copia forense antes de modificar el sitio.
2. Poner la web en mantenimiento o limitar temporalmente el acceso.
3. Identificar la vulnerabilidad utilizada.
4. Comparar los archivos con paquetes originales y limpios.
5. Eliminar las puertas traseras confirmadas.
6. Revisar usuarios del CMS, administradores y cuentas del sistema.
7. Examinar tareas programadas, claves SSH y sesiones activas.
8. Actualizar el CMS, plugins, componentes, temas y plantillas.
9. Cambiar las contraseñas del CMS, base de datos, FTP/SFTP, SSH y panel.
10. Revocar sesiones y renovar claves o tokens de API.
11. Revisar los registros para determinar cuándo y desde dónde se produjo el acceso.
12. Repetir la auditoría después de la limpieza.

Si se elimina una puerta trasera sin corregir la vulnerabilidad que permitió instalarla, el sitio puede volver a ser comprometido.

Ejemplo completo en un servidor Plesk

Nos situamos en un directorio privado para guardar los resultados:

sudo -i
mkdir -p /root/auditorias/sitioweb.com
cd /root/auditorias/sitioweb.com

Ejecutamos la auditoría:

auditor-web.sh \
    -r /var/www/vhosts/sitioweb.com/httpdocs \
    --logs /var/www/vhosts/system/sitioweb.com/logs \
    --days 30

Al finalizar veremos las rutas generadas:

Informe completo:              /root/auditorias/sitioweb.com/auditoria-web-httpdocs-20260723-120530.log
Lista de ficheros sospechosos: /root/auditorias/sitioweb.com/auditoria-web-httpdocs-20260723-120530.sospechosos.txt
Script de revisión generado:  /root/auditorias/sitioweb.com/revisar-httpdocs-20260723-120530.sh

Iniciamos la revisión:

/root/auditorias/sitioweb.com/revisar-httpdocs-20260723-120530.sh

Si queremos conservar conjuntamente los resultados:

tar -czf auditoria-sitioweb.com-20260723.tar.gz \
    auditoria-web-httpdocs-20260723-120530.log \
    auditoria-web-httpdocs-20260723-120530.sospechosos.txt \
    revisar-httpdocs-20260723-120530.sh

El archivo comprimido puede contener rutas, nombres de usuario, fragmentos de código y otra información sensible. Debe guardarse con permisos restrictivos y no publicarse.

Auditor Web ayuda a investigar, no sustituye al administrador

La principal ventaja de Auditor Web es reunir en una sola ejecución muchas comprobaciones que normalmente realizaríamos mediante diferentes órdenes de find, grep, awk, consultas SQL y búsquedas en registros.

La salida en colores permite diferenciar rápidamente la ruta del archivo y el código encontrado. El informe conserva toda la información en texto plano y el revisor autónomo facilita recorrer uno por uno los archivos sospechosos sin ejecutarlos.

No obstante, la decisión final siempre debe basarse en el contexto. Un archivo legítimo puede utilizar funciones potencialmente peligrosas, mientras que una puerta trasera bien diseñada puede intentar evitar las firmas más conocidas.

Auditor Web debe considerarse el punto de partida de la investigación: una forma rápida, reproducible y ordenada de encontrar aquello que merece una revisión humana.

Nombre: Auditor Web
Versión descrita: 1.3.1
Sistemas: GNU/Linux
CMS reconocidos: Joomla, WordPress y sitios PHP genéricos
Funcionamiento: auditoría y revisión en modo de solo lectura