gmh5225/cs-dropspawn_bofCobaltStrike BOF para lanzar Beacons mediante el secuestro del directorio de aplicaciones DLL
DropSpawn es un BOF de CobaltStrike utilizado para lanzar Beacons adicionales mediante un método relativamente desconocido de secuestro de DLL. Funciona en 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 al intentar 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 mayor precedencia en el orden de búsqueda 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 puede colocarse en una carpeta escribible por el usuario dentro de 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) falsificando "El directorio desde el cual se carga la aplicación" a 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 aprovecha un generador de payloads propietario, lo que hace que la experiencia sea mucho más fluida para el operador. La versión pública ha sido modificada ligeramente para tener en cuenta que los usuarios tendrán sus propias formas de generar payloads compatibles con el secuestro de DLL. Se ha incluido 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 intenten cargar DLL sin especificar sus rutas absolutas. Puedes hacerlo copiando el exe en un directorio escribible por el usuario y ejecutándolo mientras lo monitoreas 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 todos 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 normalmente no es una preocupación porque el directorio de aplicación de WerFault ES System32.
Descarga una de las DLL secuestrables del sistema objetivo.
Esto es necesario para que podamos 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 lanzado intente llamar a una función real dentro de la DLL falsificada, nuestra DLL de payload reenviará la llamada a la DLL real ubicada en System32 para que el proceso anfitrión no se bloquee.
Llama a dropspawn usando la DLL de payload generada.
dropspawn <payload DLL> <x86|x64> <programa a lanzar> [carpeta objetivo escribible] [proceso padre]
payload DLL - la ruta completa a la DLL de payload generada. arquitectura - la arquitectura del proceso que deseas lanzar programa a lanzar - el nombre/ruta del proceso que deseas lanzar. Si este proceso reside en System32 (o syswow64), puedes simplemente especificar 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. carpeta objetivo escribible - Opcional. Si se deja en blanco, dropspawn intentará usar el directorio actual del Beacon. Usa comillas si hay espacios en la ruta. proceso padre - Opcional. El nombre del proceso a usar para la falsificación de PPID con el proceso recién lanzado. Si se especifica un proceso que tiene múltiples instancias en ejecución con diferentes niveles de privilegios (es decir, svchost.exe), dropspawn intentará identificar una que pueda usarse para la falsificación de PPID.
Ejemplo: dropspawn /root/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 de Auto-Eliminación 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 de juego, ya que normalmente la DLL estaría bloqueada en disco mientras nuestro proceso que la cargó continúe ejecutándose. Si la técnica de Auto-Eliminación falla por alguna razón (o el proceso no logra lanzarse), 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 típicamente sigue la cadena de abrir proceso remoto -> asignar memoria remota -> escribir memoria remota -> ejecutar memoria remota, con la opción de lanzar un nuevo proceso al principio en lugar de usar uno existente. DropSpawn solo crea un nuevo proceso; el proceso recién lanzado es responsable de asignar, escribir y ejecutar el shellcode, por lo que podemos evitar muchos de los IOC típicamente asociados con la inyección de procesos remotos.
Esta técnica está, por supuesto, a merced de qué tan buenas 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 el lanzamiento de 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 falsificación de PPID:
Sin falsificación de PPID:
En ambos casos vemos nuestro proceso beacon original (también un werfault) colocar dbgcore.dll en disco, crear un nuevo proceso WerFault.exe, el proceso recién lanzado cargando dbgcore.dll, y luego renombrándola (eliminándola). Críticamente, no hay un escrutinio adicional de dbgcore.dll que a menudo viene con los secuestros de DLL porque no la estamos escribiendo en ninguna ubicación frecuentemente secuestrada, y WerFault.exe (o cualquier proceso que elijas usar) no está realmente asociado con secuestros de DLL de la misma manera que cosas como WmiPrvSE.exe.
Curiosamente, es casi más visible hacer esto con falsificación de PPID que sin ella. Sin embargo, esto puede variar dependiendo del 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 resultar en que el proceso lanzado se bloquee si intenta llamar a una función que no existe.
DropSpawn puede usarse con ejecutables fuera de System32; sin embargo, ten en cuenta que pueden surgir problemas si el proceso intenta cargar DLL adicionales desde el verdadero directorio de aplicación del proceso. Debido a que hemos falsificado el directorio de aplicación en otro lugar, si el directorio de aplicación real tampoco es alcanzable a través del orden de búsqueda de DLL de otra manera, el proceso se bloqueará/fallará al iniciar porque no puede localizar DLL esenciales. ¡Siempre prueba los secuestros potenciales en máquinas de desarrollo antes de usarlos en producción!
Esta investigación surgió por primera vez mientras exploraba cómo los procesos ensamblan su orden final de búsqueda de DLL (ya que debe determinarse en tiempo de ejecución debido a que los ejecutables residen en diferentes directorios, el directorio actual siendo parte de la ruta de búsqueda, etc.). Mi investigación me llevó a esta publicación del foro, que sirvió como origen de las dos API no documentadas críticas que son centrales para esta técnica.
Ya están enlazadas anteriormente, pero esta publicación sobre cómo evitar el bloqueo del loader, este script para generar un archivo .def para el proxy de DLL, y esta investigación sobre cómo habilitar la auto-eliminació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í
