optiv/dentUn framework para crear bypasses basados en COM utilizando vulnerabilidades en los sensores WDAPT de Microsoft.
Para ver la última versión de Dent o reportar un problema, consulte https://github.com/Tylous/Dent.
Dent
Si desea obtener más información sobre las técnicas utilizadas en este framework, consulte este artículo.
Este framework genera código para explotar vulnerabilidades en las reglas de Reducción de Superficie de Ataque (ASR) de Microsoft Defender Advanced Threat Protection para ejecutar shellcode sin ser detectado o prevenido. ASR fue diseñado para ser la primera línea de defensa, detectando eventos basados en acciones que violan un conjunto de reglas. Estas reglas se centran en indicadores de comportamiento específicos en el endpoint que a menudo están asociados con las Tácticas, Técnicas o Procedimientos (TTP) de un atacante. Estas reglas tienen un fuerte enfoque en la suite de Microsoft Office, ya que este es un vector de ataque común para establecer un punto de apoyo remoto en un endpoint. Muchos de los controles basados en reglas se centran en indicadores de comportamiento basados en red o procesos que se destacan de la operación normal del negocio. Estas reglas se enfocan ya sea en el compromiso inicial de un sistema o en una técnica que puede afectar gravemente a una organización (por ejemplo, divulgación de credenciales o ransomware). Cubren una gran parte de la superficie de ataque común y se centran en obstaculizar técnicas conocidas utilizadas para comprometer activos.
Dent aprovecha varias vulnerabilidades para eludir estos controles restrictivos y ejecutar cargas útiles en un endpoint sin ser bloqueado o detectado efectivamente por los sensores de Microsoft Defender Advanced Threat Protection. El artículo anterior describe estas vulnerabilidades que AÚN están presentes en Microsoft Defender Advanced Threat Protection incluso después de la divulgación.
El primer paso, como siempre, es clonar el repositorio y luego compilarlo.
go build Dent.go
./Dent -h
________ __
\______ \ ____ _____/ |_
| | \_/ __ \ / \ __\
| | \ ___/| | \ |
/_______ /\___ >___| /__|
\/ \/ \/
(@Tyl0us)
"Call someone a hero long enough, and they'll believe it. They'll become it.
They have no choice. Let them call you a monster, and you become a monster."
Usage of ./Dent:
-C string
Name of the COM object.
-N string
Name of the XLL playload when it's writen to disk.
-O string
Name of the output file. (default "output.txt")
-P string
Path of the DLL for your COM object. (Either use \\ or '' around the path)
-U string
URL where the base64 encoded XLL payload is hosted.
-show
Display the script in the terminal.
Este framework está destinado a explotar vulnerabilidades y deficiencias en Microsoft Defender Advanced Threat Protection, por lo que no genera realmente cargas útiles/implantes. Para generarlos, puede utilizar una gran cantidad de herramientas disponibles públicamente; sin embargo, toda la investigación, desarrollo y pruebas se realizaron con ScareCrow. Microsoft Defender Advanced Threat Protection no depende del hooking en el espacio de usuario para la telemetría, sino que utiliza varios otros mecanismos como callbacks del kernel. Según las pruebas, este framework funciona extremadamente bien para eludir Microsoft Defender Advanced Threat Protection y ejecutar shellcode.
En el momento del lanzamiento, actualmente hay dos técnicas. Estaré agregando constantemente diferentes que utilicen estas vulnerabilidades de diversas formas periódicamente, así que estén atentos para más.
Los objetos COM a menudo se crean cuando se instala una aplicación en un sistema. Una vez creados, cualquier aplicación o script puede llamarlos; sin embargo, esta no es la única forma de crearlos. Modificando/creando claves de registro en la sección HKEY_CLASSES_ROOT del Registro de Windows, podemos crear un objeto COM que apunte a nuestro shellcode en el sistema. Esto significa que cualquier aplicación o script que pueda utilizar COM puede llamarlo, ejecutando el shellcode.
Esto funciona debido a cómo funciona la API CoCreatInstance. CoCreateInstance se utiliza para crear e inicializar objetos COM basados en el CLSID (un identificador único global utilizado para identificar una clase específica de objeto COM). Esta función obtiene la información para ejecutar la llamada utilizando los valores almacenados en las claves de registro. Estos valores CLSID se pueden encontrar en la ruta HKEY_CLASSES_ROOT\CLSID\ del registro. Sin embargo, antes de que un proceso pueda llamar al CLSID, debe conocer el valor de ese CLSID. Esto se realiza primero realizando una consulta de registro para buscar el objeto COM en HKEY_CLASSES_ROOT\<nombre del objeto COM>, y si existe, se realizará una segunda consulta de registro para obtener el valor CLSID almacenado en la subcarpeta.
Una inspección adicional de las subcarpetas del registro muestra que los permisos para los valores CLSID no son consistentes. Una gran mayoría de los objetos COM almacenados aquí solo permiten permiso de "Control total" al Instalador de confianza. El Instalador de confianza es una cuenta de servicio que posee recursos para protegerlos, incluso de los Administradores. Esto tiene la intención de asegurar que incluso si un atacante obtiene privilegios administrativos, los recursos no puedan ser manipulados maliciosamente. Desafortunadamente, muchos objetos COM permiten a cualquier persona en el grupo de Administradores permiso de "Control total". Además, la clave raíz CLSID permite al grupo de Administradores permisos de "Control total" en lugar de NT AUTHORITY\Sistema o Instalador de confianza. Debido a esto, en un contexto elevado podemos crear o incluso modificar valores específicos de objetos COM.
Importante
La creación de estas claves de registro solo funciona si se ejecuta en un contexto elevado. Hacer doble clic en esto a través de una GUI no ejecutará el archivo .VBS en un contexto elevado incluso si eres administrador. Se recomienda ejecutarlo desde un shell o símbolo del sistema administrativo. Sin embargo, una vez creadas las claves, cualquier aplicación puede llamar a este objeto COM bajo cualquier contexto.
Para utilizar una carga útil de ScareCrow con este tipo de bypass, puede ejecutar el siguiente comando:
./ScareCrow -I <path to your raw stageless shellcode> -domain <domain name> -Loader dll
Una vez que tengas tu carga útil, usa la bandera -N para el nombre de la carga útil cuando se escriba en disco, la bandera -C para el nombre del objeto COM, la bandera -I para la ubicación donde escribirla y, por último, la bandera -O para el archivo de salida donde almacenar el contenido.
Esta opción genera un bloque de código para eludir varias reglas ASR para descargar, escribir en disco, cargar y ejecutar shellcode, evitando los controles preventivos de ASR. Esto se hace utilizando el objeto COM Excel.Application que representa toda la aplicación Excel, pero de forma automatizada, y permite la interacción programática con ella. Debido a que sigue siendo Excel, no activa la regla ASR. Esto se debe a que cuando llamamos a Excel.Application, podemos ver que se genera bajo un proceso de Host de Servicio (Svchost.exe) y no bajo el proceso WinWord.exe. Mientras que Svchost.exe es un proceso a nivel de sistema utilizado para alojar múltiples servicios basados en Windows, el proceso hijo creado (Excel.exe) no obtuvo privilegios a nivel de sistema.
Debido a que creamos un objeto COM que era una aplicación completa, el proceso de Excel se creó bajo Svchost.exe para que pudiera manejarse adecuadamente y evitar inestabilidades en el proceso WinWord.exe. Aunque este proceso está bajo Svchost.exe, hay otro desafío que enfrentar: ejecutar shellcode. Ya que la ejecución binaria o el uso de WinAPI dentro de una macro activará otras reglas ASR, esto limita lo que podemos hacer sin activar una regla ASR o ser detectados por el componente EDR de WDATP. Aquí es donde las DLL brillan. Si una carga útil basada en DLL se compila con las funciones de exportación adecuadas, se puede usar como un complemento de Office que, al cargarse, ejecutará automáticamente el shellcode. Para hacer esto, podemos utilizar la función RegisterXLL de Excel. La función RegisterXLL carga un complemento XLL en memoria, registrándolo automáticamente y ejecutándolo. Los archivos XLL son esencialmente DLL basadas en Excel.
Para obtener el contenido en el sistema, podemos usar otro objeto COM (Microsoft.XMLHTTP), obteniendo la capacidad de ejecutar una solicitud HTTP, en este caso, una solicitud HTTP GET a una URL. El segundo objeto COM (ADODB.stream) proporciona la capacidad de leer/escribir bytes de un flujo de datos. Combinando los dos objetos COM, un atacante puede solicitar un recurso remoto a través de una solicitud HTTP GET y escribir la respuesta (en este caso, el archivo en sí) en el disco. Esto se hace usando nuevamente el objeto COM (ADODB.stream) para manejar la lectura/escritura de bytes del flujo de datos. El segundo objeto COM (Microsoft.XMLDOM) permite la lectura de datos almacenados en un archivo. El objeto XMLDCOM permite establecer el tipo de datos (en este caso, base64) y una vez abierto y almacenado en una cadena con el tipo de datos adecuado, el objeto ADODB.stream puede escribir la cadena de código en el disco usando un tipo de datos diferente (en este caso, BinaryStreamType), convirtiendo la cadena base64 de nuevo a una forma binaria.
Para utilizar una carga útil de ScareCrow con este tipo de bypass, puede ejecutar el siguiente comando:
./ScareCrow -I <path to your raw stageless shellcode> -domain <domain name> -Loader excel -O <Output filename>
Una vez generado, copie las líneas 13 y 14 del archivo de salida, y combínelas, asegurándose de eliminar:
var <nombre de variable>; al final de cada línea
Una vez que tengas tu carga útil codificada, usa la bandera -N para el nombre de la carga útil cuando se escriba en disco, la bandera -U para la URL donde se alojará la carga útil codificada (por ejemplo, https:///), y la bandera -F para el nombre del archivo que está siendo alojado por el sitio. El código de salida está diseñado para funcionar en un documento de macro.
A través de una investigación adicional, se observó que no se trata de una brecha en los sensores de WDATP, sino que WDATP tiene visibilidad de esta actividad, pero se ignora. A través de la línea de tiempo de eventos del endpoint de WDATP buscando cualquier referencia a Appwiz.xll, observamos que WDAPT registró un evento de "archivo creado" cuando Word creó el archivo AppWiz.xll. Es importante tener en cuenta que los archivos .XLL son ejecutables.
11/20/2020 - Desarrollo de la investigación y artículo escrito.
03/14/2021 - Se proporcionó a Microsoft un documento de divulgación preliminar que describe los problemas identificados.
03/31/2021 - Microsoft reconoció y admitió que las vulnerabilidades relacionadas con la generación de un proceso hijo de Office y la escritura de archivos en disco eran vulnerabilidades reales y comenzó a trabajar en la corrección. Sin embargo, las inconsistencias de permisos en el registro no se consideraron una vulnerabilidad debido al requisito de privilegios elevados.
04/21/2021 - Microsoft informó al autor que la compilación de firmas 1.333.1055.0 lanzada el 03/22/2021 y la 1.335.1321.0 lanzada el 04/21/2021 contenían la detección de las vulnerabilidades basadas en aplicaciones de Office y cerró el caso.
04/22/2021 - El autor volvió a probar las mismas técnicas, identificando que las vulnerabilidades aún estaban presentes.