OPSEC Checklist

Operational security checklists for red team engagements. Pre-engagement setup, identity separation, communication security, artifact review, and post-op cleanup.

#Pre-Engagement

#Infrastructure Checklist

Before any engagement, infrastructure must be built and verified independently from personal or previous assets. Rushing this phase leads to burned operations - a single reused domain or misconfigured redirector can unravel an entire engagement. Treat infrastructure setup as a dedicated project with its own timeline and sign-off process.

  • Dedicated VPS per engagement (not reused)
  • Separate C2, redirector, and phishing servers
  • Aged domains (30+ days, categorized)
  • Valid SSL certificates (Let's Encrypt)
  • Redirector rules tested (only C2 traffic passes)
  • Firewall: C2 server only accepts from redirectors
  • SSH hardened (key-only, non-standard port)
  • DNS records configured and propagated
  • Domain categorization verified (Bluecoat, McAfee, etc.)
  • Infrastructure tested end-to-end before go-live

#Identity Separation

Mixing personal and operational identities is the number one OPSEC failure in red team operations. Every engagement needs a clean identity stack - separate accounts, separate machines, separate payment methods. A single overlap between your real identity and your operational persona can compromise the entire operation and, in adversary simulation scenarios, invalidate the assessment.

  • Dedicated email accounts (ProtonMail via Tor)
  • No personal accounts on engagement machines
  • Separate browser profiles (or VMs)
  • VPN/Tor for all infrastructure management
  • Payment: crypto or prepaid cards (never personal CC)
  • No personal phone for engagement comms
  • Dedicated machines/VMs per engagement
  • No cross-contamination between engagements

#During Engagement

#Network OPSEC

Network-level OPSEC protects against attribution back to your real infrastructure and location. Every connection you make to engagement infrastructure or to the target environment is a potential data point for defenders. Assume the blue team is capturing full packet data.

  • Always connect to infra via VPN/Tor
  • Verify VPN kill switch is active
  • DNS leak checks before each session
  • No direct connections to target from personal IP
  • Monitor your own infra for compromise
  • Rotate IP addresses if blocked/flagged
  • Check VirusTotal/AnyRun for sample submissions
  • Avoid uploading tools to public sandbox services

#Host OPSEC

Your engagement workstation is a forensic artifact. If it is ever examined - whether through compromise, legal process, or accidental exposure - it should contain nothing that links back to you personally or to other engagements. Treat it as disposable and compartmentalized.

  • Engagement VM only (no personal use)
  • Disable telemetry in tools (Cobalt Strike, etc.)
  • Timestamp awareness (match target timezone if needed)
  • Clipboard isolation between VMs
  • Screenshot evidence in encrypted storage
  • Avoid storing credentials in plaintext
  • Encrypt all exfiltrated data
  • Clear terminal scrollback regularly

#Payload OPSEC

Payloads are the most scrutinized artifacts in any engagement. A single mistake - leftover metadata, a reused binary hash, or a public sandbox upload - can burn the payload globally and link it back to your team. Every payload should be unique, stripped, and tested privately.

  • Never upload to VirusTotal (use antiscan.me or local testing)
  • Unique payloads per engagement (no reuse)
  • Strip metadata from all files (exiftool -all=)
  • Compile timestamps randomized or zeroed
  • Import table minimized
  • String obfuscation for all sensitive references
  • Test against target's specific EDR before deploying
  • Stage payloads, don't drop full implant at once

#Communication OPSEC

All team communications about the engagement must be treated as sensitive. Assume that any unencrypted channel is monitored. This includes email, SMS, and standard voice calls. Establish secure communication protocols before the engagement begins and enforce them throughout.

  • Encrypted channels only (Signal, Matrix)
  • No engagement details on unencrypted email
  • PGP for any email reporting
  • No real names in tool configs or C2 profiles
  • Sanitize screenshots before sharing (redact IPs, hostnames)
  • Shared secrets for team authentication
  • Pre-agreed emergency burn procedures

#C2 Traffic OPSEC

#Profile Hardening

Raw, unmodified C2 traffic is trivially detected by modern network security monitoring. Every C2 channel must be profiled to blend into the target's normal traffic patterns. The goal is to make your command-and-control traffic indistinguishable from legitimate application traffic on the wire.

  • Malleable C2 profiles (Cobalt Strike) or HTTP profiles (Sliver)
  • Mimic legitimate traffic (user-agent, headers, URI patterns)
  • HTTPS with valid certificate
  • Jitter 20-50% on beacon callbacks
  • Domain fronting or CDN relay where possible
  • Kill date configured (auto-shutdown after engagement)
  • Watermarking disabled or controlled

#Traffic Blending

Select a traffic pattern that matches what the target environment already generates. If the target organization heavily uses Office 365, blending into Graph API traffic is more effective than generic HTTPS browsing. Profile the target's normal egress traffic before choosing your C2 channel.

Pattern Mimics Tools
HTTPS GET/POST Web browsing Malleable C2, custom profiles
DNS TXT DNS resolver DNS C2, DNScat2
WebSocket Chat/streaming Custom C2
Office 365 API Legitimate O365 Graph API C2
Slack/Teams webhook Team collaboration LOLC2 channels

#Post-Engagement

#Cleanup Checklist

Post-engagement cleanup is not optional. Leaving implants, backdoors, or persistence mechanisms on a client's network after the engagement is a serious professional and legal liability. Every artifact you placed must be removed, documented, and verified as removed.

  • Remove all implants/backdoors from target
  • Delete staged payloads and tools
  • Remove persistence mechanisms installed
  • Clear relevant logs (only what you created)
  • Verify removal (re-scan target)
  • Document everything removed for the report

#Infrastructure Teardown

Engagement infrastructure must be completely destroyed after the operation. Leftover VPS instances, active DNS records, or valid certificates are loose ends that can be discovered and attributed back to your team or your client. Use infrastructure-as-code to make teardown deterministic.

  • Revoke SSL certificates
  • Delete DNS records
  • Terminate all VPS instances
  • Wipe VPS before termination (if possible)
  • Delete redirector configs
  • Rotate all credentials/keys
  • Terraform destroy if IaC was used
  • Verify no infrastructure remains

#Data Handling

Exfiltrated data, credentials, screenshots, and logs collected during an engagement are highly sensitive. Handle them according to the rules of engagement (ROE) and the client's data handling requirements. Retain only what is needed for the final report, and destroy everything else on an agreed schedule.

  • All collected data encrypted at rest
  • Transfer report data via secure channel
  • Delete exfiltrated data per ROE
  • Secure evidence storage for reporting period
  • Destroy engagement VM/data after report delivery
  • Client approval before data destruction

#Common OPSEC Failures

#Lessons Learned

Most OPSEC failures are preventable with discipline and process. The table below documents recurring mistakes observed in real-world red team operations and adversary campaigns. Use it as a review checklist before, during, and after every engagement.

Failure Consequence Prevention
Reusing C2 infrastructure Cross-engagement attribution Dedicated infra per engagement
Uploading to VirusTotal Payload signatures burned globally Use private scanning only
Personal email in tool config Real identity exposed Audit all configs before deploy
Direct connection to target IP attribution Always use redirectors/VPN
GPS metadata in screenshots Physical location revealed Strip all metadata (exiftool)
Unencrypted comms Engagement details intercepted E2E encryption mandatory
Same payload across targets One detection burns all Unique per target/engagement
No kill date on C2 Implant persists after engagement Always set kill dates

#OPSEC Tooling

#OPSEC Tools

Curated OPSEC tools by purpose - identity separation, communications, metadata, and infrastructure.

OPSEC Tools

#Also See

#Cyber Aurelien Guidi