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ívelConfigure
Cache Based on Selected Request Headers
comoAll
Em
Forward Cookies
, também selecioneAll
Em
Query String Forwarding and Caching
, selecioneForward 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):
Agora faça um reload, inicie e verifique o seu status
Se o serviço estiver running
, execute:
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).
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.
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:
Sendo assim, adicione a linha abaixo, no início do arquivo .profile
.
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.
Note que no terminal irá mostra no final o seguinte trecho
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 x86MS 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 OfficeStager Payload Generator
= Gera umStager
(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 x64Stageless Payload Generator
= Trabalha de forma semelhante aoStager Payload Generator
, porém esse gera payloadsStageless
(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 P2PWindows Stager Payload
= Produz um stager pré-compilado como um EXE, Service EXE ou DLLWindows 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 P2PWindows 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 atualjobs
= Lista todos os jobs ativosjobkill <JID>
= Encerra uma determinada job, através do seu JID, que é capturado com o comandojobs
keylogger
= Ativa o keylogger. Utilize ojobkill
para encerrarclipboard
= Exibe o que a pessoa copiou (CTRL + C). Válido somente para texto planoscreenshot
= Tira um único print da tela. Para ver as imagens, vá no MenuView
>Screenshot
printscreen
= Tira um print da tela via PrintSrcscreenwatch
= Tira prints periodicamentepowershell-import <file.ps1>
= Importando módulo no Powershellps
= Lista os processos que estão em execuçãonet logons
= Lista todos os usuários que estão conectados na máquinaupload <file>
= Faz upload de um arquivodownload file>
= Faz download de arquivos da máquina alvoelevate uac-schtasks tcp-local
= Eleva privilégios administrativos na máquinarun 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 deUnquoted Service Paths
run sc qc <service>
= Verificando detalhes de um detereminado serviçologonpasswords
= Realiza um Dump de credentiais and hashes através do Mimikatz. Para ver o resultado, vá no MenuView
>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
Last updated