Malware basado en deserialización insegura en .suo de Visual Studio

Los vectores de ataque menos evidentes suelen ser los más interesantes y peligrosos. Un ejemplo claro es el proyecto EvilSln, disponible en GitHub, que explota la deserialización insegura en archivos .suo de Visual Studio para introducir un backdoor que se ejecuta simplemente al abrir una solución. 

Desde campañas previas como la del grupo Lazarus (2021), que usó comandos maliciosos en proyectos para ejecutar código durante la compilación, ya se sabía que los proyectos de Visual Studio podían ser abusados para ejecución remota. Sin embargo, estas técnicas requerían que el usuario compilara o interactuara activamente con el proyecto.

El hallazgo de EvilSln es más insidioso: aprovecha la carga automática del archivo .suo —un archivo binario y oculto generado automáticamente en la carpeta .vs— que Visual Studio abre sin avisos de seguridad ni diálogo de confianza, incluso ignorando las protecciones como zonas de confianza (Trust Zones) o marcas MOTW (Mark of the Web).

El .suo (Solution User Options) guarda configuraciones de usuario, estados de ventanas y otros metadatos en un formato Structured Storage binario poco documentado. Pero al abrir la solución, Visual Studio:

  1. Enumera los VSPackages cargados.

  2. Llama al método IVsPersistSolutionOpts.LoadUserOptions, pasando un Stream con el contenido del .suo.

  3. En concreto, la clase VSCorePackage delega la carga a VsToolboxService.LoadOptions(Stream).

  4. VsToolboxService usa un BinaryFormatter.Deserialize() sin restricciones para leer objetos almacenados.

El uso de BinaryFormatter es crítico porque permite la ejecución de código arbitrario al deserializar tipos que pueden contener payloads maliciosos (como se puede generar con ysoserial.net).

La explotación en detalle

  • El atacante genera un payload serializado malicioso (p. ej. un objeto que en el constructor o métodos de deserialización ejecuta calc.exe o código PowerShell).

  • Este payload se inserta en el stream adecuado dentro del .suo.

  • El .suo se distribuye junto a un proyecto legítimo (GitHub, redes sociales, phishing).

  • Al abrir la solución, Visual Studio deserializa automáticamente el .suo sin alertas y ejecuta el payload en memoria.

  • La ejecución ocurre sin compilación ni interacción adicional, y no hay warnings de Smartscreen ni diálogos de confianza.

Estructura mínima del proyecto malicioso:
/App1
    /Form1.cs
/App1.sln
/.vs/App1/v17/.suo  <-- payload inyectado aquí (stream específico con objeto serializado malicioso)

Esta técnica evidencia cómo la complejidad y la automatización de los IDEs pueden abrir puertas a ataques sofisticados y silenciosos. Los desarrolladores y pentesters deben considerar los archivos auxiliares y binarios generados por herramientas de desarrollo como vectores de riesgo, no solo el código fuente. En el caso de Visual Studio, abrir un proyecto puede ser, literalmente, abrir la puerta a un ataque. Así que recuerda:

  • Nunca abrir proyectos de orígenes no confiables o desconocidos.
  • Revisar la configuración de Visual Studio para activar manualmente “trusted locations” y otras protecciones (aunque por defecto están deshabilitadas).
  • Usar herramientas para inspeccionar .suo y otros archivos binarios de soluciones.
  • Considerar abrir los proyectos en entornos aislados o máquinas virtuales.

Comentarios

Publicar un comentario