DIARIO ya detecta las macros “stomped” pero, ¿qué son exactamente?

Hace pocas semanas presentamos DIARIO, el detector de malware que respeta la privacidad de los usuarios, y seguimos mejorándolo para que detecte más y mejor. Recientemente añadimos la capacidad de detectar malware en documentos ofimáticos cuyas macros usan la técnica conocida como VBA stomping. ¿En qué consiste esta técnica y por qué es tan importante?

Ya sabemos que el correo electrónico con adjuntos es una de las vías de entrada de malware más populares, concretamente los adjuntos de tipo ofimático. Esto es posible, en gran medida, gracias a la capacidad de programar código en las macros de los documentos ofimáticos. Las razones por la que esta técnica sigue funcionando dos décadas después de que se comenzase a utilizar son diversas:

• Las macros son fáciles de esconder.
• Las macros son legítimas. Aun deshabilitadas por defecto, es fácil que el usuario las habilite.
• Es más complejo el sandboxing para emularlas.
• Se envían por correo electrónico, por lo que habitualmente solo se analizan estáticamente.
• El usuario no piensa que un documento u hoja de cálculo pueda llegar a ser peligroso.
• Sigue siendo una vía muy lucrativa para los ciberatacantes.

Y aunque haya pasado tanto tiempo, todavía se sigue innovando sobre esta técnica. La técnica del stomping es una prueba. Veamos primero de qué se compone una macro “reciente”. Encontraremos un archivo binario, de extensión .bin dentro del archivo .zip que hoy por hoy son los documentos. Al menos en las versiones más recientes de Office.

Lo primero que hay que tener en cuenta es que en ese fichero .bin no se encuentran “las macros” como tal, sino todo un sistema listo para ser compilado y ejecutado por el propio Office. Sí, puede compararse a un proyecto cualquiera realizado con Visual Studio, donde tenemos el código fuente, las definiciones, el código compilado… El sistema Office de turno, como puede ser Word o Excel, disponen de un motor de compilación y ejecución de ese código.

De hecho, dentro de este fichero .bin, encontramos (si lo analizamos con las herramientas adecuadas):

• PROJECT: flujo (fichero): es como el fichero de configuración.
• VBA_PROJECT: flujo con las instrucciones para el motor VBA. Sin documentar.
• Dir: comprimido y tiene el layout del proyecto.
• Module streams del tipo VBA/ThisDocument/NewMacros/…/__SPR_1/Module1, que contiene el código que se ejecutará. Cada módulo del código se compone a su vez de PerformanceCache y el CompressedSourceCode, que es el código fuente de la macro comprimido.

¿Para qué sirve todo esto?

Esto sirve para la obsesiva retrocompatibilidad de Microsoft. Imaginemos que creamos un documento con macros en una versión de Office reciente, por ejemplo Word 2016. Creamos la macro y queda compilada en el sistema, pero también se almacena el código fuente con ella. La persona que recibe el documento puede disponer de un Office 2016, en cuyo caso para ir más rápido, se ejecutará la macro compilada directamente. Pero, ¿y si quiere abrir el documento con un Word 2003? Entonces, por compatibilidad, deberá tomar el código fuente VBA de la macro, compilarlo en su motor y ejecutarlo. Y esta es la razón por la que encontramos “en claro” el código fuente de las macros en los documentos.

Esto ha supuesto históricamente una ventaja para quienes analizan este tipo de malware: pueden acceder al código fácilmente, analizarlo de forma más sencilla, etc. Los antivirus han confiado en este código fuente incluso para clasificar muestras. Pero a alguien se le ocurrió que el documento podía infectar igual si se mantenía el código compilado pero se borraba el código fuente. Y así fue. Esta técnica de borrado del código fuente es el VBA stomping, y permite pasar más desapercibido al malware sin apenas tener impacto en su capacidad de infección. Solo se librarían de la infección aquellos usuarios con versiones de motor VBA (versiones de Office al fin y al cabo) no compatibles o muy antiguas.

Ya existe la herramienta Evil Clippy, capaz de facilitar el VBA stomping y automatizar todos los procesos necesarios.

Como se puede ver, DIARIO ya detecta este tipo de documentos y muestra el código aunque se haya usado esta técnica: