nccgroup/async-pico-hubAsync PICO Hub is a work-in-progress framework to extend Cobalt Strike with custom event monitoring and in-process Asynchronous BOFs
Async PICOs é um framework para executar Beacon Object Files de longa duração e orientados a eventos dentro de um processo Beacon do Cobalt Strike. Ele fornece execução assíncrona, rastreamento de tarefas, encerramento gracioso e saída assíncrona segura ao combinar os PICOs do Crystal Palace com um modelo de execução no lado do Beacon.
Ao contrário dos BOFs assíncronos nativos do Cobalt Strike, os Async PICOs executam no processo do Beacon e podem acordar o Beacon para exibir a saída quando eventos ocorrem.
Os BOFs assíncronos nativos do Cobalt Strike resolvem um problema diferente. Os Async PICOs são destinados a tarefas de longa duração e orientadas a eventos que executam dentro do Beacon e podem comunicar resultados com segurança imediatamente de volta ao operador.
Para detalhes de implementação e justificativa do design, consulte a postagem do blog associada:
https://www.nccgroup.com/research/async-picos-and-custom-beacon-wakeups-in-cobalt-strike/
Antes de compilar, os seguintes componentes são necessários:
Um checkout local deste repositório
Uma versão compilada do Crystal Palace
Visual Studio com suporte a MSVC e CMake
Tradecraft Garden
Clone o repositório
git clone <repo-url>
cd async-pico-hub
Os Async PICOs dependem do Crystal Palace para a geração de PICOs.
Baixe a versão compactada mais recente do Crystal Palace e compile-a de acordo com suas instruções. Depois de compilado, coloque os binários do Crystal Palace dentro de:
pico-tools/crystal-palace/
O layout esperado deve ser semelhante a:
pico-tools/
└── crystal-palace/
├── src/
├── lib/
└── ...
Baixe a versão mais recente do Tradecraft Garden e coloque-a em
pico-tools/tradecraftgarden
O layout esperado deve ser semelhante a:
pico-tools/
└── tradecraftgarden/
├── libtcg/
├── simple_pic/
└── ...
Certifique-se de compilar libtcg e o exemplo simple_pic para conseguir compilar os Async PICOs.
O projeto usa CMake para simplificar a compilação com MSVC.
Na raiz do repositório, clique com o botão direito na pasta e selecione:
Open with Visual Studio
Isso carrega o projeto CMake e expõe as configurações de compilação disponíveis.
As seguintes configurações de compilação estão disponíveis:
x64 Debug
Compila versões executáveis locais dos PICOs e BOFs para depuração.
Use esta configuração ao depurar o comportamento localmente ou ao percorrer o código no Visual Studio.
x64 Release
Compila versões executáveis locais otimizadas dos PICOs e BOFs.
Use esta configuração para testar o comportamento de release fora do Beacon.
x64 Release Objects
Compila artefatos de implantação:
Esta é a configuração usada para produzir objetos para o Cobalt Strike.
Quando a compilação for concluída, os artefatos gerados podem ser encontrados em:
build/x64-ReleaseObject/obj/
Este diretório contém os PICOs e BOFs compilados, prontos para uso.
Os Async PICOs exigem que o Beacon use um sleepmask personalizado.
No seu perfil maleável, habilite o suporte a um sleepmask personalizado antes de tentar usar os Async PICOs.
O script
picos-cna/sleepmask.cnacarrega oasync-sleepmask, uma implementação de referência mínima usada para suportar saída assíncrona e a coordenação de despertar do Beacon.Este sleepmask é intencionalmente simples e apresenta as limitações descritas na seção Limitações. Ele é fornecido para demonstrar o framework e simplificar os testes, não como um componente finalizado e pronto para produção.
Se você já tem um sleepmask personalizado com técnicas de OPSEC, como manipulação de pilha ou outras, consulte Modificando seu sleepmask existente para ser um Async sleepmask para integrar o suporte a Async PICO em sua implementação existente.
Depois de compilar o projeto com a configuração x64 Release Objects, carregue os scripts Aggressor picos.cna e sleepmask.cna no Cobalt Strike:
Script Manager → Load → picos-cna/picos.cna
Script Manager → Load → picos-cna/sleepmask.cna
Depois de carregados, os Async PICOs podem ser gerenciados por meio do comando picos.
Para iniciar um PICO:
picos start [path to pico] [arguments]
Por exemplo:
picos start C:\temp\MonitorTGT.pico
Ou com argumentos:
picos start C:\temp\MonitorTGT.pico DOMAIN\serviceaccount
Para visualizar os Async PICOs em execução:
picos
Isso exibe as tarefas atualmente em execução e seus identificadores.
Para parar um Async PICO:
picos stop [pico id]
Por exemplo:
picos stop 3
O PICO recebe um sinal de parada e encerra graciosamente após realizar a limpeza.
Informações adicionais de uso estão disponíveis diretamente dentro do Cobalt Strike por meio dos menus de ajuda integrados para os comandos picos.
Consulte docs/writing_custom_async_pico.md para obter detalhes.
Consulte docs/modifying_existing_sleepmask.md para obter detalhes.
A implementação pública é mantida intencionalmente simples, sem técnicas evasivas avançadas. Ela é destinada a ser uma base para adaptação, e não algo a ser implantado sem alterações.
Os Async PICOs são iniciados usando CreateThread. Isso mantém o modelo de execução simples e fácil de entender, mas também introduz uma superfície de detecção. Na implementação pública, a thread começa a execução a partir de memória que não é respaldada por uma imagem de módulo, o que pode ser detectado por produtos ou heurísticas que inspecionam endereços de início de thread.
Os usuários devem avaliar se estratégias alternativas de criação de threads ou de execução são mais apropriadas para seu ambiente.
O framework depende de um sleepmask modificado para retransmitir a saída assíncrona de volta para o Beacon e coordenar eventos de despertar. A implementação incluída aqui é intencionalmente mínima e deve ser revisada antes do uso operacional.
O sleepmask faz parte do modelo de execução, não é apenas uma camada de conveniência. Qualquer alteração em como a saída é enfileirada, drenada ou sinalizada deve ser avaliada cuidadosamente para evitar introduzir problemas de concorrência ou interações não suportadas com as partes internas do Beacon.
A implementação pública traz várias limitações práticas que devem ser compreendidas antes de seu uso.
O Crystal Palace torna possível que os PICOs usem variáveis globais, mas a implementação pública usa um modelo simples de armazenamento compartilhado para guardar o estado global. Como resultado, as variáveis globais não são isoladas por thread.
Na prática, isso significa que executar vários Async PICOs simultaneamente pode exigir cuidado adicional quando eles dependem de globais.
Os Async PICOs dependem de um sleepmask modificado para saída assíncrona e coordenação de despertar do Beacon. Portanto, o framework não é totalmente autossuficiente e não pode ser tratado como um BOF drop-in.
O repositório foi projetado para demonstrar um framework e uma abordagem de implementação, em vez de fornecer um componente finalizado e pronto para produção. Os exemplos incluídos são destinados a serem estendidos, modificados e adaptados a casos de uso individuais.