AMSI, un paso más allá de la detección de malware en Windows

lunes, 23 de abril de 2018

Al principio fue el virus. Trozos de código en ensamblador que se concatenaban a los archivos, a los que modificaban el "entrypoint". Después, esta técnica se retorció y mejoró hasta sus límites, se buscó la ejecución automática, la reproducción, la independencia de un "huésped" (el malware ya es standalone desde hace tiempo) y el pasar bajo el radar de los antivirus. "Tocar disco" era la premisa (¿cómo infectar, si no?) y a su vez el anatema del malware. Si se conseguía evitar en lo posible este peaje, se podría llegar a huir de los detectores. "Fileless", se llamó a esta técnica que buscaba una fórmula etérea en la que subsistir en memoria todo lo posible. No tocar disco o retrasarlo al máximo, no aterrizar en aquello que controla férreamente el antivirus. "Fileless" se ha perfeccionado hasta tal punto (¿os suena el malware que combina macros y Powershell?), que ya existe una fórmula nativa en Windows para mitigarla en lo posible. Pero no se le presta la atención que debería.

Estructura básica AMSI imagen
Estructura básica AMSI, proporcionada por Microsoft

Anti-Malware Scan Interface (AMSI), básicamente, busca solucionar un grave problema de toda la vida en la industria antivirus: detectar lo que no "toca disco". Se introdujo en Windows 10 y se trata de establecer un canal de comunicación nativo del sistema operativo que "pase por un antivirus" sin necesidad de "hookear" disco, llamadas I/O, etc. Cualquier flujo podrá pasar por ese detector, incluso las ofuscadísimas llamadas de scripts que evalúan y reconstruyen su carga maliciosa en memoria. AMSI viene de serie en Windows y supone una facilidad para que:
  • Cualquier programador pueda mandar a analizar los flujos de entrada a su programa que se encuentren en memoria
  • Cualquiera pueda analizar ese flujo, estableciéndose como un proveedor de análisis (como un antivirus)
En un mundo donde todavía se infectan sistemas gracias a cualquier truco "fileless" burdo de ofuscación, esta herramienta es más que necesaria.

¿Cómo se usa?
Se establece el modelo de provider, por el que se puede hacer pasar un flujo de información. El provider será el que reciba el flujo, y este rol debería cumplirlo quien tenga la capacidad de analizar ese flujo como si fuese un fichero, o sea, los antivirus. A su vez, AMSI facilita que cualquier desarrollador pueda solicitar en su código que se pase por AMSI cierto "input". Por ejemplo, un script para Powershell (cosa que ya hace Windows) o un código JavaScript de un navegador. ¿No sería interesante que Chrome o Firefox pasasen por AMSI un trozo de JavaScript antes de lanzarlo, sin que este tocase ni siquiera una carpeta temporal? Sí, en teoría es posible… solo que todavía ninguno lo hace de forma nativa. ¿Quién lo hace? Fundamentalmente, las herramientas de scripting de Microsoft... Y entre ellas, una de las más necesarias: Powershell. Desde que aproximadamente en 2015 se popularizara el malware basado en Powershell, se vio necesario un movimiento en este sentido. Con AMSI, el intérprete lanza el flujo para que primero se analice por el provider correspondiente. Como el provider que existe por defecto es el propio Windows Defender, su capacidad de detección es la que es, pero si un antivirus ejerciera de provider AMSI, podría llegar a evaluar código que no pasa a disco, sino que se encuentra simplemente en formato "flujo" de información.

AMSI en powershell imagen
AMSI en Powershell (Fuente aquí)

De las posibilidades más atractivas (más allá del software de scripting propio de Microsoft, que ya lo hace), pensemos en las ventajas de un mundo en el que, de forma nativa, el contenido del navegador como "flujo" puede ser evaluado por un sistema antimalware tradicional por firmas. El antivirus podría llegar mucho más lejos, e incluso no preocuparse de tener que meterse dentro del tráfico, esperar a que se almacene la información, detectar "mineros" on the fly, etc. En definitiva, se ofrece a los antivirus que soporten AMSI (por ahora, hasta donde sabemos, pocos parecen soportarlo: AVG/Avast, Dr.Web, ESET…), engancharse a la interpretación de los scripts, cosa que suponemos mejoraría o facilitaría la capacidad de detección.

Un apunte práctico
Es muy sencillo, imagina esta línea de Powershell que se observa en la imagen y descarga en remoto una instancia de Mimikatz (software usado habitualmente para mostrar credenciales en memoria, y detectado por muchos sistemas antimalware). Una descarga y ejecución a través de PowerShell sin almacenar realmente la información, acaba siendo detectada por el propio Windows Defender. En realidad es Windows Defender a través de AMSI quien se ha interpuesto en este caso.


AMSI en acción imagen
AMSI en acción cuando se invoca a un script "descargado"
Si, por otro lado, lo que hacemos es realmente descargar ese fichero ps1 de Mimikatz en disco, será Windows Defender "directamente" quien lo detecte. En los logs queda muy claro. A la izquierda el evento generado con la primera invocación con Webclient. A la derecha, el evento generado con la segunda guardando en disco.

detección por descarga y como fichero imagen
A la izquierda, detectado con el intento de descarga. A la derecha, detectado al ser almacenado como fichero

Muy bien pero... ¿es eludible?
Por supuesto, como todo. Es eludible en el sentido de que no se pase por él, o se invalide de alguna forma. No hablamos de falsos positivos, puesto que AMSI en sí no detecta nada, es un simple canal o mensajero. La lista que mostramos a continuación quizás no sea todas las posibilidades encontradas para desactivarlo o eludirlo, pero contempla la mayoría.
  • Usando COM hijacking: esta fórmula se publicó a mediados de 2017 y ya ha sido solucionada por Microsoft. AMSI buscaba un objeto COM (CLSID) primero a HKCU (donde no existía), luego lo buscaba en HKLM donde en realidad estaba. Si se crea ese CLSID dentro de HKCU primero, se impedía la inicialización correcta de AMSI.
  • Usando un nullbyte: publicado en febrero de 2018 y ya solucionado por Microsoft. Consistía en agregar un byte null tradicional antes de la cadena detectada como maliciosa por los potenciales antivirus. AMSI utiliza strncpy cuya función copiaba en el buffer a escanear hasta que se encontraba con un \00. Un fallo bastante inaceptable para el momento. Más información aquí.
  • Patching en memoria: publicado también en febrero de este año y ya solucionado por Microsoft. Consistía en un parche en memoria para la función AmsiScanBuffer() que debía ser ejecutado en Powershell antes de ejecutar el script malicioso. Más información sobre esta técnica en la Black Hat Asia
Existen otras fórmulas para eludirlo, como la publicada aquí, además de ejemplos en los que se desactiva de alguna forma, o se intenta eludir la detección del flujo. Tenemos varios ejemplos en esta charla.

Lista de funciones exportadas por amsi.dl imagen
Lista de funciones exportadas por amsi.dll. Todo esto está muy poco documentado

Conclusión
Puede que AMSI, junto con otras medidas de seguridad incrustadas de serie en Windows 10, estén mejor o peor implementadas, que tengan mayor o menor usabilidad, que gusten poco o mucho, que resulten útiles o no... Pero, las medidas de seguridad (ahora en Windows 10 todas agrupadas bajo el paraguas de Device Guard con su especie de EMET, antivirus, CFG, cortafuegos hacia afuera, el antiguo AppLocker...) están ahí por defecto, eso es un hecho, y es necesario conocerlas en profundidad para aprovecharlas y que a su vez, mejoren la seguridad global. AMSI es una de las más interesantes y a la vez, menos conocidas.

Sergio de los Santos
Equipo de Innovación y Laboratorio de ElevenPaths
ssantos@11paths.com
@ssantosv

Sheila Berta
Equipo de Innovación y Laboratorio de ElevenPaths
sheila.berta@11paths.com
@unapibageek

No hay comentarios:

Publicar un comentario