DSCourier BOF

Esta es una implementación BOF del proyecto DSCourier de Dylan Davis y Matthew Schramm. Utiliza la interfaz COM de WinGet para ejecutar código arbitrario de PowerShell en un proceso firmado y de confianza de Microsoft. Su blog de investigación completo se encuentra aquí.

A diferencia de la mayoría de los proyectos que publico, esto NO es una herramienta operativamente lista, sino más bien una POC. Decidí no continuar con esto después de descubrir varios problemas que impiden que sea un BOF fácilmente desplegable. El código fue casi totalmente improvisado. Varios problemas permanecen sin resolver y se discuten a continuación.

Uso

Coloca tu código arbitrario de PowerShell en el archivo dist/rev.yml. Por defecto contiene un simple reverse shell de PowerShell del repositorio original. Si decides usarlo, asegúrate de reemplazar la IP en el ejemplo existente con tu IP deseada.

Ejemplo usando el reverse shell de PowerShell:

Cómo funciona / Limitaciones

Sin un orden particular, aquí hay algunos problemas/limitaciones de esta herramienta.

1. Para que las llamadas COM tengan éxito, el archivo Microsoft.Management.Configuration.winmd debe estar presente en el mismo directorio que el ejecutable que realiza las llamadas COM. Esto representa un problema inmediato al ejecutar un Beacon desde un proceso de system32 vaciado, por ejemplo, donde los usuarios normales no tienen permisos de escritura. Para solucionarlo, el archivo se coloca en %APPDATA%\temp y se engancha la función WinTypes!RoGetMetaDataFile que recupera la ruta del archivo winmd con un inline hook para poder proporcionar la ubicación temporal. Esto permite que el archivo winmd sea leído/las llamadas COM tengan éxito, pero implica llamadas a VirtualProtect y sobrescritura de memoria de DLL, lo que genera IOCs.
2. Como consecuencia de #1, el archivo winmd queda bloqueado en disco después de ejecutar el BOF hasta que el proceso del Beacon termine. Experimenté un poco para intentar resolverlo, incluyendo agregar la funcionalidad de autoeliminación que es bien conocida en este punto, pero el archivo permaneció bloqueado en disco. Quizás se pueda ingeniar una solución, pero eso queda para que alguien más lo investigue.
3. Como se mencionó en la investigación original, debido a que esto utiliza el recurso pwsh dentro de WinGet, se genera un proceso conhost.exe bajo ConfigurationRemotingServer.exe. Claude sugirió que sería posible cargar un módulo binario personalizado como recurso en lugar de invocar pwsh, lo que resolvería el problema de conhost, pero esto requiere colocar archivos adicionales en disco y no pude hacerlo funcionar. Quizás no sea posible. Si lo fuera, abriría la puerta a colocar un DLL .NET genérico en disco que podría ser cargado por y ejecutar shellcode/parámetros/etc. pasados.

Compilación

Esta herramienta fue escrita sin el uso de declaraciones normales de API de BOF (por ejemplo, un archivo bofdefs.h). Como se describe en este artículo de blog de Matt Ehrnschwender, es posible usar objcopy para parchear los símbolos correctos con el formato DLL$API en el BOF después de la compilación.

He escrito una herramienta llamada BOFPatcher que automatiza este proceso. Esto permite a los usuarios escribir BOFs como C normal sin preocuparse por engorrosas declaraciones de API:

Esta herramienta está disponible para quienes compren mi curso BOF Development and Tradecraft.

Aunque la herramienta BOFPatcher no está incluida en este repositorio, el Makefile de esta herramienta llama a objcopy, pasando un archivo imports_dscourier64.txt que contiene los reemplazos de símbolos adecuados, lo que hace que el BOF sea utilizable.

Créditos

1. Gran trabajo de Dylan y Matt. ¡Espero ver más de ellos!
2. Claude por improvisar la mayor parte de esto.