Hackeo según el manual: una vulnerabilidad Zero-Day en Sitecore permaneció ocho años en la documentación oficial.

Especialistas Mandiant descubrieron un ataque contra instalaciones antiguas de la plataforma Sitecore. Los atacantes utilizaron una clave de demostración de ASP.NET que se publicaba en la documentación oficial hasta 2017. El problema recibió el identificador CVE-2025-53690 y permite ejecutar código malicioso mediante el mecanismo de deserialización de ViewState.

El ataque comenzaba con una petición sencilla a la página /sitecore/blocked.aspx, presente en todas las instalaciones de Sitecore. Esa página no requiere autenticación y contiene el campo oculto ViewState —el objetivo ideal para insertar código malicioso. Los atacantes enviaban solicitudes POST con un ViewState especialmente preparado, firmado con el antiguo machineKey de la documentación. Aunque Sitecore hace tiempo que no usa esas claves en versiones nuevas, muchas instalaciones antiguas siguen siendo vulnerables.

Tras la intrusión exitosa, los atacantes subían al servidor una biblioteca .NET llamada Information.dll (conocida como WEEPSTEEL). Esta herramienta recopilaba información del sistema: versión del sistema operativo, configuración de red, lista de procesos en ejecución y la estructura de la aplicación web. Todos los datos recogidos se enviaban de vuelta a través del mismo campo ViewState, disfrazados como una respuesta normal del servidor.

A continuación los atacantes archivaban todo el directorio raíz del sitio, incluyendo el archivo crítico web.config con la configuración del servidor. Para reconocimiento ejecutaban comandos del sistema: obtenían listas de usuarios y procesos, analizaban conexiones de red y la estructura del dominio. Para mantener acceso persistente se usaron tres herramientas de código abierto: EARTHWORM (servidor de túnel con proxy SOCKS), DWAGENT (gestión remota con privilegios SYSTEM) y SHARPHOUND (recolección de datos de Active Directory).

En la siguiente fase los atacantes crearon dos administradores falsos —asp$ y sawadmin— camuflándolos como cuentas del sistema habituales. Con privilegios administrativos, copiaron los registros SAM y SYSTEM para extraer contraseñas. También emplearon la herramienta GoToken.exe para interceptar y usar tokens de otros usuarios.

Para el control remoto los atacantes emplearon RDP (Protocolo de Escritorio Remoto), encaminando el tráfico a través del proxy SOCKS EARTHWORM. A través de esas conexiones se descargaban programas adicionales: scripts y clientes de gestión remota. Paralelamente se realizaba reconocimiento del dominio en busca de contraseñas débiles en archivos XML de directivas de grupo.

Al final del ataque las cuentas temporales asp$ y sawadmin fueron eliminadas, y todas las acciones se realizaron en nombre de administradores reales del dominio. Para comprometer otros equipos se volvió a usar RDP con la instalación del túnel EARTHWORM y la ejecución de utilidades de auditoría del sistema.

Aunque el ataque fue detenido en una fase temprana, Mandiant destaca el alto nivel profesional de los atacantes. Demostraron una comprensión profunda de la arquitectura de Sitecore y de los mecanismos de ViewState. Todas las acciones estuvieron cuidadosamente planificadas: desde el acceso inicial hasta la consolidación en la red y el movimiento lateral entre sistemas.

Los propietarios de Sitecore XP hasta la versión 9.0 y del módulo Active Directory hasta la versión 1.4 deben con urgencia: reemplazar los valores predeterminados de <machineKey> en web.config por valores únicos, activar la verificación MAC para ViewState y cifrar los parámetros de configuración. Son especialmente peligrosas las instalaciones con las mismas claves en varios servidores. En riesgo quedan: Sitecore Experience Manager, Experience Platform, Experience Commerce y Managed Cloud. No afectados: XM Cloud, Content Hub, CDP, Personalize, OrderCloud, Send, Discover, Search y Commerce Server.

Mandiant publicó la lista completa de indicadores de compromiso en la colección GTI: direcciones IP, hashes de archivos maliciosos y nombres de cuentas. Se recomienda a los administradores consultar las recomendaciones oficiales sobre protección y actualización regular de las claves ASP.NET.