octoberfest7/dropspawn_bofCobaltStrike BOF para gerar Beacons usando sequestro de diretório de aplicação DLL
O DropSpawn é um BOF do CobaltStrike usado para gerar Beacons adicionais através de um método relativamente desconhecido de sequestro de DLL. Funciona x86-x86, x64-x64 e x86-x64/vice-versa. Use como alternativa à injeção de processo.
Os executáveis do Windows seguirão a ordem de pesquisa de DLL ao tentar carregar DLLs cujos caminhos absolutos não foram especificados:
O sequestro de DLL normalmente exige que:
A. Um usuário tenha permissões de escrita em uma pasta com precedência de ordem de pesquisa maior do que onde a DLL real reside
ou
B. Que a DLL em questão não exista em nenhum lugar do sistema, caso em que pode ser colocada em uma pasta gravável pelo usuário na variável %PATH% do usuário (como %USERPROFILE%\appdata\local\microsoft\windowsapps).
Esses requisitos descartam o sequestro de DLL para executáveis que residem em C:\Windows\System32, porque quase todas as DLLs que esses executáveis carregam também residem em System32. Copiar um executável do System32 para um local gravável pelo usuário e executá-lo lá é uma opção, mas não é muito seguro do ponto de vista OPSEC, pois binários do System32 sendo executados de locais alternativos são fáceis de identificar.
O DropSpawn permite o sequestro de DLL usando executáveis do System32 (e outros encontrados em pastas adicionais não graváveis pelo usuário) ao falsificar o "Diretório a partir do qual o aplicativo é carregado" para um arbitrário especificado pelo usuário.
A versão pública do DropSpawn difere ligeiramente da não pública. A versão não pública utiliza um gerador de payload proprietário, tornando a experiência muito mais fluida para o operador. A versão pública foi alterada ligeiramente para considerar que os usuários terão suas próprias maneiras de gerar payloads compatíveis com sequestro de DLL. Um script Python3, bem como o código-fonte para uma DLL de demonstração, foram incluídos para ajudar os usuários a integrar e armar o dropspawn.
Identifique alguns executáveis alvo que tentam carregar DLLs sem especificar seus caminhos absolutos. Você pode fazer isso copiando o exe para um diretório gravável pelo usuário e executando-o enquanto o monitora com o Procmon. Neste exemplo, usaremos o WerFault.exe que normalmente reside em C:\Windows\System32\WerFault.exe
No exemplo acima, cryptsp.dll, wer.dll, dbghelp.dll e bcrypt.dll são todos candidatos viáveis porque seus caminhos absolutos não foram especificados dentro do WerFault; como resultado, o WerFault tentará carregá-los do seu diretório de aplicativo primeiro antes de recorrer ao restante da ordem de pesquisa de DLL. Observe que isso normalmente não é uma preocupação porque o diretório de aplicativo do WerFault É System32.
Baixe uma das DLLs sequestráveis do sistema alvo.
Isso é necessário para que possamos extrair suas exportações e incluí-las em nossa DLL de payload. É importante pegar a DLL sequestrável da mesma máquina em que você pretende usar o DropSpawn, pois as DLLs mudam entre versões do Windows. Além disso, se você estiver executando um beacon x86 e quiser gerar um beacon x64 usando o DropSpawn, certifique-se de baixar a versão x64 da DLL real especificando 'C:\windows\sysnative...' em vez de 'C:\windows\system32...'.
Execute generate_dll.py, passando a DLL baixada e a arquitetura de payload desejada. O generate_dll.py é uma versão modificada deste script. Ele irá analisar a DLL fornecida, criar um arquivo .def contendo as exportações da DLL e chamar o MingW para compilar nossa DLL de payload de demonstração. Quando o processo gerado tentar chamar uma função real dentro da DLL falsificada, nossa DLL de payload encaminhará a chamada para a DLL real localizada em System32 para que o processo hospedeiro não falhe.
Chame dropspawn usando a DLL de payload gerada.
dropspawn <payload DLL> <x86|x64> <program to spawn> [writable target folder] [parent]
payload DLL - o caminho completo para a DLL de payload gerada.
architecture - a arquitetura do processo que deseja gerar
program to spawn - o nome/caminho do processo que deseja gerar. Se este processo residir em System32 (ou syswow64), você pode apenas especificar o nome. Caso contrário, especifique o caminho completo. Você também pode fornecer argumentos de linha de comando para o processo. Se houver espaços no caminho/se você usar argumentos, coloque tudo entre aspas.
writable target folder - Opcional. Se deixado em branco, o dropspawn tentará usar o diretório atual do Beacon. Use aspas se houver espaços no caminho.
parent - Opcional. O nome do processo a ser usado para falsificação de PPID com o processo recém-gerado. Se for especificado um processo que tenha múltiplas instâncias em execução com diferentes níveis de privilégio (ex.: svchost.exe), o dropspawn tentará identificar uma que possa ser usada para falsificação de PPID.
Exemplo: dropspawn /root/gitlab/DropSpawn_BOF/dist/dbgcore.dll x64 "WerFault.exe -u -p 4352 -s 160" C:\users\user\appdata\local\temp explorer.exe
Isso irá colocar a DLL de payload 'dbgcore.dll' no disco em 'c:\users\user\appdata\local\temp\dbgcore.dll' e gerar um processo WerFault.exe x64 com os argumentos de linha de comando '-u -p 4352 -s 160' e explorer.exe como processo pai.
A limpeza é fácil. Ao incluir a função Self-Deletion na DLL de payload que é colocada no disco, ela será excluída assim que nosso novo processo for gerado e a carregar. Isso é um divisor de águas, pois normalmente a DLL ficaria bloqueada no disco enquanto o processo que a carregou continuasse em execução. Se a técnica de Self-Deletion falhar por algum motivo (ou o processo falhar ao ser gerado), o DropSpawn tentará excluir a DLL de payload do disco e informará o usuário sobre o resultado da operação de qualquer forma.
A injeção de processo normalmente segue a cadeia abrir processo remoto -> alocar memória remota -> escrever memória remota -> executar memória remota, com a opção de gerar um novo processo no início em vez de usar um existente. O DropSpawn apenas cria um novo processo; o processo recém-gerado é responsável por alocar, escrever e executar shellcode, então podemos evitar muitos dos IOCs normalmente associados à injeção remota de processo.
Esta técnica está, é claro, à mercê da qualidade de suas DLLs de payload. Mas podemos dar uma olhada no que o Windows vê (esta próxima seção usa a versão privada do DropSpawn e geração de Beacons).
No que diz respeito ao Visualizador de Eventos, tudo parece normal:
No MDE há muito pouco para ver.
Executando dropspawn:
