Cobalt Strike

Fases de um Ataque

Reconnaissance = Explore um alvo e encontre vetores de ataque em potencial Weaponisation = Desenvolva um payload malicioso Delivery = Encontre um meio de entregar o payload Exploitation = O ataque inicial de entrega do payload Installation = Instale o malware persistente no alvo Command & Control = Estabeleça um meio de controlar alvos comprometidos Actions on Objectives = Atinga o objetivo operacional (desfiguração, roubo de dados, etc).

Agresssor Script

É a linguagem de script (sucessor da Cortana) incorporada ao Cobalt Strike na versão 3.0 e posterior. O Agressor Script permite modificar e estender o cliente Cobalt Strike.

Cobalt Strike 3.0 é uma reescrita básica do Cobalt Strike sem Armitage como base. Essa mudança proporcionou uma oportunidade de revisitar os scripts do Cobalt Strike e criar algo em torno dos seus próprios recursos. O resultado deste trabalho é o Agressor Script.

O Aggressor Script é utilizado em operações de Red Teams e simulações de adversários inspiradas em clientes e bots com script do IRC. Você pode criar bots de longa duração que simulam membros da Red Team, trabalhando lado a lado com você. Você também pode usá-lo para estender e modificar o cliente Cobalt Strike de acordo com suas necessidades.

Domain Fronting

O Domain Fronting é uma técnica normalmente usada para evitar evasão a censura. Ele conta com redes populares de entrega de conteúdo (CDNs), como o CloudFront da Amazon, para mascarar as origens do tráfego. Ao alterar o cabeçalho do host HTTP, a CDN encaminhará para o servidor correto. Red Teams usam bastante essa técnica para ocultar o tráfego C2 usando redirecionadores de alta reputação.

NOTA: Utilizamos aqui o AWS como exemplo, mas podemos também utilizar serviços como Google Cloud, Microsoft Azure, Alibaba, etc.

Configurando CloudFront (AWS)

Faça login na AWS e navegue até o CloudFront. Você precisará de um nome de domínio que possua ou que tenha adquirido gratuitamente de um registrador como a Freenom. Clique em Create Distribution. O nome do domínio de origem será o domínio que você possui. Você também precisa corresponder à política do protocolo de origem (HTTP / HTTPs), para que o CloudFront roteie os dois tipos de tráfego para você.

Agora precisamos ajustar algumas configurações para que a CDN armazene em cache o mínimo de tráfego possível.

  • Em Allowed HTTP Methods, selecione o máximo de métodos possível

  • Configure Cache Based on Selected Request Headers como All

  • Em Forward Cookies, também selecione All

  • Em Query String Forwarding and Caching, selecione Forward all, cache based on all

NOTA: AWS e Google tem soluções para evitar esse tipo de ataque, então é preciso utilizar recursos de terceiros diferentes.

Configurando CS como Serviço

Ter um servidor rodando como um serviço e configurando para sempre iniciar junto com o SO, ajuda muito. Para fazer isso, crie um arquivo /etc/systemd/system/teamserver.service, com o seguinte conteúdo (altere os paths):

[Unit]
Description=Cobalt Strike Team Server
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
User=root
WorkingDirectory=</path/to/cobaltstrike>
ExecStart=</path/to/cobaltstrike/teamserver> <ip> <senha> <path/to/file.profile>

[Install]
WantedBy=multi-user.target

Agora faça um reload, inicie e verifique o seu status

sudo systemctl daemon-reload
sudo systemctl status teamserver.service

sudo systemctl start teamserver.service
sudo systemctl status teamserver.service

Se o serviço estiver running, execute:

sudo systemctl enable teamserver.service

Configurando o Profile

O arquivo .profile nada mais é do que um arquivo de configuração para a execução do CS. Podemos usar como exemplo, o arquivo webbug.profile.

A primeira configuração que devemos fazer, é adicionar o seguinte trecho de código no início do arquivo (antes ad função http-get). Isso irá deixar nossos Beacons com uma estabilidade melhor (Mais detalhes na sessão Microsoft Defender Antivirus).

post-ex {
        set amsi_disable "true";

        set spawnto_x64 "%windir%\\sysnative\\dllhost.exe";
        set spawnto_x86 "%windir%\\syswow64\\dllhost.exe";
}

Também podemos editar o arquivo e adicionar em seu início, a linha descrita abaixo. Fazendo isso, os Beacons irão vir com o modo Interativo, ou seja, não irá ser preciso aguardar 1 minuto para que seja enviada algum comando via Beacon.

set sleeptime "0";

Outra configuração que podemos adicionar (caso seja necessário), é o aumento de memória. Note que isso é preciso somente em casos específicos, onde uma requisição muito pesada, demanda mais memória.

Geralmente precisamos realizar essa altearção, quando recebermos mensagens de erro como:

[-] Task size of <number> bytes is over the max task size limit of 1048576 bytes

Sendo assim, adicione a linha abaixo, no início do arquivo .profile.

set tasks_max_size "2097152";

Iniciando

Iniciando o CS (Server). Utilize uma senha qualquer e depois utilize essa mesma senha no Client. Esse processo irá utilizar por padrão a porta 50050. No valor de profile, podemos usar o valor c2-profiles/normal/webbug.profile. Caso já tenha efetuado a configuração do CS como serviço, não precisa fazer esses passos.

sudo ./teamserver <ip> <senha> <profile>

Note que no terminal irá mostra no final o seguinte trecho

SHA256 hash of SSL cert is: <hash>

Ao realizar a conexão via Client, verifique se o hash é o mesmo.

Listeners

No CS, precisamos configurar nosso Listener (Ouvinte) para receber conexões recebidas dos nossos Beacons. Existem dois tipos principais de Listeners, sendo eles o Egress (saída) e o Peer-to-Peer (ponto a ponto). Mas vamos aos detalhes.

Egress Listeners

Esse, permite que o Beacon se comunique fora da rede de destino com nosso servidor. Os tipos padrões de Egress Listener são HTTP/S e DNS, onde o Beacon vai encapsular o tráfego C2 nesses respectivos protocolos.

Para gerenciar os Listeners, vá no Menu Cobalt Strike > Listeners ou clique no ícone de fone de ouvido, que abrirá a guia Listeners, no qual é possível adicionar, editar, remover e reiniciar Listeners.

HTTP

O listener HTTP permite que o Beacon envie e receba mensagens C2 por meio de solicitações HTTP GET e/ou POST. Para criar um novo Listener HTTP, clique em Add. Certifique-se de que Beacon HTTP seja do tipo de payload selecionado e dê um nome ao listener. O nome do listener é usado em muitos comandos CLI do Cobalt Strike, então escolha um que permita reconhecer facilmente qual listener é esse. Clique no pequeno botão de + (próximo à caixa HTTP Hosts). Aqui, você fornece os endereços IP e/ou nomes de domínio para os quais o payload do Beacon retornará a chamada. Por padrão, ele será preenchido automaticamente com o endereço IP da VM Linux do atacante, mas é mais realista usar nomes DNS adequados.

DNS

O Listener DNS permite que o Beacon envie e receba mensagens C2 em vários tipos de pesquisa/resposta, incluindo A, AAAA e TXT. O tipo TXT são usados por padrão porque podem conter a maior quantidade de dados. Isso requer a criação de um ou mais registros DNS para um domínio para o qual o servidor terá autoridade.

Peer-to-Peer

Os listeners Peer-to-Peer (P2P) diferem dos listeners de saída, porque não se comunicam diretamente com o servidor. Em vez disso, os listeners P2P são projetados para encadear vários Beacons em relacionamentos de pai/filho. As principais razões para fazer isso são:

  • Para reduzir o número de hosts conversando com o servidor, pois quanto maior o volume de tráfego, maior a probabilidade de ele ser detectado

  • Para executar o Beacon em máquinas que nem conseguem se comunicar fora da rede, por exemplo em casos de regras de firewall e outras segregações de rede

Os dois tipos de listeners P2P no Cobalt Strike são Server Message Block (SMB) e TCP bruto. É importante entender que esses protocolos não saem da rede de destino (ou seja, o servidor não está escutando SMB na porta 445). Em vez disso, um Beacon SMB/TCP filho será vinculado a um Beacon HTTP/DNS de saída e o tráfego do filho será enviado ao pai, que por sua vez o enviará ao servidor.

SMB

Os listeners SMB são muito simples, pois possuem apenas uma opção, o nome do Pipe. O padrão é msagent_## (onde ## é um hexadecimal aleatório), porém você pode especificar o que quiser. Uma payload do Beacon SMB iniciará um novo servidor de pipe nomeado com esse nome e escutará uma conexão de entrada. Este pipe nomeado está disponível tanto localmente (127.0.0.1) quanto remotamente (0.0.0.0).

Este nome de pipe padrão do CS (msagent_##) já está bem assinado, porém é uma boa estratégia é emular nomes conhecidos por serem usados por aplicativos comuns ou pelo próprio Windows. Execute no Powershell ls \\.\pipe\ para listar todos os pipes atualmente, isso irá servir de base de para definir um nome para o seu Listener. Procure por nomes com o padrão TSVCPIPE-ab55907a-a8af-b0f4-e2bb-3a3af01dac5f e altere os últimos caracteres.

TCP

Um payload do Beacon TCP irá vincular e escutar no número da porta especificado. Você também pode especificar se ele será vinculado apenas ao host local (127.0.0.1), caso contrário, será vinculado a todas as interfaces (0.0.0.0).

Payloads

Ao acessar o Menu Payloads, podemos ver alguns tipos de payloads que estão disponíveis.

  • HTML Application = Gera um arquivo com extensão .hta (deve ser enviado ao alvo por meio de um navegador utilizando engenharia social) e usa VBScript incorporado para executar o payload. Gera apenas payloads para listeners de saída (Egress) e é limitado para a arquitetura x86

  • MS Office Macro = Gera uma parte do VBA que pode ser inserida em um documento MS Word ou Excel habilitado para macro. Gera apenas payloads para listeners de saída (Egress), mas é compatível arquitetura x86 e x64 do Office

  • Stager Payload Generator = Gera um Stager (estágios) de payload em diversas linguagens, incluindo C, C#, PowerShell, Python e VBA. Eles são úteis ao criar seus próprios payloads ou exploits. Gera apenas payloads para listeners de saída (Egress), mas é compatível arquitetura x86 e x64

  • Stageless Payload Generator = Trabalha de forma semelhante ao Stager Payload Generator, porém esse gera payloads Stageless (sem estágios) em vez de stagers. Possui um pouco menos formatos de saída, por exemplo sem PowerShell, mas tem a opção adicional de especificar uma função de saída (process ou thread). Ele também pode gerar payloads para listeners P2P

  • Windows Stager Payload = Produz um stager pré-compilado como um EXE, Service EXE ou DLL

  • Windows Stageless Payload = Produz um paylaod Stageless (sem estágio) pré-compilada como EXE, EXE de serviço, DLL, Shellcode e também PowerShell. Este também é o único meio de gerar payloads para listeners P2P

  • Windows Stageless Generate All Payloads = Produz todas as variantes de payloas do tipo Stageless (sem estágio), para cada tipo de listener, em x86 e x64

Beacons

Após o alvo executar o nosso arquivo malicioso, irá aparecer no grid do Client, um novo registro (Beacon) a mais Na última coluna, temos o sleep, que define de quanto em quanto tempo, o alvo irá fazer um check-in. O Client então manda uma requisição via GET para o alvo, e se tiver algum comando no OS que foi enviado, o alvo executa e devolve a resposta do comando via POST. Para alterar o valor do sleep, basta executar sleep <valor_segundos>. Quanto menor o valor, mais rápido terá a resposta, porém mais ruído irá fazer. Utilize o valor 0 para deixar no modo interativo. Quando o valor da coluna last estiver negrito e itálico, significa que perdeu a conexão com o alvo. Nesse cenário, estamos falando de um HTTP Beacon, mas se fosse um DNS Beacon, não teria seus metadados enviados automaticamente (devido à menor largura de banda de dados do DNS), portanto ele aparecerá na UI como um Beacon "unknown". Sempre que ver um registro de uma nova máquina, dê dois cliques nele para interagir e enviar comandos no SO.

Comandos Úteis

  • getuid = Detalhes do usuário atual

  • jobs = Lista todos os jobs ativos

  • jobkill <JID> = Encerra uma determinada job, através do seu JID, que é capturado com o comando jobs

  • keylogger = Ativa o keylogger. Utilize o jobkill para encerrar

  • clipboard = Exibe o que a pessoa copiou (CTRL + C). Válido somente para texto plano

  • screenshot = Tira um único print da tela. Para ver as imagens, vá no Menu View > Screenshot

  • printscreen = Tira um print da tela via PrintSrc

  • screenwatch = Tira prints periodicamente

  • powershell-import <file.ps1> = Importando módulo no Powershell

  • ps = Lista os processos que estão em execução

  • net logons = Lista todos os usuários que estão conectados na máquina

  • upload <file> = Faz upload de um arquivo

  • download file> = Faz download de arquivos da máquina alvo

  • elevate uac-schtasks tcp-local = Eleva privilégios administrativos na máquina

  • run wmic service get name, pathname = Obtém uma lista de todos os serviços e o caminho para seu executável. Útil para verificar binárioas com falha de Unquoted Service Paths

  • run sc qc <service> = Verificando detalhes de um detereminado serviço

  • logonpasswords = Realiza um Dump de credentiais and hashes através do Mimikatz. Para ver o resultado, vá no Menu View > Credentials

  • portscan <ip> <port> = Verifica se uma determinada porta está aberta

Pivot Listener

Um Pivot Listener só pode ser criado em um Beacon existente e não por meio do Menu Listeners. Esses Listeners funcionam da mesma maneira que os Listeners TCP normais, porém ao contrário. Um payload Beacon TCP padrão se liga a 127.0.0.1 (ou 0.0.0.0) e escuta uma conexão de entrada na porta especificada. Você então inicia uma conexão com ele a partir de um Beacon existente (com o comando connect). O Pivot Listener funciona ao contrário, dizendo ao Beacon existente para vincular e escutar em uma porta, e a novo payload do Beacon TCP inicia uma conexão com ele. Para criar um Pivot Listener, clique com o botão direito em um Beacon e selecione Pivoting > Listener. Isso abrirá uma janela New Listener. Ja janela que abrir, defina um nome e uma porta. Feito isso, vá no Menu Payloads > Windows Stageless Payload. No popup, em Listener selecione o nome do Pivot Listener que acabou de criar e depois cliquie em Generate. Com o EXE gerado, faça com que o alvo execute-o.

Sites

# Agressor Script
https://www.cobaltstrike.com/aggressor-script/index.html

# Extender o CS
https://hstechdocs.helpsystems.com/manuals/cobaltstrike/current/userguide/content/topics/agressor_script.htm

# Domain Fronting
https://www.cyberark.com/threat-research-blog/red-team-insights-https-domain-fronting-google-hosts-using-cobalt-strike/
https://medium.com/@vysec.private/alibaba-cdn-domain-fronting-1c0754fa0142

# Explicação sobre Staged e Stageless
https://buffered.io/posts/staged-vs-stageless-handlers/

Last updated