Red Team: real adversary simulation to measure your detection capability

A pentest finds vulnerabilities within a scoped, known target. A Red Team simulates what a real attacker would do with a concrete objective — reaching your ERP, exfiltrating customer data, compromising the domain — combining technical, social and, where applicable, physical vectors, without your security team knowing it's happening. The question it answers isn't "what vulnerabilities do you have?" — it's "would you have caught us?"

Why isn't a pentest enough to know if you're ready?

A technical pentest is essential, but it answers a different question: within a defined scope and a fixed timeframe, what vulnerabilities exist? The defensive team usually knows it's happening, which changes their behavior. A real attacker doesn't warn you, doesn't limit itself to one vector, and doesn't stop at the first control it hits: it combines targeted phishing, technical exploitation, lateral movement and, if needed, in-person social engineering, over weeks, looking for the quietest path to a concrete business objective. A Red Team is the only way to check whether your SOC, your alerts and your response team actually work when no one warns them in advance.

What a Red Team exercise covers

Business objective definition (crown jewels): the asset or data the red team must "capture" for the exercise to be considered successful
OSINT reconnaissance: exposed surface, employees, technologies, previously leaked credentials
Initial entry vector: spear phishing, exploitation of exposed services, or social engineering
Post-exploitation and lateral movement: privilege escalation, pivoting across systems, persistence
Active evasion of EDR/AV and the SOC's (blue team's) detection capabilities
Simulated data exfiltration to controlled infrastructure, without extracting real production data
In-person social engineering when in scope: physical access to facilities, tailgating, USB devices
Measurement of the defensive team's real mean time to detect (MTTD) and respond (MTTR)

Exercise methodology (aligned with TIBER-EU / MITRE ATT&CK)

Objective definition and rules of engagement: We agree the business objective, systems strictly out of scope and the emergency stop protocol with leadership or the CISO. The defensive team is NOT informed of the exercise.
Threat intelligence and reconnaissance: We build the attack profile using TTPs from real threat actors relevant to your sector, and map the exposed surface: domains, employees, technologies, leaked credentials.
Initial intrusion: We execute the agreed entry vector — spear phishing, exploitation of an exposed service, or social engineering — seeking initial footholds with as little noise as possible.
Post-exploitation and persistence: We escalate privileges, move laterally toward the defined objective and establish persistence while actively evading EDR, AV and SOC alerts, documenting every TTP used.
Objective achievement and closure: We reach (or attempt to reach) the agreed business objective. We deliver a joint report with the full attack timeline, what you detected and when, and a prioritized improvement plan for the blue team.

What you receive at the end of the exercise

Executive report: whether the objective was reached, how long it took and how stealthily
Full technical attack timeline (kill chain) with TTPs mapped to MITRE ATT&CK
Detection timeline: which alerts fired, which didn't, and why
Joint session with the SOC/blue team (purple teaming) to review each technique and improve detection rules
Prioritized improvement plan: what to reinforce first based on demonstrated real impact, not a generic hardening checklist
Optional re-test of the corrected detection vectors

When does a Red Team make more sense than a pentest?

You already have a mature pentesting program and the obvious critical vulnerabilities are fixed
You have an in-house or outsourced SOC and need to validate it detects real attacks, not just that it exists
You're subject to DORA and your entity may be designated for TLPT (Threat-Led Penetration Testing)
You need to justify a detection-and-response investment to leadership with real, not hypothetical, evidence
You've suffered an incident and need to validate that the corrective measures actually work under a real attack
Financial, energy, healthcare or critical infrastructure sector with advanced resilience regulatory requirements

Frequently asked questions about Red Team

How is this exactly different from an Active Directory pentest?

An Active Directory pentest analyzes the AD environment in depth within a known technical scope, looking for the maximum number of configuration and privilege escalation flaws. A Red Team starts from outside the perimeter, with a concrete business objective, without the defensive team knowing, and only touches AD if that's the most realistic path to the objective — it's a test of the whole organization, not of the AD environment itself.

Is this the same as the TLPT DORA requires?

TLPT is a Red Team run under the TIBER-EU regulatory framework, with specifically accredited providers and coordination with the supervisor, mandatory for financial entities designated as critical. Our standard Red Team follows the same methodological logic and is the ideal preparation before a formal TLPT; for the regulatory TLPT itself, we guide you through the required accreditation process.

What happens if the defensive team catches us on day one?

That's a valid and valuable outcome — it means your defenses work for that vector. In that case, with your consent, we can adjust the exercise to keep testing other vectors or more advanced evasion techniques, maximizing what you learn from the exercise.

Does it include in-person social engineering and physical access?

Only if explicitly agreed in scope. It's not a default component: some organizations include it (tailgating, USB devices, impersonating technical staff) and others prefer to limit it to digital vectors. It's defined during the rules-of-engagement phase.