O servidor de exploit para descobertas out-of-band. Aponte um alvo para um domínio que você possui. Cada requisição HTTP e cada e-mail que ele envia de volta chega a um painel que você controla, e ele recebe qualquer resposta que você escolher em troca.
O BEAR-C2 é um framework de simulação e emulação de adversários construído em torno de TTPs do mundo real inspiradas em grupos APT russos, chineses, norte-coreanos e iranianos. Ele fornece um ambiente flexível para diversos cenários de engajamento e oferece uma base realista para operações de red team e emulação de adversários, baseando-se em pesquisas relacionadas de simulação no . Ele suporta técnicas de evasão de defesa e múltiplas opções de criptografia para representar com precisão cenários de intrusão do mundo real.
[!CAUTION] É essencial observar que este projeto destina-se apenas a fins educacionais e de pesquisa, e qualquer uso não autorizado dele pode acarretar consequências legais.
git clone https://github.com/S3N4T0R-0X0/BEAR-C2.git && cd BEAR-C2
chmod +x requirements.sh && ./requirements.sh
./BEAR-C2
## 🧠 O Desafio da Simulação de Adversários:
Replicar com precisão as **técnicas de APT** exige um `ambiente flexível capaz de imitar protocolos de conexão, métodos de criptografia, técnicas de exfiltração e Canais/Perfis de C2` usados em intrusões modernas. No entanto, alcançar esse nível de precisão sempre foi um desafio.
<img width="1366" height="732" alt="main " src="https://assets.kitploit.com/production/public/readmes/54775/8af4474bf61f52114745ec8403b4ea6d01d26a57f85913f1f01b4bba559a1eb7/59654a7b465df184554d5c31ee49293c1f5d9da71a1e6ef81aa0a2fa5b88b8ea-display-v1.webp" />
Toda vez que um operador precisa testar um **esquema de criptografia** específico com um determinado **perfil de exfiltração**, um **script C2** separado `deve ser criado para corresponder ao cenário de ataque.` Por exemplo, uma simulação pode exigir **criptografia AES** com **exfiltração via OneDrive**, enquanto outra pode precisar de **um método de criptografia diferente** combinado com **exfiltração via Dropbox** para refletir as técnicas observadas em ataques do mundo real. Essa falta de flexibilidade torna o processo ineficiente e demorado.
<img width="1359" height="680" alt="Screenshot From 2026-09-01 05-54-48" src="https://assets.kitploit.com/production/public/readmes/54775/c106129e53832b08e6575610090337721e4e5892eade10bee395fae638326cc2/299229b4ffae9286d368a6e9243c4528d469f5395f166d9b67fa0020beaf5d8a-display-v1.webp" />
É por isso que o **BEAR C2** foi desenvolvido para fornecer **simulação de adversários** com personalização total através do novo listener, permitindo a configuração contínua de `protocolos de conexão, criptografia, exfiltração,` e técnicas de carregamento automatizado. Isso garante que as simulações possam refletir com precisão **intrusões APT** reais sem a necessidade de criar scripts personalizados para cada cenário.
## Amostras de Payload do Reaper Node
O Reaper Node fornece amostras de payload em C++ `/Stagers-Loaders/Reaper Node Samples/` que podem ser usadas como modelos personalizáveis para ambientes onde um payload pré-gerado não é necessário. As amostras contêm os campos de configuração principais necessários para estabelecer comunicação com a instância correspondente do Reaper Node.
Antes de compilar o payload, os parâmetros de conexão e transporte necessários devem ser configurados para corresponder à configuração do Reaper Node.
### Configuração do Payload
A configuração do payload deve fornecer campos de entrada para os seguintes parâmetros:
* **Authentication ID**
O identificador usado para associar o payload à instância configurada do Reaper Node.
* **Server Host**
O endereço IP ou hostname do endpoint do Reaper Node.
* **Server Port**
A porta de rede exposta pelo Reaper Node para o protocolo de comunicação selecionado.
* **Encryption Key**
Necessária quando o transporte selecionado usa criptografia. O valor deve corresponder à configuração de criptografia usada pelo Reaper Node. Se a criptografia estiver desabilitada, este campo não é necessário.
* **User-Agent**
O valor de identificação do cliente HTTP usado ao estabelecer a comunicação HTTP/HTTPS inicial. O payload deve usar um User-Agent suportado pela configuração correspondente do Reaper Node.
O User-Agent não precisa ser idêntico entre diferentes configurações do Reaper Node. Um payload pode usar qualquer User-Agent definido como suportado pelo perfil selecionado do Reaper Node, desde que a configuração resultante seja compatível com as configurações de transporte do lado do servidor.
### Exemplo de Configuração
O exemplo a seguir mostra uma configuração de transporte HTTPS de exemplo com autenticação, endereçamento do servidor, criptografia e parâmetros de User-Agent:```cpp
const string AUTH_ID = "YOUR_AUTH_ID";
const string SERVER_HOST = "YOUR_SERVER_HOST";
const int SERVER_PORT = YOUR_SERVER_PORT;
const string KEY = "YOUR_ENCRYPTION_KEY";
const string DEFAULT_USER_AGENT = "YOUR_USER_AGENT";
bool VERIFY_SSL = true;
Esta configuração representa um transporte HTTPS com criptografia habilitada. Os valores mostrados acima são placeholders e devem ser substituídos pelos parâmetros definidos pela configuração correspondente do Reaper Node.
O exemplo em C++ tem como objetivo fornecer um ponto de partida para personalização. Os usuários podem modificar a configuração e os parâmetros relacionados ao transporte de acordo com o perfil do Reaper Node que estão testando e, em seguida, compilar o payload personalizado para seu ambiente de simulação autorizado.
A Tabela de Listeners fornece uma visão centralizada de todos os listeners C2 ativos e configurados. Ela exibe detalhes essenciais, como nome do listener, endereço, protocolo de rede, método de criptografia, perfil de exfiltração e status atual (Ativo ou Parado/Desconectado). A partir desta interface, os operadores podem iniciar, parar, renomear ou remover listeners com facilidade. Ela também oferece acesso rápido às chaves de criptografia e IDs de autenticação para gerenciar a comunicação dos beacons. Esta tabela serve como o hub de comando para orquestrar e monitorar sua infraestrutura C2.
Esta versão apresenta uma GUI completa que simplifica as operações de simulação de adversários por meio de gerenciamento centralizado de listeners, rastreamento de sessões em tempo real, perfis de comunicação personalizáveis, fluxos de trabalho de exfiltração integrados e controles flexíveis para operadores, permitindo um gerenciamento eficiente dos engajamentos.
⚠️ NOTA: Este projeto está em desenvolvimento ativo. Recursos são continuamente adicionados e aprimorados.
| Recurso | Descrição |
|---|---|
| Listeners Multi-Protocolo | DoH, HTTPS, HTTP, QUIC, Reverse TCP |
| Criptografia por Listener | AES, XOR, RC4, DES, ChaCha20, RSA |
| Perfis de Exfiltração | Google Drive, OneDrive, Dropbox |
| Canais C2 Integrados | Canal de comunicação C2 integrado Telegram, Discord |
| Suporte a Proxy | Suporte a proxy e redirector SOCKS4, SOCKS4a e SOCKS5 |
| Algoritmo de Geração Dinâmica de Domínios | Suporte a DGA para simulação de infraestrutura resiliente |
| Fingerprinting JA3S | Fingerprints JA3S personalizáveis para simulação de tráfego e ajuste de perfil de rede |
| Perfis Malleable C2 | Suporte a Malleable C2 profiles da comunidade para simulação flexível de tráfego de rede |
| Stagers e Loaders | Técnicas automatizadas de stager e loader projetadas para simulação de adversários APT |
| Ferramentas Integradas | Obfuscador de scripts integrado, kit de phishing e hospedagem de arquivos |
| Geração de Certificados TLS | Certificados TLS autoassinados imitando fornecedores confiáveis |
| Personalização HTTP | Codificação Base64 de URL e cabeçalhos HTTP personalizados para comunicação tanto do cliente quanto do servidor |
| Gerenciador de Sessões em Tempo Real | Rastreamento de status ao vivo, monitoramento de sessões e capacidades de atualização em tempo real |
| Nomes Personalizados e Caminhos de URI |
Configure definições de exfiltração por sessão para provedores de armazenamento em nuvem suportados, como Google Drive, OneDrive, e Dropbox. A interface Exfiltration Profile permite definir tokens de acesso à API e caminhos de pastas de destino, possibilitando personalizar fluxos de trabalho de coleta de dados para cada sessão. Cada sessão pode usar seu próprio perfil de exfiltração, facilitando o roteamento dos dados coletados para diferentes provedores de armazenamento em nuvem ou destinos, dependendo da operação.
A camada de comunicação do Telegram usa um bot do Telegram como intermediário entre o servidor C2 e o payload. O servidor C2 autentica-se na conta do Telegram usando o API ID, API Hash e Número de Telefone configurados, e então se conecta ao bot do Telegram previamente criado por meio dessa conta
O Bot Token do bot é incorporado ao payload, permitindo que o payload se comunique com o bot através da API do Telegram. Os comandos são enviados do servidor C2 para o bot, e o bot os encaminha para o payload, que executa a tarefa recebida e retorna os resultados pelo mesmo caminho de comunicação. Isso cria um canal bidirecional de comando e controle usando o Telegram como camada de comunicação.
Abra o @BotFather no Telegram e crie um novo bot usando /newbot.
/newbotbot
O Bot Token é exigido pelo Agente Telegram para autenticar-se na API do Telegram Bot.
Abra o portal oficial de desenvolvimento da API do Telegram e crie uma nova aplicação.
Gere as seguintes credenciais: https://my.telegram.org/apps
API IDAPI Hash
Essas credenciais são usadas pelo BEAR-C2 para autenticar a conta do Telegram usada para gerenciar a comunicação do bot.
Abra Telegram Agent.cpp e configure as definições de comunicação do Telegram.
O Bot Token gerado pelo BotFather deve ser colocado em /Stagers-Loaders/C2 Channel Agent Samples/Telegram Agent.cpp antes de compilar o payload.
O fluxo de configuração é:
BotFather → Bot Token → payload.cpp → Compile
O API ID e o API Hash são usados pela integração do BEAR-C2 com o Telegram, enquanto o Bot Token é configurado no payload do Telegram para que ele possa se comunicar com o Bot do Telegram configurado.
Esta etapa substitui o canal tradicional de comunicação de comando e controle por uma camada de comunicação baseada em Discord usando a Discord Gateway API. Em vez de depender de servidores dedicados, endereços IP fixos ou domínios personalizados, os operadores se comunicam com o implante simulado através de um canal privado do Discord.
A camada de comunicação do Discord usa dois bots do Discord conectados através do mesmo canal do Discord. Um bot está conectado ao servidor C2, enquanto o segundo bot é atribuído ao payload. Os dois bots se comunicam através do canal compartilhado do Discord, permitindo tarefas e comunicação entre o servidor C2 e o payload por meio do Discord.
Como o Discord não permite que bots se comuniquem diretamente com outros bots, o uso de um canal compartilhado fornece o caminho de comunicação entre os dois lados.
O Agente Discord usa o Discord Gateway e a API como camada de comunicação entre o payload e o BEAR-C2. A configuração requer aplicações de Bot do Discord, um canal de texto dedicado, as permissões de bot necessárias e os valores correspondentes configurados no exemplo de agente em C++.
Abra o "Discord Developer Portal" oficial (https://discord.com/developers/applications) e crie as aplicações de Bot do Discord necessárias para a simulação.
O canal C2 do Discord usa duas identidades de Bot:
Para cada aplicação, abra as configurações de Bot e gere o Bot Token necessário.
Abra a configuração do Bot no Discord Developer Portal e habilite o Message Content Intent.
O Bot também deve ter as permissões necessárias para o canal de texto do Discord usado pela simulação, incluindo:
Essas permissões permitem que o Bot acesse mensagens do canal configurado e envie mensagens pelo mesmo caminho de comunicação. O Discord exige o Message Content Intent para aplicações que precisam receber conteúdo de mensagens através da API.
Crie um canal de texto privado dedicado para o Agente Discord e adicione ambas as aplicações de Bot ao canal.
Certifique-se de que as mesmas permissões configuradas no Discord Developer Portal também estejam habilitadas para as aplicações de Bot no canal.
Copie o Channel ID com o Modo de Desenvolvedor do Discord habilitado. O Discord fornece o Channel ID através da opção Copy Channel ID quando o Modo de Desenvolvedor está habilitado.
O mesmo Channel ID é usado pela configuração do C2 e pelo Agente Discord para que ambos os lados se comuniquem através do mesmo canal do Discord.
Abra o exemplo do Agente Discord localizado em:
"Stagers-Loaders/C2 Channel Agent Samples/Discord Agent.cpp"
O exemplo fornece campos de configuração para o Bot Token do Discord, Channel ID e Bot User ID:
Substitua os placeholders pelos valores pertencentes ao Payload Bot e ao canal dedicado do Discord.
O "BOT_USER_ID" identifica a conta de Bot usada pelo payload. Os User IDs do Discord podem ser copiados após habilitar o Modo de Desenvolvedor.
Na configuração do Canal do Discord dentro do BEAR-C2, forneça o C2 Bot Token, Channel ID, e Listener Name correspondentes.
O C2 Bot e o Payload Bot usam o mesmo canal do Discord como caminho de comunicação, enquanto cada lado se autentica usando seu próprio Bot Token.
Após a configuração do Discord e o exemplo de payload terem sido concluídos, compile o Agente em C++ para uso no ambiente autorizado de simulação de adversários.
⚠️ NOTA: Limitações dos Canais C2
Os Canais C2 introduzem limitações relacionadas à transferência de dados e à identificação de Beacons ao usar plataformas de mensagens de terceiros como camada de comunicação entre o Servidor C2 e os Beacons
● Limitações de Transferência de Dados
Telegram e Discord impõem um limite máximo de caracteres em mensagens individuais trocadas através de suas APIs de bot. No BEAR C2, o Canal C2 atua como uma camada de transporte entre o Servidor C2 e o Beacon, portanto essa limitação se aplica aos dados sendo transferidos através do canal e não ao tamanho do payload do Beacon em si. Os dados enviados do Servidor C2 para o Beacon e os dados retornados do Beacon para o Servidor C2 podem ser codificados em Base64 antes da transmissão. Como o Base64 aumenta o tamanho da representação transmitida, a quantidade de dados originais que pode ser transferida em uma única mensagem é menor que o limite de caracteres da plataforma.
[ Telegram ] 4096 caracteres no máximo por mensagem, 4000 caracteres configurados para transferência de dados C2
[ Discord ] 2000 caracteres no máximo por mensagem, 1400 caracteres configurados para transferência de dados C2
Os limites configurados são intencionalmente mantidos abaixo dos limites da plataforma para fornecer margem suficiente para a estrutura da mensagem C2 e a sobrecarga de codificação. Quando os dados excedem o limite configurado, os dados codificados devem ser divididos em várias mensagens e reconstruídos pelo lado receptor.
● Identificação de Beacon e Atribuição de Respostas
Os Canais C2 também introduzem uma limitação quando vários Beacons compartilham o mesmo bot do Telegram ou canal do Discord. Todos os Beacons que se comunicam através do mesmo bot ou canal usam o mesmo caminho de comunicação, portanto o Servidor C2 não pode inerentemente representar cada Beacon como uma sessão de comunicação independente. Por exemplo, se cinco Beacons se comunicam através do mesmo bot do Telegram ou canal do Discord, eles aparecerão como um único caminho de comunicação C2 em vez de cinco Beacons identificáveis independentemente.
A mesma limitação afeta as respostas de comandos. Quando um comando é distribuído para vários Beacons através do mesmo bot ou canal, as respostas resultantes são retornadas através desse mesmo caminho de comunicação. Sem um mecanismo adicional de identificação de Beacon, o Servidor C2 não pode determinar de forma confiável qual Beacon gerou uma resposta específica.
A solução direta é atribuir um bot dedicado a cada Beacon no Telegram, ou uma configuração isolada de canal ou bot para cada Beacon no Discord. Isso cria um mapeamento um para um entre o Beacon e seu caminho de comunicação, permitindo que Beacons individuais e suas respostas sejam distinguidos. A contrapartida é o aumento da infraestrutura e da sobrecarga de gerenciamento à medida que o número de Beacons aumenta.
Essas limitações são específicas do uso de plataformas de mensagens como canais de transporte C2 e são independentes do payload do Beacon em si.
● Impacto Prático
A limitação de tamanho de mensagem reduz a quantidade de dados que pode ser transferida de uma só vez, o que pode aumentar o tempo necessário para enviar comandos e receber suas saídas
Usar um bot do Telegram ou canal do Discord compartilhado faz com que vários Beacons apareçam como um único Beacon na tabela C2, enquanto os comandos são entregues a todos os Beacons que usam esse bot ou canal e as respostas não podem ser atribuídas de forma confiável a um Beacon específico.
Simule campanhas de spear-phishing através de uma interface dedicada para configurar e gerenciar cenários de phishing durante exercícios autorizados de simulação de adversários. O módulo fornece controles de campanha, como limites de submissão de vítimas, parâmetros de phishing configuráveis e gerenciamento de sessões, permitindo que os operadores controlem o comportamento da campanha e avaliem a interação do usuário com cenários simulados de phishing. Ele foi projetado para apoiar avaliações controladas de phishing, proporcionando aos operadores maior visibilidade e controle sobre a execução da campanha.
Hospede e distribua arquivos através de uma interface dedicada de Host File com configurações de servidor configuráveis e entrega automatizada de arquivos. Os arquivos hospedados são carregados automaticamente quando acessados, sem exigir interação do usuário ou um prompt manual de download. A interface fornece hospedagem centralizada de arquivos e gerenciamento de entrega para fluxos de trabalho controlados de simulação de adversários e testes de segurança autorizados.
O Script Obfuscator fornece um mecanismo abrangente de ofuscação com suporte a payloads PS1, BAT, HTML, VBS, JS e PY com múltiplas camadas configuráveis de ofuscação. Ele inclui renomeação de variáveis e funções, criptografia de strings, inserção de código inútil, ofuscação em múltiplas camadas, técnicas anti-debugging e criptografia de payload baseada em XOR. Esses recursos aumentam a complexidade da análise, reduzem a legibilidade dos scripts e tornam a engenharia reversa significativamente mais difícil, ao mesmo tempo que ajudam os payloads a resistir melhor à análise estática.
A lista completa de grupos APT simulados pelo BEAR-C2 ao longo de seu desenvolvimento
| País de Origem | Rússia 🇷🇺 | China 🇨🇳 | Coreia do Norte 🇰🇵 | Irã 🇮🇷 |
|---|---|---|---|---|
| Grupos APT |
Cozy Bear ✅ |
Mustang Panda ✅ |
| Nomes de campanha definidos pelo usuário e caminhos de URI configuráveis para flexibilidade operacional |
| Controles de Reconexão e Timeout | Atrasos de reconexão configuráveis e limites de timeout ajustáveis por sessão |
| Identificadores de Autenticação | Tokens de autenticação exclusivos com controles de expiração integrados para maior segurança |
| Utilitários de Fortalecimento de Sessão | Limpador de histórico, limitador de sessões e gerenciamento de timeout de autenticação para sessões ativas |
| [**Labyrinth Chollima ✅**](https://github.com/S3N4T0R-0X0/APTs-Adversary-Simulation/tree/main/North%20Koreans%20APT/Labyrinth%20Chollima) [**Velvet Chollima ✅**](https://github.com/S3N4T0R-0X0/APTs-Adversary-Simulation/tree/main/North%20Koreans%20APT/Velvet%20Chollima) [**Famous Chollima ✅**](https://github.com/S3N4T0R-0X0/APTs-Adversary-Simulation/tree/main/North%20Koreans%20APT/Famous%20Chollima) [**Stardust Chollima ✅**](https://github.com/S3N4T0R-0X0/APTs-Adversary-Simulation/tree/main/North%20Koreans%20APT/Stardust%20Chollima) [**Ricochet Chollima ✅**](https://github.com/S3N4T0R-0X0/APTs-Adversary-Simulation/tree/main/North%20Koreans%20APT/Ricochet%20Chollima) [**Silent Chollima ✅**](https://github.com/S3N4T0R-0X0/APTs-Adversary-Simulation/tree/main/North%20Koreans%20APT/Silent%20Chollima) |
|
Helix Kitten |
