c2

# 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 | 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 ```nginx # /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 ```