Malware en CMS: por qué se producen reinfecciones y cómo evitarlas de forma definitiva
Por Kike Gandia · Co-Fundador y CEO, OSCP
La reinfección es el patrón más frustrante de los compromisos de CMS: la web se limpia, vuelve a aparecer malware en días o semanas. Ocurre porque la limpieza superficial no elimina el vector de entrada original ni los mecanismos de persistencia que instaló el atacante. Esta guía explica el ciclo de reinfección y cómo romperlo.
Por qué los CMS comprometidos se reinfectan
La limpieza de malware en CMS tiene dos capas: eliminar el código malicioso visible y cerrar el vector de entrada que permitió el compromiso inicial. La mayoría de limpiezas superficiales solo hacen la primera parte.
Cuando el vector de entrada original no se cierra —un plugin vulnerable, credenciales comprometidas, una web shell en un directorio de uploads— el atacante puede reinstalar el malware en horas o días. En compromisos sofisticados, el atacante deja múltiples mecanismos de persistencia: web shells en rutas poco habituales, usuarios administrativos ocultos, tareas programadas (cron) que reinstalan el malware, modificaciones en el núcleo del CMS y código malicioso en ficheros de tema.
Tipos de malware habituales en CMS
Web shells PHP: Ficheros PHP que dan control remoto del servidor al atacante. Se camuflan con nombres de ficheros similares a los del core (wp-feed.php, class.db.php) o se inyectan en ficheros legítimos.
SEO spam: Inyección de enlaces a sitios de spam en el contenido de la web (invisible para el visitante, visible para Google). Destruye el posicionamiento orgánico y puede derivar en deindexación.
Redirects maliciosos: El visitante es redirigido a páginas de phishing, descarga de malware o scam. Frecuentemente condicionado al user-agent (solo afecta a visitantes desde móvil, desde Google, etc.).
Skimmers de tarjeta: JavaScript malicioso inyectado en el checkout que captura datos de pago.
Criptomineros: Scripts que usan la CPU del visitante para minar criptomonedas en segundo plano.
Proceso correcto de remediación para evitar reinfecciones
1. Identificar el vector de entrada: Sin saber cómo entró el atacante, la limpieza es temporal. Análisis de logs de acceso, revisión de ficheros modificados en el período de compromiso y contraste con historial de CVEs de plugins instalados.
2. Inventariar todos los mecanismos de persistencia: Web shells, usuarios administrativos no autorizados, tareas cron maliciosas, modificaciones en el core y en ficheros de configuración.
3. Restaurar desde un backup limpio verificado: Si hay un backup anterior al compromiso (y verificado como limpio), restaurarlo es más fiable que limpiar manualmente. El backup debe ser posterior al cierre del vector de entrada para evitar restaurar el estado comprometido.
4. Cerrar el vector de entrada original: Actualizar o eliminar el plugin o módulo vulnerable, cambiar todas las credenciales (CMS, hosting, base de datos, FTP), revisar permisos de ficheros y aplicar hardening.
5. Verificar la limpieza: Escaneo con múltiples herramientas y revisión manual de los directorios más habituales de persistencia.
FAQ
¿Un escáner de malware es suficiente para confirmar que la web está limpia?
No. Los escáneres automáticos detectan firmas conocidas de malware. Un atacante con acceso puede ofuscar el código para evadir las firmas o inyectarlo en ficheros legítimos en posiciones que los escáneres no analizan en profundidad. La verificación manual de ficheros modificados y logs de acceso es necesaria.
¿Hay que notificar a los usuarios si la web fue comprometida?
Depende del tipo de datos expuestos. Si el compromiso afectó a datos personales de usuarios, el RGPD obliga a notificar a la AEPD en 72 horas desde la detección y potencialmente a los afectados. Si solo fue inyección de malware sin acceso a datos, la obligación de notificación depende del análisis forense del alcance.
Servicio relacionado
servicio de pentesting y auditoría de CMS
Contenido relacionado
- Pentesting y auditoría de CMS
- Vulnerabilidades comunes en CMS
- Seguridad del panel de administración CMS
- Auditoría de seguridad WordPress