ADAPTIXC2: CONHECENDO UMA ALTERNATIVA OPEN SOURCE AO COBALT STRIKE PARA RED TEAM

Operações de Red Team que simulam adversários reais dependem de um componente central: a infraestrutura de Command and Control. É esse elemento que permite ao operador manter uma sessão persistente em um host comprometido, executar comandos, mover lateralmente pela rede e coordenar múltiplos implantes durante uma avaliação de segurança autorizada.

Por muito tempo, o Cobalt Strike dominou esse espaço como padrão de mercado. Sua licença comercial, porém, tem custo elevado e distribuição restrita, o que abriu espaço para alternativas open source amadurecerem. Sliver, Havoc e, mais recentemente, o AdaptixC2 passaram a ocupar essa lacuna, cada um com decisões de arquitetura próprias.

Este artigo analisa o AdaptixC2 em profundidade: sua arquitetura cliente/servidor, os listeners e agentes disponíveis, o suporte a Beacon Object Files, os recursos de tunneling e a interface gráfica usada pelo operador. Também mostramos como compilar e colocar o framework em funcionamento em um laboratório controlado, e fechamos com uma leitura sob a ótica do Blue Team — afinal, entender como um C2 funciona por dentro é o que torna possível detectá-lo.

O que é um framework Command and Control (C2)?

Um framework C2 é o conjunto de software que permite a um operador controlar remotamente um ou mais hosts comprometidos durante uma operação autorizada, de forma centralizada e coordenada. Ele existe porque, depois da exploração inicial de um alvo, é preciso alguma forma estruturada de manter acesso, executar comandos e organizar as próximas etapas da operação — sem isso, cada shell obtido seria um recurso isolado e difícil de gerenciar em escala.

A maioria dos frameworks modernos, incluindo o AdaptixC2, segue o mesmo modelo conceitual:

Operador
   ↓
Cliente C2
   ↓
Servidor C2
   ↓
Listener
   ↓
Agente
   ↓
Host do laboratório

• Operador: o profissional de Red Team conduzindo a operação.
• Cliente C2: a interface (gráfica ou de linha de comando) usada pelo operador para interagir com o servidor.
• Servidor C2 (teamserver): o núcleo do framework. Centraliza sessões, autentica operadores, armazena tarefas e distribui trabalho entre os agentes.
• Listener: o componente que abre uma porta ou serviço de rede e aguarda check-ins de agentes, usando um protocolo específico (HTTP, DNS, SMB etc.).
• Agente (beacon/implant): o software leve em execução no host comprometido, responsável por buscar tarefas, executá-las e retornar resultados.
• Sessão: a linha de comunicação lógica entre um agente específico e o operador, geralmente exibida como uma entrada na interface do cliente.
• Job/task: uma unidade de trabalho enviada a um agente — um comando de shell, um upload de arquivo, a execução de um BOF.

Essa separação em camadas é o que permite que múltiplos operadores trabalhem na mesma operação, que diferentes protocolos de comunicação sejam usados simultaneamente e que o framework evolua sem reescrever o sistema inteiro a cada novo recurso.

O que é o AdaptixC2?

O AdaptixC2 é um framework de pós-exploração e adversary emulation open source, licenciado sob GPL-3.0, construído para uso em testes de segurança autorizados. O projeto se declara explicitamente restrito a operações legítimas de Red Team.

A arquitetura segue o modelo clássico cliente/servidor: o AdaptixServer é escrito em Go e concentra toda a lógica de orquestração — autenticação de operadores, gerenciamento de sessões, persistência de dados e comunicação com os agentes. O AdaptixClient é uma aplicação gráfica multiplataforma construída em C++ com Qt6, responsável por toda a interação visual do operador com a operação.

O que diferencia o AdaptixC2 de boa parte dos concorrentes open source é a ênfase em modularidade: listeners e agentes não são embutidos de forma rígida no núcleo do servidor, mas carregados como extenders — plugins compilados separadamente e integrados em tempo de execução. Essa escolha de arquitetura aproxima o AdaptixC2 do modelo de extensibilidade que consagrou o Cobalt Strike no mercado comercial, mas sem o custo de licenciamento.

Entre os recursos que o framework oferece hoje estão:

• suporte multioperador, com autenticação individual por senha;
• comunicação cliente-servidor autenticada e criptografada;
• suporte a Beacon Object Files (BOF) e Async BOF;
• proxy SOCKS4/SOCKS5 e port forwarding local e reverso;
• terminal remoto, file browser e process browser integrados;
• gerenciamento de targets e de credenciais coletadas durante a operação;
• motor de scripting AxScript para automação e extensões;
• controles de KillDate e Working Time para limitar a janela operacional de um agente.

Entendendo a arquitetura do AdaptixC2

Adaptix Server

O AdaptixServer é o processo central da operação. Ele expõe uma API autenticada para os clientes, mantém o estado da operação em um banco de dados local (criado automaticamente em um diretório data/) e gerencia o ciclo de vida de listeners e agentes. A autenticação de clientes segue um fluxo em camadas: login com validação de credenciais e emissão de um token JWT, seguido de um upgrade para WebSocket protegido por OTP (one-time token) — inclusive para canais secundários, como túneis SOCKS ou sessões de terminal interativo.

Adaptix Client

O AdaptixClient é a superfície de trabalho do operador. Além de listar sessões ativas, ele concentra os módulos de organização da operação: tabela e grafo de sessões, jobs, targets, credenciais, downloads e o gerenciador de extensões. O cliente mantém um diretório local (~/.adaptix) para preferências e projetos, e permite ao operador escolher o que sincronizar com o servidor no momento da conexão.

Listeners

Um listener define o protocolo e a porta pelos quais os agentes farão check-in. Cada listener é implementado como um extender independente, o que permite habilitar apenas os protocolos relevantes para a operação em curso.

Agents

Um agente é o código executado no host comprometido. Ele é responsável por se comunicar com o listener configurado, buscar tarefas pendentes, executá-las localmente e devolver o resultado. Assim como os listeners, os agentes são distribuídos como extenders — o que abre espaço para novos tipos de implante sem alterar o núcleo do servidor.

Extenders

Extenders são o mecanismo de plugin do AdaptixC2: módulos compilados separadamente (listeners, agentes, ou ambos) e registrados no servidor através do arquivo de configuração. Essa é a peça central da proposta de extensibilidade do framework — em vez de um binário monolítico, o operador compõe a instalação com os módulos que a operação exige.

Extension-Kit

O Extension-Kit é o repositório oficial de extensões prontas para o framework, tratado em detalhe mais adiante neste artigo.

Listeners e protocolos

Na versão atual do projeto, os extenders oficiais de listener cobrem:

A diferença conceitual entre eles está no canal de transporte e no contexto de rede em que fazem sentido. Listeners HTTP/HTTPS tendem a se camuflar melhor em redes corporativas comuns; DNS é reservado para ambientes com saída de internet extremamente restrita; SMB não sai da rede local e serve principalmente para encadear agentes já dentro do perímetro; TCP e mTLS priorizam simplicidade e autenticação forte, respectivamente, dentro do próprio laboratório.

Confirme sempre no repositório oficial quais extenders estão disponíveis na branch que você está compilando — a lista de listeners e agentes está sujeita a mudanças conforme o projeto evolui.

O que são Beacon Object Files (BOFs)?

Beacon Object File é um pequeno programa em C, compilado em formato de objeto (.o), carregado e executado dentro do processo do agente — sem precisar gravar um novo executável em disco nem iniciar um processo separado. O conceito ficou conhecido a partir do ecossistema de plugins do Cobalt Strike e, desde então, se tornou um padrão de fato adotado por praticamente todo framework C2 sério, incluindo o AdaptixC2.

A ideia central é modularidade: em vez de embutir cada nova capacidade — enumeração de Active Directory, coleta de credenciais, escalonamento de privilégios — diretamente no agente principal, essas funcionalidades são compiladas separadamente como BOFs e carregadas sob demanda. Isso mantém o agente base pequeno e reduz a superfície exposta em disco, já que o código do BOF só existe na memória do processo durante a execução da tarefa.

O AdaptixC2 suporta duas variantes:

• BOF síncrono: executa, retorna o resultado e libera o agente para a próxima tarefa. É o modelo mais comum, adequado para operações rápidas como consultas ou coleta pontual de dados.
• Async BOF: pensado para tarefas de duração mais longa ou que não bloqueiam o agente enquanto rodam, permitindo que o operador continue interagindo com a sessão sem esperar a conclusão.

As vantagens operacionais desse modelo são claras: menor pegada em disco, reaproveitamento de código entre diferentes engajamentos e um ecossistema de módulos que pode ser compartilhado independentemente do framework em si — muitos BOFs escritos originalmente para outros C2s podem ser adaptados com pouco esforço. A limitação principal é que um BOF mal escrito, com um crash ou vazamento de memória, pode comprometer a estabilidade do processo do agente inteiro, já que roda no mesmo espaço de memória.

Tunneling, SOCKS e Port Forwarding

Depois que um agente está estabelecido, frequentemente é necessário alcançar outros hosts que não têm rota direta até o operador. É para isso que servem os recursos de tunneling do AdaptixC2.

SOCKS4 e SOCKS5

O agente comprometido atua como um proxy SOCKS, permitindo que o operador direcione outras ferramentas (scanners, clientes RDP, navegadores) através da sessão, como se estivesse fisicamente dentro da rede do alvo. O SOCKS5 acrescenta suporte a autenticação e a resolução de nomes do lado remoto.

Operador → Cliente C2 → Servidor C2 → Agente (proxy SOCKS) → Rede interna do laboratório

Local Port Forwarding

Uma porta é aberta na máquina do operador e todo o tráfego recebido nela é encaminhado, através do agente, até um destino específico na rede comprometida — útil para acessar um serviço interno (por exemplo, uma interface administrativa) como se ele estivesse na própria máquina do operador.

Reverse Port Forwarding

O inverso: uma porta é aberta no host onde o agente está rodando, e conexões recebidas ali são encaminhadas de volta até o operador ou até outro ponto da infraestrutura de C2. É útil quando o destino final precisa iniciar a conexão, e não o operador.

Essas funcionalidades existem em praticamente todo framework de Red Team porque replicam um comportamento real de adversário: uma vez dentro do perímetro, o atacante raramente para no primeiro host — ele usa esse ponto de apoio para alcançar o restante da rede.

Conhecendo a interface do AdaptixC2

O AdaptixClient organiza a operação em painéis dedicados, no estilo de outras ferramentas GUI de C2:

• Notifications: feed de eventos da operação — novos check-ins, tarefas concluídas, erros de listener.
• Listeners & Sites: painel de gerenciamento onde listeners são criados, editados e monitorados.
• Extension Docks: área onde extensões carregadas via AxScript expõem seus próprios painéis e menus.
• Session Table: listagem tabular de todos os agentes ativos, com metadados como usuário, host, processo e última atividade.
• Session Graph: visualização em grafo das sessões, útil para entender relações de pivoting entre agentes.
• Jobs & Tasks: fila de tarefas enviadas a cada agente e seu status de execução.
• Chat: canal de comunicação interno entre operadores conectados à mesma operação.
• Tunnels: painel de controle dos túneis SOCKS e port forwardings ativos.
• Downloads: arquivos coletados dos hosts comprometidos, centralizados para análise.
• Targets: catálogo de hosts identificados durante a operação, mesmo os que ainda não têm um agente ativo.
• Credentials: repositório de credenciais coletadas, organizadas por host e tipo.
• Screens: capturas de tela enviadas pelos agentes que suportam esse recurso.
• Agent Console: o terminal de interação direta com um agente específico, onde comandos são digitados e resultados retornam.

Cada um desses painéis existe para resolver um problema real de operações com múltiplos alvos simultâneos: sem uma forma centralizada de rastrear sessões, credenciais e targets, uma operação de Red Team com dezenas de hosts comprometidos rapidamente se torna impossível de gerenciar apenas de memória.

Preparando o ambiente

Para este laboratório, partimos de uma distribuição Linux baseada em Debian (Kali Linux é a referência mais comum em Red Team). O próprio repositório oficial fornece um script de bootstrap, pre_install_linux_all.sh, que resolve as dependências de compilação tanto do servidor quanto do cliente.

Os requisitos confirmados na branch principal do projeto incluem:

• Go (o script instala uma versão própria, com suporte a compatibilidade com Windows 7 nos binários gerados para agentes);
• Qt6 (módulos base, websockets, declarative e svg) para compilar o cliente gráfico;
• OpenSSL (libssl-dev) para os certificados TLS do servidor;
• mingw-w64 para compilação cruzada de agentes Windows a partir do Linux;
• ferramentas de build padrão: git, make, cmake, gcc, g++, build-essential.

O modo servidor demanda um conjunto mais enxuto de dependências, focado em Go e nas ferramentas de cross-compilation para Windows. O modo cliente exige, além disso, todo o conjunto de bibliotecas Qt6 e libxkbcommon-dev, necessário para a interface gráfica.

Obtendo o AdaptixC2

Cada caixa corresponde a um bloco copiável nas seções seguintes. Não é captura do binário Adaptix.

git clone https://github.com/Adaptix-Framework/AdaptixC2.git
cd AdaptixC2

O git clone baixa uma cópia completa do histórico e da estrutura do repositório oficial — incluindo o código do servidor (AdaptixServer/), do cliente (AdaptixClient/), os extenders padrão e os scripts de build. Usar o repositório oficial, em vez de forks ou pacotes de terceiros, garante que você está compilando o código auditável pela comunidade e sem modificações não documentadas.

Instalação das dependências

O script pre_install_linux_all.sh automatiza a instalação de tudo que foi listado na seção anterior, evitando resolver manualmente uma lista longa de pacotes. Ele aceita um argumento indicando o que preparar:

Para uma máquina que vai compilar e rodar apenas o servidor:

sudo bash ./pre_install_linux_all.sh server

Para uma máquina que vai compilar e rodar o cliente gráfico:

sudo bash ./pre_install_linux_all.sh client

O script precisa ser executado como root porque instala pacotes via gerenciador do sistema. Ele registra eventuais falhas em um arquivo de log com timestamp, o que ajuda a diagnosticar problemas de dependência sem precisar rodar tudo de novo em modo verboso.

Antes de rodar esse script em qualquer máquina fora de um laboratório descartável, vale abrir o arquivo e conferir os pacotes que ele instala — é uma boa prática para qualquer script que exige privilégios de root.

Compilando o servidor

O projeto usa um Makefile central para orquestrar o build. Para compilar servidor e extenders de uma só vez:

make server-ext

Esse target executa, em sequência, a limpeza do diretório de saída, a compilação do binário Go do servidor com flags de otimização, e a compilação de todos os extenders encontrados em AdaptixServer/extenders — ou seja, os listeners e agentes padrão do projeto. O resultado fica centralizado no diretório dist/.

Para conferir o que foi gerado:

ls -lah dist/

Você deve encontrar o binário adaptixserver, o arquivo profile.yaml de configuração padrão e as bibliotecas compartilhadas (.so) correspondentes a cada extender habilitado.

Certificado TLS

O AdaptixServer usa TLS para proteger o canal entre clientes e servidor — sem isso, credenciais de operador e todo o tráfego de comando trafegariam em texto claro, algo inaceitável mesmo em um laboratório interno. Para um ambiente de testes, um certificado autoassinado é suficiente:

openssl req -x509 -nodes -newkey rsa:2048 -keyout server.rsa.key -out server.rsa.crt -days 3650

O comando gera um par de chaves RSA de 2048 bits e um certificado X.509 autoassinado, válido por 10 anos, sem senha de proteção na chave privada (-nodes) — aceitável para laboratório, mas nunca para produção. A chave privada (server.rsa.key) nunca deve ser versionada em repositórios, compartilhada ou reutilizada entre ambientes distintos; o certificado (server.rsa.crt) é o único arquivo que pode circular livremente. Em um cenário de operação real, contratada e com validação de terceiros, o certificado deveria ser emitido por uma cadeia própria da operação, não um autoassinado genérico.

Entendendo o profile.yaml

O profile.yaml é o arquivo central de configuração do AdaptixServer, dividido em duas seções principais.

A seção Teamserver controla a lógica de operação:

• interface e port: endereço e porta em que o servidor aceita conexões de clientes;
• endpoint: caminho da URI usado pelos clientes para se conectar (por exemplo, /endpoint);
• password / only_password: credenciais de acesso ao teamserver;
• operators: mapa de usuários adicionais, cada um com seu próprio hash de senha;
• cert / key: caminho para o certificado e a chave TLS gerados na etapa anterior;
• extenders: lista de caminhos para os módulos (.so) que o servidor deve carregar na inicialização;
• access_token_live_hours / refresh_token_live_hours: tempo de vida dos tokens JWT emitidos na autenticação.

A seção HttpServer controla o transporte HTTP/TLS:

• error: página retornada para requisições que não correspondem a um listener válido — um detalhe importante para não expor a existência do C2 a quem faz scanning na porta;
• http: timeouts e limites de requisição;
• tls: versão mínima e máxima do protocolo, e o conjunto de cifras aceito.

Um exemplo mínimo e sanitizado, sem segredos reais:

Teamserver:
  interface: "0.0.0.0"
  port: 4321
  endpoint: "/endpoint"
  password: "CHANGE_ME"
  cert: "server.rsa.crt"
  key: "server.rsa.key"
  extenders:
    - "extenders/listener_beacon_http.so"
    - "extenders/agent_beacon.so"

HttpServer:
  tls:
    min_version: "1.2"
    max_version: "1.3"

O servidor valida essa configuração de forma estrita na inicialização: porta fora da faixa válida, endpoint mal formatado ou certificado ausente impedem o serviço de subir. Isso evita que uma infraestrutura de C2 suba parcialmente configurada e exponha um listener sem TLS por engano. Segredos como senhas e chaves privadas nunca devem ser commitados em repositórios de controle de versão — trate profile.yaml preenchido como um artefato sensível de cada operação, não como um arquivo genérico do projeto.

Iniciando o servidor

Dentro do diretório dist/, com o profile.yaml já ajustado e o certificado no lugar:

cd dist
sudo ./adaptixserver -profile profile.yaml

O servidor lê o profile, valida cada campo, carrega os extenders configurados e passa a escutar na interface e porta definidas. Os logs de inicialização indicam se cada extender foi carregado com sucesso — é o primeiro lugar a olhar se um listener específico não aparecer disponível no cliente depois. Um servidor iniciado corretamente mantém o processo em primeiro plano exibindo eventos de conexão; para rodar como serviço permanente em laboratório, o caminho recomendado é um gerenciador como systemd, e não nohup solto em background.

Compilando o cliente

Em uma máquina com as dependências de cliente já instaladas (via pre_install_linux_all.sh client):

make client

Esse target invoca o CMake para compilar o AdaptixClient em C++/Qt6. Para builds mais rápidos em máquinas com múltiplos núcleos, o projeto também expõe make client-fast, que paraleliza a compilação.

Depois de compilado, o cliente é iniciado diretamente:

./AdaptixClient

Na primeira execução, o AdaptixClient cria um diretório de configuração local (~/.adaptix) para armazenar preferências e projetos. A janela inicial apresenta o formulário de conexão a um teamserver — é ali que entram os dados definidos no profile.yaml do servidor.

Conectando cliente e servidor

A conexão do AdaptixClient ao AdaptixServer usa exatamente os parâmetros definidos na seção Teamserver do profile: endereço IP (ou hostname) da interface configurada, porta, endpoint e senha do operador.

Em um laboratório isolado, use sempre endereçamento privado — nunca um IP público real:

Host: 192.168.56.10
Porta: 4321
Endpoint: /endpoint

Ao conectar, o cliente solicita também um apelido de operador e o nome do projeto local, usados para organizar múltiplas operações dentro do mesmo AdaptixClient. Depois da autenticação inicial (usuário/senha, validado via JWT) e do upgrade para o canal WebSocket protegido por OTP, a interface principal é carregada e as sessões já ativas no servidor aparecem na Session Table.

Expandindo o AdaptixC2 com o Extension-Kit

O Extension-Kit é o repositório oficial de extensões prontas para o framework — a forma mais direta de dar capacidades de pós-exploração ao AdaptixC2 sem escrever BOFs do zero. Ele reúne módulos organizados por finalidade:

AdaptixC2
   ↓
Extension Engine (AxScript)
   ↓
BOFs / Scripts / Módulos

Para obter o kit:

git clone https://github.com/Adaptix-Framework/Extension-Kit.git

Compilando o Extension-Kit

cd Extension-Kit
make

A compilação depende de um toolchain de cross-compilation para Windows, já que a maioria dos BOFs tem como alvo agentes rodando nesse sistema. Em distribuições baseadas em Debian/Ubuntu, isso significa pacotes como g++-mingw-w64-x86-64-posix, gcc-mingw-w64-x86-64-posix e mingw-w64-tools; em Arch Linux, o equivalente é mingw-w64-x86_64-gcc. Confirme os nomes exatos dos pacotes na sua distribuição antes de instalar, já que podem variar entre versões.

O resultado da compilação é consolidado em um arquivo extension-kit.axs, o formato de pacote de extensão lido pelo AdaptixClient. Para carregá-lo, dentro do cliente:

Main menu → AxScript → Script Manager → botão direito → Load new, apontando para o extension-kit.axs gerado.

Depois de carregado, os módulos do kit passam a aparecer nos menus de contexto do Agent Console, prontos para ser executados contra uma sessão ativa.

AdaptixC2 é realmente uma alternativa ao Cobalt Strike?

“Alternativa” não é sinônimo de “equivalente”. O Cobalt Strike carrega mais de uma década de maturidade, um ecossistema imenso de BOFs e Malleable C2 profiles de terceiros, e é o padrão contra o qual a maioria dos produtos de EDR já foi calibrada — o que é, ao mesmo tempo, sua força comercial e uma desvantagem operacional (é bem conhecido pelos defensores). O AdaptixC2 não tenta replicar isso ponto a ponto; ele resolve o mesmo problema — orquestrar uma operação de pós-exploração — com uma arquitetura mais nova, aberta e sem custo de licença.

Na prática, o AdaptixC2 é uma opção sólida para equipes e pesquisadores que precisam de um C2 modular, auditável e sem custo de licenciamento — especialmente para laboratório, formação técnica e operações onde o orçamento ou a política de compras torna o Cobalt Strike inviável. Não é, hoje, um substituto direto em todos os cenários onde a maturidade do ecossistema de terceiros do Cobalt Strike é um requisito.

AdaptixC2 no ecossistema de frameworks C2

Vale situar o AdaptixC2 ao lado de outros dois nomes recorrentes no espaço open source:

• Sliver (Bishop Fox): também em Go, mas opera primariamente via CLI, sem cliente gráfico nativo. Prioriza simplicidade operacional e suporte nativo a múltiplos transportes, incluindo WireGuard.
• Havoc: escrito em C/C++ com cliente Qt, conceitualmente próximo ao AdaptixC2 — GUI multiplataforma, agente (“Demon”) com foco em técnicas de evasão modernas.
• AdaptixC2: se diferencia pela combinação de servidor em Go, cliente Qt6 nativo e uma arquitetura de extenders explicitamente pensada para plugabilidade de listeners e agentes.

Nenhum dos três substitui integralmente o Cobalt Strike hoje, mas juntos representam a direção que o mercado de C2 open source vem tomando: frameworks modulares, com GUI própria, e ecossistemas de extensão que se aproximam cada vez mais do que antes só existia em produtos comerciais.

O que o Blue Team deve saber sobre frameworks C2

Entender a arquitetura de um C2 como o AdaptixC2 é tão relevante para quem defende quanto para quem opera a ferramenta — é essa simetria que torna possível construir detecção.

Do ponto de vista de telemetria de endpoint, agentes de C2 tendem a deixar rastros em pontos previsíveis: criação de processos filhos incomuns a partir de aplicações comuns (browsers, Office, PowerShell), carregamento de módulos não assinados em processos legítimos, e padrões de acesso a memória associados à execução de código injetado — algo que soluções de EDR modernas monitoram através de hooks de API e análise comportamental, não apenas assinatura de arquivo.

No tráfego de rede, listeners HTTP/HTTPS de C2 costumam gerar padrões de beaconing: conexões periódicas, com intervalos e volumes de dados relativamente regulares, para um mesmo destino — um comportamento que se destaca quando comparado ao tráfego humano real, especialmente quando correlacionado por período prolongado. Listeners DNS geram um volume de consultas incomum para um único domínio, muitas vezes com subdomínios de aparência aleatória. Listeners SMB não cruzam o perímetro, mas geram tráfego de named pipes atípico entre hosts internos que vale correlacionar com os logs de autenticação da rede.

Nenhum desses sinais isolados é definitivo — é a correlação entre telemetria de endpoint, logs de DNS/proxy e comportamento de rede ao longo do tempo que revela infraestrutura de C2, seja ela baseada em Cobalt Strike, AdaptixC2 ou qualquer outro framework. Segmentação de rede e monitoramento ativo de saída (egress) continuam sendo os controles mais eficazes para reduzir o raio de ação de um agente, mesmo quando a detecção inicial falha.

OPSEC em laboratórios de Red Team

Alguns cuidados básicos evitam que um laboratório de testes vire, ele mesmo, um risco:

• mantenha o laboratório em uma rede isolada, sem rota para produção ou internet pública desnecessária;
• use snapshots de máquina virtual para restaurar o ambiente rapidamente entre testes;
• nunca reutilize credenciais reais — use sempre usuários e senhas fictícios no ambiente de laboratório;
• gere certificados TLS próprios para cada laboratório, e nunca reaproveite chaves privadas entre ambientes;
• restrinja o acesso à interface do teamserver por firewall, mesmo dentro da rede isolada;
• nunca exponha a porta do AdaptixServer diretamente à internet;
• não reutilize senhas de operador entre diferentes engajamentos ou laboratórios;
• destrua a infraestrutura temporária (servidor, certificados, agentes compilados) assim que o teste for concluído.

Problemas comuns durante a instalação

Sintoma: make client falha ao encontrar módulos do Qt.
Possível causa: pacotes Qt6 incompletos ou variáveis de ambiente de CMake apontando para uma instalação diferente.
Como diagnosticar: rode qmake6 --version (ou o equivalente da distribuição) e confira se todos os pacotes exigidos pelo pre_install_linux_all.sh client foram de fato instalados.
Correção: reexecute o script de pré-instalação em modo client e confirme que não houve falha silenciosa registrada no log de erro gerado pelo script.

Sintoma: compilação do servidor falha por incompatibilidade de versão do Go.
Possível causa: uma instalação de Go pré-existente no sistema conflita com a versão esperada pelo projeto.
Como diagnosticar: rode go version e compare com a versão exigida no script de pré-instalação.
Correção: use a instalação de Go provisionada pelo próprio pre_install_linux_all.sh, evitando misturar com uma instalação de Go já existente no PATH.

Sintoma: adaptixserver encerra imediatamente ao iniciar.
Possível causa: profile.yaml inválido — porta fora de faixa, endpoint mal formatado ou caminho de certificado incorreto.
Como diagnosticar: leia a mensagem de erro impressa no console; o servidor valida o profile de forma estrita antes de abrir qualquer listener.
Correção: corrija o campo indicado no log e confirme que os arquivos de certificado e chave existem no caminho declarado.

Sintoma: porta do teamserver já está em uso.
Possível causa: outra instância do servidor, ou outro serviço, já está vinculada à porta configurada.
Como diagnosticar: verifique processos escutando na porta com uma ferramenta de rede padrão do sistema.
Correção: finalize o processo conflitante ou altere a porta no profile.yaml.

Sintoma: AdaptixClient não consegue se conectar ao servidor.
Possível causa: divergência entre o endpoint/porta configurados no cliente e os definidos no profile.yaml, ou bloqueio de firewall entre as máquinas do laboratório.
Como diagnosticar: confirme conectividade de rede básica entre cliente e servidor, e revise se os campos preenchidos no formulário de conexão batem exatamente com o profile.
Correção: ajuste os parâmetros de conexão ou libere a porta do teamserver no firewall da máquina servidora, respeitando o isolamento do laboratório.

Conclusão

O AdaptixC2 é um framework de pós-exploração open source construído sobre uma arquitetura cliente/servidor modular: servidor em Go, cliente gráfico em Qt6, e listeners e agentes carregados como extenders independentes. Essa modularidade é o que permite ao operador compor uma instalação sob medida — habilitando apenas os protocolos de comunicação relevantes para cada operação — e ao projeto evoluir adicionando novos módulos sem reescrever o núcleo do servidor.

No ecossistema de C2, ele ocupa um espaço em expansão ao lado de Sliver e Havoc: alternativas abertas e sem custo de licença ao domínio histórico do Cobalt Strike, ainda sem a mesma maturidade de ecossistema, mas evoluindo rapidamente e já com recursos consolidados como suporte a BOF, tunneling SOCKS e port forwarding.

Estudar um framework como esse em laboratório vale tanto para quem atua ofensivamente quanto para quem defende: entender como listeners, agentes e beaconing funcionam por dentro é o que transforma telemetria bruta em detecção real de infraestrutura de C2.