nvisosecurity/pycobalthoundpyCobaltHound é uma extensão de script Aggressor para o Cobalt Strike que visa fornecer uma integração profunda entre o Cobalt Strike e o Bloodhound.
pyCobaltHound é uma extensão de script Aggressor para o Cobalt Strike que visa fornecer uma integração profunda entre o Cobalt Strike e o BloodHound.
pyCobaltHound busca auxiliar os operadores de red team ao:
BloodHound para descobrir caminhos de escalonamento abertos por credenciais recém-coletadas.Para tal, pyCobaltHound utiliza um conjunto de consultas incorporadas. Os operadores também podem adicionar/remover suas próprias consultas para ajustar as capacidades de monitorização do pyCobaltHound. Isto concede-lhes flexibilidade para adaptar o em tempo real durante os engajamentos para considerar alvos específicos do engajamento (utilizadores, hosts, etc.).
pyCobaltHoundPara instalar o pyCobaltHound, clone este repositório. Não se esqueça de também clonar o submódulo incluído!
Pode usar o seguinte comando:
git clone https://github.com/NVISOsecurity/pyCobaltHound.git --recurse-submodulesAssegure-se de que as seguintes dependências estejam corretamente instaladas:
PyCobalt é uma API Python para o Cobalt Strike. Ela expõe muitas funções Aggressor para serem usadas diretamente a partir do Python.
Assegure-se de ter o Python3+ instalado. Embora o PyCobalt possa funcionar também no macOS e Windows, testemo-lo apenas no Linux.
Existem duas formas de usar a biblioteca Python PyCobalt:
pyCobaltHound adota esta abordagem, definindo o caminho de busca a partir do programa Python usando a variável sys.path.PyCobalt. Para tal, execute python3 setup.py install. Terá de modificar o ficheiro pycobalthound.py para garantir que ele use a biblioteca instalada em vez da que está no repositório incluído.PyCobalt será mantido no futuro. Na verdade, a última atualização do projeto foi para incorporar as alterações feitas no Cobalt Strike 4.2. No entanto, como o pyCobaltHound usa apenas funções Aggressor básicas para interagir com o Cobalt Strike e o seu operador, isto não é um grande problema para o pyCobaltHound.PyCobalt usado neste projeto é um fork feito por nós. No entanto, não controlamos o repositório do PyCobalt.O PyCobalt vem com alguns comandos da Script Console para gerir os scripts Python em execução. Quando recarregar o seu script Aggressor, deve parar explicitamente os scripts Python primeiro. Caso contrário, eles permanecerão em execução para sempre sem fazer nada. Durante o desenvolvimento do pyCobaltHound, notámos que isso também pode levar a comportamentos indefinidos.
Recarregar o pyCobaltHound pode ser feito da seguinte forma:
aggressor> python-stop-all`
[pycobalt] Asking script to stop: /root/pycobalthound/pycobalthound.py
[pycobalt] Script process exited: /root/pycobalthound/pycobalthound.py
aggressor> reload example.cna`
[pycobalt] Executing script /root/pycobalthound/pycobalthound.py
Para que o PyCobalt funcione corretamente, só pode chamar o PyCobalt num script Aggressor. Tenha isto em mente se quiser usar o pyCobaltHound juntamente com outros scripts Aggressor que usem o PyCobalt. A nossa abordagem é ter um script Aggressor com chamadas a python() e include() para cada ferramenta baseada em PyCobalt.
notify2 é - ou era - um pacote para exibir notificações de desktop no Linux. Como veremos mais adiante, o pyCobaltHound suporta algumas formas de notificar o operador. O notify2 é usado no Linux para enviar notificações ao daemon de notificações através do D-Bus.
Para ativar isto, o notify2 precisa ser instalado usando:
pip install notify2
Usar o pyCobaltHound no Cobalt Strike é tão simples quanto importar o script Aggressor pycobalthound.cna para o seu cliente. Uma vez feito isto, deverá ver um menu pyCobaltHound aparecer na barra de menus do seu Cobalt Strike.
O objetivo inicial do pyCobaltHound era monitorizar a cache de credenciais do Cobalt Strike (View > Credentials) em busca de novas entradas. Ele faz isso reagindo ao evento on_credentials que o Cobalt Strike dispara quando são feitas alterações no armazenamento de credenciais.
Quando este evento é disparado, o pyCobaltHound irá:
Cobalt StrikeBloodHoundBloodHound para cada nova entidade usando consultas incorporadas e personalizadas.Como tudo isto ocorre de forma assíncrona em relação ao cliente principal do Cobalt Strike, este processo não deve bloquear a sua interface de utilizador, permitindo-lhe continuar a trabalhar enquanto o pyCobaltHound investiga em segundo plano.
O pyCobaltHound usa caches separadas por teamserver para evitar problemas ao usar múltiplos teamservers.
Por vezes, há situações em que deseja investigar novamente utilizadores específicos (ou todo o armazenamento de credenciais). Isto pode acontecer quando carregou novos dados na base de dados do BloodHound.
Como o pyCobaltHound já deve ter investigado (e, portanto, colocado em cache) todas as entidades do seu armazenamento de credenciais, não as avaliará em relação a estes novos dados sem alguma intervenção do operador.
Estão disponíveis dois métodos para os operadores controlarem quais entidades estão em cache.
Nos casos em que deseja remover uma entidade específica (ou várias) da cache, pode fazê-lo no visualizador de credenciais (View > Credentials). Basta selecionar o(s) seu(s) alvo(s) e clicar na opção remove from cache sob a entrada do menu pyCobaltHound.
Nos casos em que deseja remover todas as entidades da cache, pode fazê-lo no menu principal do pyCobaltHound (Cobalt Strike > pyCobaltHound > Wipe cache). Isto é mais útil quando pretende reavaliar todo o seu armazenamento de credenciais.
Depois de remover os seus alvos da cache, pode solicitar manualmente ao pyCobaltHound que re-investigue o conteúdo do armazenamento de credenciais. Isto segue exatamente o mesmo processo descrito acima.
O pyCobaltHound contém funcionalidades para interagir com sessões beacon existentes. Isto pode ser encontrado no menu de contexto do beacon. Note que estes comandos podem ser executados num único beacon ou numa seleção de beacons.
Esta funcionalidade é especialmente útil ao lidar com utilizadores e computadores cujas credenciais não foram comprometidas (ainda), mas que estão efetivamente sob o nosso controlo (por exemplo, porque temos um beacon a executar sob o token da sua sessão).
A funcionalidade Mark as owned (pyCobaltHound > Mark as owned) pode ser usada para marcar um beacon (ou coleção de beacons) como owned na base de dados do BloodHound.
Esta janela de diálogo solicitará ao operador as seguintes informações:
pyCobaltHound só marcará computadores como owned se a sessão beacon estiver em execução como administrador local, SYSTEM ou uma sessão de alta integridade como outro utilizador.A funcionalidade Investigate (pyCobaltHound > Mark as owned) pode ser usada para investigar os utilizadores e hosts associados a um beacon (ou coleção de beacons).
Esta janela de diálogo solicitará ao operador as seguintes informações:
pyCobaltHound só investigará computadores se a sessão beacon estiver em execução como administrador local, SYSTEM ou uma sessão de alta integridade como outro utilizador.pyCobaltHound investigará todas as entidades sem verificar níveis de integridade.O pyCobaltHound contém funcionalidades para investigar livremente entidades. Isto pode ser encontrado no menu principal (Cobalt Strike > pyCobaltHound > Investigate).
Esta funcionalidade é especialmente útil ao lidar com utilizadores e computadores cujas credenciais não foram comprometidas e não estão sob o nosso controlo.
Esta janela de diálogo solicitará ao operador as seguintes informações:
O menu de definições do pyCobaltHound pode ser encontrado em Cobalt Strike > pyCobaltHound > Settings.
O pyCobaltHound guardará as suas definições em disco. Cada vez que o pyCobaltHound for recarregado, verificará a existência de um ficheiro de definições e carregará as definições guardadas se encontrar um.
O pyCobaltHound guarda um ficheiro de definições por teamserver, pelo que é possível ter definições diferentes em diferentes teamservers.
Para autenticar na base de dados do BloodHound, o pyCobaltHound precisará das seguintes informações:
Nota: se optar por guardar as suas definições de forma persistente (para preservá-las entre reinícios do cliente/host), o pyCobaltHound irá desserializar e armazenar estas credenciais em disco.
Como discutido anteriormente, o pyCobaltHound utiliza cache para garantir que não realiza trabalho desnecessário. Esta cache pode ser desativada nas definições. Isto é especialmente útil ao desenvolver novas consultas, para não ter de gerir/limpar constantemente a cache.
O pyCobaltHound suporta alguns métodos diferentes para notificar o operador quando identifica uma entidade de interesse. É possível desativar estas notificações.
Por predefinição, o pyCobaltHound notificará o operador usando a caixa de mensagem padrão do Aggressor. Esta opção pode interferir com o fluxo de trabalho do operador. No entanto, é o método predefinido por ser suportado em todas as plataformas onde pode executar um cliente Cobalt Strike.
O pyCobaltHound também suporta a exibição de notificações de desktop no Linux. Esta é a nossa opção preferida, pois não interrompe o fluxo de trabalho do operador.
Durante alguns dos seus fluxos de trabalho, o pyCobaltHound gerará um relatório HTML. Esta escolha de design foi feita para evitar inundar o operador com notificações enormes no caso de muitas entidades serem investigadas. Estes relatórios serão gerados na pasta reports. É possível desativar a geração de relatórios.
Por predefinição, o pyCobaltHound sincronizará consultas entre teamservers usando um ficheiro central para todas as definições relacionadas com consultas. Isto significa que as consultas que são ativadas, adicionadas ou eliminadas num teamserver também serão ativadas, adicionadas ou eliminadas nas consultas feitas por outros teamservers. Isto é principalmente uma opção de conveniência e pode ser desativada, o que é útil em casos onde está a executar consultas específicas de um engajamento que não se aplicam a todos os teamservers aos quais está ligado.
Quando a sincronização de consultas está desativada, o pyCobaltHound verificará a existência de ficheiros de consulta únicos. Se estes existirem, irá carregá-los e usar essas consultas durante os seus fluxos de trabalho. Se os ficheiros não existirem, irá criá-los e carregá-los. Esta definição persistirá através de recarregamentos.
Quando a sincronização de consultas está ativada, o pyCobaltHound verificará a existência de ficheiros de consulta únicos. Se estes existirem, o operador será solicitado a fazer uma escolha.
O operador tem as seguintes opções:
pyCobaltHound simplesmente removerá os ficheiros de consulta únicos. Todas as consultas personalizadas serão perdidas.pyCobaltHound tentará fundir os ficheiros de consulta únicos nos ficheiros de consulta gerais. Antes de fundir uma consulta, verificará se não existe nenhuma consulta no ficheiro geral com o mesmo nome ou a mesma declaração Cypher. Se ocorrerem conflitos de fusão, o operador será questionado se deseja manter as consultas não fundidas. Estas serão guardadas num ficheiro separado. Os ficheiros de consulta únicos serão então removidos.pyCobaltHound simplesmente deixará os ficheiros de consulta únicos. Todas as consultas personalizadas serão preservadas e os ficheiros serão carregados novamente se a sincronização de consultas for desativada novamente.O pyCobaltHound atualmente suporta as seguintes consultas incorporadas:
A gestão das várias consultas que o pyCobaltHound utiliza pode ser feita através do menu principal (Cobalt Strike > pyCobaltHound > Queries).
A janela de diálogo Update queries permite aos operadores ativar/desativar consultas específicas. Ao usar esta janela, o operador será primeiro questionado sobre o tipo de consultas que deseja atualizar. Isto é feito para renderizar/carregar dinamicamente as consultas corretas durante este fluxo de trabalho.
Após responder à primeira janela, o operador verá então uma lista de todas as consultas disponíveis daquele tipo. Aqui pode escolher quais as consultas que deseja ativar/desativar.
A opção de tipo de consulta é uma solução provisória para passar o tipo de consulta para a função seguinte no fluxo de trabalho e não é relevante para o operador.
A funcionalidade Add query permite aos operadores adicionar/remover as suas próprias consultas para ajustar as capacidades de investigação do pyCobaltHound. Isto concede-lhes flexibilidade para adaptar o pyCobaltHound em tempo real durante os engajamentos para considerar alvos específicos do engajamento (utilizadores, hosts, etc.).
Esta janela de diálogo solicitará ao operador as seguintes informações:
pyCobaltHound.pyCobaltHound precisa executar. Os operadores são bastante livres para definir as suas consultas. Os únicos requisitos são os seguintes:
pyCobaltHound gera dinamicamente a seguinte string Cypher com base nos nomes das entidades que está a investigar:
WITH [account names here] AS samAccountNames UNWIND samAccountNames AS names.MATCH (x) WHERE x.name STARTS WITH names(x:User)) dependendo do tipo de consulta que está a adicionar.pyCobaltHound espera que a consulta devolva um conjunto distinto de nomes de utilizador.
RETURN DISTINCT (x.name)pyCobaltHound usa para a consulta personalizada. Isto será usado em notificações e relatórios durante os fluxos de trabalho do pyCobaltHound.
pyCobaltHound substituirá pela quantidade de resultados para esta consulta.A janela de diálogo Delete query permite aos operadores remover consultas personalizadas específicas do pyCobaltHound. Ao usar esta janela, o operador será primeiro questionado sobre o tipo de consulta que deseja remover. Isto é feito para renderizar/carregar dinamicamente as consultas corretas durante este fluxo de trabalho.
Após responder à primeira janela, o operador verá então uma lista de todas as consultas disponíveis daquele tipo. Aqui pode escolher quais as consultas que deseja remover.
A opção de tipo de consulta é uma solução provisória para passar o tipo de consulta para a função seguinte no fluxo de trabalho e não é relevante para o operador.
O pyCobaltHound utiliza/inspira-se nos seguintes: