octoberfest7/dropspawn_bofCobaltStrike BOF para generar Beacons usando DLL Application Directory Hijacking
DropSpawn es un BOF de CobaltStrike utilizado para lanzar Beacons adicionales mediante un método relativamente desconocido de secuestro de DLL. Funciona x86-x86, x64-x64, y x86-x64/viceversa. Úsalo como alternativa a la inyección de procesos.
Los ejecutables de Windows seguirán el orden de búsqueda de DLL cuando intenten cargar DLL cuyas rutas absolutas no fueron especificadas:
El secuestro de DLL normalmente requiere que:
A. Un usuario tenga permisos de escritura en una carpeta con un orden de precedencia de búsqueda mayor que donde reside la DLL real
o
B. Que la DLL en cuestión no exista en ningún lugar del sistema, en cuyo caso se puede colocar en una carpeta escribible por el usuario en la variable %PATH% del usuario (como %USERPROFILE%\appdata\local\microsoft\windowsapps).
Estos requisitos descartan el secuestro de DLL para ejecutables que residen en C:\Windows\System32 porque casi todas las DLL que cargan estos ejecutables también residen en System32. Copiar un ejecutable de System32 a una ubicación escribible por el usuario y ejecutarlo allí es una opción, pero no es muy segura desde el punto de vista OPSEC porque los binarios de System32 que se ejecutan desde ubicaciones alternativas son fáciles de identificar.
DropSpawn permite el secuestro de DLL utilizando ejecutables de System32 (y otros encontrados en carpetas adicionales no escribibles por el usuario) suplantando "El directorio desde el que se carga la aplicación" por uno arbitrario especificado por el usuario.
La versión pública de DropSpawn difiere ligeramente de la no pública. La versión no pública utiliza un generador de payloads propietario, lo que hace que la experiencia sea mucho más fluida para el operador. La versión pública se ha modificado ligeramente para tener en cuenta que los usuarios tendrán sus propias formas de generar payloads compatibles con el secuestro de DLL. Se incluye un script de Python3 así como el código fuente de una DLL de demostración para ayudar a los usuarios a integrar y weaponizar DropSpawn.
Identifica algunos ejecutables objetivo que intentan cargar DLL sin especificar sus rutas absolutas. Puedes hacerlo copiando el exe en un directorio escribible por el usuario y ejecutándolo mientras lo monitorizas con Procmon. En este ejemplo usaremos WerFault.exe que normalmente reside en C:\Windows\System32\WerFault.exe
En el ejemplo anterior, cryptsp.dll, wer.dll, dbghelp.dll y bcrypt.dll son candidatos viables porque sus rutas absolutas no fueron especificadas dentro de WerFault; como resultado, WerFault intentará cargarlos desde su directorio de aplicación primero antes de recurrir al resto del orden de búsqueda de DLL. Ten en cuenta que esto no suele ser un problema porque el directorio de aplicación de WerFault ES System32.
Descarga una de las DLL secuestrables del sistema objetivo.
Esto es necesario para poder extraer sus exportaciones e incluirlas en nuestra DLL de payload. Es importante obtener la DLL secuestrable de la misma máquina en la que deseas usar DropSpawn, ya que las DLL cambian entre versiones de Windows. Además, si estás ejecutando un beacon x86 y deseas lanzar un beacon x64 usando DropSpawn, asegúrate de descargar la versión x64 de la DLL real especificando 'C:\windows\sysnative...' en lugar de 'C:\windows\system32...'.
Ejecuta generate_dll.py, pasando la DLL descargada y la arquitectura de payload deseada. Generate_dll.py es una versión modificada de este script. Analizará la DLL proporcionada, creará un archivo .def que contiene las exportaciones de la DLL y llamará a MingW para compilar nuestra DLL de payload de demostración. Cuando el proceso generado intente llamar a una función real dentro de la DLL suplantada, nuestra DLL de payload redirigirá la llamada a la DLL real ubicada en System32 para que el proceso anfitrión no falle.
Llama a dropspawn usando la DLL de payload generada.
dropspawn <payload DLL> <x86|x64> <program to spawn> [writable target folder] [parent]
payload DLL - la ruta completa a la DLL de payload generada.
architecture - la arquitectura del proceso que deseas lanzar
program to spawn - el nombre/ruta del proceso que deseas lanzar. Si este proceso reside en System32 (o syswow64), puedes especificar solo el nombre. De lo contrario, especifica la ruta completa. También puedes proporcionar argumentos de línea de comandos al proceso. Si hay espacios en la ruta/si usas argumentos, envuelve todo entre comillas.
writable target folder - Opcional. Si se deja en blanco, dropspawn intentará usar el directorio actual del Beacon. Usa comillas si hay espacios en la ruta.
parent - Opcional. El nombre del proceso a utilizar para el spoofing de PPID con el proceso recién lanzado. Si se especifica un proceso que tiene múltiples instancias en ejecución de diferentes niveles de privilegio (por ejemplo, svchost.exe), dropspawn intentará identificar una que pueda usarse para el spoofing de PPID.
Ejemplo: dropspawn /root/gitlab/DropSpawn_BOF/dist/dbgcore.dll x64 "WerFault.exe -u -p 4352 -s 160" C:\users\user\appdata\local\temp explorer.exe
Esto colocará la DLL de payload 'dbgcore.dll' en disco en 'c:\users\user\appdata\local\temp\dbgcore.dll' y lanzará un proceso WerFault.exe x64 con los argumentos de línea de comandos '-u -p 4352 -s 160' y explorer.exe como proceso padre.
La limpieza es fácil. Al incluir la función Self-Deletion en la DLL de payload que se coloca en disco, se eliminará tan pronto como nuestro nuevo proceso se lance y la cargue. Esto es un cambio radical, ya que normalmente la DLL estaría bloqueada en disco mientras el proceso que la cargó continúe ejecutándose. Si la técnica de Self-Deletion falla por alguna razón (o el proceso no se lanza), DropSpawn intentará eliminar la DLL de payload del disco e informará al usuario del resultado de la operación en cualquier caso.
La inyección de procesos normalmente sigue la cadena: abrir proceso remoto -> asignar memoria remota -> escribir memoria remota -> ejecutar memoria remota, con la opción de lanzar un nuevo proceso al inicio en lugar de usar uno existente. DropSpawn solo crea un nuevo proceso; el proceso recién lanzado es responsable de asignar, escribir y ejecutar shellcode, por lo que podemos evitar muchos de los IOC típicamente asociados con la inyección remota de procesos.
Esta técnica, por supuesto, depende de lo buenas que sean tus DLL de payload. Pero podemos echar un vistazo a lo que Windows ve (esta siguiente sección usa la versión privada de DropSpawn y lanza Beacons).
En lo que respecta al Visor de eventos, todo parece normal:
En MDE hay muy poco que ver.
Ejecutando dropspawn:
Registros de MDE:
Con spoofing de PPID:
Sin spoofing de PPID:
En ambos casos vemos que nuestro proceso beacon original (también un werfault) coloca dbgcore.dll en disco, crea un nuevo proceso WerFault.exe, el proceso recién lanzado carga dbgcore.dll, y luego lo renombra (elimina). Críticamente, no hay un escrutinio adicional de dbgcore.dll que a menudo viene con los secuestros de DLL porque no lo estamos escribiendo en ninguna ubicación comúnmente secuestrada, y WerFault.exe (o cualquier proceso que elijas usar) no está realmente asociado con secuestros de DLL de la misma manera que elementos como WmiPrvSE.exe.
Curiosamente, es casi más visible hacer esto con spoofing de PPID que sin él. Sin embargo, esto puede variar según el producto de seguridad.
Como se mencionó, es esencial que los usuarios descarguen las DLL reales de la máquina objetivo en la que planean usar DropSpawn. Usar la versión incorrecta de una DLL puede provocar que el proceso lanzado falle si intenta llamar a una función que no existe.
DropSpawn se puede usar con ejecutables fuera de System32; sin embargo, ten en cuenta que pueden surgir problemas si el proceso intenta cargar DLL adicionales desde el directorio de aplicación real del proceso. Debido a que hemos suplantado el directorio de aplicación en otro lugar, si el directorio de aplicación real no es accesible a través del orden de búsqueda de DLL de otra manera, el proceso fallará/no se iniciará porque no puede localizar DLL esenciales. ¡Siempre prueba los posibles secuestros en máquinas de desarrollo antes de usarlos en producción!
Esta investigación surgió mientras exploraba cómo los procesos ensamblan su orden de búsqueda final de DLL (ya que debe determinarse en tiempo de ejecución debido a que los ejecutables residen en diferentes directorios, el directorio actual es parte de la ruta de búsqueda, etc). Mi investigación me llevó a este mensaje del foro, que sirvió como origen de las dos API críticas no documentadas que son centrales para esta técnica.
Ya están enlazados anteriormente, pero esta publicación sobre cómo evitar el bloqueo del cargador, este script para generar un archivo .def para proxy de DLL y esta investigación sobre cómo habilitar la autoeliminación de ejecutables en ejecución son esenciales para producir payloads DLL efectivos y weaponizados adecuados para DropSpawn.
Cuando publiqué por primera vez esta técnica en Twitter, varios otros se unieron a la conversación y produjeron POC. SecurityAndStuff produjo este, mientras que Snovvcrash tiene el suyo aquí.
