Caso de éxito: Desinfección integral y erradicación de malware en WordPress

En este caso de estudio documento paso a paso la auditoría técnica, la desinfección y el posterior blindaje que realicé en el sitio web de una clínica médica. El servidor se encontraba completamente colapsado por una infección de malware recurrente extremadamente agresiva que se reactivaba sola. Aquí detallo cómo conseguí erradicarla de raíz y restablecer el rendimiento del sistema a niveles óptimos.

Cliente	Clínica de Especialistas Médicos (Anonimizado)
Sector	Salud y Bienestar
Objetivo principal	Eliminar infecciones recurrentes por malware, corregir consumo de CPU al 99% y erradicar malware con autogeneración de archivos.

Resumen Ejecutivo: Una clínica médica sufría caídas constantes y una sobrecarga de recursos del servidor (CPU al 99% constante) debido a una infección de malware recurrente que se autogeneraba cada vez que era borrada. Llevé a cabo una auditoría forense a través de SSH, saneé el core de WordPress, eliminé scripts de persistencia en archivos ocultos de configuración del servidor y base de datos, y blindé el entorno perimetral. El servicio se restableció por completo y el consumo del servidor regresó a niveles óptimos de reposo.

🔍 1. Diagnóstico Inicial y Auditoría de Seguridad

El sitio web presentaba un comportamiento errático, redirecciones móviles no autorizadas hacia sitios sospechosos, caídas intermitentes causadas por el consumo de recursos (CPU de forma constante al 99-100% de su capacidad) y advertencias de seguridad de los proveedores de búsqueda.

Tras una inspección inicial por línea de comandos, determiné que no se trataba de una inyección simple en un theme. Existía un entramado de archivos coordinados para la persistencia: scripts capaces de autogenerarse inmediatamente y restaurar el código malicioso en cuanto yo intentara borrar algún archivo infectado.

ℹ️ Info: Resumen no técnico (¿Qué significa esto en cristiano?)

La página web de la clínica fallaba, mandaba a los usuarios que entraban desde el móvil a páginas de publicidad engañosa y hacía que el servidor de hosting estuviera saturado trabajando al 99% de su capacidad. Tras analizar los archivos con la línea de comandos, descubrí que no era un hackeo simple en una plantilla: el virus tenía "mecanismos de persistencia", es decir, programas ocultos diseñados para volver a crear el virus de forma automática e inmediata si yo intentaba borrarlo manualmente.

🦠 2. Anatomía de la Infección (Mecanismos de Persistencia)

Localicé backdoors y payloads ocultos en diferentes capas del CMS y el servidor web:

A. Nivel Servidor (Pre-Ejecución de PHP)

• Archivos .user.ini: Ubicados en la raíz y en subcarpetas clave. Forzaban la directiva auto_prepend_file = "/ruta-absoluta/wp-content/.1cfb1425.php". Esto garantizaba que el archivo malicioso se ejecutara antes que cualquier archivo legítimo de WordPress.
• Inyección en .htaccess: Configurado con directivas similares de PHP prepended para ejecutar código malicioso silenciosamente en cada petición HTTP externa.

B. Nivel Core de WordPress (Dropins y mu-plugins)

• Backdoor en wp-content/mu-plugins/sso-loader.php: Un plugin "Must-Use" no listado en el panel administrativo que permitía el inicio de sesión remoto automatizado de atacantes con privilegios de administrador.
• Dropins parasitarios (db.php y object-cache.php): Modificados para incluir stagers ofuscados en base64 que interceptaban conexiones de base de datos.
• Archivos ocultos hexadecimales: Archivos con nombres aleatorios y ocultos mediante punto inicial (por ejemplo, .01fe17d9.php, eae879f0.php, .63e9870d.php y empaquetados .zip en directorios profundos).

C. Nivel Plantillas y Plugins

• Tema clonador inactivo (perf-theme-child): Un theme hijo inactivo que servía como stager redundante. Su archivo functions.php monitorizaba y recreaba las puertas traseras principales del sitio si estas eran eliminadas.
• Tabla huérfana en base de datos (wp_wpfm_backup): Rastro de un popular plugin de gestión de archivos con vulnerabilidades RCE (ejecución remota de código) conocidas, una de las vías de entrada históricas.

D. Nivel Base de Datos

• Administrador oculto: Creación del usuario con privilegios de administración adm_e5c3784d73.
• Tareas cron en wp_options: Tareas automáticas del planificador de WordPress (como sc_cron_fetch o j7coqs9ezlp9fztb4dww) destinadas a forzar descargas externas del virus periódicamente.

ℹ️ Info: Resumen no técnico (¿Qué significa esto en cristiano?)

El malware se había escondido como un parásito en cuatro sitios distintos: 1) configuraciones invisibles del servidor (.user.ini) que obligaban a ejecutar el virus antes que la propia web, 2) un plugin falso oculto de administración, 3) plantillas inactivas que servían de "vigilantes" para recrear el virus si era eliminado, y 4) un usuario administrador secreto con tareas automáticas programadas en la base de datos para infectar la web repetidamente.

🛠️ 3. Plan de Acción y Desinfección Quirúrgica

Para garantizar una limpieza definitiva, implementé un protocolo de saneamiento completo basándome en la estrategia de reinstalación limpia:

Paso 1: Aislamiento Local y Desinfectación de Archivos

1. Descargué el sitio completo a un entorno de desarrollo seguro e incomunicado del exterior.
2. Eliminé los directorios wp-admin and wp-includes en su totalidad, sustituyéndolos por copias oficiales e íntegras.
3. Audité manualmente el directorio wp-content/themes/custom-theme (el tema activo de la clínica) y desinfecté su archivo functions.php de cargadores de scripts de terceros.
4. Borré el resto de plugins, sustituyéndolos por sus versiones limpias del repositorio oficial de WordPress.

Paso 2: Saneamiento Profundo de la Base de Datos

1. Localicé y eliminé el usuario administrador oculto adm_e5c3784d73.
2. Limpié la tabla wp_options buscando transient variables inyectadas y opciones sospechosas relacionadas con la persistencia.
3. Eliminé la tabla huérfana de backups vulnerables (wp_wpfm_backup).
4. Desactivé y eliminé las tareas programadas maliciosas dentro de la opción de crons serializados de WordPress.
5. Actualicé la contraseña de la cuenta administradora legítima a un hash de alta seguridad.

Paso 3: Recuperación de la Página de Portada y Estructura

La base de datos original tenía corrompida la página fijada como portada de la clínica (provocando errores 404 en la home tras limpiar los archivos). Reconstruí y reasigné el ID de la página mediante SQL y corregí los límites del blog en functions.php (forzando 9 elementos por página en las consultas principales para estabilizar el diseño).

ℹ️ Info: Resumen no técnico (¿Qué significa esto en cristiano?)

Para curar la web de forma definitiva sin dejar rastro del virus, me descargué toda la página a mi ordenador local en un entorno seguro y aislado del exterior. Allí eliminé por completo los archivos del sistema de WordPress y los reemplacé por copias limpias y oficiales. Además, revisé a mano la plantilla de diseño de la clínica, borré los plugins y reconstruí la base de datos eliminando al administrador pirata y las tareas de autoinfección.

🔒 4. Hardening y Blindaje en Producción

Subir de nuevo el sitio limpio al hosting no es suficiente si el servidor web no está protegido. Apliqué las siguientes medidas de seguridad perimetral:

A. Reglas en .htaccess perimetral

• Bloqueo de Query Strings parametrizados (410 Gone): Dado que el malware utilizaba llamadas URL con parámetros para ejecutar comandos (ej. ?action=cmd...), bloqueé todas las Query Strings del frontend devolviendo una respuesta 410, protegiendo explícitamente rutas de administración e indexación legítimas (wp-admin, wp-json, wp-login.php, admin-ajax.php).
• Permití parámetros de caché como ?ver= para archivos JS, CSS e imágenes comunes.
• Impedí la ejecución de archivos PHP en directorios de subida de imágenes y carpetas comunes de wp-content.

B. Directivas de wp-config.php

Añadí parámetros restrictivos en la configuración:

• define('DISALLOW_FILE_EDIT', true);: Deshabilita el editor de código del panel para impedir modificaciones si un atacante comprometiera una sesión.
• define('FS_METHOD', 'direct');: Resuelve los permisos de escritura del core sin requerir credenciales FTP en texto plano.
• Salts de seguridad: Invalidé todas las cookies y sesiones activas en navegadores de forma inmediata sustituyendo los Security Salts corporativos de WordPress.

ℹ️ Info: Resumen no técnico (¿Qué significa esto en cristiano?)

Volver a subir la web limpia al servidor no sirve de nada si las puertas de entrada siguen abiertas. Por ello, apliqué un "escudo digital": bloqueé las solicitudes sospechosas que intentaran inyectar comandos o códigos maliciosos mediante parámetros en la barra de direcciones, prohibí la ejecución de cualquier programa en las carpetas de imágenes y desactivé la edición de código interna de WordPress. Así, aunque un atacante consiga contraseñas, no podrá cambiar los archivos del servidor.

🕵️‍♂️ 5. Playbook de Auditoría: Comandos Útiles

Este es el protocolo rápido de comandos SSH que utilizo para buscar rastros de malware en otros proyectos alojados en el mismo servidor:

Buscar inyecciones de pre-ejecución (.user.ini)

find . -maxdepth 3 -name ".user.ini" -exec grep -H "auto_prepend_file" {} \;

Buscar archivos php hexadecimales ocultos

find wp-content/ -type f -name "[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f].php" \
  -o -name ".[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f].php" 2>/dev/null

Comprobar dropins y mu-plugins sospechosos

ls -la wp-content/mu-plugins/sso-loader.php wp-content/db.php wp-content/advanced-cache.php 2>/dev/null

Buscar opciones maliciosas y eventos cron (WP-CLI)

wp db query "SELECT option_name FROM wp_options WHERE option_name LIKE '%sc_payload%';"
wp cron event list | grep -E "sc_cron_fetch|j7coqs9ezlp9fztb4dww"

ℹ️ Info: Resumen no técnico (¿Qué significa esto en cristiano?)

Estos comandos técnicos son como los análisis de sangre que utilizo para buscar rastros invisibles de virus en cualquier servidor. Me permiten detectar de forma automática carpetas sospechosas, archivos ocultos y configuraciones fraudulentas en segundos mediante la terminal negra del sistema.

📈 6. Resultados Obtenidos

• Consumo de CPU del Hosting: Estabilizado por debajo del 5% tras eliminar los bucles y peticiones parasitarias del malware.
• Disponibilidad e Integridad: Sitio web limpio certificado sin incidencias ni redirecciones no deseadas.
• SEO de Spam Neutralizado: Las redirecciones y las URLs generadas artificialmente devuelven el código 410 Gone, eliminando los enlaces fantasma de los índices de búsqueda.

📝 7. Conclusiones y Aprendizajes (Key Takeaways)

1. La desinstalación superficial no sirve: Borrar un plugin comprometido de WordPress no elimina tablas de bases de datos huérfanas o scripts con directivas de ejecución automática configuradas en el servidor web.

2. Inspección profunda obligatoria: Los escáneres automáticos de seguridad a menudo fallan al no auditar archivos del sistema externo a WordPress como `.user.ini` o dropins específicos. La línea de comandos y el acceso SSH directo son insustituibles.

3. Defensa a nivel perimetral: Implementar reglas estrictas a nivel de servidor web (como las redirecciones 410 ante intentos de inyección y la denegación de ejecución PHP en carpetas de uploads) detiene los ataques antes de que interactúen con el software de WordPress, protegiendo los recursos de hardware.