Etiqueta: malware detection

  • Diagnóstico profesional: herramientas que revelan lo que esconden los atacantes

    Diagnóstico profesional: herramientas que revelan lo que esconden los atacantes

    Diagnóstico profesional: herramientas que revelan lo que esconden los atacantes

    Cuando analizo un sitio web comprometido, lo primero que hago es dejar a un lado las suposiciones. En mi experiencia, la diferencia entre identificar una amenaza real o pasar por alto un backdoor silencioso depende casi enteramente de las herramientas que uses y de cómo las domines. En este artículo te muestro el arsenal técnico que yo utilizo diariamente para exponer lo que los atacantes intentan ocultarte.

    Por qué necesitas herramientas de diagnóstico específicas

    Un malware moderno no deja señales obvias. No es un archivo rojo titilante en tu panel de WordPress. Es código inyectado en funciones.php, es una tabla de base de datos con registros de backdoor, es un certificado SSL comprometido que sigue siendo válido, es un usuario fantasma creado hace seis meses que nadie recuerda. Sin las herramientas adecuadas, navegas a ciegas.

    Lo que recomiendo siempre es un enfoque en capas: escaneo superficial, análisis de código, inspección de base de datos, auditoría de logs, y búsqueda de indicadores de compromiso (IoC). Cada herramienta te revela una perspectiva distinta del ataque.

    Herramientas de escaneo web: tu primera línea de defensa

    Empiezo con Sucuri SiteCheck. No es una herramienta cara ni requiere instalación. Metes la URL y en segundos ves si Google ha marcado el dominio como malicioso, si hay inyección de código malicioso detectada, si los certificados SSL están comprometidos. He descubierto cryptominers que llevaban dos meses inyectados solo porque SiteCheck los detectó en la lista negra de proveedores.

    Sucuri SiteCheck es gratuito. Es tu aliado. Úsalo antes de hacer nada más.

    Para análisis más profundo, recomiendo MalCare Security. Es un plugin de WordPress que ejecuta un escaneo de malware comparando tu código contra una base de datos de más de 100 millones de firmas de malware conocidas. Lo que MalCare hace bien es detectar backdoors incrustados en temas y plugins legitimados. He visto casos donde un plugin de contacto aparentemente limpio contenía una webshell escondida bajo el nombre de una clase falsa.

    Wordfence Security es otra herramienta que uso constantemente. Su escáner es agresivo (a veces demasiado), pero su función de detección de cambios en archivos es imprescindible. Cuando alguien modifica tu wp-config.php o inyecta código en index.php, Wordfence lo sabe. Su CLI te permite automatizar auditorías sin depender del navegador.

    Inspección de línea de comandos: donde viven los ataques reales

    Las herramientas gráficas son tranquilizantes. La realidad está en la terminal.

    WP-CLI es mi arma más valiosa. Con un comando puedo listar todos los usuarios de WordPress, incluidos los fantasmas creados por backdoors. Con otro, puedo inspeccionar el contenido de funciones.php sin que el navegador intente renderizarlo (evitando que el código malicioso se ejecute mientras lo examino). Ejemplo básico:

    wp user list –allow-root

    Me muestra cada usuario, cada dirección de correo, cada fecha de creación. He encontrado usuarios llamados «temp», «admin2», «backup» creados en horarios extraños, siempre un indicador de compromiso.

    Para inspeccionar archivos sospechosos sin ejecutarlos, uso strings y grep. Si veo que un archivo .js tiene un tamaño inusual (200 KB cuando debería tener 20 KB), ejecuto:

    strings archivo.js | grep -i «eval|base64|setTimeout»

    Los atacantes casi siempre usan eval(), ofuscación base64 o setTimeout para ocultar código. Si lo encuentro, lo sé.

    Análisis de base de datos: donde los atacantes guardan los secretos

    La base de datos es el corazón del sitio. Un atacante que coloque una puerta trasera bien hecha siempre guarda credenciales, configuración maliciosa o registros en la BD.

    Accedo vía SSH y conecto directamente a MySQL:

    mysql -u usuario -p basedatos

    Luego ejecuto:

    SELECT * FROM wp_users WHERE user_registered > DATE_SUB(NOW(), INTERVAL 30 DAY);

    Esto me muestra cada usuario creado en los últimos 30 días. Frecuentemente encuentro usuarios que no reconoce nadie.

    También inspecciono tablas personalizadas que no deberían existir. Los atacantes a menudo crean tablas como wp_cache_malware o wp_tmp_data para almacenar datos exfiltrados. Un comando simple:

    SHOW TABLES;

    Te revela si hay tablas inusuales. Una vez encontré una tabla llamada «crypto_data» con direcciones de wallet de Bitcoin.

    Análisis de logs: la cronología del ataque

    Los logs nunca mienten. Un atacante puede borrar muchas cosas, pero si los logs de servidor están intactos, puedes reconstruir el ataque completo.

    Apache/Nginx logs en /var/log/apache2/access.log o /var/log/nginx/access.log contienen cada solicitud HTTP. Busco patrones sospechosos:

    grep «wp-admin|wp-login.php» /var/log/apache2/access.log | cut -d’ ‘ -f1 | sort | uniq -c | sort -rn

    Este comando me muestra qué IPs intentaron acceder a wp-login.php más veces. Ataques de fuerza bruta son obvios: cientos de peticiones desde la misma IP en minutos.

    Wordfence genera sus propios logs (en /wp-content/plugins/wordfence/) que son aún más útiles porque ya filtran intentos de ataque identificados.

    Herramientas de detección de inyección de código

    VirusTotal no es específicamente para WordPress, pero es poderosa. Subo archivos sospechosos (o incluso URLs completas) y dejo que 70+ antivirus los analicen simultáneamente. He detectado webshells que MalCare pasó por alto simplemente porque VirusTotal lo flagueó como Trojan.PHP.Shell.

    Para análisis local, grep recursivo es tu aliado. Busco patrones característicos de inyección:

    grep -r «eval(» . –include=»*.php» | head -20

    grep -r «base64_decode» . –include=»*.php»

    grep -r «assert(» . –include=»*.php»

    El 90% de los backdoors contienen al menos una de estas funciones. Es raro encontrar código legítimo que las use.

    Auditoría de permisos de archivos y propietarios

    Un ataque exitoso casi siempre requiere cambiar permisos de archivos. Un archivo .php que debería ser 644 pero es 777 es una bandera roja. Ejecuto:

    find . -type f -perm 777 -o -type f -perm 666

    Cualquier archivo con permisos de escritura global es sospechoso.

    También verifico propietarios:

    find . -not -user usuario_www -type f

    Si hay archivos propiedad de «root» o un usuario extraño en una carpeta que el servidor debería controlar, algo ocurrió.

    Inspección de certificados SSL y conexiones externas

    Atacantes modernos a menudo redirigen tráfico hacia servidores C2 (command and control). Inspecciono:

    openssl s_client -connect dominio.com:443

    Verifico que el certificado es legítimo y que no hay MITM (man-in-the-middle). También busco configuraciones de DNS sospechosas o modificaciones en .htaccess que redirijan tráfico.

    Monitoreo continuo vs. diagnóstico puntual

    El diagnóstico profesional no es un evento único. Después de detectar y limpiar un ataque, configuro monitoreo permanente. Wordfence en modo «monitoring» revisa cambios de archivos diariamente. Sucuri proporciona alertas de malware. Google Search Console notifica si hay malware detectado nuevamente.

    Lo que aprendí después de limpiar cientos de webs es que el 40% de los sites reinfectados lo fueron porque no se configuró vigilancia post-limpieza.

    Herramientas específicas para PrestaShop

    Si tu problema es PrestaShop, el enfoque es ligeramente distinto. Busco modificaciones en /classes/, inyecciones en /modules/, y especialmente en módulos de pago comprometidos. La herramienta más útil es una auditoría manual de hashes de archivos comparándola con la versión oficial de PrestaShop descargada directamente desde su web.

    El diagnóstico que no puedes hacer solo

    Estas herramientas te dan visibilidad. Pero cuando encuentras un backdoor bien ofuscado, o cuando necesitas reconstruir un ataque APT (Advanced Persistent Threat) para entender cómo los atacantes mantuvieron acceso durante meses, necesitas análisis forense profesional. Yo combino estas herramientas con análisis manual de código, ingeniería inversa de malware, y reconstrucción de cadenas de ataque.

    Si tu sitio ha sido comprometido o sospechas que lo está, estas herramientas te dan un diagnóstico inicial. Pero si necesitas garantía de que está completamente limpio, si necesitas investigación forense de un ataque sofisticado, o si el malware está bien oculto, contacta conmigo para un diagnóstico profesional completo. Ejecuto análisis manual, verifico cada línea de código sospechosa, audito permisos, inspecciono logs históricos, y te doy un reporte detallado de qué pasó, cómo entró, y cómo garantizar que no vuelva.

    El coste de no diagnosticar correctamente es mucho mayor que el de hacerlo bien desde el principio.

  • Cómo auditar logs de WordPress para encontrar malware

    Cómo auditar logs de WordPress para encontrar malware

    Cómo auditar logs de WordPress para encontrar malware

    Cuando analizo un sitio WordPress comprometido, lo primero que hago es revisar los logs. Los archivos de registro son tu mejor aliado para detectar qué ha pasado, cuándo entró el atacante y qué acciones realizó. En mi experiencia, muchos administradores ignoran completamente estos archivos, lo que les impide identificar infecciones hasta que es demasiado tarde.

    Los logs de WordPress no están habilitados por defecto, y esa es precisamente la razón por la que tantos sitios caen sin que nadie se dé cuenta. Aquí te enseño cómo configurarlos, dónde encontrarlos y cómo interpretarlos para detectar actividad maliciosa antes de que cause daños irreversibles.

    ¿Por qué los logs son críticos en la seguridad de WordPress?

    Los logs son el registro de eventos de tu sitio. Sin ellos, es como tener una tienda sin cámaras de vigilancia: cualquiera puede entrar, robar y marcharse sin dejar rastro. Un atacante que inyecta un backdoor, modifica archivos o ejecuta consultas maliciosas deja huellas en los logs si están configurados correctamente.

    Cuando no auditas logs regularmente, los malwares pueden vivir en tu servidor durante meses sin que lo sepas. He visto sitios de clientes con cryptominers ejecutándose 24/7, robando recursos, mientras el propietario no tenía ni idea. Los logs habrían mostrado exactamente cuándo se instaló el script malicioso y desde dónde.

    Además, los logs te permiten:

    • Identificar intentos de acceso no autorizados al wp-admin
    • Detectar inyecciones SQL y XSS en tiempo real
    • Encontrar plugins o temas modificados maliciosamente
    • Rastrear cambios no autorizados en la base de datos
    • Cumplir requisitos legales de auditoría (RGPD, AEPD)
    • Análisis forense después de una brecba de seguridad

    Habilitando debug y logging en WordPress

    Lo primero es activar los logs. WordPress tiene un sistema nativo de debug que, sorprendentemente, está deshabilitado por defecto. Accede a tu archivo wp-config.php (en la raíz de tu instalación) y busca esta sección:

    define(‘WP_DEBUG’, false);

    Cámbialo por:

    define(‘WP_DEBUG’, true);
    define(‘WP_DEBUG_LOG’, true);
    define(‘WP_DEBUG_DISPLAY’, false);

    El parámetro WP_DEBUG_DISPLAY en false es importante: hace que los errores se registren en un archivo en lugar de mostrarse públicamente en tu sitio (lo que sería un riesgo de seguridad).

    Una vez guardado, WordPress creará automáticamente un archivo de log en /wp-content/debug.log. Este archivo contendrá todos los errores de PHP, advertencias y mensajes de depuración de plugins y temas.

    Los diferentes tipos de logs en WordPress

    WordPress genera varios tipos de logs, y cada uno cuenta una historia diferente:

    1. Debug.log (PHP errors)

    Este es el más obvio. Contiene errores de PHP, advertencias y notificaciones. Si un plugin malicioso intenta ejecutar código, aquí aparecerán sus errores. Cuando reviso un sitio comprometido, busco patrones como:

    • Llamadas a funciones no definidas (típico de backdoors que intentan ejecutar comandos del sistema)
    • Errores de permisos en archivos (alguien intentó escribir un webshell)
    • Warnings de conexión a bases de datos externas (comunicación con servidores de comando y control)

    2. Logs del servidor (Apache/Nginx)

    Estos están a nivel de servidor, no de WordPress. Contienen:

    • Access logs: Cada solicitud HTTP (GET, POST) con IP, timestamp, navegador, código de respuesta
    • Error logs: Errores del servidor, intentos de acceso a archivos inexistentes, errores de permiso

    En Apache, busca en /var/log/apache2/access.log o /var/log/apache2/error.log. En Nginx, en /var/log/nginx/access.log.

    3. Logs de la base de datos MySQL

    Si habilitaste el query logging en MySQL, verás cada sentencia SQL ejecutada. Esto es especialmente útil para detectar inyecciones SQL. Para habilitarlo en MySQL, añade esto a /etc/mysql/mysql.cnf:

    general_log = 1
    general_log_file = /var/log/mysql/mysql.log

    Ten cuidado: el query logging impacta en el rendimiento. Úsalo solo durante auditorías, no en producción permanentemente.

    4. Logs de plugins de seguridad

    Si tienes Wordfence, Sucuri o similar instalados, generan sus propios logs. Estos son especialmente valiosos porque esos plugins ya filtran eventos sospechosos por ti. Wordfence CLI permite analizar logs desde la terminal:

    wordfence-cli scanner scan –verbose

    Dónde encontrar los logs de WordPress

    El archivo debug.log está en /wp-content/debug.log (suponiendo que tu instalación de WordPress está en la raíz).

    Lo puedes consultar vía:

    • SFTP/FTP: Conecta a tu servidor y descarga el archivo directamente
    • SSH: Usa comandos como tail -f /path/to/wp-content/debug.log para ver el final del archivo en tiempo real
    • Panel de control: Si tienes cPanel, busca File Manager y navega a wp-content
    • WP-CLI: wp eval ‘echo file_get_contents( WP_CONTENT_DIR . «/debug.log» );’

    Para los logs del servidor (Apache/Nginx), necesitarás acceso SSH o a través de tu proveedor de hosting.

    Señales de malware en los logs: qué buscar

    Ya tienes los logs. Ahora vamos a lo importante: detectar el malware. Aquí están los patrones que yo busco siempre:

    Intentos de ejecución de comandos del sistema

    Los backdoors intentan ejecutar comandos como exec(), system(), shell_exec(), passthru(). Si ves errores como:

    Fatal error: Call to undefined function exec()

    Significa que alguien está intentando ejecutar comandos. Busca el archivo fuente en el mensaje de error.

    Accesos a archivos sospechosos en access.log

    En los logs de Apache/Nginx, busca patrones como:

    • wp-admin/upload.php?param=… – Upload de archivos no autorizado
    • wp-admin/admin-ajax.php?action=malicious_action – AJAX manipulation
    • GET /wp-content/uploads/2024/01/shell.php – Acceso a webshell inyectado
    • POST /index.php?id=1′ OR ‘1’=’1 – Inyección SQL clásica

    También busca códigos de respuesta sospechosos: 403 (acceso denegado), 500 (error interno, a menudo por malware), 200 para archivos que no deberían estar ahí.

    Cambios en la base de datos

    Si tienes MySQL general log habilitado, busca:

    • ALTER TABLE – Modificación de estructura de tablas
    • INSERT INTO wp_posts desde IPs raras o a horas inusuales
    • UPDATE wp_options SET option_value – Cambio de configuraciones críticas
    • DROP TABLE – Eliminación destructiva (ransomware)

    Modificaciones de archivos

    Si tu hosting registra cambios de archivos, busca:

    • Archivos PHP nuevos en /wp-content/uploads/ (zona típica para inyectar webshells)
    • Cambios en wp-config.php o .htaccess en fechas sospechosas
    • Plugins o temas con fechas de modificación reciente sin que los hayas actualizado

    Herramientas para automatizar el análisis de logs

    Analizar logs manualmente es tedioso. Estas herramientas lo hacen más fácil:

    WP-CLI con grep

    Si tienes WP-CLI instalado, puedes extraer información rápidamente:

    tail -500 /path/to/wp-content/debug.log | grep «Fatal|Warning|Notice»

    Esto te muestra los últimos 500 líneas del log, filtrando solo errores relevantes.

    Wordfence CLI

    Si tienes Wordfence (gratuito), la herramienta CLI es excelente:

    wordfence-cli firewall view-live

    Te muestra en tiempo real qué está intentando bloquear el firewall.

    MalCare y Sucuri

    Si usas estos plugins de seguridad premium, generan reportes visuales de los logs. Recomiendo especialmente MalCare por su interfaz de análisis forense.

    Google Search Console y Google Analytics

    No son logs técnicos, pero son señales. Si ves un aumento repentino de:

    • Advertencias de malware en GSC
    • Tráfico desde URLs raras
    • Redirecciones no autorizadas

    Eso significa que Google ha detectado algo. Ve a los logs del servidor para confirmarlo.

    Análisis forense: paso a paso

    Aquí está mi metodología cuando encuentro un sitio comprometido:

    Paso 1: Recolecta todos los logs
    Descarga los logs de al menos 30 días atrás (o más, si tienes espacio). El malware puede estar dormido y activarse después.

    Paso 2: Identifica el timeline
    Busca la primera aparición de actividad sospechosa. ¿Cuándo comenzó? ¿Hubo un cambio de plugin, una actualización, un pico de tráfico antes?

    Paso 3: Traza la IP del atacante
    En access.log, filtra por IPs que hayan accedido a wp-admin o uploads justo antes del evento. Algunos atacantes usan proxies, pero otros dejan rastros claros.

    Paso 4: Analiza el payload
    ¿Qué archivos modificaron? ¿Qué parámetros enviaron en POST? Esto te dice qué tipo de malware instalaron.

    Paso 5: Identifica el vector de entrada
    ¿Fue un plugin desactualizado? ¿Una contraseña débil de wp-admin? ¿Una vulnerabilidad de temas? Esto es crítico para evitar que vuelva a pasar.

    Configuración defensiva: logs para el futuro

    Una vez limpies el malware, implementa logging defensivo para detectar futuros ataques rápidamente:

    • Habilita WP_DEBUG_LOG permanentemente
    • Configura rotación de logs (con logrotate en Linux) para que no ocupen demasiado espacio
    • Activa alertas en tu hosting si un archivo .php se crea en wp-content/uploads/
    • Usa un plugin como Activity Log para registrar cambios en WordPress (qué usuario cambió qué, cuándo)
    • Implementa reglas en .htaccess para bloquear acceso directo a archivos sospechosos
    • Monitoriza los logs regularmente (mínimo semanal)

    Si tu sitio es crítico, un Sistema de Detección de Intrusiones (IDS) como Fail2Ban puede bloquear automáticamente IPs que intenten ataques comunes:

    [sshd]
    enabled = true
    port = ssh
    filter = sshd
    logpath = /var/log/auth.log
    maxretry = 5

    Errores comunes que cometen los administradores

    En mi experiencia auditando cientos de sitios, estos son los errores que veo constantemente:

    • No rotar los logs: El debug.log crece infinitamente si no lo limpias. Puedes usar un cron job: 0 0 * * * > /path/to/wp-content/debug.log
    • Ignorar los warnings: «Un warning no es un error grave». Error. Los warnings son a menudo el primer signo de malware.
    • No correlacionar logs: Mirar solo debug.log y no cruzarlo con access.log. Necesitas ver la imagen completa.
    • Acceso inseguro a logs: Si dejas debug.log visible públicamente, los atacantes ven qué plugins tienes. Usa .htaccess: Deny from all
    • No archivar logs antiguos: Después de 30-90 días, descarga los logs a almacenamiento seguro. Los atacantes a menudo los borran para cubrir sus huellas.

    Protegiendo los propios logs

    Un detalle importante: los atacantes intentan borrar logs para no dejar rastro. Protégelos:

    • Hace que wp-content/debug.log no sea legible por el servidor web (permisos 600)
    • Copia los logs regularmente a un almacenamiento remoto (S3, Google Cloud)
    • Usa un servicio de log centralizado como ELK Stack o Splunk para empresas

    Técnicamente, puedes configurar Syslog en WordPress para enviar logs directamente a un servidor syslog remoto, lejos del sitio comprometido:

    define(‘WP_DEBUG_LOG’, ‘/dev/log’);

    Esto envía los logs al demonio syslog en lugar de a un archivo local.

    Integración con herramientas de monitoreo SIEM

    Para sitios empresariales, recomiendo integrar WordPress con un SIEM (Security Information and Event Management). Esto centraliza todos los logs (WordPress, servidor, firewall, base de datos) en un único panel para análisis automático de amenazas.

    Incluso sin SIEM, un simple script bash que revise los logs diariamente y te envíe un resumen es muy útil:

    #!/bin/bash
    LOG_FILE=»/var/www/html/wp-content/debug.log»
    ERRORS=$(grep -i «fatal|error» «$LOG_FILE» | wc -l)
    if [ $ERRORS -gt 10 ]; then
      mail -s «Alerta: $ERRORS errores en WordPress» admin@tudominio.com < «$LOG_FILE»
    fi

    Conclusión: auditoría de logs como hábito de seguridad

    Auditar logs regularmente no es complicado, pero es la diferencia entre detectar un malware en 24 horas o descubrirlo cuando ya ha robado datos de clientes. He visto el daño que causa la negligencia.

    Mi recomendación es sencilla: habilita logging hoy, revisa los logs semanalmente, crea alertas automáticas y archiva logs históricos. Es como un sistema inmunológico para tu WordPress.

    Si descubres actividad sospechosa en los logs y no sabes cómo proceder, o si necesitas una auditoría forense profesional, en ManuelFolgar.com disponemos de herramientas especializadas y experiencia en decenas de casos de compromiso. Contacta conmigo para una auditoría de seguridad completa de tu sitio WordPress.

    Referencias técnicas

    Para más información sobre logging en WordPress y seguridad web: