🥷Private C2
Red Team C2 Framework Built with Focus on Stealth to emulate adversaries
Introduction
Cobalt Strike remains reliable and well‑established, but its consistency has also made it highly recognizable to modern EDR platforms that have spent years profiling its behavior. The objective of the Private C2 was not to compete with larger frameworks on features, but to operate quietly in areas where traditional tools are easily detected.
The result is a lightweight, flexible, and operationally efficient C2 that deploys cleanly, establishes communication, initializes its environment, and then retrieves only the capabilities required for the mission. It avoids unnecessary components and minimizes activity to reduce detection risk.
Core Capabilities
DLL Proxying via Microsoft-signed binaries
Simulate real ransomware attacks (encryption of all types of files)
Token-based HTTPS communications (agent integrity checks included)
SOCKS tunneling over MS DevTunnel for stealthy outbound traffic
Entra ID token manipulation and exfiltration
MOTW bypass via browser cache smuggling
Sandbox evasion (cursor activity, runtime anomalies, VM detection)
Flexible payload execution: BoF, execute-assembly, inline-execute
XOR-encrypted shellcode
Environment keying to ensure safe execution
Web management interface for real-time tasking and agent control
Tested Where It Counts
Demonstrating stealth in theory is not enough; it must be validated in real, hardened environments. The Private C2 framework has been operationally tested against multiple enterprise‑grade EDR platforms, including SentinelOne, Cortex XDR, CrowdStrike, Elastic EDR, and Cybereason.
Across these evaluations, the platform consistently avoided detection and maintained effective suppression of security telemetry for the duration of each engagement.
In Development
UDRL (User Defined Reflective Loader)
Sleep Mask (in-memory implant encryption during inactivity)
Ransomware Simulation
This custom command‑and‑control infrastructure was developed to replicate the behavior of a real‑world ransomware operation during the final phase of the red team engagement. This objective is reflected in its internal project name, DaBombC4.
Browser cache smuggling
The C2 implant can be deployed through browser cache smuggling, allowing it to bypass traditional download‑based delivery methods that would normally generate Mark of the Web warnings. This approach does not require the user to download any files, as cached content does not inherit Mark of the Web flags by default.
Video-camera stealthily
In addition, a new capability was recently introduced that enables covert camera and microphone recording. This feature leverages legitimate Microsoft Edge functionality to activate audio and video inputs without generating security prompts, as such behavior is commonly associated with routine activities like Microsoft Teams calls.
Dynamic Implant Builder
A web‑based interface is currently under development to allow operators to modify configuration settings and generate implant payloads in real time. This capability will simplify payload staging, support rapid customization, and enable operators to adjust operational parameters directly from the Private C2 control panel as requirements evolve.
SOCKS Tunneling via Microsoft Dev Tunnels
Microsoft Dev Tunnels (*.devtunnels.ms) offers SSH-based port forwarding over Azure’s infrastructure a low-profile, OPSEC-safe alternative to conventional SOCKS proxies for lateral movement and data exfiltration during offensive operations.
Why it works: Traffic routed through Dev Tunnels inherits Azure’s legitimacy. Egress filtering appliances typically allow this traffic by default due to its association with Microsoft developer services.
Operational Use Cases:
Bypass Egress Controls: Traffic blends with legitimate Azure traffic (
SNI: devtunnels.ms), slipping through restrictive firewall rules.Multi-Hop Pivoting: Chain tunnels with
-v(forward) and-r(reverse) flags for controlled routing through intermediate compromised hosts.Efficient Data Exfiltration: Native compression (
-z) combined with WebSocket transport minimizes detection when compared to direct TCP exfil methods.
Private C2 integrates native support for Dev Tunnel operations via the Microsoft.DevTunnels.Cli, offering operators dynamic pivoting and controlled C2 infrastructure exposure.
C2 Agent Integrity Verification
One of the weak points in traditional beaconing frameworks is the lack of robust agent verification mechanisms. Private C2 addresses this using token-based HTTPS communication, inspired by techniques implemented in the Burak framework.
Core Concept: Each agent is cryptographically bound to a unique token, established at build time and verified during check-ins. This ensures that only trusted agents receive tasking, mitigating impersonation and man-in-the-middle risks while blending into legitimate HTTPS C2 traffic.
Workflow Overview:
Token Generation (Server-side): The C2 server generates a unique token for each agent instance.
Payload Embedding: Token is embedded into the agent configuration prior to deployment.
Agent Check-In: On initial callback, the agent presents the token over encrypted HTTPS.
Validation: The C2 server authenticates the token before permitting tasking or staging additional modules.
This process maintains operational integrity, particularly in environments where infrastructure is exposed to hostile monitoring or active defensive operations.
Sentinel One
During testing, SentinelOne did not generate any alerts. Although it registered some memory‑related activity during shellcode injection, such as memory allocation events, it did not classify these behaviors as suspicious. The DLL injection activity appeared entirely benign to the platform, with no anomalies or incidents recorded.
It is important to note that SentinelOne may raise an incident if a trusted process, such as onedrive.exe, is used to spawn cmd.exe and execute commands like tasklist, dir, or hostname, depending on the broader behavioral context.
Elastic EDR
Elastic EDR produced results similar to SentinelOne, with no detections related to implant execution or shell activity. The only alert observed was a low‑severity notification triggered by the implant’s first‑stage persistence mechanism, which involves copying itself into the Startup folder. This behavior generated a minor warning but did not escalate into an incident or investigation.
No additional alerts were raised during execution or when spawning shells, as the implant operated under a Microsoft‑signed binary, which further reduced scrutiny.
This project is designed as a learning platform for understanding malware development concepts in a controlled and responsible environment.
Last updated