Real World 5 Playbooks for RED vs BLUE Exercises
- eugenekornevski
- Aug 8
- 15 min read
This section provides five practical, adaptable playbooks for conducting adversarial simulation exercises. Each playbook is designed to test a different combination of people, processes, and technology against a common and high-impact threat vector. The White Team can use these scenarios as a foundation, tailoring the specific targets and TTPs to their organization's unique environment and strategic objectives. The inclusion of specific Key Performance Indicators (KPIs) for each scenario allows for the quantitative measurement of defensive capabilities and the tracking of improvements over time.
Overview of Simulation Playbooks
Playbook Title | Primary Objective | Key Capabilities Tested | Primary Success Metrics (KPIs) |
1. The Multi-Vector Social Engineering Campaign | Assess resilience to credential harvesting via phishing and vishing, targeting human and process vulnerabilities. | People (Awareness), Process (Help Desk IDV), Technology (Email Gateway, MFA, SIEM) | Phishing Click Rate, Credential Submission Rate, Report Rate, Help Desk Bypass Rate, MTTD/MTTC |
2. The Physical Breach and Insider Threat Simulation | Test physical security controls and the ability to detect anomalous internal network activity. | People (Guards, Employees), Process (Access Control), Technology (Cameras, NAC, SIEM) | Physical Breach Success Rate, Time to Detect Physical Breach, Time to Detect Rogue Device, Incident Response Time (Physical/Cyber) |
3. The Enterprise Ransomware Catastrophe Simulation | Evaluate end-to-end resilience against a ransomware attack, focusing on detection, response, and recovery. | People (SOC, IT, Execs), Process (IR/DR/BCP), Technology (EDR, Backups, SIEM) | MTTD, MTTR, Backup Integrity, Recovery Time Objective (RTO), Recovery Point Objective (RPO) |
4. The Critical Web Application Exploit (SQL Injection) | Assess the security of a critical web application and the ability to detect and respond to a technical data exfiltration attempt. | People (Developers), Process (SDLC), Technology (WAF, SAST/DAST, Database Monitoring) | WAF Block Rate, MTTD, Mean Time to Remediate (MTTR-Vuln), Number of Exploitable Vulnerabilities, Patching Cadence |
5. The Cloud Infrastructure Misconfiguration Exploit | Evaluate the security posture of the cloud environment by identifying and exploiting common misconfigurations. | People (Cloud Engineers), Process (Cloud Governance), Technology (CSPM, Cloud-Native Monitoring) | Number of Critical Misconfigurations, Time to Detect/Respond (Cloud), IAM Policy Effectiveness, Compliance Audit Score |
Playbook 1: The Multi-Vector Social Engineering Campaign
Scenario Objective: To assess the organization's resilience to a sophisticated, multi-stage social engineering attack targeting human vulnerabilities and help desk processes, with the ultimate goal of harvesting high-privilege credentials. This scenario emulates the TTPs of threat actors like Scattered Spider, who specialize in social engineering to bypass multi-factor authentication (MFA).
Key Capabilities Tested:
People: The security awareness of employees and their ability to recognize and report phishing attempts. The adherence of IT help desk staff to identity verification protocols under pressure.
Process: The robustness and consistency of the IT help desk's identity verification and MFA reset procedures. The efficiency of the organization's incident reporting and triage process for user-reported threats.
Technology: The effectiveness of the email security gateway in filtering malicious messages. The resilience of the MFA solution to social engineering-based resets. The ability of the SIEM to correlate login events and help desk activity to detect anomalous behavior.
Red Team Actions & TTPs:
Reconnaissance (OSINT): The Red Team begins by gathering intelligence from public sources. They use platforms like LinkedIn to collect names, job titles, and professional connections of employees . They browse the company website to understand the organizational structure and identify the official format for corporate email addresses. This information is used to build a credible pretext for the attack.
Initial Contact (Phishing): A targeted phishing campaign is launched. The Red Team crafts an email that appears to be from a trusted internal source (e.g., "IT Support") or a common external service (e.g., "Microsoft Office 365"). The email creates a sense of urgency, such as an impending password expiration or a required security update. It contains a link to a pixel-perfect clone of the organization's real login portal, hosted on a domain controlled by the Red Team.
Escalation (Vishing/Impersonation): When an employee clicks the link and enters their credentials on the fake portal, the Red Team captures them. They immediately attempt to use these credentials to log in. If the login is blocked by MFA, the vishing phase begins. A Red Team operator calls the IT help desk, impersonating the compromised employee . They will use a pretext, such as "I just got a new phone and lost my authenticator app," and leverage the information gathered during OSINT to sound convincing and pass identity verification questions. The goal is to persuade the help desk agent to reset the MFA for the account.
Actions on Objective: If the help desk agent resets the MFA, the Red Team immediately enrolls their own device and completes the login. They have now bypassed the primary technical control. Once inside, they will seek to establish persistence (e.g., by setting up email forwarding rules) and begin exploring for sensitive data or pathways for privilege escalation, thus achieving the exercise's primary objective.
Expected Blue Team Detection & Response:
Detection: Ideally, the email security gateway flags and quarantines the initial phishing emails based on sender reputation, domain age, or content analysis [8]. Security-aware employees who receive the email will not click the link but will instead use the "Report Phish" button in their email client, which forwards the message directly to the SOC for analysis. The help desk agent, following a strict verification script, should deny the MFA reset request if the caller cannot provide sufficient proof of identity. The SIEM should generate an alert for a pattern of multiple failed login attempts from one IP address, followed by a help desk ticket for an MFA reset, and then a successful login from a new, unusual IP address.
Response: Upon receiving a user-reported phish, the SOC team analyzes the email headers and the malicious URL. They block the sender's domain and the credential-harvesting site at the web proxy and firewall. If a compromise is suspected based on SIEM alerts, the SOC initiates the incident response plan. They immediately disable the compromised user account, force a password reset, and contact the legitimate user to re-establish secure MFA. They then coordinate with the help desk to review the call and ticket logs to conduct a root cause analysis of the process failure.
Key Performance Indicators (KPIs):
Phishing Click Rate: The percentage of targeted employees who clicked the malicious link in the phishing email.
Credential Submission Rate: The percentage of employees who proceeded to enter their credentials on the fraudulent landing page.
Report Rate: The percentage of employees who correctly identified the email as a phish and reported it using the official channel. This is a critical measure of security awareness.
Help Desk Bypass Rate: The percentage of vishing attempts that successfully convinced a help desk agent to reset MFA.
Mean Time to Detect (MTTD): The time elapsed from the moment of successful credential compromise to the generation of a high-confidence alert in the SOC.
Mean Time to Contain (MTTC): The time elapsed from the initial detection to the point where the compromised account is disabled and secured.
Playbook 2: The Physical Breach and Insider Threat Simulation
Scenario Objective: To test the effectiveness of the organization's layered physical security controls and its ability to detect and respond to anomalous internal network activity consistent with either a malicious insider or an external attacker who has successfully gained physical access.
Key Capabilities Tested:
People: The alertness and adherence to procedure of physical security guards. The willingness of employees to enforce security policies by challenging strangers or reporting suspicious behavior (e.g., "tailgating").
Process: The efficacy of physical access control procedures, visitor logging and escort policies, and the coordination between physical security and cybersecurity (SOC) teams during a converging incident.
Technology: The reliability of physical access control systems (e.g., badge readers, door alarms). The coverage and utility of surveillance cameras for investigation. The effectiveness of Network Access Control (NAC), EDR, and SIEM tools in detecting and alerting on unauthorized device connections or anomalous internal network traffic.
Red Team Actions & TTPs:
Physical Reconnaissance: The Red Team conducts surveillance of the target facility. They observe employee entry and exit routines, identify high-traffic doors, note the locations of security cameras and guards, and look for potential weak points like designated smoking areas where employees might be more relaxed about security .
Initial Access (Physical): The Red Team attempts to gain unauthorized entry. A common technique is "tailgating," where an operator simply follows an authorized employee through a secured door before it closes. Another approach is to impersonate a legitimate visitor, such as a maintenance contractor or a courier, to be granted access. In a more advanced scenario, the Red Team might use a device to skim an employee's access card credentials and create a clone .
Establish Foothold (Digital): Once inside the facility, the Red Team's goal is to gain access to the internal network. They will look for an unoccupied desk with a live network port or an unlocked, unattended computer. They might connect a small, pre-configured rogue device (like a Raspberry Pi or a "rubber ducky" USB) to the network, which is designed to establish a covert C2 channel to the Red Team's external infrastructure.
Actions on Objective (Simulating Insider Threat): From this internal position, the Red Team simulates the actions of a malicious insider. They begin with slow, low-profile network reconnaissance to identify valuable targets like file servers or databases. They will then attempt to access sensitive data, escalate privileges, and exfiltrate a small, non-sensitive "trophy" file (e.g., a document named Project_X_Financials_SIMULATION.docx) to an external server to prove they achieved their objective.
Expected Blue Team Detection & Response:
Detection: In an ideal scenario, the physical breach is prevented at the perimeter. A security guard or an aware employee challenges the Red Team operator during the tailgating attempt and denies entry. If the breach is successful, a Network Access Control (NAC) system should immediately detect an unauthorized MAC address on the network, generate an alert, and automatically place the device into a quarantined VLAN. If NAC is not in place, the SIEM should alert on the subsequent anomalous network activity, such as port scanning from a new host, or an EDR agent could alert on the execution of reconnaissance tools on a compromised workstation.
Response: Upon receiving a physical security alert (e.g., a door held open too long) or an employee report, physical security guards are dispatched to investigate. Upon receiving a NAC or SIEM alert, the SOC team begins its investigation. They identify the switch and port of the rogue device connection and dispatch a technician or physical security to the location. They correlate the digital alert with physical location data and coordinate with the physical security team to review camera footage to identify the individual responsible. The compromised port is disabled, and the device is confiscated for forensic analysis.
Key Performance Indicators (KPIs):
Physical Breach Success Rate: The percentage of attempts to gain unauthorized physical access that were successful.
Time to Detect Physical Breach: The time from the moment of unauthorized entry to the first detection by a person or system.
Time to Detect Rogue Device: The time from the connection of the rogue device to the network to the generation of a SOC alert.
Incident Response Time (Physical): The average time from an alert to the arrival of a security guard on the scene.
Incident Resolution Time (Cyber): The time from the initial SOC alert to the successful network isolation of the threat.
Cross-Team Communication Effectiveness: A qualitative metric, assessed by the White Team, on the efficiency and clarity of communication and collaboration between the physical security and cybersecurity teams during the response.
Playbook 3: The Enterprise Ransomware Catastrophe Simulation
Scenario Objective: To test the organization's end-to-end resilience against a simulated, widespread ransomware attack. This exercise focuses less on the initial breach and more on the Blue Team's ability to detect, respond, contain, and recover from a fast-moving, high-impact threat, without the risk of encrypting actual production data.
Key Capabilities Tested:
People: The readiness and technical skills of SOC analysts and incident responders under extreme pressure. The ability of the IT/infrastructure team to execute recovery procedures. The crisis management and decision-making capabilities of executive leadership.
Process: The completeness, clarity, and effectiveness of the organization's Incident Response Plan (IRP), Disaster Recovery (DR) Plan, and Business Continuity Plan (BCP). The execution of internal and external communication plans.
Technology: The effectiveness of EDR/antivirus solutions in detecting and blocking ransomware-like behavior. The accuracy of SIEM detection rules for mass file modification or deletion. The integrity, security, and restorability of the backup and recovery systems.
Red Team Actions & TTPs:
Initial Access & Privilege Escalation: For this exercise, the Red Team can be granted initial access to a standard user workstation to expedite the scenario. From there, they will use common techniques to escalate privileges to Domain Administrator, mimicking the path real ransomware operators take to gain control of the environment .
Staging and Reconnaissance: The Red Team identifies a set of pre-approved, non-critical file servers or a sandboxed environment to target. They will also attempt to discover the location and credentials for the organization's backup systems.
Actions on Objective (Simulated Encryption): The Red Team does not deploy actual ransomware. Instead, they execute a custom, benign script on the target servers. This script performs actions that mimic ransomware behavior:
It rapidly traverses directories and renames files to add a .locked extension.
It creates a text file named RANSOM_NOTE.txt in every directory it touches.
This simulation generates the same network and endpoint telemetry as a real attack without causing irreversible damage.
Simulated Backup Destruction: The Red Team will attempt to access the backup management console and perform actions that simulate destruction, such as deleting backup jobs or renaming backup repositories, to test the security of the recovery infrastructure.
Expected Blue Team Detection & Response:
Detection: The EDR solution, using behavioral analysis, should detect the script's rapid file modification activity, block the process, and generate a high-severity alert for potential ransomware. The SIEM, configured with a file integrity monitoring (FIM) or "canary file" rule, should trigger a critical alert when it observes thousands of file rename events originating from a single source in a short time. Help desk calls from users reporting they cannot open files and see a ransom note will serve as a secondary detection vector.
Response: The Blue Team immediately declares a critical incident and invokes the ransomware-specific annex of their IRP. The first priority is containment: they isolate the affected servers from the network to prevent the "infection" from spreading. They work to identify the source of the attack and eradicate the Red Team's presence. Simultaneously, the IT infrastructure team assesses the scope of the "encrypted" data and initiates the DR plan. They begin restoring the affected files from backups to a clean, isolated environment for validation. The executive leadership team convenes to manage the crisis, activating the BCP to maintain critical business operations and executing the communication plan to inform stakeholders.
Key Performance Indicators (KPIs):
Mean Time to Detect (MTTD): The time elapsed from the start of the simulated encryption script to the generation of a high-confidence, actionable alert in the SIEM or EDR console.
Mean Time to Respond (MTTR): The time from the initial alert to the successful network isolation of the affected systems.
Backup Integrity: A binary metric: Was the Red Team able to successfully access and simulate the destruction of the backups?
Recovery Time Objective (RTO): A measure of how long it took the IT team to restore the "encrypted" data. This is compared against the organization's pre-defined RTO for that data class.
Recovery Point Objective (RPO): A measure of potential data loss, determined by the age of the most recent viable backup that could be used for restoration.
IR/DR/BCP Plan Effectiveness: A qualitative assessment by the White Team on the clarity, accuracy, and overall effectiveness of the organization's documented response and recovery plans.
Playbook 4: The Critical Web Application Exploit (SQL Injection)
Scenario Objective: To assess the security of a critical, internet-facing web application and test the organization's ability to detect and respond to a sophisticated technical exploit aimed at exfiltrating sensitive data.
Key Capabilities Tested:
People: The secure coding knowledge of the application developers (sometimes called the Yellow or Orange Team ). The ability of SOC analysts to understand and investigate application-layer attacks by analyzing web and database logs.
Process: The integration of security into the Software Development Lifecycle (SDLC). The effectiveness of the vulnerability management and patching process for applications. The incident response procedures for application-level breaches.
Technology: The effectiveness of the Web Application Firewall (WAF) in preventing common attacks. The coverage of Static and Dynamic Application Security Testing (SAST/DAST) tools. The visibility provided by database activity monitoring and SIEM logging for anomalous query detection.
Red Team Actions & TTPs:
Reconnaissance & Enumeration: The Red Team selects a critical, in-scope web application (e.g., a customer portal). They use both automated scanners and manual browsing to map the application's functionality, identifying all user input fields, including forms, URL parameters, and HTTP headers, that could potentially interact with a backend database .
Vulnerability Identification: The Red Team probes the identified input fields for SQL Injection (SQLi) vulnerabilities. They submit crafted inputs containing special SQL characters (', --, ;) and analyze the application's responses for errors or behavioral changes that indicate a vulnerability is present .
Exploitation: Upon confirming an SQLi vulnerability, the Red Team uses a tool like sqlmap or constructs manual payloads to exploit it. Their initial goal is to confirm the exploit by extracting simple data, such as the database version or current user. They then proceed to enumerate the database schema to identify tables likely to contain sensitive information.
Actions on Objective: The final goal is to exfiltrate a small sample of data to prove the severity of the vulnerability. To test different defensive layers, the Red Team may attempt both in-band exfiltration (where the data is returned directly in the HTTP response) and out-of-band exfiltration (where data is sent to an external server via DNS or HTTP requests initiated by the database itself). The data used will be pre-approved, non-sensitive test data.
Expected Blue Team Detection & Response:
Detection: A properly configured Web Application Firewall (WAF) should detect and block the majority of the Red Team's SQLi payloads based on its signature rule set [62]. The SIEM, which should be ingesting logs from the web server, WAF, and database server, should generate alerts based on correlations, such as a high number of SQL error messages from the database tied to a single source IP, or logs from the WAF showing repeated SQLi blocks . A dedicated database activity monitoring (DAM) solution would provide even more granular alerting on suspicious query structures.
Response: The SOC team triages the WAF and SIEM alerts. They identify the attacker's source IP address and can implement a temporary block at the network firewall to stop the active attack. They analyze the logs to determine which application parameter was vulnerable and what data was potentially accessed. The incident is escalated to the application development team with all relevant logs and data, and the vulnerability remediation process is initiated.
Key Performance Indicators (KPIs):
WAF Block Rate: The percentage of SQLi attack payloads that were successfully blocked by the WAF.
Mean Time to Detect (MTTD): The time from the start of the successful exploitation (not just scanning) to the generation of a SOC alert.
Mean Time to Remediate (MTTR - Vulnerability): The time from the vulnerability being reported to the development team to a patch being successfully deployed to production. This is a key metric for application security .
Exploitable Vulnerabilities: The number of critical vulnerabilities discovered by the Red Team that were not previously identified by automated SAST/DAST scans [65].
Patching Cadence: A broader metric measuring the average time it takes the organization to patch critical, publicly disclosed vulnerabilities in its web applications.
Playbook 5: The Cloud Infrastructure Misconfiguration Exploit
Scenario Objective: To assess the security posture of the organization's public cloud environment (e.g., AWS, Azure, GCP) by identifying and exploiting common, high-impact misconfigurations related to identity management and exposed services.
Key Capabilities Tested:
People: The adherence of cloud engineers and DevOps teams to secure configuration baselines and the principle of least privilege.
Process: The effectiveness of cloud governance policies, the process for reviewing and approving IAM roles and policies, and the organization's incident response plan for cloud-specific threats.
Technology: The detection capabilities of Cloud Security Posture Management (CSPM) tools. The completeness of cloud-native logging and monitoring (e.g., AWS CloudTrail, Azure Monitor). The ability of SIEM/XDR platforms to ingest and correlate cloud logs to detect sophisticated attack paths.
Red Team Actions & TTPs:
Reconnaissance: The Red Team uses automated tools and public sources to discover the organization's cloud footprint. They scan for misconfigurations like publicly accessible S3 buckets or Azure blobs, open security groups that expose management ports (SSH, RDP) to the internet, and search code repositories like GitHub for accidentally leaked access keys or credentials.
Initial Access: The Red Team exploits a discovered misconfiguration to gain their initial foothold. This could be as simple as downloading files from a public S3 bucket or using leaked credentials to log into the AWS Management Console or Azure Portal .
Privilege Escalation & Lateral Movement: This is the core of the cloud attack. Once inside, the Red Team focuses on abusing misconfigured Identity and Access Management (IAM) policies. They will analyze the permissions of their compromised user or role, looking for pathways to escalate privileges. For example, they might find a user with the iam:CreatePolicyVersion permission, which can be abused to grant themselves administrator access. They will then move laterally by exploiting trust relationships between roles or services to access different parts of the cloud environment .
Actions on Objective: The Red Team works to achieve a pre-defined goal that demonstrates significant impact. This could involve accessing a sensitive database like Amazon RDS, exfiltrating data from a "crown jewel" storage account, or demonstrating the ability to deploy a rogue virtual machine that could be used for cryptomining or as a C2 server.
Expected Blue Team Detection & Response:
Detection: Proactively, a Cloud Security Posture Management (CSPM) tool should have already alerted the Blue Team to the critical misconfiguration (e.g., the public S3 bucket or overly permissive IAM policy) before the exercise even begins. Reactively, cloud-native threat detection services like AWS GuardDuty or Microsoft Defender for Cloud should detect anomalous API activity, such as a user enumerating permissions or accessing data in an unusual pattern. The SIEM, ingesting these cloud logs, should correlate the events—for example, a login from a new IP followed by a series of suspicious IAM API calls—and generate a high-severity alert.
Response: The Cloud Security or SOC team triages the alerts from their CSPM or SIEM. They investigate the activity using cloud-native logs (e.g., CloudTrail) to confirm the unauthorized access. They immediately take containment actions, such as revoking the compromised access key, disabling the user, or modifying the security group to block external access. They then conduct a forensic analysis to trace the Red Team's path through the cloud environment and determine the full scope of the compromise.
Key Performance Indicators (KPIs):
Number of Critical Misconfigurations: A raw count of high-risk misconfigurations discovered, such as public storage, exposed management ports, or IAM policies with wildcard permissions.
Time to Detect & Respond (Cloud): The MTTD and MTTR specifically for threats originating and contained within the cloud environment.
IAM Policy Effectiveness: The percentage of IAM roles and users that adhere to the principle of least privilege, as assessed by the Red Team's ability to escalate privileges.
Compliance Audit Score: A measure of how well the cloud environment's configuration adheres to established security benchmarks, such as those from the Center for Internet Security (CIS).
Tool Coverage: The percentage of cloud assets and services that are being actively monitored by CSPM, SIEM, and other security tools.







Comments