OPSEC Checklist

A checklist of XoloC2 configurations and practices that reduce your exposure during a real engagement. Not all apply to every scenario — use what fits.

Server

Run behind a redirector — never expose your real C2 IP. Use Apache, nginx, or Caddy to proxy only valid beacon URIs. See the Redirectors tutorial.
Use a valid TLS certificate — self-signed certs generate AV/proxy alerts and are trivially fingerprinted. Use Let’s Encrypt on the redirector.
Enable IP whitelist — restrict panel access to your operator IPs. Beacon endpoints always bypass the whitelist.
Enable MFA — require TOTP for all operator accounts. See MFA Setup.
Enable webhook alerts — get notified of unexpected logins or failed auth attempts. See Webhook Notifications.
Rotate agent secret after each engagement — go to Settings > Security > Rotate Secret. Old beacons from previous engagements will stop working.
Back up the database before secret rotation or upgrades: cp server/xoloc2.db server/xoloc2.db.bak

Beacon configuration

Set a kill date — beacon self-destructs after the engagement window. Prevents lingering implants.
Set a heartbeat timeout — beacon self-destructs if the C2 is unreachable for N days. Avoids orphaned implants if your server goes down.
Enable traffic camouflage — randomized real-browser User-Agents and Referer headers blend beacon polling into normal HTTPS traffic.
Enable sandbox detection — beacon checks for VM indicators, sandbox usernames/hostnames, and analysis tools before running. Reduces detonations in sandboxes.
Tune sleep + jitter — high sleep (60–300 s) + high jitter (40–80%) reduces polling frequency and makes timing-based detection harder. Use lower values only during active interaction.
Use server-side key delivery — if binary forensics is a risk, use the server-side key encryption mode so the AES key is never embedded in the beacon.
Set fallback C2 URLs — add a secondary C2 or redirector URL so the beacon can reconnect if the primary redirector goes down.
Enable persistence only when necessary — persistence (registry run key / crontab) is noisy. Only enable if the engagement requires it.

Delivery

Use the stager system — deliver via a one-time token one-liner instead of copying files. The token expires and is revokable. See Stager Delivery.
Single-use tokens — set max uses to 1 so the payload URL becomes invalid after the first fetch.
Short expiry — set a tight expiry window (1–2 hours) on stager tokens.
Revoke tokens immediately after delivery — don’t leave live stager URLs open longer than needed.

During the engagement

Tag sessions — use the tags and notes fields to track hostnames, roles, and what you’ve done. Easier to track than memory and shows up in reports.
Mark sessions as detected if caught — the detection field tracks EDR/AV name. Useful for the report and for rotating to a different beacon type.
Export task history — use the export button on each session to save command output before deleting a session.
Generate a report before cleanup — capture the full timeline, commands, and exfil listing while data is still in the DB.

Cleanup

Delete sessions after the engagement — removes agent records from the DB. Does not kill the beacon process on the target (that requires a kill or exit command first).
Rotate agent secret — invalidates all previously generated beacons.

Remove persistence — send the appropriate cleanup command before killing the beacon:

# Windows (registry)
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdate /f

# Linux (crontab)
crontab -l | grep -v xolo | crontab -

Clear audit log (admin only, optional) — Settings > Audit Log > Clear. Only do this after exporting any records you need.