The exploit server for out-of-band findings. Point a target at a domain you own. Every HTTP request and every email it sends back lands in a dashboard you control, and it gets whatever response you choose in return.
BEAR-C2 is an adversary simulation and emulation framework built around real world TTPs inspired by Russian, Chinese, North Korean, and Iranian APT groups. It provides a flexible environment for diverse engagement scenarios and delivers a realistic foundation for red team operations and adversary emulation drawing from related simulation research in the . It supports defense evasion techniques and multiple encryption options for accurate representation of real world intrusion scenarios.
[!CAUTION] It's essential to note that this project is for educational and research purposes only, and any unauthorized use of it could lead to legal consequences.
git clone https://github.com/S3N4T0R-0X0/BEAR-C2.git && cd BEAR-C2
chmod +x requirements.sh && ./requirements.sh
./BEAR-C2
Accurately replicating APT techniques requires a flexible environment capable of mimicking connection protocols, encryption methods, exfiltration techniques, and C2 Channels/Profiles used in modern intrusions. However, achieving this level of precision has always been a challenge.
Every time an operator needs to test a specific encryption scheme with a particular exfiltration profile, a separate C2 script must be built to match the attack scenario. For example, one simulation might require AES encryption with OneDrive exfiltration, while another might need a different encryption method combined with Dropbox exfiltration to reflect the techniques observed in real world attacks. This lack of flexibility makes the process inefficient and time consuming.
This is why BEAR C2 was developed to provide adversary simulation with full customization through the new listener, allowing seamless configuration of connection protocols, encryption, exfiltration, and automated loading techniques. This ensures that simulations can accurately reflect real APT intrusions without the need to build custom scripts for every scenario.
Reaper Node provides C++ payload samples /Stagers-Loaders/Reaper Node Samples/ that can be used as customizable templates for environments where a pre-generated payload is not required. The samples contain the core configuration fields required to establish communication with the corresponding Reaper Node instance.
Before compiling the payload, the required connection and transport parameters must be configured to match the Reaper Node configuration.
The payload configuration should provide input fields for the following parameters:
Authentication ID The identifier used to associate the payload with the configured Reaper Node instance.
Server Host The IP address or hostname of the Reaper Node endpoint.
Server Port The network port exposed by the Reaper Node for the selected communication protocol.
Encryption Key Required when the selected transport uses encryption. The value must match the encryption configuration used by the Reaper Node. If encryption is disabled, this field is not required.
User-Agent The HTTP client identification value used when establishing the initial HTTP/HTTPS communication. The payload should use a User-Agent supported by the corresponding Reaper Node configuration.
The User-Agent does not need to be identical across different Reaper Node configurations. A payload can use any User-Agent defined as supported by the selected Reaper Node profile, as long as the resulting configuration is compatible with the server-side transport settings.
The following example shows a sample HTTPS transport configuration with authentication, server addressing, encryption, and User-Agent parameters:
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;
This configuration represents an HTTPS transport with encryption enabled. The values shown above are placeholders and should be replaced with the parameters defined by the corresponding Reaper Node configuration.
The C++ sample is intended to provide a starting point for customization. Users can modify the configuration and transport-related parameters according to the Reaper Node profile they are testing, then compile the customized payload for their authorized simulation environment.
The Listeners Table provides a centralized overview of all active and configured C2 listeners. It displays essential details such as listener name, address, network protocol, encryption method, exfiltration profile, and current status (Active or Stopped/Disconnected). From this interface, operators can start, stop, rename, or remove listeners with ease. It also offers quick access to encryption keys and authentication IDs for managing beacon communication. This table serves as the command hub for orchestrating and monitoring your C2 infrastructure.
This version features a full GUI that streamlines adversary simulation operations through centralized listener management, real-time session tracking, customizable communication profiles, integrated exfiltration workflows, and flexible operator controls for efficient engagement management.
⚠️ NOTE: This project is under active development. Features are continuously added and improved.
| Feature | Description |
|---|---|
| Multi-Protocol Listeners | DoH, HTTPS, HTTP, QUIC, Reverse TCP |
| Per-Listener Encryption | AES, XOR, RC4, DES, ChaCha20, RSA |
| Exfiltration Profiles | Google Drive, OneDrive, Dropbox |
| Integrated C2 Channels | Integrated Telegram, Discord C2 communication channel |
| Proxy Support | SOCKS4, SOCKS4a, and SOCKS5 proxy and redirector support |
| Dynamic Domain Generation Algorithm | DGA support for resilient infrastructure simulation |
| JA3S Fingerprinting | Customizable JA3S fingerprints for traffic simulation and network profile tuning |
| Malleable C2 Profiles | Support for community Malleable C2 profiles for flexible network traffic simulation |
| Stagers & Loaders | Automated stager and loader techniques designed for APTs adversary simulation |
| Integrated Tooling | Built-in script obfuscator, phishing toolkit, and file hosting |
| TLS Certificate Generation | Self-signed TLS certificates mimicking trusted vendors |
| HTTP Customization | Base64 URL encoding and custom HTTP headers for both client and server communication |
| Real-time Session Manager | Live status tracking, session monitoring, and real‑time update capabilities |
| Custom Naming & URI Paths | User‑defined campaign names and configurable URI paths for operational flexibility |
Configure per-session exfiltration settings for supported cloud storage providers such as Google Drive, OneDrive, and Dropbox. The Exfiltration Profile interface allows you to define API access tokens and destination folder paths, enabling you to customize data collection workflows for each session. Each session can use its own exfiltration profile, making it easy to route collected data to different cloud storage providers or destinations depending on the operation.
The Telegram communication layer uses a Telegram bot as the intermediary between the C2 server and the payload. The C2 server authenticates to the Telegram account using the configured API ID, API Hash, and Phone Number, then connects to the previously created Telegram bot through that account
The bot's Bot Token is embedded in the payload, allowing the payload to communicate with the bot through the Telegram API. Commands are sent from the C2 server to the bot, and the bot forwards them to the payload, which executes the received tasking and returns the results through the same communication path. This creates a bidirectional command and control channel using Telegram as the communication layer.
Open @BotFather in Telegram and create a new bot using /newbot.
/newbotbot
The Bot Token is required by the Telegram Agent to authenticate with the Telegram Bot API.
Open the official Telegram API development portal and create a new application.
Generate the following credentials: https://my.telegram.org/apps
API IDAPI Hash
These credentials are used by BEAR-C2 to authenticate the Telegram account used to manage the bot communication.
Open Telegram Agent.cpp and configure the Telegram communication settings.
The Bot Token generated by BotFather must be placed in /Stagers-Loaders/C2 Channel Agent Samples/Telegram Agent.cpp before compiling the payload.
The configuration flow is:
BotFather → Bot Token → payload.cpp → Compile
The API ID and API Hash are used by the BEAR-C2 Telegram integration, while the Bot Token is configured in the Telegram payload so it can communicate with the configured Telegram Bot.
This stage replaces the traditional command and control communication channel with a Discord-based communication layer using the Discord Gateway API. Instead of relying on dedicated servers, fixed IP addresses, or custom domains, operators communicate with the simulated implant through a private Discord channel.
The Discord communication layer uses two Discord bots connected through the same Discord channel. One bot is connected to the C2 server, while the second bot is assigned to the payload. The two bots communicate through the shared Discord channel, allowing tasking and communication between the C2 server and payload through Discord.
Since Discord does not allow bots to directly communicate with other bots, using a shared channel provides the communication path between the two sides.
The Discord Agent uses the Discord Gateway and API as the communication layer between the payload and BEAR-C2. The setup requires Discord Bot applications, a dedicated text channel, the required bot permissions, and the corresponding values configured in the C++ agent sample.
Open the official "Discord Developer Portal" (https://discord.com/developers/applications) and create the Discord Bot applications required for the simulation.
The Discord C2 channel uses two Bot identities:
For each application, open Bot settings and generate the required Bot Token.
Open the Bot configuration in the Discord Developer Portal and enable Message Content Intent.
The Bot must also have the required permissions for the Discord text channel used by the simulation, including:
These permissions allow the Bot to access messages from the configured channel and send messages through the same communication path. Discord requires the Message Content Intent for applications that need to receive message content through the API.
Create a dedicated private text channel for the Discord Agent and add both Bot applications to the channel.
Make sure the same permissions configured in the Discord Developer Portal are also enabled for the Bot applications in the channel.
Copy the Channel ID with Discord Developer Mode enabled. Discord provides the Channel ID through the Copy Channel ID option when Developer Mode is enabled.
The same Channel ID is used by the C2 configuration and the Discord Agent so both sides communicate through the same Discord channel.
Open the Discord Agent sample located at:
"Stagers-Loaders/C2 Channel Agent Samples/Discord Agent.cpp"
The sample provides configuration fields for the Discord Bot Token, Channel ID, and Bot User ID:
Replace the placeholders with the values belonging to the Payload Bot and the dedicated Discord channel.
The "BOT_USER_ID" identifies the Bot account used by the payload. Discord User IDs can be copied after enabling Developer Mode.
In the Discord Channel configuration inside BEAR-C2, provide the corresponding C2 Bot Token, Channel ID, and Listener Name.
The C2 Bot and Payload Bot use the same Discord channel as the communication path, while each side authenticates using its own Bot Token.
After the Discord configuration and payload sample have been completed, compile the C++ Agent for use in the authorized adversary simulation environment.
⚠️ NOTE: C2 Channel Limitations
C2 Channels introduce limitations related to data transfer and Beacon identification when using third party messaging platforms as the communication layer between the C2 Server and Beacons
● Data Transfer Limitations
Telegram and Discord impose a maximum character limit on individual messages exchanged through their bot APIs. In BEAR C2, the C2 Channel acts as a transport layer between the C2 Server and the Beacon, so this limitation applies to the data being transferred through the channel and not to the size of the Beacon payload itself. Data sent from the C2 Server to the Beacon and data returned from the Beacon to the C2 Server may be Base64 encoded before transmission. Since Base64 increases the size of the transmitted representation, the amount of original data that can be transferred in a single message is lower than the platform character limit.
[ Telegram ] 4096 characters maximum per message, 4000 characters configured for C2 data transfer
[ Discord ] 2000 characters maximum per message, 1400 characters configured for C2 data transfer
The configured limits are intentionally kept below the platform limits to provide sufficient margin for the C2 message structure and encoding overhead. When the data exceeds the configured limit, the encoded data must be split into multiple messages and reconstructed by the receiving side.
● Beacon Identification and Response Attribution
C2 Channels also introduce a limitation when multiple Beacons share the same Telegram bot or Discord channel. All Beacons communicating through the same bot or channel use the same communication path, so the C2 Server cannot inherently represent each Beacon as an independent communication session. For example, if five Beacons communicate through the same Telegram bot or Discord channel, they will appear as a single C2 communication path rather than five independently identifiable Beacons.
The same limitation affects command responses. When a command is distributed to multiple Beacons through the same bot or channel, the resulting responses are returned through that same communication path. Without an additional Beacon identification mechanism, the C2 Server cannot reliably determine which Beacon generated a specific response.
The direct solution is to assign a dedicated bot to each Beacon on Telegram, or an isolated channel or bot configuration to each Beacon on Discord. This creates a one to one mapping between the Beacon and its communication path, allowing individual Beacons and their responses to be distinguished. The tradeoff is increased infrastructure and management overhead as the number of Beacons increases.
These limitations are specific to using messaging platforms as C2 transport channels and are independent of the Beacon payload itself.
● Practical Impact
The message size limitation reduces the amount of data that can be transferred at once, which can increase the time required to send commands and receive their output
Using a shared Telegram bot or Discord channel causes multiple Beacons to appear as a single Beacon in the C2 table, while commands are delivered to all Beacons using that bot or channel and responses cannot be reliably attributed to a specific Beacon.
Simulate spear-phishing campaigns through a dedicated interface for configuring and managing phishing scenarios during authorized adversary simulation exercises. The module provides campaign controls such as victim submission limits, configurable phishing parameters, and session management, allowing operators to control campaign behavior and evaluate user interaction with simulated phishing scenarios. It is designed to support controlled phishing assessments while providing operators with greater visibility and control over campaign execution.
Host and distribute files through a dedicated Host File interface with configurable server settings and automated file delivery. Hosted files are automatically loaded when accessed, without requiring user interaction or a manual download prompt. The interface provides centralized file hosting and delivery management for controlled adversary simulation and authorized security testing workflows.
The Script Obfuscator provides a comprehensive obfuscation engine supporting PS1, BAT, HTML, VBS, JS, and PY payloads with multiple configurable obfuscation layers. It includes variable and function renaming, string encryption, junk code insertion, multi-layer obfuscation, anti-debugging techniques, and XOR-based payload encryption. These features increase analysis complexity, reduce script readability, and make reverse engineering significantly more difficult while helping payloads better withstand static analysis.
The complete list of APT groups simulated by BEAR-C2 throughout its development
| Country of Origin | Russia 🇷🇺 | China 🇨🇳 | North Korea 🇰🇵 | Iran 🇮🇷 |
|---|---|---|---|---|
| APT Groups |
Cozy Bear ✅ |
Mustang Panda ✅ |
| Configurable reconnect delays and adjustable timeout thresholds per session |
| Authentication Identifiers | Unique authentication tokens with built‑in expiration controls for enhanced security |
| Session Hardening Utilities | History cleaner, session limiter, and authentication timeout management for active sessions |
|
Labyrinth Chollima ✅ |
|
Helix Kitten |
