What is red teaming?
Red teaming is an adversary simulation exercise that evaluates how well an organization can detect, contain, and resolve live attacks. Ethical hackers pursue specific objectives, for example, compromising a privileged account, exfiltrating sensitive data, or launching an account takeover attempt, with enterprise SOC teams kept unaware of the exercise to measure how effectively the “adversary” is detected and contained.
In addition to traditional on-premises and cloud infrastructure, modern red team engagements also probe AI models, assessing how LLMs respond to adversarial inputs, attempts to circumvent guardrails, data extraction efforts, and other emerging attack techniques.
Whether the focus is application, cloud, or AI security, red team engagements share several foundational principles:
Assumed breach: The exercise begins from a realistic foothold, such as a compromised credential, exposed IAM key, insider threat, successful phishing attack, or supply chain compromise.
Command and control (C2): Red teams maintain communication with deployed implants through command-and-control (C2) infrastructure. Mature teams often use redirectors to hide operator origin and may also use CDN-based channels or domain-fronting-style techniques, where supported, to make destination traffic blend into normal web activity.
Persistence: The team establishes mechanisms to retain access across sessions, such as long-lived service account tokens, dormant IAM users, or serverless function backdoors.
Rules of engagement (RoE): Documented boundaries define the engagement’s scope and keep the process aligned with business objectives.
Traditionally, this process operates as a manual, episodic war game, bounded by time, budget, and scope. But expanding attack surfaces have organizations adopting continuous automated red teaming (CART) to complement periodic manual red teaming.
Continuous automated red teaming (CART) automates the execution of predefined adversary playbooks to validate detections, preventive controls, and attack-path assumptions on an ongoing basis. CART scales frequent testing across software, network, identity, and infrastructure defenses, but it does not replace human-led exercises such as phishing campaigns, insider simulations, or strategic objective-based operations.
But while CART detects environment drift between manual engagements and allows for proactive risk prioritization and real-time validation of security investments, it doesn’t replace the deep, strategic validation that human-led red teaming offers.
Incident Response Plan Template
A quickstart guide to creating a robust incident response plan - designed specifically for companies with cloud-based deployments.
Benefits of red teaming
By simulating sophisticated adversary tactics, red teaming exercises generate actionable insights that help security teams in four major ways:
Proactive identification of vulnerabilities: Instead of flagging isolated CVEs or misconfigurations (as is the case with vulnerability assessment), red teaming uncovers inconspicuous misconfigurations that chain together to form highly exploitable attack paths, such as an exposed workload, an overprivileged IAM role, and a misconfigured trust relationship. This lets teams prioritize remediations correctly.
Stress-testing security investments, detection and response: Ethical hackers test whether enterprise security operations centers (SOCs) detect, investigate, and contain adversary activity within acceptable mean time to detect (MTTD) and mean time to contain (MTTC) targets. The results validate how well teams, security controls, telemetry, detection logic, and security tools respond to malicious behavior, revealing gaps that conventional testing often misses.
Improving operational maturity: Red teaming highlights weaknesses in incident response (IR) workflows, escalation procedures, and IR playbooks, helping organizations mature from reactive alerting to proactive detection engineering, threat hunting, and structured IR.
Compliance and assurance: Red team engagements provide defensible evidence to auditors and stakeholders that organizations can withstand sophisticated, real-world adversary tactics, strengthening assurance beyond traditional compliance-driven assessments.
Qu’est-ce que la sécurité IAM ? Composants, fonctionnalités, bonnes pratiques
La sécurité IAM (Identity and Access Management) est un ensemble de politiques et de technologies qui aident les organisations à contrôler les identités qui peuvent disposer d’autorisations d’accès aux ressources, aux données, aux systèmes et aux applications.
En savoir plus
How is red teaming different from pen testing and vulnerability assessments?
| Criteria | Red teaming | Penetration testing | Vulnerability assessments |
|---|---|---|---|
| Primary question | Would we detect and respond if a realistic attacker breached our systems? | Where are our exploitable security weaknesses? | What vulnerabilities exist and how do we prioritize them? |
| Goal | Test how close to a specific objective or asset a skilled adversary can get before they are detected and stopped | Find as many exploitable vulnerabilities as possible across defined systems | Uncover all vulnerabilities in enterprise assets and configurations |
| Scope | Broad: multi-vector attacks targeting people, processes, technology, cloud | Targeted: scoped systems, cloud assets, apps, or networks | Broad: entire attack surface |
| Approach | Manual adversary emulation using realistic TTPs, stealth, evasion, and multi-vector attacks, such as phishing, credential compromise, and vulnerability exploitation | Automated scanning plus controlled manual exploitation of identified weaknesses, with blue teams typically aware of the engagement | Automated scanning overseen by security teams |
| Core output | Attack narratives (mapped to frameworks like MITRE ATT&CK), detection gaps, IR evaluation, and resilience findings | List of exploitable vulnerabilities with proof, potential impact, and remediation roadmap | Prioritized list of known security flaws, and ideally, remediation guidance or auto-remediation |
| Success metric | Ability to halt attack and measure detection and response maturity, including evaluating ATT&CK coverage gaps, dwell time, and DeTT&CK-aligned detection improvements | Prioritized exploits, actionable remediation guidance | Accuracy, asset coverage, prioritization correctness, and ease/speed of remediation |
Red teaming: How do purple teams and bug bounties fit into the mix?
Purple teams and bug bounty programs broaden red team coverage. In a purple team exercise, blue (defensive) and red teams work side by side to test security controls. Rather than a red team operating covertly, they carry out normal adversary activity while the blue team observes the “attack” unfold, validates telemetry, and tunes detection rules in real time. This collaborative approach allows your team to improve its detection rules before the exercise even ends.
In the case of bug bounty exercises, enterprises crowdsource vulnerability discovery to independent security researchers who uncover zero-day vulnerabilities in software and internet-facing assets. Unlike red and purple teams, bug bounty hunters focus entirely on discovering unknown security flaws rather than testing your full incident response workflows. Their job is to flag isolated software vulnerabilities so your engineering teams can patch them before malicious actors find them.
Red Team vs Blue Team: Roles and Differences Explained
Red team vs blue team refers to offensive security experts probing system defenses while defensive teams detect, respond to threats, and improve protection.
En savoir plus
What’s the difference between red teams vs. blue teams vs. purple teams?
| Criteria | Red team | Blue team | Purple team |
|---|---|---|---|
| Focus | Offensive security | Defensive security | Collaborative security |
| Primary goal | Simulate attacks to test defenses | Detect, respond to, and prevent attacks | Bridge offensive/defensive teams for continuous improvement |
| Mindset | “Think like an attacker” | “Protect and defend” | “Collaborate on attack simulation to shore up enterprise defenses” |
| Key output | Vulnerability findings & exploit paths | Incident response & system hardening | Improved detection logic & process efficiency |
How does a red team engagement work?
Red teaming works almost exactly like adversary attacks. Ethical hackers use the same TTPs, tools, and skill sets as malicious hackers but with a fundamentally different objective: to improve detection and response. Where a real attacker seeks to cause harm while remaining undetected, a red team’s ultimate success is measured by what the defenders see and do about it.
This difference is why the entire red team lifecycle is structured as write-spec for detection logic, with both red teams and detection engineers anchoring their work on the MITRE ATT&CK framework. As a shared taxonomy, ATT&CK provides a standardized language for mapping every red team activity, from initial access to exfiltration, to a specific technique ID that detection engineers can relate to during SIEM rule tuning.
This way, when a red team executes T1078.004 (Valid Accounts: Cloud Accounts), the detection engineer knows exactly which CloudTrail events to query, which identity compromise Sigma rules to write, and which telemetry sources to validate.
Here’s the red team process, mapped to detection engineering:
Phase 1: Scoping and rules of engagement (RoE)
Each red team engagement begins with scoping. Here, objectives, in-scope resources, and success criteria are clearly defined and aligned with business needs before a single command is executed.
Is the goal to exfiltrate a specific dataset? Demonstrate a path from the public internet to a production database?
What’s off limits?
What techniques are authorized?
Who has the authority to halt the exercise?
What outcomes does the enterprise expect?
Everything is documented in the RoE.
For detection logic, this phase determines what business-critical assets and attack paths require detection coverage or tuning. This way, the scoping document becomes the blueprint for what to monitor, what to prioritize, and where to focus detection engineering resources before the engagement even starts.
In a cloud-native context, the scoping phase should also define the assumed breach scenario that will anchor the engagement. Rather than starting from a compromised workstation, the assumed breach typically begins with a leaked IAM key or a compromised CI/CD service account. Selecting a realistic cloud-native entry point ensures the exercise reflects how modern attackers gain initial access while keeping objectives, attack paths, and detection expectations aligned with the organization’s actual threat landscape.
Phase 2: Reconnaissance to initial access
With the scope defined, ethical hackers gather information about users, systems, identities, and infrastructure to gain a foothold. Unlike traditional on-premises testing, which often starts with port scanning, phishing, and network mapping, cloud reconnaissance centers on API enumeration, public code repository secret scanning, cloud service enumeration, and exploitation of exposed management consoles. Common targets include Amazon S3, Azure Blob Storage, Google Cloud services, CI/CD systems, and public admin endpoints tied to cloud workloads.
Standard cloud audit logs routinely miss the footprint of these exploits. This phase shows detection engineers exactly how to isolate those hidden events so they can answer two core questions:
Can we detect reconnaissance activity against unauthorized access in our environment?
Can we differentiate between a ListBuckets call from a legitimate user and an attacker cataloging our S3 estate?
Qu’est-ce que l’IA Red Teaming ?
Les tests de sécurité traditionnels ne suffisent pas à faire face à la surface d’attaque étendue et complexe de l’IA. C’est pourquoi le red teaming de l’IA, une pratique qui simule activement des attaques adverses dans des conditions réelles, est en train de devenir un élément essentiel des stratégies de sécurité modernes de l’IA et un contributeur clé à la croissance du marché de la cybersécurité de l’IA.
En savoir plus
Phase 3: Lateral movement, privilege escalation, and objective achievement
The moment red teams establish an initial foothold, the goal becomes expanding access, moving towards target assets, and achieving the goal (e.g., data theft, cryptojacking, or ransomware deployment).
In the cloud, lateral movement runs through IAM role chains and metadata credential abuse tactics like T1078.004 (Cloud Accounts), T1552.005 (Cloud Instance Metadata API), and T1611 (Escape to Host), not the common network-based pass-the-hash method.
Ethical hackers use T1552.005, exploiting SSRF or instance-level access to query the cloud metadata service at 169.254.169.254 and retrieve IAM credentials. This technique was central to the Capital One breach. T1611 follows a similar cloud attack path; hackers break out of a compromised container to gain node-level access and harvest cluster credentials.
In T1078.004, red teams compromise a low-privileged identity and then exploit overly permissive trust policies through the AssumeRole API. That role chaining lets attackers move across AWS accounts and services, progressively escalating privileges toward sensitive data, production workloads, or privileged identities.
As red teams execute these tactics, their activities map to a CloudTrail event that should have fired an alert. The goal is for detection engineers to learn if they can detect and stop attacker activity across identities, cloud resources, and runtime assets before business impact occurs.
Phase 4: Reporting and debrief
This is where adversary simulation is translated into operational improvements. The primary practitioner output is a narrative attack story mapped to CloudTrail events (or Azure/GCP equivalents) and a detection gap analysis, not a severity-sorted finding list. It tells the story of the engagement step by step: Here’s what we did, here’s what telemetry generated, here’s what fired (and what didn’t), and here’s how the SOC responded (or didn’t).
This is where the purple team debrief becomes invaluable. Instead of waiting days for a report, defenders verify detection logic and close gaps in real time, while the attack path is still fresh in everyone’s mind.
Watch 5-min demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime. Watch now
Red teaming and Wiz
Wiz supports red team workflows by connecting external exposure, cloud context, and validated attack paths in one view.
Wiz Attack Surface Management (ASM) continuously discovers external exposure, automatically verifying which assets are truly reachable. During reconnaissance, ASM helps teams inventory internet-facing assets, while the Wiz Security Graph maps relationships across identities, workloads, and network paths. To quantify business impact, Wiz DSPM (Data Security Posture Management) exposes whether attack paths reach sensitive data stores like PII or IP, helping red teams target high-value assets and demonstrate realistic data exfiltration risks.
For execution and validation, the Wiz Red Agent identifies complex application and API attack chains at scale. Red teams can then validate whether their maneuvers trigger appropriate security alerts by testing against Wiz Defend, leveraging its runtime detection and response capabilities to help SOC analysts and detection engineers sharpen their defenses.
The result is a red teaming workflow that moves beyond severity scores to show exact business impact: "This path is reachable, this sensitive data is at risk, and our runtime detection caught it."
See how Wiz connects red team findings to cloud context, validated attack paths, and automated remediation, closing the loop from discovery to fix. Request a demo to see continuous exposure validation in action.
Detect active cloud threats
Learn how Wiz detects active threats using runtime signals and cloud context—so you can respond faster and with precision.
