Por Renato Malta
Faz parte de uma das missões da equipe de Cyber Threat Intelligence da Tempest identificar e documentar os TTP’s (Táticas, Técnicas e Procedimentos) utilizados por adversários e cibercriminosos.
Uma parte importante deste processo é a identificação e o monitoramento da infraestrutura utilizada por estes atores, e temos registrado uma crescente adoção do Cobalt Strike como Command and Control para atividades maliciosas.
1.Resumo
- Lançado em 2012, o Cobalt Strike (S0154) é uma plataforma comercial de simulação de adversário que possui uma série de funcionalidades de pós-exploração as quais auxiliam o trabalho de times de Red Team e defesa.
- Porém estes benefícios também vêm sendo usados por operadores de APT’s, cartéis de ransomware e cibercriminosos, fato que tem sido amplamente reportado por diversas entidades da indústria de cibersegurança.
- Com base no material analisado, pudemos constatar um frequente uso de configurações padrão do Cobalt Strike o que pode oferecer oportunidades de detecção aos times de defesa.
- Este relatório tem como finalidade apresentar um panorama sobre mais de 6800 servidores Cobalt Strike expostos à internet e suas configurações. As particularidades descritas no documento podem auxiliar times de defesa na detecção, hunting e emulação de ameaças que utilizam este framework, podendo também oferecer insights para detecção de ferramentas que utilizam técnicas similares como Metasploit, Empire, Covenant dentre outros.
2.Metodologia
Para esta análise, combinamos metodologias públicas que se aproveitam de particularidades notadas em instalações padrão do Cobalt Strike Team Server e que podem ser utilizadas como fingerprint para identificação destes servidores na internet.
Uma das técnicas foi descrita pela Recorded Future que identifica estes servidores por meio de uma informação contida no estudo “Cobalt Strike Team Server Population Study“, feito pela Strategic Cyber LLC (desenvolvedora do Cobalt Strike). A menos que seja alterado por seu operador, o Cobalt Strike Team Server utiliza um certificado auto-assinado padrão, cujo hash SHA256 87f2085c32b6a2cc709b365f55873e207a9caa10bffecf2fd16d3cf9d94d390c pode ser usado para identificação em motores de busca como Shodan e Censys.
Outra técnica, descrita pela Salesforce, identifica servidores maliciosos na internet com o auxílio do software JARM, que utiliza atributos da resposta de servidores TLS para gerar uma espécie de fingerprint. A instalação padrão do Cobalt Strike possui o JARM 29d21b20d29d29d21c41d21b21b41d494e0df9532e75299f15ba73156cee38 o qual também pode ser identificado em motores de busca como Censys.
Adicionalmente, utilizamos listas de servidores disponibilizadas no serviço RiskIQ em fontes abertas, como o perfil no Pastebin CobaltStrikeMonitor, e também em redes sociais, nas quais vários pesquisadores de segurança publicam servidores identificados diariamente.
De posse dos endereços IP, utilizamos o script desenvolvido pela SentinelOne para extrair a configuração que define como será feita a comunicação e execução do beacon referente a cada servidor, assim, além de identificar padrões e especificidades podemos confirmar que estes endereços estão ativos e de fato hospedando servidores Cobalt Strike.
Os dados coletados neste estudo estão relacionados a 6819 servidores espalhados pela internet. Em muitos momentos, os gráficos abaixo apresentam números superiores ao volume de servidores. Isto ocorre em situações nas quais os mesmos servidores possuem duas ou mais características apresentadas no gráfico.
3.Análise dos servidores
Entre o período de 11/05/2021 à 20/10/2021, identificamos 6,819 servidores de Cobalt Strike ativos com uma média de 100 novos por dia, os quais podem estar em uso tanto por criminosos quanto por por times de segurança, como por exemplo os servidores identificados em endereços IP relacionados ao Department of Homeland Security dos Estados Unidos, na imagem abaixo.
4.Geolocalização
Os servidores que identificamos estão localizados em mais de 30 países, Estados Unidos, China e Hong Kong aparecem no topo da lista, o que não necessariamente determina a localização ou nacionalidade dos adversários que estão operando estes servidores.
O Brasil aparece entre os países que menos hospeda servidores, com apenas 13 ocorrências. Na verdade, estes números se explicam pela localização dos maiores provedores globais de hosting e computação em nuvem, como Alibaba, Amazon e Google.
5.Hospedagem
Dentre os mais de 250 serviços de hospedagem utilizados, notamos uma preferência pelos grandes serviços de nuvem como Tencent, Amazon e Alibaba. Serviços de nuvem permitem maior flexibilidade na ativação e desativação dos servidores e geralmente também têm custo menor em relação aos provedores de hospedagem tradicionais.
Percebemos também uma grande presença em provedores com maior resistência a pedidos de remoção de conteúdo (takedown) como Vultr/Choopa e Leaseweb.
Muitos servidores foram identificados através dos domínios e alguns deles estavam utilizando o serviço da Cloudflare, o que impossibilitou a identificação de seus provedores de hospedagem.
6.Análise das configurações
Como descrito na seção de metodologia (acima), nós buscamos extrair a configuração dos beacons contidas nos servidores identificados em nosso processo de monitoramento. Estas configurações, também conhecidas como “Profile”, fazem referência a uma das mais poderosas funcionalidades do Cobalt Strike. o C2 Maleável.
A funcionalidade dá ao operador da ferramenta a capacidade de utilizar perfis que permitem a customização do tráfego de rede; da injeção do payload em processos e dos métodos de ofuscação em memória de modo a dificultar sua detecção por ferramentas de segurança. Abaixo uma imagem que representa este conjunto de configurações.
7.Listener
O funcionamento básico do Cobalt Strike está atrelado aos Listeners, os quais permitem ao usuário configurar o método de comando e controle (C2) que será utilizado no ataque. Para cada ataque ou payload gerado existe um Listener incorporado ao alvo. Isso determina como o processo de comunicação será realizado entre o host infectado e o servidor. Um usuário pode configurar diversas informações sobre o Listener e escolher o tipo de operação que será realizada através do C2, tais como DNS, HTTP, HTTPS, SMB, SMTP dentre outros.
Em nosso estudo, direcionamos os nossos sensores exclusivamente para servidores cujo tráfego é baseado nos protocolos HTTP e HTTPS.
Nos servidores identificados apenas 5 deles estavam utilizando o listener híbrido de HTTP + DNS e a grande maioria utilizava HTTPS como padrão.
8.User Agent
Esta configuração permite customizar o user-agent que o beacon vai utilizar para se comunicar com o servidor. Com isto, o operador pode tentar simular o comportamento de browsers comuns e assim não chamar atenção de mecanismos de defesa ou de analistas que estejam analisando o tráfego de rede em busca de anomalias.
O user-agent mais utilizado é o do Internet Explorer devido a sua grande adoção em ambientes corporativos, mas também foi possível identificar configurações relacionadas a outros navegadores como Firefox e Chrome e também navegadores de dispositivos mobile como Iphone e Android.
9.URI
Há diversas configurações que podem ser implementadas de modo a customizar a comunicação entre o beacon e o servidor do Cobalt Strike, uma delas é manipular URI que será acessada.
É comum aos operadores da ameaça utilizar URIs que falsifiquem acessos que são comumente usados, como o tráfego do JQuery (/jquery-3.3.1.min.js) e a comunicação com o site da Amazon (/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books).
10.Fator Jitter
Por definição, beaconing é a prática de enviar comunicações curtas e regulares de um host para outro usando beacons, os quais são sinalizadores, na tradução para português. Nem todos os beacons são maliciosos. Há muitos casos de uso benigno, como serviços de hora do sistema, serviços de atualização de software, entre outros.
No Cobalt Strike ele é usado para comunicar ao servidor que a máquina comprometida está ativa, pronta para receber instruções e comandos.
Porém esta comunicação regular e contínua facilita a identificação e detecção por mecanismos de defesa de modo que, para se manter oculto destas ferramentas, muitos frameworks de pós-exploração utilizam uma funcionalidade conhecida como fator Jitter.
Jitter é uma variação estatística do atraso na entrega de dados em uma rede, ou seja, pode ser definida como a medida de variação do atraso entre os pacotes sucessivos de dados.
Por padrão o beacon do Cobalt Strike se comunica com o servidor a cada sessenta segundos, porém o operador pode alterar a periodicidade e, além disso, configurar um valor para o fator de Jitter de 0 a 99 que será utilizado para randomizar o tempo desta comunicação.
A maior parte dos servidores identificados possui o fator Jitter em 0, ou seja, o tempo de verificação não é randomizado, o que pode facilitar a detecção de sua comunicação dentro da rede.
11.Instruções de Data Transform
Data Transform é uma sequência de instruções que indicam ao beacon como transformar os dados antes de serem enviados ao servidor que, por sua vez, também utiliza estas instruções para traduzir os dados recebidos. Desta forma, se o tráfego de rede for interceptado, se difícil identificar o que está sendo transmitido.
Por exemplo, se assim for configurado, o beacon vai codificar os dados em Base64 e o servidor, programado com esta instrução, automaticamente decodificaria o material recebido utilizando o mesmo método.
Apesar destas instruções poderem ser usadas em conjunto, separamos as mais utilizadas pelos servidores que identificamos:
12.Injeção de processos
A injeção de payloads em processos é uma técnica de evasão de defesa, muito utilizada por malwares e ferramentas de pós-exploração como o Cobalt Strike. Através dela é possível a execução de código malicioso no espaço de memória de outro processo.
Existem diversas formas de conduzir a injeção e, no caso do Cobalt Stike, o modo como o beacon vai ser injetado também está contido na configuração do servidor e do próprio beacon.
Abaixo os modos mais utilizados pelos servidores de nossa amostra:
- RtlCreateUserThread – Injeta código por além dos limites da sessão.
- CreateRemoteThread – Injeção remota em um processo
- CreateThread – Injeção em código malicioso no seu próprio processo.
- SetThreadContext – Assume threat de um processo temporário gerado para um trabalho de pós-exploração.
- NtQueueApcThread-s – Utiliza o NtQueueApcThread para enfileirar uma função única que funciona quando a thread de processo alvo é ativada.
Mais detalhes sobre o modo de injeção de processos na documentação do Cobalt Strike
13.Spawn_to
As configurações de Spawn_to controlam o processo que será abusado por um beacon de modo a gerar os trabalhos de pós-exploração, assim o operador pode simular processos que são comumente utilizados no sistema operacional para tentar confundir sistemas de defesa e analistas de segurança.
Uma oportunidade de detecção seria a de observar se estes processos estão executando comandos que não fazem parte do seu comportamento tradicional.
No exemplo da tabela abaixo, extraída de um log, é possível constatar a execução de comandos como whoami /all, route print ou cmd /c set por parte do processo rundll32.exe cuja função primária é a de carregar DLLs em memória e não a de executar comandos de rede, por exemplo.
Nas configurações que tivemos acesso o processo mais utilizado é o rundll32.exe o qual faz parte da configuração padrão utilizado pelo Cobalt Strike, abaixo os 10 processos mais abusados:
14.Marca d’água
Uma informação que costuma ser relevante em análises e na investigação de intrusões envolvendo CobaltStrike é o parâmetro de marca d’água contido na configuração do beacon. Este identificador é um número gerado a partir do arquivo de licença do Cobalt Strike o qual pode ajudar a identificar e vincular várias campanhas ao mesmo ator.
Grande parte dos servidores identificados (1148) utilizam a marca d’água “0”, que está ligada a versões piratas do produto que foram vazadas em fóruns underground.
Outras três marcas aparecem com frequência em nosso monitoramento: a 305419896 atribuída a um afiliado do grupo de ransomware Maze; a 1359593325 atribuída a operações relacionadas ao Trickbot e a 1580103814 atribuída ao grupo LuckyMouse.
Por terem tido visibilidade através de relatórios de empresas de segurança, estas marcas d’água podem estar sendo customizadas na tentativa de despistar analistas causando uma atribuição errônea. Portanto, não é possível determinar que a quantidade de servidores identificados com estas marcas realmente pertençam aos grupos/atores citados.
15.Considerações Finais
O processo de detecção do Cobalt Strike pode ser complexo por conta da sua capacidade de customização de processos e conexões, o que torna a atividade de desassociar o seu tráfego, do tráfego legítimo de uma rede comum algo praticamente impossível se usarmos apenas um dos parâmetros de sua configuração.
No entanto, durante nossa análise identificamos que vários servidores utilizam “profiles” idênticos, pois muitas vezes se baseando na adoção da configuração padrão do Cobalt Strike por parte do operador. Este comportamento pôde ser comprovado nas configurações do fator Jitter, nas instruções de data transform e na escolha do processo a ser abusado na máquina alvo. Este tipo de desleixo ao personalizar o ataque pode ser algo importante para sua detecção. Mais detalhes sobre maneiras de detectar essa ameaça no whitepaper sobre a ferramenta publicado em meados deste ano.
Apesar dos números crescentes de utilização do Cobalt Strike por parte de cartéis de ransomware é importante lembrar que o acesso inicial à corporações muitas vezes é feito através de famílias de malware conhecidas como Trickbot, BazarLoader, QakBot dentre outros. Recomendamos que seja redobrada a atenção a respeito destas famílias
Disponibilizamos os IOCs dos servidores analisados neste estudo no GitHub da Tempest. Clientes do serviço de Threat Intelligence podem ter acesso em tempo real a atualizações nessa lista por meio do nosso MISP.
FIM DO RELATÓRIO
