Evadiendo el Anti-Malware Scan Interface (AMSI) - Virus No Detected

March 2023 (1332 Words, 8 Minutes)

Durante una prueba de intrusión interna, es muy importante el uso de herramientas para automatizar o realizar movimientos dentro de un directorio activo, tales como Mimikatz, Rubeus, Chisel, PowerView, SharpHound etc. Sin embargo, llevar estas herramientas y utilizarlas en un equipo comprometido conlleva a que estas sean bloqueadas por una protección EndPoint/Antivirus y que se genere alguna alerta sobre los ataques que se estarían realizando.

Quizá una opción poco ortodoxa para evitar ser detectado seria intentar deshabilitar la protección Endpoint/AntiVirus, sin embargo, en su mayoría el activar/desactivar el Antivirus se encontraría restringido por la propia organización y un EDR pudiese aislar el host comprometido al detectar dicho comportamiento malicioso.

En este punto aun se podría pensar en dos opciones, modificar el código del malware/herramientas a utilizar o bien cargar el contenido de este en memoria, evitando tocar el disco y de esta manera no ser bloqueados.

Si bien modificar el código fuente podría ayudar a evitar la detección por la firma que este genera, se tendría que modificar el código fuente en cada herramienta, lo cual dejaría de ser algo practico. Sin embargo, si se logra cargar el malware en memoria, se podría utilizar casi cualquier malware y cualquier herramienta de pentesting ofensivo, sin ser detectados en el momento (dejando fuera un análisis forense obviamente).

0. AMSI

Es en este punto en donde el Anti-Malware Scan Interface (desde ahora AMSI) toma un papel importante, AMSI se introdujo por primera vez en las versiones de Windows 10 y Windows Server 2016, con la finalidad de proteger al usuario final de ejecución de malware común, en donde de forma predeterminada escanea secuencias de comandos de Powershell, Macros de VBA, JavaScript y comandos mediante Windows Script Host.

En el pasado, era posible generar un script con el módulo multi/script/web_delivery de Metasploit, el cual generaba un comando codificado en base64, en donde al pegarlo en una PowerShell daba un acceso remoto al sistema víctima.

Creación de script en metasploit

Ejecución de script en Powershell

Reverse Shell

Sin embargo, actualmente cuando se inicia una Shell de PowerShell, se carga en el mismo proceso la dll amsi.dll, la cual se encargará de interceptar y conjuntamente con Windows Defender analizar el contenido de los comandos escritos en la termina de Powershell, para posterior a ello permitir o bloquear los comandos antes de que estos sean ejecutados.

Get-Process -Name powershell | Select-Object -ExpandProperty Modules | Where-Object { $_.FileName -like "*amsi.dll" }

amsi.dll dentro el proceso powershell.exe

Teniendo un concepto básico sobre el funcionamiento del AMSI, es fácil intuir que al momento de enviar el script en la terminal de PowerShell, este será interceptado por amsi.dll y enviado a Windows Defender, el cual lo identificara como un contenido malicioso y bloqueara la ejecución del mismo.

Detección de script por AMSI

Pero, veamos paso a paso hasta llegar a necesitar el byppas del AMSI.

1. Descarga

La manera más fácil de obtener las herramientas en un dispositivo víctima, podría ser levantándo un servicio Web, SMB, FTP, etc y descargándolos en el sistema comprometido.

Servidor HTTP en python

Descarga desde powershell

Teniendo las herramientas descargadas en el sistema víctima, bastaría con importarlas o simplemente ejecutarlas para poder hacer uso de ellas.

Modulos disponibles

Importando PowerView

Uso de PowerView para visualizar relaciones de confianza

Sin embargo, esto funcionaria si y solo si, se presentara un escenario en donde no existiera una solución Endpoint con algún antivirus comercial administrado de forma centralizada e inclusive que Windows Defender se encontrase de igual manera desactivado.

Pero este escenario es muy poco probable de encontrar, en su lugar, es probable encontrarse con que estas configuraciones sean administradas por el administrador del dominio y que se cuenten con al menos una solución de antivirus EndPoint.

Lo mas probable seria que al descargar alguna herramienta o malware, esta sea eliminada inmediatamente del sistema.

2. Ejecución en memoria

Los archivos son eliminados inmediatamente, debido a que al momento de tocar el disco, el Antivirus es capaz de detectar su firma y aplicar acciones correctivas, sin embargo, si estos archivos son cargados directamente en memoria , el Antivirus no será capaz de analizarlos.

Para ello basta con hacer uso del cmdlet de PowerShell Invoke-Expression (IEX para los amigos), el cual fue diseñado para poder probar scripts sin necesidad de guardarlos en disco, ya que se encarga de cargar los comandos en memoria.

Al realizar un Get-Module, no se mostrara el script y esto es debido ha que se encuentra en memoria y no en disco, sin embargo es posible realizar uso de ella, tal y como se muestra en la siguiente imagen, el modulo de PowerUp no se encuentra importado y Get-ModifiableService no es un comando del sistema, sin embargo es posible hacer uso del mismo.

Esta carga en memoria funcionaria si el AMSI no estuviese presente, como se mencionó al inicio, AMSI sería capaz de interceptar los comandos de PowerShell, analizar el contenido del script y bloquear su ejecución.

3. Ejecución en memoria + Forzar un fallo en el inicio de AMSI

Tomando un último escenario (muy probable en auditorias reales), en el cual nos encontremos con sistemas actualizados (Windows Server 2019), con parches de seguridad aplicados, IDS, IPS, políticas de Firewall analizando el trafico (capaces de aislar un host comprometido), Antivirus EndPoints, Syslog, SIEM, etc.

La utilización de técnicas vistas tales como intentar desactivar el Antivirus, descargar malware en disco, harán que se genere ruido y alertas dentro de la red, sin embargo, una técnica que en lo personal ha sido de mucha ayuda en varias auditorias, es el provocar un error en amsiInitFailed, la cual se produce cuando existe un error en la inicialización de AMSI y este deja de interceptar y analizar comandos.

Al aplicar un cambio en la clase AmsiUtils, asignando un valor de True a la variable amsiInitFailed, AMSI dejará de analizar los comandos en consola y será posible cargar código en memoria, evadiendo casi cualquier medida de seguridad EndPoint.

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Actualmente Microsoft ha creado una firma para detectar dicho cambio, sin embargo, es posible aplicar polimorfismo y de esta manera evitar la detección, al utilizar esta técnica, en mi experiencia realizando Pruebas de Intrusión, únicamente 1 de 4 antivirus comerciales ha sido capaz de detectarlo (Antivirus con detección en base a heurística), por lo cual conocer este tipo de técnicas puede hacer la diferencia al momento de una auditoria.

S`eT-It`em ( 'V'+'aR' + 'IA' + ('blE:1'+'q2') + ('uZ'+'x') ) ( [TYpE]( "{1}{0}"-F'F','rE' ) ) ; ( Get-varI`A`BLE ( ('1Q'+'2U') +'zX' ) -VaL )."A`ss`Embly"."GET`TY`Pe"(( "{6}{3}{1}{4}{2}{0}{5}" -f('Uti'+'l'),'A',('Am'+'si'),('.Man'+'age'+'men'+'t.'),('u'+'to'+'mation.'),'s',('Syst'+'em') ) )."g`etf`iElD"( ( "{0}{2}{1}" -f('a'+'msi'),'d',('I'+'nitF'+'aile') ),( "{2}{4}{0}{1}{3}" -f ('S'+'tat'),'i',('Non'+'Publ'+'i'),'c','c,' ))."sE`T`VaLUE"( ${n`ULl},${t`RuE} )

Happy Hacking!! L.C