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.
 |
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.
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.
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.
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.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
