c2

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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

From dazeb/botron, Apache-2.0.

More from dazeb/botron