Funciones de AMSI

¡Muy buenas a todos! Hace unas cuantas publicaciones, hablamos sobre la introducción a AMSI. Hoy vamos a continuar adentrándonos en
el mundo de AMSI. En esta ocasión, vamos a profundizar en las funciones que
utiliza intérpretes como PowerShell para comunicarse con las medidas de
seguridad gracias a la API AMSI.

Dado que AMSI forma parte de la Windows API (user-mode),
está documentada por Microsoft para que los desarrolladores no tengan problema
en usarla. Es decir, las librerías de la Windows API tienen documentación
acerca de cómo se estructuran sus funciones, que parámetros espera cada
función, valores que recibe, etc.

En primer lugar, tenemos la función AmsiInitialize. Esta
función se llama antes de que ejecutemos cualquier comando en la PowerShell, es
decir, esta función se llama en el momento en el que se ejecuta el intérprete.
Por lo tanto, es una función complicada para atacar y hacer un bypass, debido a
que no se puede modificar la lógica mediante comandos PowerShell.

La documentación de Microsoft nos dice que esta función
recibe dos parámetros:

• El primer parámetro es el nombre de la
  aplicación que va a utilizar la DLL, que en nuestro caso va a ser PowerShell.
• El segundo parámetro es un puntero vacío llamado
  amsiContext. Este puntero será rellenado por la función AmsiInitialize y será
  utilizado con el resto de las funciones.

Tanto en esta función como en la mayoría de las funciones de
AMSI se devuelve HRESULT, que es un código que representa si la función se ha
ejecutado de forma exitosa o no. La lista de códigos podemos verla en la
documentación de Microsoft.

La siguiente función es AmsiOpenSession. Cada vez que se
ejecuta un comando PowerShell, es necesario crear una sesión con AMSI, por lo
que se llamará a esta función.

Al igual que AmsiInitialize, devuelve un código que
representa si la función se ha ejecutado de forma exitosa o no.

En tercer lugar, tenemos AmsiScanString y AmsiScanBuffer.
Ambas funciones tienen el mismo cometido y la forma de utilizarse es bastante
similar. Tanto es así, que en realidad AmsiScanString llama por debajo a
AmsiScanBuffer. La labor de estas funciones es capturar el contenido de un
comando para que posteriormente lo escanee el AV/EDR.

La documentación de Microsoft nos
dice que AmsiScanString recibe cinco parámetros:

• El primer argumento representa contexto que ha rellenado
  la primera función (AmsiInitialize).
• El segundo argumento es un string, que
  representa el contenido del comando.
• El tercer argumento es una especie de
  identificador.
• El cuarto argumento es la sesión, que como hemos
  visto previamente, se ha rellenado en la función AmsiOpenSession.
• Por último, con el quinto argumento la función
  recibe un puntero vacío que va a representar el resultado del escaneo (es
  decir, si el AV/EDR dice que es malware o no). Los valores pueden ser los
  siguientes:        

Por otro lado, AmsiScanBuffer
recibe, en lugar de un string que va a representar el comando, un buffer.
Además, también es necesario indicar la longitud de ese buffer. Los demás
argumentos son iguales para ambas funciones.

Por último, tanto para
AmsiScanString como para AmsiScanBuffer se devuelve HRESULT, que de la misma
forma que en las funciones anteriores, representa si la función se ha ejecutado
correctamente. Cabe destacar que no hay que confundir el resultado del escaneo
con el resultado de la función, que son dos valores completamente diferentes.

A pesar de eso, son valores que
sí que son dependientes entre sí. El contenido de result no puede ser
AMSI_RESULT_DETECTED, si HRESULT es E_INVALIDARG, puesto que esto significaría
que no se ejecutaría el análisis porque los argumentos son inválidos.

Pero si por un casual, por algún
tipo de error, el contenido de result representa que existe malware,
pero HRESULT es INVALIDARG, el comando se ejecutará con normalidad, ya que
primero se comprobará HRESULT, y si este indica que se ha ejecutado la función
con normalidad, comprobará el contenido de result.

Por último, tenemos la función
AmsiCloseSession, que tiene lugar cuando ya se ha realizado el escaneo. Esta
función se llama también cuando se ejecuta un comando en PowerShell. La tarea
de esta función es cerrar la sesión para que no se pueda volver a utilizar.

La documentación de Microsoft nos
dice que recibe dos parámetros:

• El contexto de la inicialización. 
• La sesión que se quiere cerrar.

Al ser una función void,
no devuelve nada. Es decir, por parte de Microsoft no existe control de errores
para saber si la sesión se ha cerrado con éxito, o ha habido algún tipo de
fallo.

Por lo tanto, cuando abrimos una
PowerShell, el flujo de llamadas a la API sería el siguiente:

Y en el momento que ya está la PowerShell abierta y ejecutamos comandos, el
flujo de llamadas a la API sería el siguiente:

Y por hoy ¡ya está bien!, continuaremos con AMSI en las próximas entregas.