Ligolo-ng, pivoting avanzado de la mano de Go

Muy buenas, durante esta entrega hablaremos de una herramienta que facilita mucho la temática de los túneles. ¡No os perdáis en él! .

Ligolo-ng es una herramienta simple, ligera y rápida que permite a los pentester establecer túneles desde una conexión TCP/TLS inversa utilizando una interfaz virtual “tun” (sin necesidad de SOCKS). A diferencia de Chisel u otras herramientas, con Ligolo-ng no necesitamos hacer uso de SOCKS, si no que mediante interfaces virtuales levantaremos un túnel (al más puro estilo VPN).

Gracias a esto, podremos correr herramientas como Nmap sin tener que usar proxychains, por lo que las tareas de pivoting se vuelven más sencillas y rápidas, ya que una de las ventajas de Ligolo-ng es una significativa mejora en el rendimiento de las conexiones frente al uso de SOCKS. Tendremos conexiones más rápidas y estables. 

A continuación, os detallamos cómo usar esta herramienta correctamente:

Get-ready

Agent – Máquina víctima

Proxy – Máquina atacante

En primer lugar, descargaremos en nuestro directorio de trabajo los binarios que vamos a necesitar. Os dejamos el repositorio oficial de Ligolo-ng:  .

 
Tenemos la posibilidad de descargar el código fuente o el binario ya compilado, por comodidad en este caso, descargaremos tanto el binario del agente como el del proxy en función de los sistemas operativos que vayamos a emplear (en nuestro caso Linux):

En el caso de optar por descargar el código fuente (GO), usaremos los siguientes comandos para compilarlo:

Linux:

Windows: 

Configurar Ligolo-ng:

Ligolo-ng se basa en una interfaz virtual a través de la cual se establecerá un túnel entre la máquina víctima y la atacante, es por ello por lo que será necesario levantar primeramente la interfaz “tun” sobre la que se apoya Ligolo-ng:

Consultamos las opciones que nos ofrece el proxy:

En donde se nos presenta las distintas opciones de certificados TLS que disponemos:

• Autocert: El proxy automáticamente solicitará un certificado usando Lets encrypt. Esta opción requiere accesibilidad al puerto 80. 

• Certfile / -keyfile: Si queremos usar nuestros propios certificados.

• Selfcert: Generara automáticamente un certificado autofirmado. Esta opción es la menos recomendada en términos de seguridad, pero si estamos trabajando en un laboratorio aislado o en un entorno de pruebas, es una opción válida.

• Tun <nombre interfaz>: En el caso de haber escogido otro nombre para la interfaz.

• Laddr <IP:port>:  La interfaz de escucha por defecto 0.0.0.0:11601, para definir otra interfaz lo indicaremos mediante este comando.

Lanzamos el proxy con la configuración por defecto, valiéndonos de certificados autofirmados para el cifrado de la conexión

En la máquina atacante:

En la máquina víctima:

Ya tendríamos la sesión creada:

Ahora seleccionamos en el proxy (maquina atacante) la sesión que acabamos de crear:

Siempre tendremos que indicar sobre que sesión queremos trabajar. Una vez levantada la sesión podemos llevar a cabo diferentes acciones:

Desde el propio proxy podremos consultar las interfaces de red que hay levantadas en el agente (víctima) mediante el comando ifconfig:

Para poder llegar a esta nueva red (192.168.1.0/24) tendremos que indicar a nuestra máquina atacante que redirija el tráfico con destino 192.168.1.0/24 a través del túnel Ligolo que acabamos de crear. Para ello añadimos la siguiente ruta estática a la tabla de routing de la máquina atacante: 

Y por último iniciamos el túnel: 

Os muestro en el siguiente diagrama lo realizado hasta aquí:

Y ahora pasamos a comprobar que llegamos a la nueva subred (192.168.1.0/24) a través de la interfaz eth1 de la víctima:

Enlace puente

Los agentes permiten escuchar en puertos prestablecidos, de tal forma que todo el tráfico entrante hacia esos puertos sea redirigido directamente a la máquina atacante. 

Desde el proxy (atacante) y sobre la misma sesión que teníamos establecida, levantamos un listener en el agente (víctima): 

Cualquier tráfico entrante en la máquina víctima con destino el puerto 1234, será redirigido a la máquina atacante al puerto 4321. Esto es muy útil cuando tenemos que ejecutar un reverse payload hacia la máquina atacante o descargar ficheros en la víctima desde un servidor HTTP alojado en la máquina atacante. 

Avanzamos quedando así, un ejemplo de una reverse shell seria este:

Podemos gestionar cada uno de los listener levantados mediante listener_list y listener_stop/start.

Pivotando entre varias máquinas

Si queremos pivotar entre varias máquinas, podemos crear tantas sesiones como queramos apoyándonos de los listener, de tal forma que en cada máquina haya un listener escuchado en un puerto establecido que nos redirija a la máquina anterior de salto y así sucesivamente, hasta llegar al puerto 11601 (por defecto) de la máquina atacante en donde proxy-ligolo está escuchando peticiones de nuevos agentes (víctimas).

Ejemplo: desde la red 192.168.1.0/24 (donde se encuentra la máquina de salto) levantamos el agente (víctima 2) hacia el listener de la máquina intermedia (víctima 1) que nos redirigirá directamente al proxy-ligolo (atacante).

1. Configuramos el listener en la máquina de salto (192.168.1.147) desde la máquina atacante:

2. En la nueva máquina víctima lanzamos el agente (víctima 2) hacia el listener de la máquina de salto intermedia (192.168.1.147:11601):

3. La conexión será redirigida al proxy-ligolo. Se establece una nueva sesión que permitirá a acceder a nuevas subredes:

Concluyendo con esta práctica hemos realizado este ejercicio:

¡Hasta aquí hemos llegado! ¡Esperamos que haya sido de interés y utilidad para todos!

¡¡¡A volar, perdón, a pivotar!!!! 

Alejandro Auñón, Offensive Security Senior Analyst at Zerolynx.

Técnicas de ofuscación para AMSI

Muy buenas a todos. En este post vamos a hablar de como los antivirus (AV) detectan scripts maliciosos en tiempo de ejecución y las medidas para ofuscar los scripts en Powershell y que la ejecución de este no sea bloqueada por el AV.

Como ya se ha visto en artículos anteriores , AMSI es una API que conecta el AV con Powershell para identificar si un script puede ser o no malicioso en tiempo de ejecución y en caso de serlo, bloquearlo. Pero la pregunta que hay que hacerse es la siguiente: ¿Cómo los antivirus detectan si el script es malicioso? La respuesta a esta pregunta son las firmas de los AV.

Firmas de antivirus en Powershell 

Las clásicas firmas de virus son una secuencia continua de bytes comunes en cierta muestra de malware, es decir, si esa secuencia continua de bytes está incluida en un archivo, ese archivo es malware.

Siguiendo este concepto, las firmas de antivirus en PowerShell son patrones únicos que representan cadenas características en los scripts escritos en este lenguaje. Cuando un script es escrito en la consola de Powershell, al ejecutarlo, AMSI envía el script al antivirus y este detecta si la firma de alguna de las cadenas incluidas en el script puede ser susceptible de ser maliciosa o si toda la cadena lo es y si estos casos se cumplen, la ejecución del script es bloqueada por el antivirus.

Como ejemplo a esto, si intentásemos usar mimikatz en Powershell, como la cadena de mimikatz es bien conocida por ser un script que podría ser malicioso en manos equivocadas, si se intenta invocar, aunque el archivo no esté en el path, antes de saltar el error de que el script no se encuentra, saltará el error de que el script contiene uno o más elementos malintencionados y que ha sido bloqueado por el antivirus.

Lo mismo ocurre si escribimos la cadena amsiInitFailed que es usada en algunos bypass de AMSI, el antivirus lo va a detectar y bloquear porque hay una firma en el antivirus de esta cadena en concreto:

Esto, por tanto, supone un impedimento a la hora de ejecutar scripts maliciosos en primera instancia, por eso lo que se suele hacer es ofuscar las cadenas del script de manera que estas no tengan firma en el antivirus y por tanto lo hace indetectable al AV.

Técnicas de ofuscación en Powershell

Para evadir la detección del AV, se utilizan técnicas de ofuscación para modificar el código fuente de un script de manera que sea más difícil de detectar y analizar. Este conjunto de técnicas son la siguientes:

Codificación y decodificación en Base64: 

Esta técnica consiste en codificar el contenido del script en Base64 y decodificarlo en tiempo de ejecución, es decir, se codifica en Base64 la cadena que hace de trigger para el AV y se decodifica en dentro del script. 

Como ya hemos visto, la cadena amsiInitFailed es detectada por el AV, pero si la pasamos a base64 la cadena pasa a ser YW1zaUluaXRGYWlsZWQ= y al volver a convertirla en ASCII, ya no la detecta, y se imprimirá por terminal.

Concatenación y escape de caracteres

El operador para concatenar en Powershell, como en otros muchos lenguajes, es el carácter +. Una manera de ofuscar el código de un script es dividiendo las cadenas que lo incluyen y que tienen una firma en el AV, de manera que a la hora de escribir el script y concatenarlas en tiempo de ejecución, el antivirus no detecta la ejecución que sí detectaría sin esta concatenación porque la firma de la cadena dividida no está incluida en el mismo.

Otra manera de ofuscar es incluyendo en las cadenas el carácter de escape que en Powershell es el carácter `. Este tipo de carácter se suele incluir dentro de una cadena de caracteres.

Reordenación de cadenas con formateo

Powershell también incluye el formateo de cadenas mediante el comando -f. Con esto podemos escribir una cadena que normalmente detectaría el AV por tener una firma y reordenarla en tiempo de ejecución.

Reflejo de métodos .NET

En internet existen numerosos scripts que hacen bypass a AMSI. Uno de los más famosos es el de Matt Graeber que usa el método de reflejo.

El reflejo de métodos .NET (reflection en inglés), consiste en inspeccionar, invocar y acceder a datos de tipos .NET que incluyen tanto parámetros públicos como privados. Por defecto, PowerShell proporciona acceso a las propiedades y métodos de acceso público, pero utilizando las API de reflexión, puede acceder a los parámetros privados.

El método es el siguiente:

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

Sin embargo, ya es tan usado que hay que aplicar alguna de las técnicas descritas arriba y la siguiente técnica que se va a explicar para que el antivirus no lo detecte.

División de scripts en distintas líneas

Existen muchos scripts de una sola línea (one-liner en inglés) que usan métodos como reflection junto con concatenación de cadenas, etc. Aunque, el uso de estos scripts está tan extendido que ya hay firmas para este tipo de scripts. 

No obstante, una manera simple de evitar que AMSI se queje, es dividiendo el código en distintas líneas o si es un código de una misma línea como el de Matt Graeber, dividiéndolo en distintas variables. De esta manera, aunque a primera vista pueda parecer absurdo, como ya hemos explicado cómo funcionan las firmas de los antivirus en Powershell y AMSI, tiene sentido que sea posible esta manera de ofuscar el script.

Veámoslo en un ejemplo.

En la imagen podemos ver que el primero es el script original y al segundo se le ha aplicado concatenación de cadenas de caracteres para intentar evitar al AV. Sin embargo, es tan usado que algo así no es válido.

Pero si dividimos este script en distintas líneas, el tema cambia como os voy a demostrar en la siguiente imagen:

Como se puede ver, al dividirlo en distintas variables más el uso de la concatenación de cadenas de caracteres es posible evitar que AMSI detecte este script y se efectúa correctamente el bypass.

Hay que aclarar que normalmente estas técnicas se usan a la vez en un mismo script ya que todas las explicadas en este post son más eficaces si se realizan en conjunto que por separado.

Esto es todo por ahora. En los siguientes artículos de AMSI se verán distintas técnicas de cómo realizar estas evasiones (cuyos scripts evidentemente estarán ofuscados con alguna de las técnicas aquí mencionadas).

¡Hasta el próximo post!

 Justo Martín, Security Analyst at Zerolynx.

Sistema experto portátil para la Adquisición Segura y Semiautomática de Evidencias Digitales

Hoy os presentamos un análisis, quizá demasiado ligero, de un problema actual para el que proponemos una solución seguramente no tan ligera.

¿Dónde estamos?

Según el Portal Estadístico de Criminalidad del Ministerio del Interior de España, el número de hechos conocidos relacionados con ciberdelitos no ha dejado de aumentar desde 2011. El grupo penal que más crece, y que más incidencia tiene, es el de fraude informático, que el Código Penal español define como el delito de estafa a través de la manipulación ilícita de datos y/o programas con ánimo de lucro.

Además, en la actualidad, no sólo los delitos tipificados como cibercrímenes tienen una componente tecnológica en la que es necesario hacer alguna investigación sobre algún medio digital como un móvil, un portátil o un servidor.

Por otro lado, el número de hechos esclarecidos es muy inferior al de los conocidos y su tendencia de crecimiento no se acerca a la de los primeros:

Por lo tanto, el número de casos en los que es necesaria la ayuda de un análisis informático forense dentro de un proceso judicial es cada vez mayor.

Pero en realidad no es necesaria la existencia de un litigio para que sea conveniente realizar un estudio forense de una infraestructura informática. Muchas empresas, a nivel interno, emplean metodologías de análisis forense para resolver, prevenir, reducir y controlar la ocurrencia del fraude dentro de la organización. A menudo se toman muestras o evidencias para su uso futuro en posibles procesos de control interno o judiciales.

Casi todas las metodologías de análisis forense resumen su operativa en las muy conocidas cinco fases que nos permitimos recordar:

1º Adquisición. Donde se realiza una copia de la información susceptible de poder ser presentada como prueba en un proceso. Estas evidencias deben ser recogidas sin alterar los originales, utilizando dispositivos o procedimiento de sólo lectura que garanticen que no se sobrescribe el medio de almacenamiento de origen. Se debe respetar la volatilidad de las muestras y priorizar su recogida. Y se deben etiquetar y almacenar todos los dispositivos originales de forma segura.

2º Preservación. En esta fase se garantiza la perdurabilidad en el tiempo y la cadena de custodia de la información recogida.

3º Análisis. Se emplean técnicas que, junto con la experiencia y la inteligencia del analista, ayudarán a resolver el qué, el cómo y el quién del caso analizado.

4º Documentación. Fase en la que se asegura que todo el proceso (información y procedimientos aplicados) queda correctamente documentado y fechado.

5º Presentación. Donde se generan al menos un informe ejecutivo y otro técnico recogiendo las conclusiones de todo el análisis.

Los jueces tienen muy en cuenta cómo son recogidas y almacenadas las evidencias digitales, dependiendo su validez de los métodos elegidos. Por lo tanto, es evidente que las fases de adquisición y preservación son fundamentales para todo el proceso. Si en estas fases se comete algún error, toda investigación, junto con todos los análisis posteriores, dejará de ser válidos.

¿Cuál es el problema?

En Electronic evidence - A basic guide for First Responders - ENISA se proponen los siguientes principios que deben asegurarse en la gestión de evidencias digitales:

• Integridad de los datos. No se debe modificar ningún dato que deba usarse en la resolución de un caso por un juzgado. La persona encargada de la escena del crimen o de la recolección es la responsable de que eso no ocurra. Además, si el dispositivo recogido está encendido, la adquisición debe hacerse de forma que se modifique lo mínimo posible.

• Registro. Se debe crear y actualizar un registro con todas las acciones realizadas sobre las evidencias recogidas, desde su adquisición hasta cualquier consulta posterior.

• Soporte de especialistas. En cualquier momento durante la adquisición debe ser posible la intervención de un especialista debidamente formado en técnicas forenses digitales. Dicho especialista debe tener el suficiente conocimiento técnico y legal, así como la experiencia y autorización necesarias.

• Formación. Cualquier persona que maneje evidencias digitales debe tener una formación básica técnica y legal.

•  Legalidad. Se debe asegurar la legalidad correspondiente a lo largo de todo el proceso.

Siempre con estos principios en mente, en la fase de adquisición hay que tomar decisiones y responder preguntas complicadas como:

•  ¿Dónde se encuentra físicamente la información?

•  Qué dispositivos de almacenamiento copiar.

•  ¿Se debe apagar un dispositivo para realizar la adquisición?

•  Orden para realizar las copias, teniendo en cuenta la volatilidad de los datos implicados.

•  ¿Es necesario buscar y copiar dispositivos ocultos, no visibles o remotos?

•  ¿Se han empleado técnicas anti forenses para ocultar información?

•  Necesidad de soporte de un especialista forense.

•  Necesidad de un fedatario.

En la escena del crimen pueden concurrir varios perfiles de profesionales con diferentes niveles de responsabilidad, formación y experiencia. No todos ellos pueden contestar exitosamente las preguntas anteriores.

Claramente, el número de profesionales debidamente cualificados para realizar estas adquisiciones forenses no es suficiente. Otros factores que complican la situación son las restricciones de movimiento, el teletrabajo, la necesidad de operar en entornos hostiles o los límites presupuestarios.

En este escenario, sería de gran ayuda un sistema autónomo y portable, que pudiera ser operado por una persona sin entrenamiento específico, que asistiera en la adquisición, almacenamiento y documentado seguros de evidencias digitales.

¿Qué tenemos?

Existen en el mercado múltiples herramientas específicas para la adquisición de evidencias. Algunas son comerciales y otras de uso libre. A continuación, os dejamos una lista con algunas de las más representativas y utilizadas comparando sus principales características:

Todas tienen en común que son complejas de utilizar, que necesitan formación específica para su uso y, sobre todo, que pueden ser peligrosas si no se utilizan correctamente, es fácil incurrir en una pérdida irrecuperable de datos.

Por otro lado, existen multitud de distribuciones Linux con orientación a la informática forense que proporcionan herramientas específicas para la adquisición de evidencias. Entre todas, destacamos las siguientes por su grado de actualización y especialización en el proceso forense:

Todos sabemos que existen otras distribuciones muy completas que cubren no sólo el proceso de análisis forense sino cualquier parcela relacionada con la ciberseguridad. Entre ellas cabe destacar Kali Linux, BlackArch Linux, Matriux, BackBox Linux o Parrot.

Todas ellas disponen de las mejores herramientas para el análisis forense y con todas es posible realizar una adquisición de evidencias digitales segura. Todas tienen indudable valor para el profesional de la ciberseguridad. Pero en el contexto de este análisis, todas tienen algunos inconvenientes:

•  Pueden ser complejas de poner en marcha si no se tienen los conocimientos suficientes.

•  Necesitan formación técnica específica para utilizar sus herramientas forenses.

•  No están diseñadas específicamente para la adquisición de evidencias digitales.

¿Qué proponemos?

Un sistema que permita eliminar todas estas deficiencias, ofreciendo una solución específica para la adquisición de evidencias digitales, que permita a un operador sin demasiados conocimientos recoger, de forma segura y en cualquier lugar, datos e información que podría ser utilizada en un proceso judicial.

A continuación, nos permitimos imaginar una lista de características deseables durante las fases de adquisición, preservación y documentación y no encontradas juntas en ninguna de las distribuciones anteriores:

•  Sistema integrado portátil, dedicado y autocontenido.

•  Interfaz de usuario intuitiva, sencilla y simple de utilizar, que no requiera casi aprendizaje.

•  Interfaz de usuario que evite o minimice errores por desconocimiento o malintencionados.

• Guiado de actividades para usuarios sin experiencia a través de un sistema experto que implemente la inteligencia y experiencia de un analista forense.

•  Ayuda en la identificación de evidencias. A menudo poco o nada visibles.

•  Adquisición segura (en integridad y disponibilidad) de dispositivos de almacenamiento.

• Uso de la técnica correcta según el tipo de evidencia.

•  Asistencia en el almacenado físico y etiquetado de las adquisiciones.

• Configuración de la cadena de custodia de evidencias digitales.

•  Generación del registro de actividades.

•  Generación de documentación.

Además, podríamos imaginar que integrara funciones de utilidad en las fases de análisis y presentación del proceso forense, pudiendo así cubrir todo el proceso forense. Incluso añadir inteligencia específica para el análisis de nuevos casos de fraude, industria e IoT, infraestructuras críticas, etc.

Imaginemos un caso de uso genérico:

O el flujo general de nuestro sistema:

Imaginemos el modelo de datos necesario:

O incluso cómo podría ser su interfaz:

Concluyendo

Existen todas las herramientas de diseño, implementación e integración de sistemas necesarias para desarrollar un sistema como el que ahora hemos imaginado. Es posible desarrollar un sistema experto que ayude a personal sin formación específica en informática forense a realizar una adquisición guiada y segura de las evidencias necesarias para resolver un incidente de seguridad.

Es posible integrar técnicas, procedimientos y herramientas específicas con un sistema experto que implementa la inteligencia de un analista forense en un software que puede ser utilizado por usuarios con pocos conocimientos en un entorno que requiere metodología, integridad y documentación muy exhaustivos.

Equipos de respuesta inmediata como cuerpos y fuerzas de seguridad, peritos forenses junior y profesionales de la informática y las comunicaciones podrían ser sus principales usuarios. Los principios de seguridad e integridad bajo los que estaría desarrollado permitirían su uso en investigaciones y procedimientos judiciales o en auditorías internas dentro de organizaciones privadas o públicas.

Esperamos que este artículo haya servido de inspiración para muchos. Imaginar y soñar es gratis y algunos incluso llegan a hacerlo realidad. Si eres de esos acompáñanos.

Iván Paniagua Barrilero, Teachnical Lead at Zerolynx.

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.

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

• El primer argumento es amsiContext, que equivale al contexto que se ha rellenado en la anterior función.

• El segundo argumento es un puntero vacío llamado amsiSession. Este puntero será rellenado por la función AmsiOpenSession y será utilizado por otras funciones.

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.

Juan Gabriel Ruiz, Senior Security Analyst at Zerolynx y Justo Martín, Security Analyst at Zerolynx.