DropSpawn

Introdução

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.

Nota:

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.

Como Usar

1.

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.

2.

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...'.

3.

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.

4.

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.

5.

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.

Detecção

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:

Logs do MDE:

Com falsificação de PPID:

Sem falsificação de PPID:

Em ambos os casos, vemos nosso processo beacon original (também um werfault) colocar dbgcore.dll no disco, criar um novo processo WerFault.exe, o processo recém-gerado carregando dbgcore.dll e, em seguida, renomeando (excluindo) ele. Criticamente, não há escrutínio extra de dbgcore.dll que geralmente acompanha os sequestros de DLL, pois não estamos escrevendo em um local frequentemente sequestrado, e o WerFault.exe (ou qualquer processo que você escolher usar) não é realmente associado a sequestros de DLL da mesma forma que coisas como WmiPrvSE.exe.

Curiosamente, é quase mais visível fazer isso com falsificação de PPID do que sem. Isso pode variar dependendo do produto de segurança, no entanto.

Limitações

Como mencionado, é essencial que os usuários baixem as DLLs reais da máquina alvo onde planejam usar o DropSpawn. Usar a versão errada de uma DLL pode resultar na falha do processo gerado se ele tentar chamar uma função que não existe.

O DropSpawn pode ser usado com executáveis fora do System32; no entanto, esteja avisado de que podem surgir problemas se o processo tentar carregar DLLs adicionais do diretório de aplicativo verdadeiro do processo. Como falsificamos o diretório de aplicativo em outro lugar, se o diretório de aplicativo real não estiver também acessível através da ordem de pesquisa de DLL, o processo falhará/não iniciará porque não consegue localizar DLLs essenciais. Sempre teste possíveis sequestros em máquinas de desenvolvimento antes de usá-los em produção!

Créditos

Esta pesquisa surgiu enquanto eu explorava como os processos montam sua ordem final de pesquisa de DLL (já que deve ser determinada em tempo de execução devido aos executáveis residirem em diretórios diferentes, o diretório atual fazer parte do caminho de pesquisa, etc). Minha pesquisa me levou a este post de fórum, que serviu como origem das duas APIs críticas não documentadas que são centrais para esta técnica.

Eles já estão linkados anteriormente, mas este post sobre como evitar o bloqueio do carregador, este script para gerar um arquivo .def para proxy de DLL e esta pesquisa sobre como habilitar a auto-exclusão de executáveis em execução são essenciais para produzir DLLs de payload eficazes e armadas adequadas para o DropSpawn.

Quando publiquei esta técnica pela primeira vez no Twitter, vários outros se juntaram à conversa e produziram POCs. SecurityAndStuff produziu este, enquanto Snovvcrash tem o seu aqui