Una clave expuesta transforma un LMS en vector de ataque: CVE-2026-5426 desata Cobalt Strike en KnowledgeDeliver

Un fallo de seguridad de alta severidad que ya fue parcheado en Digital Knowledge KnowledgeDeliver —un sistema de gestión de aprendizaje (LMS) con amplia presencia en Japón— fue explotado como zero‑day para instalar el web shell conocido como Godzilla (BLUEBEAM) y, desde ahí, desplegar Cobalt Strike Beacon en las máquinas de las víctimas. La vulnerabilidad, registrada como CVE‑2026‑5426 con un CVSS de 7.5, se aprovechó por la reutilización de secretos compartidos: los despliegues del LMS usaban un archivo web.config estandarizado del proveedor que contenía valores machineKey en claro para ASP.NET, lo que permitió a los atacantes crear cargas de ViewState maliciosas y provocar la deserialización remota sin autenticación.

El vector técnico es clásico pero peligroso: ASP.NET utiliza la clave de máquina para firmar y cifrar datos como el __VIEWSTATE, y si ese secreto es conocido, un atacante puede forjar un ViewState que, al ser deserializado por el servidor, ejecuta código arbitrario. Microsoft ya documentó en 2025 el uso malicioso de claves machineKey filtradas, y la cadena de abuso se ha repetido en otros productos (por ejemplo, Sitecore XM, Gladinet CentreStack y TrioFox), lo que recalca que el problema reside tanto en fallos individuales como en patrones de despliegue inseguros.

En la campaña observada por Google Mandiant y el Grupo de Inteligencia de Amenazas de Google (GTIG) el atacante no solo obtuvo ejecución remota: dejó un web shell que permitía ejecutar comandos, cambió permisos del sistema de ficheros (concediendo acceso completo a “Everyone” en el directorio de la aplicación) y alteró un script JavaScript para mostrar una alerta falsa que inducía a los usuarios a descargar un “plugin de autenticación” malicioso. Ese instalador descargado finalmente contenía Cobalt Strike Beacon; el análisis mostró además que la carga útil estaba cifrada con una clave que incluía el nombre de la organización, lo que sugiere ataques dirigidos y preparados específicamente para cada víctima.

Las implicaciones son claras y preocupantes: una sola clave filtrada puede comprometer múltiples instancias de un mismo producto, especialmente cuando los proveedores distribuyen configuraciones estándar con secretos embebidos. Esto convierte a los templates y archivos de configuración en una superficie de ataque de alto impacto, y plantea riesgos de escalada desde un acceso web inicial hasta lateralidad y persistencia en la red de la organización.

Desde el punto de vista operativo, las medidas inmediatas y de largo plazo son complementarias. En caliente, cualquier instalación anterior al 24 de febrero de 2026 debe actualizarse a la versión parcheada de KnowledgeDeliver; además, se debe inspeccionar el servidor web y los repositorios de archivos públicos por señales de compromiso: archivos web shell (por ejemplo, aspx/php con código ofuscado), modificaciones recientes en JavaScript que inyecten cargas externas, cambios de permisos a nivel de sistema en directorios web y tráfico saliente hacia dominios sospechosos. En la fase de contención es recomendable aislar instancias comprometidas, capturar imágenes forenses antes de limpiar, rotar todas las credenciales expuestas y bloquear en la red los dominios y direcciones IP asociados a la campaña.

Para reducir la probabilidad de reexposición, las organizaciones deben eliminar cualquier machineKey hard‑coded y asegurarse de que las claves sean únicas por instalación. Las buenas prácticas incluyen generar las claves en el host durante el despliegue (o utilizar un servicio de gestión de secretos como Azure Key Vault o HashiCorp Vault), habilitar la protección adecuada de ViewState (MAC y cifrado según la configuración de ASP.NET), y aplicar controles de integridad sobre ficheros web y recursos estáticos. También es crucial implementar monitoreo que detecte cadenas de explotación típicas (peticiones con __VIEWSTATE anómalas, patrones de beaconing de Cobalt Strike) y reforzar la detección de comportamientos post‑explotación.

En términos de detección, conviene revisar logs web y proxies por solicitudes HTTP que contengan valores de __VIEWSTATE inusualmente largos o codificados fuera de patrón, buscar tráfico de salida que coincida con patrones de Cobalt Strike Beacon y auditar el sistema de archivos del servidor web para detectar cambios de permisos y ficheros modificados en fechas de compromiso. La comunidad y la documentación técnica sobre deserialización insegura y sobre Cobalt Strike ofrecen indicadores y técnicas de detección que pueden ser útiles; por ejemplo, la explicación de riesgos de deserialización en OWASP y la ficha técnica de Cobalt Strike en MITRE ATT&CK son recursos prácticos para equipos de seguridad: OWASP sobre deserialización insegura y MITRE ATT&CK – Cobalt Strike (Beacon). Para entender el funcionamiento del ViewState en ASP.NET puede consultarse la documentación histórica de Microsoft sobre ese mecanismo: Documentación de Microsoft sobre ViewState.

Más allá del parche puntual, este incidente es una llamada de atención a proveedores y a clientes: los fabricantes no deben distribuir secretos por defecto en sus paquetes y las organizaciones que desplieguen software deben tratar plantillas y artefactos del proveedor como código que requiere revisión y endurecimiento. La gestión de secretos, la rotación periódica y el principio de menor privilegio en los permisos de ficheros y servicios son contramedidas esenciales para evitar que una misma configuración débile convierta a cientos de instalaciones en víctimas encadenadas de una única filtración.