Hace unas semanas hablábamos sobre AMSI (Anti Malware Scan Interface) y el porqué de este mecanismo de protección que Microsoft liberó. El juego del gato y del ratón comentamos en su momento. Así parece seguir. AMSI puede ser aplicado a diferentes lenguajes de scripting, entre ellos el potente lenguaje de administración y pentesting: Powershell.
Tal y como vimos hace unas semanas, había métodos clásicos y sencillos para jugar y conseguir el bypass de AMSI y otros métodos no tan sencillos, los cuales hablan de parchear el proceso para que el buffer de lectura siempre valga 0. Es un juego interesante y que dará que hablar, como en su día lo hizo el UAC o AppLocker. De este modo, la seguridad mejorará, ya que el encontrar caminos que hacen que una protección falle ayuda a mejorar su seguridad.
Hoy vamos a ver más técnicas de Hacking Windows que puedan ayudar en un proceso de pentesting, que puedan usarse para evadir AMSI cuando sea necesario. Hay que recordar que AMSI es una protección joven, la cual aparece en Windows 10. Es una característica de seguridad que actúa entre los intérpretes de scripting y el motor de antivirus.
AMSI en Windows
Los lenguajes de scripting que soportan AMSI son Powershell, Windows Script Host (wscript.exe y cscript.exe) y, recientemente, Visual Basic for Applications o VBA. El flujo es sencillo, cuando se ejecuta un comando en uno de estos intérpretes, los comandos son enviados a la interfaz de AMSI. Si el antivirus está ‘hookeado’, éste podrá recibir la ejecución y decidir si bloquear o permitir lo ejecutado. De este modo, se puede detectar ejecución en memoria de código malicioso y bloquear este comportamiento.
La idea del bypass es sencilla, intentar evitar que los comandos que son ejecutados a través del intérprete sean detectados como algo malicioso. Como ya comenté arriba, ya hemos visto ejemplos de bypass de AMSI en Powershell. En septiembre de 2018, Microsoft anunció la implementación de AMSI para VBA, incluyendo la característica para MS Office 365, release de enero de 2019. Hoy en día cualquier usuario de Office 365 debería ejecutar Office con AMSI habilitado para evitar las macros maliciosas.
Algunos bypasses de AMSI con VBA
Se han ido publicando algunos bypasses de AMSI para VBA. Algunos se han recopilado en un magnífico artículo de Pieter Ceelen, dónde se detalla el ámbito de ejecución de AMSI con VBA y los bypasses.
Bypass 1: Attack without VBA
El primer bypass es un ataque denominado ‘Attack without VBA’, por lo que parece que de primeras no tendremos a VBA. Está orientado al uso de macros: ‘Excel 4.0 macros’. En Excel hay un segundo motor de macros específico para Excel 4.0 macros. Este motor está implementado en Excel.exe y no utiliza el motor de VBA, el cual se encuentra en la DLL VBE7.dll.
Como el motor de AMSI solo ‘hookea’ a VBA, Excel 4.0 proporciona un vector de ataque. Sobre el ataque de Excel 4.0 se puede leer más en un interesante artículo de Stan Hegt. El resumen es rápido y sencillo, la idea es crear una macro para MS Excel 4.0 Macro.
Una vez realizada la macro y configurada con el Auto_open se tiene todo lo necesario. En el artículo de Stan Hegt se muestra un ejemplo básico para la apertura de la calculadora o cómo hacer uso de la API de Win32 y conseguir un ataque más completo y potente.
Bypass 2: Macro Runtime Scope & Abusing Trust
El segundo bypass que vamos a tratar es el denominado Macro Runtime Scope & Abusing Trust. ¿En qué consiste? Microsoft hizo varias excepciones sobre el scope o ámbito de ejecución de AMSI. Especialmente las excepciones para documentos categorizados como de confianza y ubicaciones de confianza.
Si pruebas con un documento de confianza y una macro verás que todo fluye normal pasando por AMSI, aunque quizá no debería. Esto es prueba y error. Por otro lado, el investigador Pieter Ceelen se dio cuenta que con los documentos de ubicaciones de confianza se excluían de AMSI en la configuración predeterminada.
Se puede utilizar una PoC (Prueba de Concepto) desde el Github del investigador. La idea era sencilla: lo primero es que, con el documento abierto, se guarda el documento actual como una plantilla hacia la ubicación de confianza.
Después, se abre un nuevo archivo basado en esa plantilla que activará un evento document_new desde una ubicación confiable. El script que se proporciona en el Github tiene tres semanas, por lo que sigue siendo muy funcional.
Bypass 3: Innocent COM functions
El tercer bypass es denominado como ‘Innocent COM functions’. Microsoft hace distinción entre ‘Innocent’ COM. Algunos ejemplos de funciones Innocent COM que permiten abusar de no lanzar AMSI son:
Esto está documentado por Carlos Pérez o DarkOperator, genialmente, para que puedas probarlo con un paso a paso.
Bypass 4: Non-Win32API/COM functions that have side effects
El cuarto bypass es denominado ‘Non-Win32API/COM functions that have side effects’. Hay varias funciones integradas en Word y Excel que pueden proporcionar la ejecución de código o provocar el desactivar AMSI.
Es posible utilizar una macro para editar el contenido de un archivo de Word y almacenarlo como archivos de texto con extensión REG o BAT, por ejemplo, disableamsi.reg o disableamsi.bat. Con estos ficheros se puede deshabilitar AMSI a través de la configuración macroruntimescope en el hive HKCU. Teniendo en cuenta, y esto es importante en el Ethical Hacking, que la mayoría de las empresas no van a configurar por GPO la configuración de macroruntimescope, se podrá sobrescribir en HKCU.
En el mismo archivo BAT se podrá hacer que se inicie Word sin el splash screen de bienvenida. Es un método interesante, y se puede hacer muy silencioso. Se puede descargar desde Github el código de la macro.
Conclusión
AMSI es una protección que está aquí para, en principio, estar en las nuevas generaciones de Microsoft Windows. Es una protección ambiciosa y que debe cubrir una serie de vectores de ataque muy amplios y complejos. Veremos cómo avanza el juego del gato y del ratón en los próximos meses que seguro que es divertido.
 |
| Figura 1: Hacking Windows 10: Más técnicas para saltarse AMSI (Anti Malware Scan Interface) con VBA y las Macros de Office |
Tal y como vimos hace unas semanas, había métodos clásicos y sencillos para jugar y conseguir el bypass de AMSI y otros métodos no tan sencillos, los cuales hablan de parchear el proceso para que el buffer de lectura siempre valga 0. Es un juego interesante y que dará que hablar, como en su día lo hizo el UAC o AppLocker. De este modo, la seguridad mejorará, ya que el encontrar caminos que hacen que una protección falle ayuda a mejorar su seguridad.
 |
| Figura 2: Libro de Hacking Windows: Ataques a sistemas y redes Microsoft |
Hoy vamos a ver más técnicas de Hacking Windows que puedan ayudar en un proceso de pentesting, que puedan usarse para evadir AMSI cuando sea necesario. Hay que recordar que AMSI es una protección joven, la cual aparece en Windows 10. Es una característica de seguridad que actúa entre los intérpretes de scripting y el motor de antivirus.
AMSI en Windows
Los lenguajes de scripting que soportan AMSI son Powershell, Windows Script Host (wscript.exe y cscript.exe) y, recientemente, Visual Basic for Applications o VBA. El flujo es sencillo, cuando se ejecuta un comando en uno de estos intérpretes, los comandos son enviados a la interfaz de AMSI. Si el antivirus está ‘hookeado’, éste podrá recibir la ejecución y decidir si bloquear o permitir lo ejecutado. De este modo, se puede detectar ejecución en memoria de código malicioso y bloquear este comportamiento.
La idea del bypass es sencilla, intentar evitar que los comandos que son ejecutados a través del intérprete sean detectados como algo malicioso. Como ya comenté arriba, ya hemos visto ejemplos de bypass de AMSI en Powershell. En septiembre de 2018, Microsoft anunció la implementación de AMSI para VBA, incluyendo la característica para MS Office 365, release de enero de 2019. Hoy en día cualquier usuario de Office 365 debería ejecutar Office con AMSI habilitado para evitar las macros maliciosas.
 |
| Figura 3: AMSI en Macros VBA de Office |
Según la teoría, cualquier método COM y llamadas a la API Win32 debería acabar siendo tratada por el sistema Behavior Log. Además, llamadas específicas son marcadas como triggers. La ejecución de una macro será pasada a AMSI para tomar una decisión. Por defecto, la configuración de AMSI no está habilitada para todas las macros de los documentos. Su política está configurada para documentos de baja confianza. Es decir, documentos cuya confianza es dudosa, ya sea por no estar firmado o por haber sido descargado de Internet.
Algunos bypasses de AMSI con VBA
Se han ido publicando algunos bypasses de AMSI para VBA. Algunos se han recopilado en un magnífico artículo de Pieter Ceelen, dónde se detalla el ámbito de ejecución de AMSI con VBA y los bypasses.
Bypass 1: Attack without VBA
El primer bypass es un ataque denominado ‘Attack without VBA’, por lo que parece que de primeras no tendremos a VBA. Está orientado al uso de macros: ‘Excel 4.0 macros’. En Excel hay un segundo motor de macros específico para Excel 4.0 macros. Este motor está implementado en Excel.exe y no utiliza el motor de VBA, el cual se encuentra en la DLL VBE7.dll.
 |
| Figura 4: Excel 4.0 Macro |
Como el motor de AMSI solo ‘hookea’ a VBA, Excel 4.0 proporciona un vector de ataque. Sobre el ataque de Excel 4.0 se puede leer más en un interesante artículo de Stan Hegt. El resumen es rápido y sencillo, la idea es crear una macro para MS Excel 4.0 Macro.
 |
| Figura 5: Ejemplo de Macro usando las API de Win32 |
Una vez realizada la macro y configurada con el Auto_open se tiene todo lo necesario. En el artículo de Stan Hegt se muestra un ejemplo básico para la apertura de la calculadora o cómo hacer uso de la API de Win32 y conseguir un ataque más completo y potente.
Bypass 2: Macro Runtime Scope & Abusing Trust
El segundo bypass que vamos a tratar es el denominado Macro Runtime Scope & Abusing Trust. ¿En qué consiste? Microsoft hizo varias excepciones sobre el scope o ámbito de ejecución de AMSI. Especialmente las excepciones para documentos categorizados como de confianza y ubicaciones de confianza.
Si pruebas con un documento de confianza y una macro verás que todo fluye normal pasando por AMSI, aunque quizá no debería. Esto es prueba y error. Por otro lado, el investigador Pieter Ceelen se dio cuenta que con los documentos de ubicaciones de confianza se excluían de AMSI en la configuración predeterminada.
 |
| Figura 6: PoC del Bypass 2 en GitHub |
Se puede utilizar una PoC (Prueba de Concepto) desde el Github del investigador. La idea era sencilla: lo primero es que, con el documento abierto, se guarda el documento actual como una plantilla hacia la ubicación de confianza.
Después, se abre un nuevo archivo basado en esa plantilla que activará un evento document_new desde una ubicación confiable. El script que se proporciona en el Github tiene tres semanas, por lo que sigue siendo muy funcional.
Bypass 3: Innocent COM functions
El tercer bypass es denominado como ‘Innocent COM functions’. Microsoft hace distinción entre ‘Innocent’ COM. Algunos ejemplos de funciones Innocent COM que permiten abusar de no lanzar AMSI son:
• Instanciación de Excel y llamar a ExecuteExcel4Macro o DDEInitialize.
• Utilizar WMI y SpawnInstance.
 |
| Figura 7: Ejemplo por DarkOperator |
Esto está documentado por Carlos Pérez o DarkOperator, genialmente, para que puedas probarlo con un paso a paso.
Bypass 4: Non-Win32API/COM functions that have side effects
El cuarto bypass es denominado ‘Non-Win32API/COM functions that have side effects’. Hay varias funciones integradas en Word y Excel que pueden proporcionar la ejecución de código o provocar el desactivar AMSI.
Es posible utilizar una macro para editar el contenido de un archivo de Word y almacenarlo como archivos de texto con extensión REG o BAT, por ejemplo, disableamsi.reg o disableamsi.bat. Con estos ficheros se puede deshabilitar AMSI a través de la configuración macroruntimescope en el hive HKCU. Teniendo en cuenta, y esto es importante en el Ethical Hacking, que la mayoría de las empresas no van a configurar por GPO la configuración de macroruntimescope, se podrá sobrescribir en HKCU.
 |
| Figura 8: Macros para hacer estas pruebas |
En el mismo archivo BAT se podrá hacer que se inicie Word sin el splash screen de bienvenida. Es un método interesante, y se puede hacer muy silencioso. Se puede descargar desde Github el código de la macro.
Conclusión
AMSI es una protección que está aquí para, en principio, estar en las nuevas generaciones de Microsoft Windows. Es una protección ambiciosa y que debe cubrir una serie de vectores de ataque muy amplios y complejos. Veremos cómo avanza el juego del gato y del ratón en los próximos meses que seguro que es divertido.
Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.
No hay comentarios:
Publicar un comentario