What Is a Red Team: Complete Business Guide

A Red Team is an offensive team that simulates a real, complete attack against your organisation to measure whether your defence detects it in time and responds well. We don't go after a long list of vulnerabilities like in classic pentesting: we go after getting in, persisting and reaching a concrete goal (taking control of Active Directory, exfiltrating sensitive data, reaching the CEO) while your Blue Team tries to catch us without knowing we're inside. The difference with a pentest is fundamental: a pentest measures what fails; a Red Team measures what happens when someone exploits it. A typical exercise runs 6 to 16 weeks, combines OSINT, targeted phishing, EDR evasion and lateral movement, and ends with an honest debriefing that usually shifts security investment priorities for the next year.

What a Red Team is

A Red Team is a group of offensive cybersecurity professionals that emulates the behaviour, tools and objectives of a real attacker against a specific organisation. The question it answers isn't "what vulnerabilities do I have?" but "could an organised group compromise my business today without us seeing it coming?".

The term comes from Cold War military doctrine. The RAND Corporation used "red teams" to think like the adversary and stress-test defence plans. The transposition to the digital world is exact: instead of simulating an attack on a base, we simulate the compromise of your infrastructure to find the cracks a motivated attacker would find before they do.

In practice, a Red Team exercise:

• Starts without privileged information (black-box model) or from an agreed starting point (assumed breach).
• Pursues business objectives, not technical checklists: domain control, access to the customer database, reading management committee mail.
• Uses any reasonable vector: phishing, phone social engineering, USB implants, physical access, vulnerabilities exposed on the web, credential leaks on the dark web.
• Runs without prior notice to the defensive team (Blue Team), except for a small group known as the White Team that is aware and authorises the exercise.
• Measures detection and response, not just exploitation: how long does the SOC take to alert after the first suspicious move? Does the compromised endpoint get isolated? Do reused credentials get hunted down?

It's deliberately uncomfortable. And it should be: if everyone involved felt comfortable, we wouldn't be measuring reality.

Red Team vs Blue Team vs Purple Team: differences in a table

These three terms get mixed up constantly in RFPs. The distinction isn't academic: it changes cost, schedule and, above all, what gets measured.

The quick rule: Red Team measures detection capability under real pressure; Purple Team trains the Blue Team while specific techniques are attacked. If your SOC has never seen an attacker moving inside, you first need Purple to teach and then Red to examine. If you already have mature detections and want an honest grade, go straight to Red.

What exactly a Red Team does during the exercise

After planning with the White Team, the team starts with the least visible and most decisive phase: reconnaissance. Nothing gets attacked yet; a map gets built.

For days or weeks, the Red Team tracks public OSINT to understand the organisation: org charts on LinkedIn, forgotten domains and subdomains, Google Dorks over corporate domains, public repositories with leaked secrets, systems exposed on Shodan, corporate credentials leaked in combolists, external providers with access to your network. All the information typically gets consolidated into a graph with Maltego and, increasingly, accelerated with generators like DorkGPT. The goal is to answer: how would I get in if I were an attacker with budget and patience?

Then comes initial access. Here what almost always works is the boring stuff: a phishing email with a credible lure (an invoice, a fake SharePoint share, an internal meeting invite), a combo of leaked credentials reused, or an unpatched N-day vulnerability in an exposed service. Spoiler: the glamorous 0-day vector is the least common.

Once inside, the exercise shifts tempo:

• C2 establishment (Command & Control) discreet, avoiding burned domains and known tools the EDR would detect on the spot.
• Local privilege escalation to reach, for example, NT AUTHORITY\SYSTEM or root.
• Lateral movement between machines using techniques like pass-the-hash, Kerberoasting or exploitation of trust relationships.
• Persistence through scheduled tasks, service accounts, malicious GPOs, implants in legitimate software.
• Action on objectives: simulated exfiltration, access to critical systems, demonstration of impact.

And all this without triggering the SOC's alerts, if possible. That's the hard part. A good Red Team isn't the one that throws ten exploits; it's the one that gets in, lives inside for six weeks and leaves having demonstrated it could have done anything, without anyone raising a hand.

Is a Red Team a group of ethical hackers?

Yes, technically it is: they're professionals using offensive skills with contractual authorisation to improve their clients' security. But calling a Red Team "ethical hackers" falls short and adds noise.

A bug hunter on a bug bounty programme is also an ethical hacker. A consultant doing pentesting on an API is too. The difference with a Red Team is scope, authorisation and goal:

• Scope: not limited to an application or perimeter. It's the whole organisation.
• Authorisation: there's a signed contract, an identified White Team and written rules of engagement (ROE) on what can and can't be touched.
• Goal: not to find vulnerabilities for you to fix; to demonstrate business impact and measure your detection.

That's why we prefer talking about offensive cybersecurity professionals or red teamers and reserving "ethical hacker" for more general conversations. The label matters less than understanding what's being contracted.

Exercise types: TTX, full-scope, intelligence-led

Not every Red Team exercise is the same. It's worth knowing the formats before asking for a quote, because the cost difference between a TTX and a TLPT is one or two orders of magnitude.

Tabletop Exercise (TTX)

A Tabletop Exercise is a conversational exercise, not technical. The team sits around a table (literally or virtually) and a facilitator presents an attack scenario in phases. At each phase, participants describe what they would do, what tools they would use, what decisions they would make.

• Duration: half a day to two days.
• Cost: low.
• When: validating response plans, training the crisis committee, practising coordination with legal and communications.

It isn't Red Team in the strict sense, but often gets sold as such. If an RFP says "Red Team" and the proposal only details in-person sessions without system access, it's a TTX and should cost what a TTX costs.

Full-scope Red Team

The "complete" exercise: real technical access, multiple vectors, business objectives, without prior notice to the Blue Team. Everything is on the table here: phishing, implants, optional physical intrusion, social engineering, EDR evasion, persistence.

• Duration: typically 6 to 16 weeks.
• Cost: medium to high, depending on scope.
• When: honest maturity evaluation, validation of SIEM/SOAR/EDR investment, preparation for a demanding audit.

This is the format most companies have in mind when they say "we want a Red Team".

Intelligence-led Red Team (TIBER-EU / TLPT)

Regulated variant of full-scope with two differentiating traits: the exercise runs on production systems and is based on threat intelligence specific to the sector and the entity. It's the methodology the ECB consolidated as TIBER-EU in 2018 and that DORA makes mandatory, under the name TLPT, for designated financial entities, with minimum frequency every 3 years.

• Duration: 12 to 20 weeks usually.
• Cost: high. Public sector ranges quote €80,000 to €250,000 depending on complexity.
• When: required by regulation (DORA, local TIBER) or by the regulator.

If your organisation isn't a designated financial entity, you don't need TLPT. If it is, you need an accredited provider: TIBER-EU and TLPT covers the requirements in detail.

Red Team vs Pentesting: when to use each

This confusion costs companies the most money. They buy "a Red Team" when what they need is a pentest, or they request a cheap pentest when they need to measure the full chain.

The practical rule: if your Blue Team still doesn't detect a mass scan from outside, you're not ready for Red Team. You need pentesting plus detection tuning first. Skipping steps is throwing money away.

To decide between classic pentesting and Red Team, ask yourself: do I want to know what vulnerabilities I have or what would happen if someone exploited them? The first question is pentest. The second is Red Team.

The phases of a Red Team exercise

Although each provider has its variant, the basic chain is standardised and aligns with the Cyber Kill Chain and MITRE ATT&CK. At Secra we work with this sequence:

1. Planning and rules of engagement (ROE). We define objectives, scope, excluded systems, time windows, kill switch mechanism and signatures. We agree here what happens if someone from the SOC detects us and calls the authorities, because it happens.
2. Client-specific threat intelligence. We study which APT groups attack the sector, which TTPs they use per MITRE ATT&CK, what credentials of the organisation are leaked, what vectors are most likely.
3. Reconnaissance (OSINT and passive enumeration). Without touching client infrastructure. Map of people, systems and providers.
4. Offensive infrastructure development. C2 servers, redirectors, warm and cold domains, droppers unique to the exercise, evasion specific to the client's EDR.
5. Initial access. Phishing, social engineering, exposed vulnerability, leaked credentials, physical. Whatever works first.
6. Foothold. Stable C2, minimum viable persistence, OPSEC.
7. Escalation and lateral movement. Local privileges, hopping between assets, trust relationship abuse, Kerberos.
8. Action on objectives. Reproducible, verifiable impact demonstration: captures, hashes of exfiltrated files, session logs.
9. Detection and response analysis. Cross of the Red Team timeline with SOC logs to identify what was seen, what was ignored and what passed completely unnoticed.
10. Reporting and joint debriefing. Executive report, technical report and open debriefing session with the Blue Team. This session is, by far, the part that generates the most value.

Phases 5 to 8 usually iterate several times if the first vector burns. A realistic exercise contemplates Plan B, C and D from the start.

When a company needs a Red Team

Not every organisation is ready for a Red Team. Asking for one too early wastes money and demoralises the defensive team. These are the honest criteria:

It makes sense if...

• There's a functioning SOC already, internal or external, with mature detections.
• You've run recent pentests and the findings are mostly remediated.
• There's SIEM/EDR deployed in production and someone reviews the alerts.
• The organisation has an incident response plan rehearsed at least once.
• There's budget for findings, not only for the exercise.
• The management committee has approved the discomfort of the process.

It doesn't make sense yet if...

• Basic detections don't exist (a scan from the Internet goes unnoticed).
• Previous pentests are unremediated.
• There's no defensive team, internal or external.
• You're after a "we did Red Team" stamp with no intention of acting on the result.

In that second scenario, what you need isn't Red Team: it's pentesting, configuration hardening, detection tuning and, eventually, a Purple Team. Raise the grade before asking for the exam.

How to choose a Red Team provider

The Spanish market has excellent boutiques and consultancies that use the term without having a team. These are the filters we recommend to our clients when comparing offers:

1. Named team in the proposal. Ask for CVs, platform handles (HackTheBox, etc.), certifications (OSCP, OSEP, CRTO, CRTL, OSED, GXPN). If the offer names no one, there's no team.
2. Own published CVEs. A Red Team that discovers vulnerabilities in commercial software demonstrates real technical capability, not just Cobalt Strike usage. Ask for them by CVE number.
3. Accreditation where applicable. If you're going TLPT under DORA, only providers accredited per the RTS published by the ESAs. Without this, the exercise doesn't count.
4. MITRE ATT&CK alignment. Explicit mapping of each technique used to the framework. If the sample report doesn't include TTPs, rigour is missing.
5. Transparency plan with the Blue Team. A good Red Team doesn't hide its work when it finishes. It must be able to sit with the SOC and reproduce every step so they learn.
6. OPSEC policy. How they manage offensive infrastructure, exfiltrated data and destruction at exercise close.
7. Verifiable references. Ask to talk with previous clients. A serious boutique provides them.

If you get offered "Red Team" in less than 4 weeks and at a fraction of the usual range, it isn't Red Team. It's marketing.

About us: at Secra we're a small offensive cybersecurity team with experience in banking, public and critical sectors, and CVEs published in our name. If we fit, let's talk; if not, we'll tell you which sector provider you should talk to and why.

Frequently asked questions about Red Team

How much does a Red Team exercise cost?

It depends on scope, duration and whether it includes physical vector or intelligence-led component. For a corporate full-scope, public sector ranges run between €40,000 and €150,000 for 6-12 weeks. A TLPT under DORA climbs to €80,000-€250,000 because of regulated complexity and minimum duration. The most useful approach is to request 2-3 detailed proposals with days and profiles, and compare cost per day and team experience, not isolated totals.

How long does a typical exercise last?

A corporate full-scope between 6 and 16 weeks from kick-off to debriefing. A TLPT between 12 and 20. The reconnaissance and intelligence phase usually takes up the first third, which surprises those expecting immediate action.

Can Red Team break production systems?

It's one of the risks bounded in the rules of engagement. In most full-scope exercises, actions that may cause denial of service are avoided and work happens within agreed hours. A TLPT, in contrast, runs on production by design: there, risk gets managed with more safeguards (kill switch, communication with the White Team, controlled windows).

How do you measure if a Red Team has been a success?

You don't measure by number of objectives compromised. You measure by what the Blue Team learned and the decisions management changed. An exercise where the Red Team fails on some objectives but the SOC improved its detections three times is a success. One where the Red Team compromised everything but no one changed anything afterwards is a disaster.

What's the difference between Red Team and APT simulation?

Almost none in practice. APT simulation (or adversary emulation) usually refers to a Red Team exercise focused on emulating a specific APT group (e.g., APT29, Lazarus or Sandworm) using only their documented TTPs. It's a Red Team with a script. Useful when an organisation wants to validate detections against a specific threat for its sector.

Do I need an internal Blue Team to run Red Team?

No, but you need someone to receive the result and act. If your defence is an external MSSP, that can work if they sit side by side during the debriefing. If no one is going to read the report or change anything, save the exercise.

Are Red Team and Bug Bounty the same?

No. A bug bounty programme rewards point findings from external researchers on a bounded, public scope. A Red Team is a dedicated team, with a plan, with business objectives, over a specific period, without notifying the defence. They can coexist and in fact complement each other: bug bounty keeps continuous pressure on the perimeter; Red Team gives a deep, point-in-time picture of the full chain.

---

Next step

If you've made it this far, you're probably weighing whether your organisation is ready. Two paths depending on where you are:

• If you don't have recent pentests or tuned basic detections: start with a web/mobile audit or infrastructure audit and, in parallel, deploy or outsource a SOC.
• If you already have a reasonable defensive base and want an honest test: tell us the context at contact and we'll tell you whether a Red Team exercise makes sense and, if it fits our pipeline, how we'd approach it. If we don't fit, we'll point you to another sector provider that can do it well.

And if your case is DORA and you need an accredited TLPT, the mandatory prior reading is TIBER-EU and TLPT.