VPS Security

End-to-end security for red team attack infrastructure — from anonymous acquisition through hardened provisioning, encrypted storage, C2 deployment, continuous monitoring, and rapid teardown.

This skill treats every VPS as a disposable, compartmentalized node in an attack infrastructure graph. The goal is never "secure a server for production" — it is "make this node operationally useful while leaving zero forensic trail when it burns."

Reference Files

Opsec Profile Integration

Every action in this skill adapts to the active opsec profile. Check the current profile before starting any VPS work:

node "${CLAUDE_PLUGIN_ROOT}/scripts/opsec-profile.js" show

Workflow

Phase 1 — Plan

1. Determine engagement requirements: how many VPS nodes, what roles (C2, redirector, phishing, exfil), which regions
2. Check opsec profile — this dictates every subsequent decision
3. Design the infrastructure graph: which nodes talk to which, what protocols, what domains
4. Read references/anonymous-acquisition.md for provider selection

Phase 2 — Acquire

1. Acquire VPS nodes anonymously per opsec profile
2. Use separate identities per node (email, payment, provider account)
3. Log acquisition details via ops-tracker

Phase 3 — Provision

1. Run the hardened provisioning playbook from references/hardened-provisioning.md
2. Set up encrypted storage per references/encrypted-storage.md
3. Configure C2/redirector infrastructure per references/c2-infrastructure.md
4. Log all provisioning steps

Phase 4 — Operate

1. Monitor with auditd, tripwire, fail2ban — severity depends on opsec profile
2. Rotate SSH keys and access credentials periodically
3. Watch for provider abuse notifications
4. Maintain ops-tracker entries for all changes

Phase 5 — Teardown

1. Follow rapid teardown procedures from references/teardown-and-recovery.md
2. Wipe data, destroy snapshots, burn accounts as profile dictates
3. Log final teardown actions

Compartmentalization Principles

Compartmentalization is the single most important opsec practice for attack infrastructure. Every node should be isolated so that compromise of one does not expose others.

Rules:

• One role per VPS: never run C2 and phishing on the same box
• Separate identities per VPS: different email, different payment method, different provider if possible
• No direct C2-to-target traffic: always go through at least one redirector
• Segment by engagement: never reuse infrastructure across engagements
• Network isolation: VPS nodes communicate only through encrypted tunnels (WireGuard preferred); no direct SSH between nodes
• Time-bound: every VPS has a planned destruction date; extend only with justification

Recommended architecture for a standard engagement:

Target ←→ Redirector(s) ←→ C2 Team Server ←→ Operator (via Tor/VPN)
                                    ↕
                              Exfil Server (separate)
                                    ↕
                         Encrypted Backup (offline)

Cross-Skill References

Logging

All VPS security operations MUST be logged:

node "${CLAUDE_PLUGIN_ROOT}/scripts/ops-tracker.js" add \
  --category "vps-security" \
  --action "<action>" \
  --detail "<detail>"

Use these action types for consistency:

• acquire — VPS purchased/provisioned
• provision — Initial hardening applied
• encrypt — Disk/partition encryption configured
• c2-deploy — C2 or redirector deployed
• monitor-setup — Monitoring configured
• rotate — Credentials or keys rotated
• teardown — VPS wiped and destroyed
• backup — Encrypted backup created
• incident — Unexpected event (abuse report, anomaly detected)