What is Red Team? Adversary simulation guide

Red Team is the end-to-end simulation of a real adversary, run to test not only an organization's vulnerabilities but its ability to detect and respond to an attack. Unlike a pentest, the focus is not a defined target but adversarial objectives — data, access, critical processes — reached by whatever path the attacker chooses.

The term comes from the military, where a "red" team plays the enemy to challenge the defenses of the "blue" team. In information security the idea is the same: an authorized group behaves like a genuine attacker — with time, creativity and clear objectives — while the defensive team operates as usual, often unaware that the exercise is under way. What gets measured, in the end, is not only what was vulnerable, but how much the organization saw, how fast it reacted and how far the adversary got before being contained.

What is a Red Team and what does it test?

A Red Team exercise is an authorized, objective-driven offensive operation that reproduces the behavior of a realistic adversary against an entire organization — people, processes and technology. Instead of asking "does this application have flaws?", it asks "if a determined attacker wanted to steal customer data or disrupt process X, could they, and would we notice?".

That changes what is under test. A Red Team evaluates three dimensions a conventional technical test does not reach:

• The full surface. Not a single system, but the combination of applications, network, cloud, endpoints, identity and the human factor. The attack path may start with a phishing e-mail and end on a database server.
• Detection. Every move by the offensive team is a chance to raise an alert. The exercise measures which actions were logged, which triggered investigation and which went unnoticed.
• Response. When (and if) the defense detects the intrusion, the exercise observes reaction time, the quality of containment and coordination between teams.

The product of a Red Team is not a list of vulnerabilities — it is an attack narrative with evidence at every step, cross-referenced with what the defense saw and what it missed. That combined reading, attack against defense, is what gives the exercise its unique value.

What is the difference between Red Team, pentest and Blue Team?

This is the most common confusion when buying. The three terms describe distinct functions, and picking the wrong exercise wastes budget and leaves gaps.

A pentest evaluates a defined target — an application, an API, a network — looking for as many exploitable vulnerabilities as possible within that scope. A Red Team pursues an adversarial objective across whatever surface is necessary, prioritizing stealth and realism over coverage. The Blue Team is the defense: the team that monitors, detects and responds, whether in-house (SOC, incident response) or outsourced. The table below summarizes:

None replaces the others. The pentest is the foundation: there is no point running a Red Team while obvious vulnerabilities remain untreated. Once technical hygiene is mature and the organization wants to know whether it would survive a real attack, the Red Team is the next step. And the Blue Team is the permanent counterpart the exercise exists to put to the test.

What are the phases of a Red Team exercise?

A professional Red Team follows a structured cycle, supported by recognized frameworks — chiefly MITRE ATT&CK, which supplies the vocabulary of tactics and techniques used to plan and document every move. The phases, in the order we run them:

1. Objectives and rules of engagement. Before any action, the team defines what counts as "winning" (for example, access to a specific data set), the operational limits, the testing windows and the emergency contacts. This step guarantees authorization, safety and an objective success criterion.
2. Reconnaissance. Gathering information about the organization, passively (open sources, employees, exposed technology) and actively (mapping surfaces and services). The goal is to find the most realistic entry point.
3. Initial access. Obtaining the first foothold — phishing, exploitation of an exposed service, abuse of leaked credentials or social engineering. Detection is already being tested here.
4. Establishment and persistence. Maintaining access stealthily, ensuring the offensive team survives reboots and possible containment attempts.
5. Privilege escalation and lateral movement. From the initial access, the team expands its reach: obtains more powerful credentials, reaches other systems and closes in on the objective.
6. Actions on objective. Executing what defines the exercise's success — access to the target data, demonstration of disruption to a critical process or controlled exfiltration, always with evidence and without causing real damage.
7. Report and joint debrief. Documenting the full attack narrative, cross-referenced with the defense timeline, and a joint session (Red and Blue) to turn every step into a concrete improvement in detection and response.

The final debrief is what separates a useful Red Team from a vanity exercise. Proving the intrusion was possible is not enough; the value lies in showing, MITRE ATT&CK technique by technique, where the defense could have seen and did not — and how to close each of those gaps.

What is Purple Team and when does it make more sense?

Purple Team is not a third team — it is a working mode in which Red Team and Blue Team operate collaboratively and transparently rather than adversarially. The offensive team executes a specific technique; the defensive team observes in real time whether it produced telemetry, an alert and a response; together they tune detection and repeat. The cycle runs technique by technique.

The difference in intent is the key:

• Red Team measures the defense as it stands today, without warning, prioritizing realism. It answers: "would we get caught?".
• Purple Team improves the defense deliberately, with both sides in the same room, prioritizing learning. It answers: "how do we make sure we catch it next time?".

In practice, a Purple Team usually makes more sense for organizations still maturing their detection capability — the return in coverage is fast and measurable. A pure Red Team pays off more once the defense has consolidated processes and the relevant question has moved from "do we have controls?" to "do they work against a determined adversary?". Many programs alternate the two: Purple to build detection, Red to validate it under realistic conditions.

When does your company need a Red Team?

There are two triggers, which often overlap: security maturity and regulatory or business demand.

On the maturity side, a Red Team makes sense when the organization already has a working security program — recurring pentests, a SOC or detection service, incident response processes — and wants to validate whether all of it holds up against a real attack. Running a Red Team before that is expensive and uninformative: the exercise would find the same obvious flaws a pentest would point out for a fraction of the cost.

On the regulatory and business side, adversary simulation is increasingly expected in critical sectors. In Brazil, financial institutions operate under the BACEN/CMN resolutions on cybersecurity, including Resolution 4.893, which reinforce the need for testing on critical environments — extending to Open Finance integrations and payment environments. In the EU, DORA requires threat-led penetration testing (TLPT) for financial entities designated by their competent authorities. Compliance frameworks such as ISO 27001 treat testing of defensive capability as part of control assessment, and data protection laws such as GDPR and LGPD require technical measures that an adversarial exercise helps evidence. Engage a Red Team, then, when:

• Your organization has already been through pentests and wants to measure detection and response, not only vulnerabilities.
• There is an audit, due diligence or regulatory requirement asking for proof of defensive capability.
• An incident occurred and leadership wants to know, independently, whether the fixes really closed the path.
• The business depends on critical processes whose disruption would have material impact — and nobody has tested, in practice, what would happen under attack.

For organizations already running AI systems in production, the same logic extends to a new surface: models, agents and RAG pipelines have their own failure classes and require specific adversarial scenarios — a topic we cover in AI agent security and in governance under ISO 42001.

How Berghem runs a Red Team

At Berghem, a Red Team exercise starts from the adversarial objective, never from a list of targets. Together with leadership we define what an attacker would actually be after in that context — customer data, privileged credentials, control of a critical process — and work backwards, chaining the techniques needed to get there by the most realistic path, not the most convenient one.

What that means in practice:

• Realism over volume. We would rather demonstrate one complete, stealthy attack path than produce a list of isolated findings. What matters is whether the objective was reached and whether the defense noticed.
• Detection as a first-class metric. Every technique executed is mapped to MITRE ATT&CK and compared with what the organization's telemetry recorded. Detection gaps are as important a result as the vulnerabilities.
• Human analysis driving the operation. Tools accelerate parts of the work; strategy, stealth and chaining are driven by specialists.
• A debrief that becomes improvement. The engagement ends with a joint session between our team and your defense, turning the attack narrative into concrete adjustments to detection and response.

We are an information security company in São Paulo and run Red Team exercises alongside pentests of applications, APIs, networks, cloud environments and AI systems. When maturity does not yet call for a full adversary, the pentest is usually the right starting point — and the Red Team the next step, once the question shifts from "do we have flaws?" to "would we survive a real attack?".

Frequently asked questions

What is the difference between Red Team and pentest?

A pentest evaluates a defined target, looking for as many exploitable vulnerabilities as possible within that scope. A Red Team pursues an adversarial objective across whatever surface is necessary, stealthily, and also measures the organization's detection and response. A pentest measures flaws; a Red Team measures the defense.

Does my company need a pentest before a Red Team?

In most cases, yes. A Red Team pays off when security hygiene is already mature — recurring pentests, detection and response in operation. Before that, the exercise would only find the same obvious flaws a pentest reveals for a fraction of the cost. The pentest builds the foundation; the Red Team validates it.

How long does a Red Team exercise take?

It depends on the objective and scope, but a Red Team always runs longer than a pentest, because it prioritizes stealth and realism over fast coverage. Reconnaissance, initial access and lateral movement take time because they replicate the pace of a real adversary. The timeline is set in the rules of engagement.