Operational Security (OPSEC)

OPSEC is the practice of protecting information about your operations from adversaries. In red team context, this means avoiding detection by the blue team while achieving objectives.

OPSEC Principles

OPSEC in a red team is a loop, not a checklist: decide what would burn you, work out who can see it, find where you are exposed, then remove the exposure — and repeat as the operation changes shape. The loop matters because the exposure moves. A technique that is invisible during initial access becomes obvious once you are running a persistence mechanism that the blue team already has a rule for.

Pre-Engagement OPSEC

Infrastructure Security

The cheapest way to lose an engagement is to connect your personal identity to the infrastructure. Buy the VPS and the domain through a business entity or the client's procurement, never a personal card; keep the attack machine in a dedicated VM that has never been used for anything else; and keep operational accounts — the ones that log into the team server and the redirector — separate from the accounts you use for email and chat. The separation is what makes "was this us?" an answerable question when the SOC reports an intrusion.

Treat the addresses as disposable and the identities as not. Domains should be registered behind privacy services and aged before use; IPs should come from a cloud provider you can rotate within minutes; and no implant should ever hold the team server's real address. Two redirector layers are usually enough: the outer one is what you expect to lose, the inner one is what the implant actually knows.

Operator communication belongs on a separate channel from the client's. Encrypted, minimal, and with no operational detail on personal devices — an operator's phone is the most likely place for the engagement's target list to end up, and it is the one device the client's own policies do not cover.

Payload OPSEC

Assume every payload is going to be submitted to a sandbox by an analyst and to a public service by a curious user. That means the build must not contain your name, your paths, your tooling versions or a hard-coded C2 address you intend to keep. Strip metadata, rebuild per target so the hash changes, and test against the client's actual EDR where the engagement allows it — a payload that fails in the lab is a finding for the report, a payload that fails on the target is a burned entry point.

Timestomping and metadata removal change what an analyst sees when they look at the file, and both are trivially detectable if done carelessly: a PE whose compile timestamp predates the toolchain that built it, or a file whose $STANDARD_INFORMATION timestamps contradict its $FILE_NAME timestamps, is a stronger IOC than an untouched file would have been (NTFS records both sets; Get-FileHash will not show you the difference, but fls will).

# Metadata removal
exiftool -all= payload.exe

# Timestomping (match a legitimate file — note the two NTFS timestamp sets)
touch -r /Windows/System32/cmd.exe payload.exe

Active Operations OPSEC

Blending In

Anomaly detection is relative to a baseline, so the goal is not to be invisible but to be unremarkable: operate in the target's business hours and time zone, keep beacon timing inside the range their normal application traffic uses, and avoid the clean round numbers that make a callback look machine-generated. A 60-second beacon at exactly 60-second intervals is a signature even when the payload is clean; the same beacon with 30–50% jitter is one more long-lived HTTPS connection in a dataset full of them.

Process lineage is the other half. cmd.exe spawned by WINWORD.EXE is an alert in every mature SOC; the same command run from an implant living inside a process that normally makes network calls is not. Decide which process your code should live in by asking what that process legitimately does, not by which one is easiest to inject into — and remember that a process tree is recorded whether or not the parent still exists.

C2 Traffic OPSEC

Network detection works on three things: destination reputation, protocol shape, and timing. A valid certificate on a categorised domain fixes the first; a malleable profile that matches a real client's headers and URIs fixes the second; sleep plus jitter fixes the third. DNS C2 trades all three for volume — it is slower and easier to spot in aggregate (query length and entropy, subdomain patterns) but survives environments where nothing else egresses.

# Beacon configuration (Cobalt Strike profile syntax)
set sleeptime "60000";    # 60 seconds (longer = stealthier)
set jitter "40";          # 40% randomization
set data_jitter "100";    # Randomize data size
set useragent "...";      # Match browser strings

Command OPSEC

Every command that spawns a process creates an event; every command that runs inside the implant does not. whoami, ipconfig and net user are not suspicious because of what they do but because of where they come from — a user double-clicking ipconfig is normal, an unknown process spawning it at 03:00 is not. Prefer the implant's built-in equivalents, which answer the same question without a child process and without a command line for the SOC to read.

# Sliver built-ins (no process spawn)
sliver > whoami
sliver > ifconfig
sliver > ps

# Cobalt Strike — getuid is built in; shell/run spawn a process
beacon> getuid          # built-in, no child process
beacon> shell whoami    # spawns cmd.exe (logged as 4688) 
beacon> run whoami      # also spawns a process

Where a built-in does not exist, prefer in-process alternatives: read the registry for user and host information, query WMI without launching wmic.exe, or run a .NET assembly in memory. The rule of thumb is that any tool you would type on your own keyboard produces a process creation event on theirs.

Detection Avoidance

Common Detection Triggers

Logging Awareness

You cannot avoid a log you do not know exists. The table below is the short list that decides whether an action is visible in a typical Windows estate — check it before choosing a technique, because the quiet option and the noisy option usually answer the same question.

Artifact Management

Minimize Artifacts

Every file you write is something the client has to be told about and something an analyst can find after the engagement. Prefer execution that never touches disk — execute-assembly for .NET, reflective loading for native DLLs, BOFs for short tasks — and when a file genuinely has to exist, put it in a directory whose contents are expected to change and delete it in the same session that created it. Registry persistence is the same trade: it survives reboots, which is exactly why it is a well-covered detection.

# In-memory execution (no file on disk)
sliver > execute-assembly Rubeus.exe kerberoast

# If a file is unavoidable, remove it in the same session
sliver > rm C:\temp\tool.exe

Cleanup Procedures

Plan cleanup before you create anything. Keep a list of every file, service, scheduled task, registry value and certificate you add, with the host and the time, and remove them in reverse order at the end — that list is also what the client's defenders need in order to tell your activity apart from a real intrusion, so it belongs in the report as an appendix.

Event logs are not part of cleanup. Clearing a log destroys the record the client commissioned the engagement to produce, it is itself one of the loudest events in Windows (1102 for the Security log), and it removes the defender's ability to reconstruct the control test. If the objective specifically includes "can the SOC detect log tampering", that test is scoped, written down, and agreed in advance — it is not something an operator does to hide a mistake. Let normal log retention do the work.

# File cleanup
Remove-Item -Path C:\path\to\file -Force
[System.IO.File]::Delete("path")     # bypasses the recycle bin, so it is not recoverable by the user

# Registry cleanup
Remove-ItemProperty -Path "HKCU:\Software\..." -Name "ValueName"

Incident Response Awareness

Know what starts an incident response, because the moment one starts you are no longer measuring detection — you are interfering with it. The usual triggers are an EDR alert with enough severity to page someone, a SIEM correlation across several hosts, a threat-hunting query that finds your beacon, or a user reporting a mail. Any of those means the client is now spending real money on you.

The response is the same in every case: go quiet (increase sleep, stop new tooling), work out what was seen and from which host, decide with the engagement lead whether the operation is burned, and follow the abort criteria agreed before the engagement started — an active IR investigation, a legal or compliance issue, or unintended impact on a production system. Continuing to push after an IR has started is how a control test becomes an incident.

Communication OPSEC

Operators need a channel that is encrypted, separate from the client's, and separate from anything personal; the client needs a channel that carries status without technical detail. Mixing the two is the common mistake — a screenshot of a beacon in a client Slack channel is operational detail in a system the client's own staff can read, and it is discoverable later.

Documentation follows the same rule: notes live in an encrypted store, operational data is encrypted at rest, anything shared with the client is sanitized first, and the working notes are destroyed when the engagement closes — after the report has been written from them. Assume every channel is monitored, including the ones you set up yourself.

Evidence Collection

False Positive Identification

Testing Checklist

Remediation