Hoy vamos a hablar acerca de una capa de seguridad por defecto que viene a partir de Windows 10.
Básicamente es una capa la cuál uno de sus objetivos es detectar lo que “no toca disco”. Como hemos comentado , se introdujo en Windows 10 y trata de establecer un canal de comunicación nativo del sistema operativo que “pase por un antivirus” (aunque ni por asomo) sin necesidad de “hookear” en la parte de disco, llamadas I/O, etc.
Cualquier flujo podrá pasar por este “detector” , incluso las ofuscadísimas llamadas de scripts que evalúan y reconstruyen su carga maliciosa en memoria (cuidadín).
En un mundo donde todavía se infectan sistemas gracias a cualquier truco burdo de ofuscación, esta herramienta es más que necesaria (Como siempre se dice , la defensa no se constituye de una sola capa).
No obstante , cómo todo en este nuestro “mundillo” es bypasseable , sin embargo , está bien comprender esos famosos mensajes que nos aparecen alguna vez que empezamos a realizar nuestros pinitos de “pentest” usando por ejemplo powershell (ya nos acordamos algunos de los invoke-mimikatz etc eh?)
Todo esto está muy bien pero , oye , ¿Cómo funciona realmente esto?, pues bien vamos a darle tajos al jamón:
Esto sería la arquitectura AMSI, donde su propia aplicación está representada por uno de los cuadros «Otra aplicación».
La interfaz Windows AMSI está abierta. Esto significa que cualquier aplicación puede llamarla; y cualquier motor antimalware registrado puede procesar el contenido enviado a él.
Es decir, esto en parte nace también para liberar de carga de trabajo a los AV y poder también tener un menor consumo de recursos.
Por ejemplo ,en nuestros equipos , Windows defender es la aplicación que llama a las API de AMSI (No obstante , otros antivirus también se aprovechan de esta funcionalidad y también las llaman, como vemos en la imagen de la arquitectura el cuadrado de “3rd party AV Provider Class)
Vamos a ver un ejemplo de un script que no nos hemos descargado pero queremos ejecutarlo
Podéis intuir que es lo que está haciendo verdad? , está ofuscando una cadena en base 64 y después realizando un xor para enmascarar el link real , si ejecutamos el script tal y como dice la línea 8 en powershell nos mostrará lo siguiente:
Como vemos , esto ha sido parado sin llegar a ejecutarse nada (intentando hacer invoques) , no obstante Si, por otro lado, lo que hacemos es realmente descargar ese fichero ps1 en disco, será Windows Defender «directamente» quien lo detecte. En los logs queda muy claro, en la segunda línea del evento generado con la primera invocación.
¿Esto se puede bypassear?
Obviamente, como cada día en todas las capas van apareciendo maneras de bypassear. ¿Cómo?
- 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 0. 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.
- Ejecución de código previo en sesión powershell: haciendo llamadas antes de ejecutar el código malicioso , estas llamadas podemos verlas en amsi.fail
Cualquier pregunta podéis dejarla en los comentarios!
Fuentes de información:
blogthinkbig.com y Microsoft
