donut

Versión actual: v1.1

Índice de contenidos

1. Introducción
2. Cómo funciona
3. Compilación
4. Uso
5. Subproyectos
6. Desarrollo con Donut
7. Preguntas y discusiones
8. Aviso legal

1. Introducción

Donut es un código independiente de la posición que permite la ejecución en memoria de archivos VBScript, JScript, EXE, DLL y ensamblados .NET. Un módulo creado por Donut puede ser servido desde un servidor HTTP o incrustado directamente en el propio cargador. El módulo está opcionalmente cifrado usando el cifrador de bloque Chaskey y una clave de 128 bits generada aleatoriamente. Después de que el archivo se cargue y ejecute en memoria, la referencia original se borra para disuadir a los escáneres de memoria. El generador y cargador soportan las siguientes características:

• Compresión de archivos de entrada con aPLib y LZNT1, Xpress, Xpress Huffman mediante RtlCompressBuffer.
• Uso de entropía para hashes de API y generación de cadenas.
• Cifrado simétrico de 128 bits de archivos.
• Sobrescritura de cabeceras PE nativas.
• Almacenamiento de PE nativos en memoria MEM_IMAGE.
• Parcheo de la Interfaz de Escaneo Antimalware (AMSI) y la Política de Bloqueo de Windows (WLDP).
• Parcheo de Seguimiento de Eventos para Windows (ETW).
• Parcheo de la línea de comandos para archivos EXE.
• Parcheo de API relacionadas con la salida para evitar la terminación del proceso anfitrión.
• Múltiples formatos de salida: C, Ruby, Python, PowerShell, Base64, C#, Hexadecimal y cadena UUID.

Hay bibliotecas dinámicas y estáticas tanto para Linux como para Windows que se pueden integrar en tus propios proyectos. También hay un módulo de Python del que puedes leer más en Construcción y uso de la extensión Python.

2. Cómo funciona

Donut contiene cargadores individuales para cada tipo de archivo soportado. Para ensamblados .NET EXE/DLL, Donut utiliza la API de Alojamiento CLR No Administrada para cargar el Common Language Runtime. Una vez que el CLR se carga en el proceso anfitrión, se crea un nuevo Dominio de Aplicación para permitir la ejecución de Ensamblados en AppDomains desechables. Cuando el AppDomain está listo, el ensamblado .NET se carga mediante el método AppDomain.Load_3. Finalmente, se invoca el Punto de Entrada para EXEs o el método público para DLLs especificado por el usuario con cualquier parámetro adicional. Consulte MSDN para obtener documentación sobre la API de Alojamiento CLR No Administrada. Para un ejemplo independiente de un Host CLR, consulte el código aquí.

Los archivos VBScript y JScript se ejecutan utilizando la interfaz IActiveScript. También hay soporte mínimo para algunos de los métodos proporcionados por el Host de Scripts de Windows (wscript/cscript). Para un ejemplo independiente, consulte el código aquí. Para una descripción más detallada, lea: Ejecución en Memoria de JavaScript, VBScript, JScript y XSL

Los archivos EXE/DLL no administrados o nativos se ejecutan utilizando un cargador PE personalizado con soporte para Importaciones Retrasadas, TLS y parcheo de la línea de comandos. Solo se admiten archivos con información de reubicación. Lea Ejecución en Memoria de DLL para más información.

El cargador puede deshabilitar AMSI y WLDP para ayudar a evadir la detección de archivos maliciosos ejecutados en memoria. Para más información, lea Cómo los Red Teams evaden AMSI y WLDP para Código Dinámico .NET. También soporta la descompresión de archivos en memoria usando aPLib o la API RtlDecompressBuffer. Lea Compresión de Datos para más información.

A partir de v1.0, ETW también se evita. Al igual que con AMSI/WLDP, este es un sistema modular que te permite intercambiar la evasión predeterminada por la tuya propia. La evasión predeterminada se deriva de la investigación de XPN. Lea Ocultando tu .NET - ETW para más información.

Por defecto, el cargador sobrescribirá las cabeceras PE de los PE no administrados (desde la dirección base hasta `IMAGE_OPTIONAL_HEADER.SizeOfHeaders`). Si no se utiliza un módulo señuelo (sobrecarga de módulos), las cabeceras PE se pondrán a cero. Si se utiliza un módulo señuelo, las cabeceras PE del módulo señuelo se usarán para sobrescribir las del módulo de carga útil. Esto es para disuadir la detección comparando las cabeceras PE de los módulos en memoria con el archivo que los respalda en disco. El usuario puede solicitar que todas las cabeceras PE se conserven en su estado original. Esto es útil para escenarios donde el módulo de carga útil necesita acceder a sus cabeceras PE, como cuando se buscan recursos PE incrustados.

Para un recorrido detallado usando el generador y cómo Donut afecta el arte operativo, lea Donut - Inyectando Ensamblados .NET como Shellcode. Para más información sobre el cargador, lea Cargando Ensamblados .NET desde Memoria.

Aquellos que deseen saber más sobre el funcionamiento interno deben consultar las Notas de desarrollo.

3. Compilación

Hay dos tipos de compilación. Si deseas depurar Donut, consulta la documentación aquí. Si no, continúa leyendo para la compilación de lanzamiento.

Clonar

Desde una ventana de comandos de Windows o terminal Linux, clona el repositorio.

 
  git clone http://github.com/thewover/donut.git

El siguiente paso depende de tu sistema operativo y del compilador que decidas usar. Actualmente, la plantilla del generador y del cargador para Donut se puede compilar correctamente tanto con Microsoft Visual Studio 2019 como con MingGW-64. Para usar las bibliotecas en tu propio proyecto C/C++, consulta los ejemplos proporcionados aquí.

Windows

Para generar la plantilla del cargador, la biblioteca dinámica donut.dll, la biblioteca estática donut.lib y el generador donut.exe. Inicia un Símbolo del sistema para desarrolladores de Microsoft Visual Studio x64, cambia al directorio donde clonaste el repositorio de Donut e ingresa lo siguiente:

  nmake -f Makefile.msvc

Para hacer lo mismo, excepto usando MinGW-64 en Windows o Linux, cambia al directorio donde clonaste el repositorio de Donut e ingresa lo siguiente:

  make -f Makefile.mingw

Linux

Para generar la biblioteca dinámica donut.so, la biblioteca estática donut.a y el generador donut. Cambia al directorio donde clonaste el repositorio de Donut y simplemente escribe make.

Módulo Python

Donut se puede instalar y usar como un módulo de Python. Para instalar desde el código fuente se requiere pip para Python3. Primero, asegúrate de que las versiones anteriores de donut-shellcode no estén instaladas ejecutando el siguiente comando en una terminal Linux o en el símbolo del sistema de Microsoft Visual Studio.

  pip3 uninstall donut-shellcode

Después de confirmar que las versiones anteriores ya no están instaladas, ejecuta el siguiente comando.

  pip3 install .

También puedes instalar Donut como un módulo de Python obteniéndolo del repositorio PyPi.

  pip3 install donut-shellcode

Para más información, consulta Construcción y uso de la extensión Python.

Docker

Construir el contenedor Docker.

  docker build -t donut .

Ejecutar Donut.

  docker run -it --rm -v "${PWD}:/workdir" donut -h

Herramientas de soporte

Donut incluye varios otros ejecutables que pueden compilarse por separado. Estos incluyen "hash.exe", "encrypt.exe", "inject.exe" e "inject_local.exe". Los dos primeros se utilizan en la generación de shellcode. Los dos últimos se proporcionan para ayudar a probar el shellcode de Donut. "inject.exe" inyectará un archivo binario sin procesar (loader.bin) en un proceso por su PID o nombre de proceso. "inject_local.exe" inyectará un archivo binario sin procesar en su propio proceso.

Para compilar estos ejecutables de soporte por separado, puedes usar el makefile de MSVC. Por ejemplo, para compilar "inject_local.exe" para probar tu shellcode de Donut, puedes ejecutar.

  nmake inject_local -f Makefile.msvc

Lanzamientos

Se han proporcionado etiquetas para cada versión de lanzamiento de Donut que contienen los ejecutables compilados.

• v0.9.3, TBD
• v0.9.2, Bear Claw
• v0.9.1, Apple Fritter
• v0.9.0, Lanzamiento inicial

Actualmente, hay otros dos generadores disponibles.

• Generador C# por n1xbyte
• Generador Go por awgh

4. Uso

La siguiente tabla enumera los modificadores compatibles con la versión de línea de comandos del generador.

Requisitos de la carga útil

Hay algunos requisitos específicos que tu carga útil debe cumplir para que Donut pueda cargarla correctamente.

Ensambleados .NET

• El método de punto de entrada solo debe aceptar cadenas como argumentos, o no aceptar argumentos.
• El método de punto de entrada debe estar marcado como público y estático.
• La clase que contiene el método de punto de entrada debe estar marcada como pública.
• El ensamblado NO debe ser un Ensamblado Mixto (que contenga código administrado y nativo).
• Como tal, el ensamblado NO debe contener Exportaciones No Administradas.

EXE/DLL nativos

• Los binarios compilados con Cygwin no son compatibles.

Los ejecutables de Cygwin usan rutinas de inicialización que esperan que el proceso anfitrión se ejecute desde el disco. Si se ejecuta desde la memoria, es probable que el proceso anfitrión falle.

DLLs no administrados

• Un método de punto de entrada especificado por el usuario solo debe aceptar una cadena como argumento, o no aceptar argumentos. Hemos proporcionado un ejemplo.

5. Subproyectos

Hay cuatro proyectos complementarios proporcionados con Donut:

6. Desarrollo con Donut

Es posible que desees agregar soporte para más tipos de cargas útiles, cambiar nuestro conjunto de características o integrar Donut en tus herramientas existentes. Hemos proporcionado documentación para desarrolladores. Las características adicionales se dejan como ejercicios para el lector. Nuestras sugerencias:

• Agregar clave ambiental.
• Hacer Donut polimórfico ofuscando el cargador cada vez que se genera shellcode.
• Integrar Donut como módulo en tu framework RAT/C2 favorito.

7. Preguntas y discusiones

Si tienes alguna pregunta o comentario sobre Donut, únete al canal #Donut en el Slack de BloodHound Gang.

8. Aviso legal

No somos responsables del mal uso de este software o técnica. Donut se proporciona como una demostración de Inyección CLR y carga en memoria a través de shellcode para proporcionar a los equipos rojos una forma de emular adversarios y a los defensores un marco de referencia para construir análisis y mitigaciones. Esto inevitablemente corre el riesgo de que los autores de malware y actores de amenazas lo utilicen de manera indebida. Sin embargo, creemos que el beneficio neto supera el riesgo. Con suerte, eso es correcto. En caso de que los productos EDR o AV sean capaces de detectar Donut mediante firmas o patrones de comportamiento, no actualizaremos Donut para contrarrestar firmas o métodos de detección. Para evitar ofenderse, por favor no preguntes.