Hoy vamos a ver una técnica llamada VBA stomping para generar documentos maliciosos (maldoc) original de Vesselin Bontchev. Básicamente consiste en quitar o modificar el código fuente de un documento de Microsoft Office dejando sólo una versión compilada de las macros llamada p-code. De esta manera, un atacante podrá bypassear la detección de maldocs basada en el análisis del código fuente.
Primero, demostraremos la técnica con una macro simple y no maliciosa. Por ejemplo, con una simple macro que mostrará el texto "ABC" cuando se abre el documento:
A continuación lo que intentaremos es modificar ese código fuente sin cambiar el p-code. En Office 2007 o superior el código fuente de VBA y el p-code generalmente se encuentran en un archivo llamado vbaProject.bin. Para modificar este archivo manualmente, primero debemos descomprimir el archivo comprimido .docm/.xlsm y luego abrir el archivo vbaProject.bin en un editor hexadecimal. En este ejemplo, cambiaremos "ABC" por "XYZ", pero solo dentro de la ubicación donde está el código fuente VBA, no en la sección del p-code.
Ahora que hemos editado manualmente el código fuente VBA para cambiar "ABC" por "XYZ", abriremos el documento e inspeccionaremos el código fuente VBA ANTES de hacer clic en el botón "Habilitar contenido".
El documento se ha abierto pero las macros no están habilitadas. En el editor de código veremos que se debería mostrar un cuadro de mensaje con el texto "XYZ"... pero este no será el caso. De hecho, tan pronto como se habilite el contenido se mostrará un cuadro de mensaje con "ABC" y el código fuente en el editor de código se actualizará para que coincida.
Bastante engañoso, verdad?
Como explica Bontchev, el p-code almacenado en el documento es lo que realmente se ejecuta, siempre que sea compatible con la versión actual de VBA en el sistema. Además, lo que se muestra en el editor de macros (una vez que se habilita el contenido) no es la fuente VBA descomprimida, sino el p-code decompilado. ¡Interesante!
Si abrimos el documento en una versión diferente de Word (que usa una versión VBA diferente), el p-code no será reutilizable. Esto obligará al código fuente de VBA a descomprimirse y volverse a compilar en el p-code, dando como resultado la visualización de "XYZ" en el cuadro de mensaje. Así que ahora tenemos un solo documento, que en una versión de Office muestra "ABC", pero en otra versión muestra "XYZ". Así para que un ataque sea totalmente efectivo la víctima tendrá que tener la misma versión de VBA que el maldoc.
Otro aspecto a tener en cuenta, es que existen herramientas como olevba, oledump.py o pcodedmp.py que detectan discrepancias entre el código fuente VBA y el p-code. Pero veamos, en lugar de simplemente modificar el código fuente de VBA, podríamos eliminarlo por completo ("pisotearlo" o stomp) sobrescribiéndolo con ceros o bytes aleatorios. La siguiente imagen muestra cómo hacer esto manualmente en un editor hexadecimal.
Al hacer esto, el editor de VBA no muestra ningún código de macro, sin embargo, el cuadro de mensaje con el texto "ABC" aparecerá después de habilitar el contenido. Ahora, si volvemos a ejecutar olevba en este archivo no se muestra el código fuente del VBA y se muestra el mensaje "No se encontraron palabras clave sospechosas o IOC", nada sospechoso.
Llevando esta técnica al mundo real, veremos las detecciones de un maldoc con Emotet, con una tasa de 36/59:
Si hacemos VBA stomping el ratio de detección baja bastante, a 7 detecciones:
Como veis esta técnica tan sencilla es también bastante efectiva. Además, no es necesario modificar los documentos manualmente, existen herramientas que pueden automatizar el trabajo.
Por último pensad en el caso en el que el maldoc está diseñado para cerrar MS Word inmediatamente después de ejecutar el payload malicioso. En combinación con VBA stomping, ninguna herramienta defensiva mostrará el código VBA.
¿Cuál serían entonces las contramedidas?
La solución más simple pasa por evitar que MS Word ejecute cualquier método tan pronto como se habiliten las macros. A partir de Office 2007 sería eliminar el archivo vbaData.xml del directorio "word" del archivo .docm como se muestra a continuación (esto se hace fácilmente con 7-Zip sin tener que descomprimir y volver a comprimir el documento manualmente).
Ahora se puede abrir el documento y se puede habilitar el contenido, lo que da como resultado la visualización del p-code decompilado en el editor de código VBA pero no la ejecución del código.
Un efecto secundario interesante de borrar vbaData.xml es que hace que MS Word enumere erróneamente ninguna Macros en el cuadro de diálogo:
Finalmente, la gente de Walmartlabs ha creado también una herramienta llamada "VBA Seismograph" para detectar el stomping: identifica las diferencias entre los nombres declarados de funciones/variables, literales de strings y comentarios que aparecen en el p-code compilado y el código fuente VBA de un documento de Office. La herramienta está disponible en https://github.com/kirk-sayre-work/VBASeismograph.
Fuente: https://medium.com/walmartlabs/vba-stomping-advanced-maldoc-techniques-612c484ab278
Primero, demostraremos la técnica con una macro simple y no maliciosa. Por ejemplo, con una simple macro que mostrará el texto "ABC" cuando se abre el documento:
A continuación lo que intentaremos es modificar ese código fuente sin cambiar el p-code. En Office 2007 o superior el código fuente de VBA y el p-code generalmente se encuentran en un archivo llamado vbaProject.bin. Para modificar este archivo manualmente, primero debemos descomprimir el archivo comprimido .docm/.xlsm y luego abrir el archivo vbaProject.bin en un editor hexadecimal. En este ejemplo, cambiaremos "ABC" por "XYZ", pero solo dentro de la ubicación donde está el código fuente VBA, no en la sección del p-code.
Ahora que hemos editado manualmente el código fuente VBA para cambiar "ABC" por "XYZ", abriremos el documento e inspeccionaremos el código fuente VBA ANTES de hacer clic en el botón "Habilitar contenido".
El documento se ha abierto pero las macros no están habilitadas. En el editor de código veremos que se debería mostrar un cuadro de mensaje con el texto "XYZ"... pero este no será el caso. De hecho, tan pronto como se habilite el contenido se mostrará un cuadro de mensaje con "ABC" y el código fuente en el editor de código se actualizará para que coincida.
Bastante engañoso, verdad?
Como explica Bontchev, el p-code almacenado en el documento es lo que realmente se ejecuta, siempre que sea compatible con la versión actual de VBA en el sistema. Además, lo que se muestra en el editor de macros (una vez que se habilita el contenido) no es la fuente VBA descomprimida, sino el p-code decompilado. ¡Interesante!
Si abrimos el documento en una versión diferente de Word (que usa una versión VBA diferente), el p-code no será reutilizable. Esto obligará al código fuente de VBA a descomprimirse y volverse a compilar en el p-code, dando como resultado la visualización de "XYZ" en el cuadro de mensaje. Así que ahora tenemos un solo documento, que en una versión de Office muestra "ABC", pero en otra versión muestra "XYZ". Así para que un ataque sea totalmente efectivo la víctima tendrá que tener la misma versión de VBA que el maldoc.
Otro aspecto a tener en cuenta, es que existen herramientas como olevba, oledump.py o pcodedmp.py que detectan discrepancias entre el código fuente VBA y el p-code. Pero veamos, en lugar de simplemente modificar el código fuente de VBA, podríamos eliminarlo por completo ("pisotearlo" o stomp) sobrescribiéndolo con ceros o bytes aleatorios. La siguiente imagen muestra cómo hacer esto manualmente en un editor hexadecimal.
Al hacer esto, el editor de VBA no muestra ningún código de macro, sin embargo, el cuadro de mensaje con el texto "ABC" aparecerá después de habilitar el contenido. Ahora, si volvemos a ejecutar olevba en este archivo no se muestra el código fuente del VBA y se muestra el mensaje "No se encontraron palabras clave sospechosas o IOC", nada sospechoso.
Llevando esta técnica al mundo real, veremos las detecciones de un maldoc con Emotet, con una tasa de 36/59:
Si hacemos VBA stomping el ratio de detección baja bastante, a 7 detecciones:
Como veis esta técnica tan sencilla es también bastante efectiva. Además, no es necesario modificar los documentos manualmente, existen herramientas que pueden automatizar el trabajo.
Por último pensad en el caso en el que el maldoc está diseñado para cerrar MS Word inmediatamente después de ejecutar el payload malicioso. En combinación con VBA stomping, ninguna herramienta defensiva mostrará el código VBA.
¿Cuál serían entonces las contramedidas?
La solución más simple pasa por evitar que MS Word ejecute cualquier método tan pronto como se habiliten las macros. A partir de Office 2007 sería eliminar el archivo vbaData.xml del directorio "word" del archivo .docm como se muestra a continuación (esto se hace fácilmente con 7-Zip sin tener que descomprimir y volver a comprimir el documento manualmente).
Ahora se puede abrir el documento y se puede habilitar el contenido, lo que da como resultado la visualización del p-code decompilado en el editor de código VBA pero no la ejecución del código.
Un efecto secundario interesante de borrar vbaData.xml es que hace que MS Word enumere erróneamente ninguna Macros en el cuadro de diálogo:
Finalmente, la gente de Walmartlabs ha creado también una herramienta llamada "VBA Seismograph" para detectar el stomping: identifica las diferencias entre los nombres declarados de funciones/variables, literales de strings y comentarios que aparecen en el p-code compilado y el código fuente VBA de un documento de Office. La herramienta está disponible en https://github.com/kirk-sayre-work/VBASeismograph.
Fuente: https://medium.com/walmartlabs/vba-stomping-advanced-maldoc-techniques-612c484ab278
Comentarios
Publicar un comentario