Why OPSEC is a habit, not a setting
When I first joined a red team, I thought operational security was about using a proxy and changing my user agent. I learned quickly that it is much bigger than that. OPSEC is the discipline of controlling what the defender can see, when they can see it, and how much they can learn from it. It affects every command, every file, and every conversation.
This post is my personal study note on red team OPSEC. I am writing it because the topic is rarely taught as a system. Most of the advice is spread across different blog posts and operational stories. My notes are an attempt to collect the habits that matter.
Understand what the defender sees
The first step is understanding the defender's visibility. A network monitor sees the traffic. An endpoint agent sees the processes and the files. A web server sees the requests. A log collector sees the events. Each layer gives the defender a different view of my activity.
The defender's visibility determines what I need to hide. If the endpoint agent is weak, I can leave more files on disk. If the network monitoring is strong, I need to control the traffic pattern. I map the visibility before I choose my techniques.
The map changes during the engagement. If I detect a new agent or a new logging source, I adjust my approach. OPSEC is not a static checklist. It is a reaction to the environment.
Reduce the footprint
The simplest OPSEC control is to create less evidence. I use the operating system's native tools when they can do the job. A built-in tool does not require uploading a file, and its behavior is often less suspicious than a random binary.
When I do need a tool, I keep it in memory or use a temporary location. I avoid writing the tool to a path that is monitored. I also remove the tool when I am done.
Every file I create is evidence. Every command I run is evidence. Every connection I make is evidence. I ask myself whether the action is necessary before I perform it.
Control the traffic
The network traffic is one of the most visible parts of an operation. An attacker who sends a burst of requests at the same time every minute is easy to detect. I randomize the timing and the volume of my activity.
The traffic should look like normal user behavior. A web scan that sends hundreds of requests with a fixed delay looks automated. A series of requests that follow the normal user flow looks less suspicious. The balance between speed and stealth is different for every engagement.
The destination also matters. A connection to a random IP on an unusual port is more suspicious than a connection to a common cloud service on port 443. I use infrastructure that blends in with the target's normal traffic when possible.
Choose the tools carefully
The choice of tools is an OPSEC decision. Public exploit tools have known signatures, and the defender may have rules that detect them. A tool that is used by every attacker will be blocked or alerted before I finish.
Custom tools are harder to detect, but they require more time to build and test. I choose the tool based on the target environment, the defender's capabilities, and the time available. A simple native command is often better than a complex framework.
I also check the tool's behavior before I use it. Some tools write configuration files, create logs, or make network calls that I did not expect. I test the tool in a lab and inspect what it leaves behind.
Manage credentials
Credentials are a critical OPSEC risk. If I use the same credential for two engagements, a leak in one engagement exposes the other. I use unique credentials, unique hostnames, and unique infrastructure for every client.
The credentials should be stored securely. I do not keep plaintext passwords in a shared folder or a note that everyone can read. I use a password manager or an encrypted vault, and I rotate the credentials regularly.
The credential lifecycle matters too. A credential that is not rotated after the engagement is a risk. I track where each credential was used and remove it when the work is complete.
Control the communication
The communication channel is part of the operation. A command and control server that sends regular beacons is easy to detect. I use a channel that matches the expected traffic and varies the pattern.
The communication should be encrypted. A plaintext channel can be read by the defender and used to understand the operation. I also protect the operational chat, because the chat messages reveal the plan.
The infrastructure should be isolated. I use a separate server, a separate domain, and a separate account for each engagement. The isolation prevents one operation from being linked to another.
Keep the engagement rules in mind
OPSEC is not only about stealth. It is also about safety and coordination. A red team operation can accidentally trigger a real incident if the defender does not know it is happening. I coordinate with the detection team and use a clear deconfliction process.
The rules of engagement define the boundaries. They tell me which systems are in scope, which actions are allowed, and which times are off limits. I follow the rules even when a different approach would be stealthier.
The deconfliction process is a communication channel between the red team and the blue team. It prevents the red team from being mistaken for a real attacker. It also helps the blue team learn from the exercise.
Clean up the operation
The cleanup phase is the final test of OPSEC. Every account, file, listener, and credential that I created should be removed. The cleanup should be verified, not assumed.
I keep a list of everything I created during the engagement. The list includes the tools, the accounts, the listeners, the scheduled tasks, and the temporary files. At the end, I compare the list with the actual state of the systems.
The cleanup also includes the infrastructure. I remove the relay server, the domain, and the credentials that were used. The infrastructure is part of the operation, and leaving it behind is a risk.
Debrief and improve
The debrief is where I learn from my mistakes. I review the operation and identify the OPSEC failures, the near misses, and the successes. The review should be honest, because the goal is to improve.
The improvements become part of my notes. I update the checklist, the tool selection, and the infrastructure setup. The next engagement starts from a better place.
Operational channels
The way the team communicates during an operation is part of the footprint. If the team uses the same chat server for every engagement, the chat history becomes a link between operations. I prefer separate channels and separate accounts for each client.
The channel should be encrypted and should not be accessible from the target network. A team member who connects to the operational chat from a compromised workstation can expose the entire operation. I keep the operational channel off the target network.
The messages themselves should be concise. A long conversation about a tool or a technique is useful to a defender who can read it. I use codenames and avoid writing the real hostnames and credentials in the chat.
The channel also needs a clear deconfliction process. If the blue team detects the activity, the red team needs a fast way to confirm that it is part of the exercise. A separate emergency channel can be used for that confirmation.
Infrastructure isolation
The red team infrastructure should be isolated by engagement. A domain used for one client should not be used for another. A credential stored in the same vault as another client's credentials creates a link between the operations.
The isolation starts with the domain registration. I use a separate domain, a separate hosting account, and a separate certificate for each engagement. The DNS records and the TLS certificates can be correlated by a defender.
The infrastructure should also have a short lifetime. A relay server that remains active after the engagement is a risk. I remove the server, the domain, and the credentials when the operation is complete.
The isolation is not only about hiding. It also limits the damage if one operation is exposed. A defender who discovers one engagement cannot use the discovery to compromise another client.
Operational tempo
The speed of the operation affects the visibility. A fast operation creates a burst of activity that is easy to detect. A slow operation is harder to detect, but it takes longer and gives the defender more time to notice the anomalies.
I adjust the tempo to the engagement goals. If the goal is to test the detection, the tempo should be realistic. If the goal is to test the recovery, the tempo can be slower and more deliberate.
The tempo should also vary during the operation. A constant speed is a signature. I mix fast actions with slow actions, and I avoid repeating the same action at the same interval.
The variation should not look random in a suspicious way. I try to match the tempo to the normal traffic pattern of the environment. A quiet network should not suddenly receive a burst of requests.
Working with defenders
OPSEC is not the same as hiding from the blue team. In a red team exercise, the blue team is expected to detect the activity. The OPSEC controls make the detection harder, but the exercise still needs a way to work together.
The deconfliction process is the bridge. The red team announces the scope, the timeline, and the key indicators. The blue team knows that the activity is part of the exercise, but it does not know every detail.
The balance between secrecy and cooperation is difficult. The red team wants to test the detection, so it should not reveal every step. The blue team wants to respond, so it needs enough information to avoid a false alarm.
The debrief is where the balance is resolved. The red team explains what it did, the blue team explains what it saw, and the two teams learn from the comparison.
A final note on discipline
OPSEC is a discipline that I have to practice even when I am tired. The last hour of an engagement is the easiest time to make a mistake. I close the connections I no longer need, write down the remaining steps, and avoid starting a new tool before I finish the old one. The discipline also includes the report. A red team operation is only useful if the client learns from it. I make sure the report explains the OPSEC decisions, the detection opportunities, and the improvements for the next exercise.
Common mistakes I make
My biggest mistake is focusing on the technical stealth and forgetting the human side. A message in an unsecured chat, a reused credential, or a careless note can expose the operation. My second mistake is using the same infrastructure for multiple engagements. The infrastructure is a link between operations.
The third mistake is not testing the tools before the engagement. A tool that leaves an unexpected file can ruin the operation. The fourth mistake is skipping the cleanup because I am tired at the end.
My quick checklist
- Map the defender's visibility before choosing techniques.
- Use native tools and remove temporary files.
- Control the traffic timing and the destination.
- Test every tool in a lab and inspect its footprint.
- Use unique credentials and rotate them.
- Encrypt and isolate the communication channel.
- Coordinate with the detection team and follow the rules.
- Clean up everything and debrief the operation.
What I would do next time
Next time I want to start with the defender's visibility map instead of the tool list. The map determines which techniques are safe and which are not. I also want to spend more time on the cleanup plan before the operation, because cleanup is harder when I am tired. OPSEC is not a single tool. It is the sum of every decision I make during the operation.