Cobalt Strike é uma das estruturas de ataque mais populares projetadas para operações do Red Team. Ao mesmo tempo, muitos APTs e agentes mal-intencionados também o usam.

Sumário executivo

 

• As versões 4.2 e 4.3 do servidor do Cobalt Strike contêm múltiplas vulnerabilidades de negação de serviço (CVE-2021-36798).
• As vulnerabilidades podem tornar os beacons existentes incapazes de se comunicar com seu servidor C2, impedir que novos beacons sejam instalados e ter o potencial de interferir nas operações em andamento.
• Lançamos uma nova biblioteca Python para ajudar a analisar genericamente a comunicação Beacon a fim de ajudar a comunidade de pesquisa de segurança.

 

Introdução

O SentinelOne presenciou vários ataques envolvendo Cobalt Strike Beacons em nossa base de clientes. O SentinelOne detecta o Cobalt Strike Beacon e estamos constantemente lançando novas maneiras de detectar modificações ou novas maneiras de carregar o Beacon na memória.

Dada a sua adoção desenfreada por equipes vermelhas e atacantes, queríamos entender melhor a segurança operacional do Cobalt Strike. Isso nos levou a descobrir as vulnerabilidades relatadas em CVE-2021-36798 e que descrevemos a seguir.

Beacon Communications

Para entender as vulnerabilidades que encontramos, cobriremos brevemente como funciona a comunicação do Cobalt Strike Beacon.

Na primeira vez que o servidor Cobalt Strike é executado, ele cria chaves RSA geradas aleatoriamente, privadas e públicas, armazenadas em um arquivo denominado “.Cobalt Strike.beacon_keys”. Cada stager Beacon tem a chave pública embutida nele.

                                                                 Podemos obter a chave RSA pública do Beacon analisando sua configuração

Quando um stager Beacon é executado, ele reúne informações sobre o computador em que está sendo executado (arquitetura da CPU, layout do teclado, IP interno, etc.), criptografa essas informações usando a chave pública e as envia ao servidor em uma solicitação HTTP GET. Iremos nos referir a essa parte como “registro de Beacon”.

Depois que o Beacon se registra no servidor, o invasor pode interagir com o Beacon. A partir deste ponto, o Beacon atua recebendo e respondendo às “tarefas”. As tarefas podem, por exemplo, ser usadas para obter uma lista de processos, executar um comando, conduzir um movimento lateral e muitas outras coisas do interesse do invasor.

O recebimento de tarefas geralmente acontece por meio de solicitações HTTP GET e o Beacon responde com os dados da tarefa por meio de solicitações HTTP POST. As tarefas são criptografadas usando uma chave AES enviada pelo Beacon na solicitação de registro. Todo o fluxo de comunicação é explicado na documentação oficial, mas o esquema acima deve bastar para o que segue.

Uma das características mais famosas do Cobalt Strike é o seu C2 maleável. Resumindo, esse recurso permite que o invasor codifique (“transforme” na linguagem do Cobalt) todas as comunicações HTTP do beacon. Todo o processo descrito acima é envolvido nas etapas de transformação do perfil Malleable escolhido, que também estão embutidas no próprio stager.

Abaixo está um exemplo de um perfil C2 maleável popular que mascara o tráfego como uma solicitação normal para o código jquery ( fonte ):

Um exemplo de um perfil C2 maleável popular

Vulnerabilidades

Em primeiro lugar, deve-se observar que já havia uma vulnerabilidade conhecida no Cobalt Strike que foi relatada anteriormente. Vale a pena ler um ótimo artigo escrito por nccgroup para uma compreensão mais aprofundada dos componentes internos de comunicação do Beacon. Na prática, essa vulnerabilidade permitia a execução remota de código no servidor.

Não estamos interessados ​​na vulnerabilidade de execução remota de código aqui, pois seria um exagero para nossos propósitos. Considerando que o código do servidor é escrito em Java e não é muito grande, não foi muito difícil encontrar bugs lá.

Por exemplo, nas respostas da tarefa Captura de tela e Keylogger, há um comportamento interessante ao ler os dados da resposta:

                                                                                   Um exemplo de um perfil C2 maleável popular

Vulnerabilidades

 

Em primeiro lugar, deve-se observar que já havia uma vulnerabilidade conhecida no Cobalt Strike que foi relatada anteriormente. Vale a pena ler um ótimo artigo escrito por nccgroup para uma compreensão mais aprofundada dos componentes internos de comunicação do Beacon. Na prática, essa vulnerabilidade permitia a execução remota de código no servidor.

Não estamos interessados ​​na vulnerabilidade de execução remota de código aqui, pois seria um exagero para nossos propósitos. Considerando que o código do servidor é escrito em Java e não é muito grande, não foi muito difícil encontrar bugs lá.

Por exemplo, nas respostas da tarefa Captura de tela e Keylogger, há um comportamento interessante ao ler os dados da resposta:

 

public  void  process_beacon_callback_decrypted ( string final beaconID, byte final  [] responseBytes)  {
...
// Verificações de integridade aqui
...
tente {
 final DataInputStream responeBytesStream = new DataInputStream ( new ByteArrayInputStream (responseBytes));
cmd = responeBytesStream.readInt ();
if (cmd == 0 ) {...}
...
else  if (cmd == 3 ) {
	 final DataParser dp = new DataParser (CommonUtils.readAll (responeBytesStream));
	dp.little ();
	 byte final [] scData = dp.readCountedBytes ();    // Bug # 1 aqui 
	final  int scDesktop = dp.readInt ();
	final String scTitle = this .getCharsets (). process (beaconID, dp.readCountedBytes ());
	final String process6 = this .getCharsets (). process (beaconID, dp.readCountedBytes ());
	if (scData.length == 0 ) {
		saída (BeaconOutput.Error (beaconID, "captura de tela do desktop" + scDesktop + "está vazio" ));
		retorno ;
	}
	...    
	output (BeaconOutput.OutputB (beaconID, "captura de tela recebida de" + scTitle + "de" + process6 + "(" + CommonUtils.formatSize (scData.length) + ")" ));
	...
}}}

 

public 

 

Neste exemplo, vemos a análise de uma resposta da tarefa de captura de tela. Para ler os dados da captura de tela, ele chama a função readCountedBytes, que lê um número inteiro dos primeiros quatro bytes dos dados e o trata como o tamanho da captura de tela sem nenhuma verificação de sanidade.

Então, antes de ler os dados da captura de tela, ele aloca um buffer grande o suficiente para armazenalos 

 

byte [] array = novo  byte [ReplySize];

Ao manipular o tamanho da captura de tela, podemos fazer com que o servidor aloque um tamanho arbitrário de memória, cujo tamanho é totalmente controlável por nós. No entanto, para acionar esse trecho de código, precisamos ser capazes de falar com o servidor como um Beacon.

Ao combinar todo o conhecimento do fluxo de comunicação do Beacon com nosso analisador de configuração, temos tudo o que precisamos para falsificar um Beacon.

Publicamos um script POC python que faz exatamente isso: ele analisa a configuração de um Beacon e usa as informações armazenadas nele para registrar um novo Beacon aleatório no servidor. Depois de registrar o Beacon, é bastante trivial usar o primitivo encontrado acima para enviar iterativamente respostas falsas de tarefas que espremem cada bit de memória disponível do encadeamento do servidor web do C2:

 

size = 1000000000 
enquanto  True :
     try :
         if size < 20 :
             break
        send_task (fake_beacon, tamanho)
    exceto KeyboardInterrupt:
        quebrar 
    exceto Exceção  como e:
        size = size // 2

Isso leva ao travamento do thread da web do servidor que lida com os stagers HTTP e a comunicação do Beacon:

 

Falha no thread da web do servidor

 

Isso permitiria que um invasor causasse o esgotamento da memória no servidor Cobalt Strike (o “Teamserver”), fazendo com que o servidor parasse de responder até que fosse reiniciado. Isso significa que os beacons ativos não podem se comunicar com seus C2 até que os operadores reiniciem o servidor.

Reiniciar, no entanto, não será suficiente para se defender contra esta vulnerabilidade, pois é possível direcionar repetidamente o servidor até que ele seja corrigido ou a configuração do Beacon seja alterada.

Qualquer um deles tornará os Beacons ativos existentes obsoletos, pois eles não poderão se comunicar com o servidor até que sejam atualizados com a nova configuração. Portanto, essa vulnerabilidade tem o potencial de interferir gravemente nas operações em andamento.

Embora usado todos os dias para ataques mal-intencionados, Cobalt Strike é basicamente um produto legítimo, portanto, divulgamos esses problemas de forma responsável para HelpSystems e eles corrigiram as vulnerabilidades na última versão.


Serviços de utilidade pública


Em nosso repositório do analisador Cobalt Strike, adicionamos novos módulos e exemplos de código que implementam:


 Análise das instruções de perfil maleável de um Beacon
Análise da configuração de um Beacon diretamente de um C2 ativo (como o popular script nmap)
Código básico para comunicação com um C2 como um farol falso
Além de registrar um Beacon falso com o servidor, o código que estamos liberando torna mais fácil analisar as comunicações Beacon capturadas de uma forma genérica.

Vamos pegar, por exemplo, um caso de uma comunicação Beacon não criptografada capturada da análise de tráfego de malware e decodificá-la usando o novo módulo de comunicação:

from urllib import parse
 from pcaper import PcapParser
 from parse_beacon_config import *
 from comm import *

conf = cobaltstrikeConfig ( r "beacon.bin" ) .parse_config ()
pparser = PcapParser ()
reqs = pparser.read_pcap ({ 'input' : r "2019-07-25-Hancitor-style-Amadey-with-Pony-and-Cobalt-Strike.pcap" })

t = Transform (conf [ 'HttpPost_Metadata' ])
 para req em reqs:
	 if conf [ 'HttpPostUri' ] em req.uri:
		params = {k: v [ 0 ] para k, v em parse.parse_qs (parse.urlsplit (req.uri) .query) .items ()}		
		print ( '\ n \ nResposta de beacon encontrada: \ n' , t.decode (req.body, req.headers, params) [ 1 ])

saida

... 
Resposta de beacon encontrada  : ♠ r ↓ 10.7.25.101: 445 (plataforma: 500 versão: 6.1 nome: HIDDENROAD- domínio PC : WORKGROUP) Módulo do scanner está completo ")) 
         
   


Resposta de farol encontrada:
 ► [*] Escreveu o hijack DLL em 'C: \ Users \ SARAH ~ 1.RUT \ AppData \ Local \ Temp \ 745f.dll'
[+] Sucesso privilegiado na cópia do arquivo! C: \ Windows \ System32 \ sysprep \ CRYPTBASE.dll
[+] C: \ Windows \ System32 \ sysprep \ sysprep.exe foi executado e saiu.
[*] Limpeza bem-sucedida
...

Ele analisa as instruções C2 maleáveis ​​embutidas na configuração do Beacon e as usa para decodificar as respostas do Beacon das solicitações HTTP capturadas.

Há muito que pode ser feito com essa nova biblioteca de comunicação e será interessante ver o que outros pesquisadores da comunidade farão com ela.

Conclusão
A pesquisa em estruturas de ataque como Cobalt Strike e Cellebrite ainda é uma área de nicho. Esperamos que esta pesquisa e as ferramentas que lançamos ajudem a encorajar ainda mais a pesquisa sobre a robustez das estruturas de ataque e a expandir a gama de opções disponíveis ao enfrentar seu abuso consistente.

 

 

Fonte: SentinelLasns