s3n4t0r-0x0/bear-c2The 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 APT Attack Simulation Repository. 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.
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.
Reaper Node provides C++/Rust payloads /Reaper Node Payloads/ that can be used as customizable templates for environments where a pre-generated payload is not required. The Payloads 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++/Rust 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.
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.