Red teaming: simulating a real attack

Red teaming is a goal-driven simulation of a real adversary. Instead of scanning one system for as many flaws as possible, a red team is handed a business objective, for example reach the production payments database or exfiltrate a copy of the customer table, and given the freedom to reach it by any path it chooses. That path can run through technology, through people, and where agreed in advance through physical access to a building. The point is not a long list of vulnerabilities. The point is a single honest answer: can a capable attacker reach the thing that matters, and will anyone notice while they do it.

For a regulated company this distinction is the whole value. A penetration test tells you whether a given application or network is hardened. A red team tells you whether your people, your processes, your technology, and crucially your detection and response work together when a real attacker is moving through the environment with intent. That is exactly the question a board, an auditor, or a financial-sector supervisor asks after an incident. Red teaming answers it before the incident, under controlled conditions, with a debrief instead of a breach notification.

Raptoric delivers red teaming as part of offensive security. This guide explains what it is, how it differs from a pentest, the phases of an operation, how it maps to MITRE ATT&CK, and when your organization is actually ready for one.

What red teaming is, and how it differs from a pentest

A penetration test is scoped to a target. You name an application, an external range, or an internal network, and the tester works through it methodically to find and prove as many exploitable weaknesses as possible within the time available. The defenders usually know it is happening. The deliverable is a ranked list of vulnerabilities with evidence and remediation advice. That is the right tool for most testing needs, and we cover it in depth in our penetration testing services guide and in VAPT.

A red team is scoped to an objective and a scenario, not a target. The brief sounds like a threat: a financially motivated group wants to reach the wire-transfer system, or an insider wants to copy the source code. The team then chooses its own route. It may phish a finance clerk, abuse a misconfigured cloud identity, pivot from a compromised laptop, or walk into a reception area with a cloned badge. Scope is deliberately broad because real attackers do not respect the boundaries of a single system.

The second big difference is stealth. A red team works quietly and assumes it is being watched, because testing detection is half the exercise. It paces its activity, blends with normal traffic, and avoids noisy tools so it can find out whether your monitoring catches a careful adversary, not just a loud automated scan. The measure of success shifts too. A pentest measures how vulnerable a system is. A red team measures whether an attacker can achieve a business objective and how long your defenders take to see it, contain it, and evict it. For the difference between a real test and an automated scan, see pentest vs scan.

A pentest asks how vulnerable this system is. A red team asks whether an attacker can reach the crown jewels, and whether you would ever know.

The phases of a red team operation

A red team operation follows the same shape as a real intrusion. It is not a single event but a campaign that unfolds in stages, each of which gives the defending team an opportunity to detect it. Understanding the phases is what makes the eventual report useful, because each phase maps to a specific defensive control you can then improve.

1. 01
   Reconnaissance

   The team gathers open-source intelligence on the organization: employees, technologies, exposed services, and supplier relationships. Much of this overlaps with external attack surface management, and most of it is invisible to the defender.
2. 02
   Initial access

   The team gets its first foothold, typically through targeted phishing, stolen or sprayed credentials, an exposed and unpatched service, or a physical entry where that is in scope.
3. 03
   Foothold and persistence

   Once inside, the team establishes a stable command-and-control channel and a way to survive a reboot or a password reset, so it does not lose access at the first sign of cleanup.
4. 04
   Lateral movement

   The team escalates privileges and moves from the entry point toward the objective, harvesting credentials and abusing trust relationships between systems and identities.
5. 05
   Objective and exfiltration

   The team reaches the defined goal, for example access to the target data or system, demonstrates impact safely, and where the scenario calls for it simulates exfiltration, all without causing real damage.

Throughout these phases the red team is recording two things in parallel: how it succeeded, and whether the blue team saw it. A finding such as we reached the objective in nine days and triggered three alerts that were never investigated is far more valuable to a regulated business than any single vulnerability, because it points at the gap between having detection and acting on it.

Mapping to MITRE ATT&CK

Serious red teams describe their activity using MITRE ATT&CK, a public knowledge base of the tactics and techniques real adversaries use, observed in actual intrusions.² ATT&CK organizes behaviour into tactics, the attacker's goal at each stage such as initial access, persistence, privilege escalation, lateral movement, and exfiltration, and techniques, the specific methods used to achieve each goal.

Mapping every action to an ATT&CK technique turns the engagement into a common language that both the offensive and defensive sides understand. When the report says the team used spearphishing for initial access and then valid accounts for lateral movement, your detection engineers can check exactly which of those techniques your tooling covers and which slipped through unseen. This is also what lets a red team feed directly into a SIEM, EDR, or XDR tuning effort: each missed technique becomes a concrete detection to build or improve, rather than a vague instruction to monitor more.

The blue team and purple teaming

The blue team is the defending side: the people and tooling responsible for detecting, investigating, and responding to attacks, usually centred on a security operations centre and often delivered as managed detection and response. In a classic red team engagement the blue team is kept in the dark, because the realism of their reaction is part of what is being measured. That is the right approach when the goal is an honest assessment of detection as it stands today.

Purple teaming flips the model from competition to collaboration. The red and blue teams work together in the same room or on the same call. The red team runs a technique, the blue team checks whether it generated a signal, and if it did not, they build or tune a detection on the spot and the red team runs it again. Purple teaming is less about getting caught and more about closing gaps quickly. Many mature programs alternate: a covert red team once a year to test reality, and purple team sessions in between to systematically raise coverage against the ATT&CK techniques that matter most to their threat profile.

When you are mature enough for a red team

Red teaming is not a starting point, it is a checkpoint. Its value comes from stress-testing defences that already exist. If your organization has never run a structured penetration test, has not closed the obvious findings from a vulnerability assessment, and has no working detection capability, a red team will simply walk to the objective and hand you a list of basic problems you could have found far more cheaply.

The signals that you are ready are concrete. You run regular penetration tests and remediate what they find. You have built detection and have a team or service that actually investigates alerts. You have an incident response plan you have rehearsed. At that point a red team stops being a way to find easy bugs and becomes a way to answer the harder question: against a patient, capable adversary, do all these controls hold together, and does the human side of detection and response work under realistic pressure. That is the insight no single pentest can give.

Threat-led testing for finance: TIBER-EU and DORA

In the financial sector, red teaming is becoming a supervised, structured practice rather than an optional extra. The European Central Bank publishes the TIBER-EU framework, which standardises threat-led penetration testing, often shortened to TLPT, for financial entities. Under TIBER-EU the scenario is driven by real threat intelligence about who is likely to attack the institution and how, and the test is run against live production systems under tight rules of engagement, with the regulator informed.

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, takes this further by making advanced threat-led penetration testing a legal requirement for significant financial entities, conducted periodically and aligned with frameworks such as TIBER-EU. If you fall under DORA, threat-led testing is not just good practice, it is part of demonstrating digital operational resilience to your supervisor. We break down the obligations in our DORA compliance checklist and across the DORA compliance overview, and contrast the regime with NIS2 in NIS2 vs DORA.

How Raptoric helps

Raptoric runs red team operations with a clearly defined objective, threat-led scenarios, and strict rules of engagement, mapping every action to MITRE ATT&CK so the result feeds straight into your detection program. As an independent firm we will also tell you honestly when you are not ready yet, and recommend a pentest, a VAPT, or detection work first, because a red team you are not ready for is wasted spend. For threat-led testing under TIBER-EU and DORA, we scope the exercise to your supervisory obligations. See offensive security and book a scoping call.