Por qué el malware regresa si no cierras todas las puertas

Por qué el malware regresa si no cierras todas las puertas

En mi experiencia como especialista en limpieza de malware, la pregunta que más escucho de mis clientes es: «¿Por qué ha vuelto el virus si ya lo eliminé?» La respuesta es casi siempre la misma: porque dejaron una puerta abierta. El malware no desaparece por arte de magia si solo eliminas los archivos infectados visibles. Es como limpiar tu casa de ladrones pero dejar la ventana del sótano sin cerrar.

La realidad es que cuando un sitio web ha sido comprometido, el atacante rara vez deja una única vía de acceso. Instala múltiples backdoors, modifica archivos críticos, crea cuentas ocultas y abre túneles de comunicación directa con servidores remotos. Si no cierras todas esas puertas, el malware volverá. Y lo hará rápido.

Las puertas abiertas más comunes en WordPress y PrestaShop

Cuando analizo un sitio infectado, lo primero que busco no es el malware evidente, sino los mecanismos de persistencia que el atacante ha dejado estratégicamente. Estos son los vectores más habituales:

• Backdoors en archivos core: código inyectado en wp-config.php, .htaccess, index.php o functions.php que permite acceso remoto incluso después de cambiar contraseñas
• Plugins y temas nulled o modificados: contienen código malicioso que se activa en cada carga de página
• Usuarios administrativos ocultos: cuentas creadas por el atacante con permisos totales y nombres genéricos como «admin2» o «service»
• Tareas cron maliciosas: trabajos programados que descargan malware o ejecutan código periódicamente
• Archivos webshell: scripts PHP que permiten ejecutar comandos en el servidor (upload.php, ajax.php, admin-ajax.php modificado)
• Hooks y filtros comprometidos: en WordPress, se inyectan en functions.php para interceptar solicitudes
• Permisos de directorio incorrectos: carpetas con permisos 777 que permiten que el malware se reinstale automáticamente
• Módulos PrestaShop maliciosos: instalados silenciosamente con capacidad de capturar datos de tarjetas (Magecart)

El problema es que la mayoría de limpiezas caseras o con herramientas automáticas solo eliminan los archivos infectados visibles. No auditan permisos, no revisan historial de cambios, no buscan cron jobs maliciosos, y definitivamente no verifican si hay backdoors en archivos que parecen legítimos.

¿Por qué vuelve tan rápido el malware?

Si has limpiado tu sitio hace una semana y la infección ha reaparecido, es porque una de estas puertas seguía abierta. El atacante simplemente executó el backdoor que dejó instalado. Este proceso es automático y ocurre en cuestión de minutos o horas.

Imaginemos un caso real: Un sitio WordPress infectado con una webshell en `/wp-content/uploads/shell.php`. Se limpia el archivo, pero nadie:

1. Revisa si hay más webshells en esa carpeta o en /wp-content/plugins/
2. Cambia los permisos de /wp-content/uploads a 755 (en lugar de 777)
3. Verifica si el .htaccess contiene redirecciones maliciosas
4. Audita las opciones de la base de datos en busca de URLs maliciosas
5. Comprueba si hay tareas cron que redescarguen el código

Resultado: el malware vuelve en 24 horas porque el atacante tiene un acceso que no fue bloqueado.

Las puertas específicas que debes cerrar

1. Vulnerabilidades en plugins y temas desactualizados

Esta es la puerta número uno. Lo que recomiendo siempre es que verifiques:

• Todos los plugins y temas instalados, incluso los inactivos, están actualizados
• No usas versiones «nulled» o crackeadas de temas premium
• Has eliminado plugins que ya no necesitas (cada uno es una superficie de ataque)
• Usas herramientas como WP-CLI para auditar: `wp plugin list –format=json` y verificar versiones contra NVD (National Vulnerability Database)

Las vulnerabilidades de día cero en plugins populares se explotan automáticamente mediante botnets. Si tu sitio es accesible y vulnerable, será atacado. Punto.

2. Contraseñas débiles y cuentas por defecto

La puerta de acceso más fácil es `wp-admin/` con credenciales malas. En mi experiencia, el 40% de los compromisos comienzan con un ataque de fuerza bruta a wp-login.php.

Lo que necesitas hacer:

• Cambiar todas las contraseñas: admin de WordPress, FTP/SFTP, acceso a base de datos, cPanel, correo del dominio
• Eliminar cuentas administrativas inactivas o sospechosas (verifica en Usuarios)
• Implementar autenticación de dos factores (2FA) en wp-admin mediante Wordfence o similar
• Proteger wp-login.php con una regla .htaccess que limite intentos: máximo 5 intentos en 15 minutos
• Usar wp-cli para listar usuarios: `wp user list –format=table`

3. Archivos modificados en directorios core

Cuando analizo un sitio, busco modificaciones recientes en:

• wp-config.php (agrega líneas de código al final, antes del «?>»)
• .htaccess (redirecciones maliciosas, inyección de PHP)
• index.php en raíz (código inyectado antes de `<?php`)
• wp-includes/template-loader.php (hooks maliciosos)
• wp-admin/includes/admin.php

La mejor forma de detectar esto es comparar los timestamps y el contenido contra una instalación limpia de WordPress, o usar herramientas como Wordfence CLI que escanean integridad de archivos.

4. Permisos de directorio inseguros

Si tus directorios tienen permisos 777, el malware se reinstala solo. Lo correcto es:

• Directorios: 755
• Archivos: 644
• wp-config.php: 600
• .htaccess: 644

Puedo ejecutar esto vía SSH:

find /home/usuario/public_html -type d -exec chmod 755 {} ;
find /home/usuario/public_html -type f -exec chmod 644 {} ;
chmod 600 /home/usuario/public_html/wp-config.php

Sin estos permisos correctos, el atacante puede cargar nuevos archivos maliciosos automáticamente.

5. Base de datos comprometida

El malware inyecta opciones, posts y metadata en la base de datos que ejecutan código cada vez que se carga la página. Cuando analizo bases de datos infectadas, busco:

• Opciones con valores que contienen etiquetas « o `eval()`
• Posts con títulos o contenido codificado en base64
• Metadata de posts con URLs maliciosas
• Tabla wp_options: busca en `option_value` strings como `eval`, `system`, `base64_decode`

Consulta SQL para detectar:

SELECT * FROM wp_options WHERE option_value LIKE ‘%eval%’ OR option_value LIKE ‘%base64_decode%’;

Si encuentras coincidencias, esas opciones son backdoors. Eliminarlas es crítico, pero también debes identificar cómo llegaron ahí (plugin vulnerable, acceso no autorizado).

6. Tareas cron maliciosas

En WordPress, el atacante puede crear eventos cron que ejecutan código periódicamente. Están almacenados en wp_options:

SELECT * FROM wp_options WHERE option_name LIKE ‘%cron%’;

Si ves cron jobs que no reconoces (especialmente con nombres genéricos), son probablemente maliciosos. También pueden estar en el servidor, en `/var/spool/cron/`.

7. Directorios y archivos ocultos

Los atacantes crean directorios con nombres que pasan desapercibidos:

• /wp-content/.cache/
• /wp-content/uploads/.htaccess (contiene redirecciones)
• /wp-includes/class-wp-.php (archivos fake que imitan nombres reales)
• /home/usuario/.ssh/ o /home/usuario/.bash_history (para acceso SSH persistente)

Necesitas hacer un listado exhaustivo del servidor. Vía SSH:

find /home/usuario/public_html -type f -name «*.php» -newer /tmp -exec ls -la {} ;

Esto lista archivos PHP creados recientemente, que probablemente sean malware.

El flujo completo de cierre de puertas

La limpieza real no es «eliminar malware», sino auditar, sellar y blindar. Estos son los pasos que aplico en cada caso:

Fase 1: Identificación exhaustiva (48-72 horas)

• Escaneo completo de archivos (VirusTotal API, Wordfence CLI, MalCare)
• Auditoría de base de datos (búsqueda de código inyectado, opciones sospechosas)
• Análisis de logs del servidor (access.log, error.log, archivo de errores de PHP)
• Comparación de integridad de archivos core contra versión oficial
• Verificación de cuentas de usuario (SSH, FTP, base de datos, WordPress)
• Análisis de tráfico de red saliente (conexiones a servidores C2)

Fase 2: Eliminación verificada

• Borrado de todos los archivos infectados (incluyendo webshells ocultos)
• Limpieza de base de datos: eliminación de opciones, posts y metadata maliciosa
• Eliminación de cuentas de usuario no autorizadas
• Limpieza de .htaccess y redirecciones
• Reseteo completo de wp-config.php y archivos core

Fase 3: Cierre de puertas

• Cambio de todas las contraseñas (WordPress, FTP, cPanel, base de datos)
• Corrección de permisos de archivos y directorios
• Instalación de WAF (Wordfence, Sucuri) para bloquear patrones de ataque
• Protección de wp-login.php y wp-admin con .htaccess
• Deshabilitación de edición de archivos en WordPress (define(‘DISALLOW_FILE_EDIT’, true);)
• Cambio de prefijo de tablas en base de datos
• Implementación de 2FA en admin

Fase 4: Fortalecimiento (hardening)

• Configuración de HTTPS con certificado SSL válido
• Activación de HSTS (HTTP Strict Transport Security)
• Content Security Policy (CSP) para evitar inyección de scripts
• Limitación de ejecución de PHP en directorios de upload
• Monitoreo continuo con alertas de cambios de archivos
• Backups automatizados en servidor remoto

Por qué las herramientas automáticas fallan

Los plugins de seguridad automáticos como Wordfence, Sucuri o MalCare son útiles, pero tienen limitaciones. No pueden:

• Auditar permisos del sistema de archivos correctamente
• Detectar código ofuscado que imita funciones legítimas
• Identificar acceso SSH no autorizado (requiere análisis forense del servidor)
• Analyzehistoria completa de cambios si no está habilitada (git log, Subversion)
• Sellar vulnerabilidades en aplicaciones custom (código a medida)

Por eso, cuando el malware regresa una y otra vez, es hora de hacer una auditoría profesional real. No es paranoia; es necesidad.

La puerta que olvidaron los atacantes (y tú también)

En el 30% de los casos que manejo, descubro que el sitio se reinfecta porque el servidor mismo está comprometido. No es solo tu WordPress: es que otro cliente en el mismo servidor compartido tiene un malware que da acceso a todos los archivos.

Si estás en hosting compartido y el malware regresa constantemente:

• Considera migrar a un servidor dedicado o VPS
• Solicita a tu proveedor que audite todas las cuentas del servidor
• Verifica si hay otros sitios comprometidos en el mismo servidor (via SSH: `ls -la /home/`)
• Cambia la IP del servidor si es posible

Esta es una puerta que muchos especialistas ni siquiera comprueban. Por eso el malware sigue regresando.

¿Cómo sabes que todas las puertas están cerradas?

La confirmación viene cuando:

1. Pasan 30 días sin detectar archivos nuevos o cambios no autorizados
2. Los logs del servidor no muestran intentos de acceso fallidos en wp-admin
3. Google Search Console no reporta malware
4. VirusTotal da resultado limpio cuando escaneas tu dominio
5. Las herramientas de monitoreo (Wordfence) no generan alertas de cambios
6. La tasa de bounce en Google Analytics vuelve a la normalidad (el malware no redirige ya)

Hasta que no cumples todos estos puntos, hay al menos una puerta abierta.

La verdad incómoda es que eliminar malware es fácil; cerrar todas las puertas es difícil. Requiere conocimiento técnico profundo, herramientas especializadas y auditoría forense completa. Por eso el 85% de las «limpiezas caseras» fracasan en los primeros 7 días.

Si tu sitio ha sido infectado más de una vez, no es mala suerte. Es que quedó una puerta abierta, y no fue cerrada adecuadamente. Contacta conmigo en ManuelFolgar.com/contacto para una auditoría de seguridad profesional que cierre todas las brechas y evite reinfecciones futuras.