Red Teaming: Scenario-Based Testing

Vulnerability scanning tells you what’s technically wrong. Scenario-based testing tells you whether an actual attacker, with actual goals, could get from the outside to something that matters. That distinction is the whole point of red teaming.

Scenario-based testing (SBT), sometimes called attack simulation, builds specific scenarios around the tactics, techniques, and procedures (TTPs) real adversaries use, then runs them against an organization’s actual defenses. It’s less a separate discipline than it is the working core of what red teaming already is: instead of “does this endpoint have a missing patch,” the question becomes “can a credential-phishing scenario modeled on a specific threat actor get from an employee’s inbox to domain admin.”

What is scenario-based testing?

#

SBT simulates real-world attack scenarios to find weaknesses that a straightforward vulnerability assessment won’t surface, because a vulnerability scanner has no concept of an attack chain. It doesn’t know that a phishing email plus a stale local admin password plus an unsegmented VLAN adds up to full domain compromise; a red team scenario is built specifically to demonstrate that chain, end to end.

Scenarios can be built around social engineering, web application attacks, physical security, or insider threats, and they’re usually informed by threat intelligence: what a specific threat actor or industry-relevant adversary is actually known to do. That’s where the MITRE ATT&CK framework earns its keep. ATT&CK is a knowledge base of adversary tactics and techniques drawn from real-world observed intrusions, organized by tactic (the attacker’s goal, like Initial Access or Privilege Escalation) and technique (how that goal gets achieved). Building a scenario around a specific threat actor’s known ATT&CK technique set, rather than a generic “try some phishing” plan, is what makes the exercise a legitimate simulation instead of a guess.

None of this starts without Rules of Engagement (RoE), the documented agreement covering scope, authorized targets, prohibited actions, and points of contact, signed off before any testing begins. NIST SP 800-115 treats this as a prerequisite for any technical security assessment, and NIST SP 800-53’s CA-8(2) control specifically requires red team exercises to run “in accordance with applicable rules of engagement.” This isn’t paperwork for its own sake: skip it and you’re not doing authorized testing anymore.

A typical SBT engagement runs through five steps:

1. Define the scope: which scenarios get tested, which systems and applications are in play, and what the RoE actually authorizes.
2. Design the scenarios: pick specific attack techniques (ideally ATT&CK-mapped) and build a plan for executing them.
3. Execute the scenarios: run them against the target systems, using whatever mix of automated tooling and manual technique the scenario calls for.
4. Analyze the results: work through logs, forensic artifacts, and the outcome of each scenario to identify what actually broke.
5. Report and remediate: hand the organization concrete findings and recommendations, whether that’s new controls, policy changes, or targeted security awareness training.

Benefits of scenario-based testing

#

SBT tests defenses against attack chains a real adversary might actually run, which is a different (and often more revealing) question than “what CVEs exist here.” A few benefits stand out in practice: it can be tuned to an organization’s specific environment and industry rather than running a generic checklist, it lets an organization find and fix gaps before an actual attacker does, and it tends to pull IT, security, and business teams into the same room, since a realistic scenario usually crosses all three. It also helps with compliance: frameworks like PCI DSS and HIPAA require regular security testing, and a well-documented SBT engagement is a stronger artifact for an auditor than a scan report.

None of that works without experienced people running it. SBT is only as good as the analysts designing and executing the scenarios.

Examples of scenario-based testing in red team exercises

#

Social engineering

#

Social engineering targets people, not systems, which is exactly why it’s a fixture in most engagements. A few common scenario types:

• Phishing campaign: emails crafted to look like they’re from a trusted source (IT, a vendor, a familiar sender) carrying a malicious link or attachment, testing how many employees fall for it and where security awareness training is actually working.
• Phone-based (vishing): calling an employee under a pretext, posing as a vendor who needs urgent network access, for example, and using manufactured urgency to get them to act without verifying.
• Physical pretexting: posing as a contractor or repair technician to talk your way into a secure area.
• USB baiting: dropping USB drives labeled with something tempting (“Executive Compensation”) in a parking lot or break room, loaded with something that phones home if plugged in.

All four map cleanly to ATT&CK’s Initial Access tactic, and running them well requires real reconnaissance on the target organization first: employees, org structure, vendor relationships, and physical layout.

Web application attacks

#

Web apps are a standing target, and the usual categories cover most of what a scenario needs:

• SQL injection: extracting data straight from the backend database, typically via sqlmap or a hand-crafted payload.
• Cross-site scripting (XSS): injecting script to steal session tokens or credentials from a victim’s browser, commonly staged with BeEF.
• File upload vulnerabilities: getting a web shell or backdoor onto the server through an insufficiently validated upload path.
• Path traversal: walking outside the intended directory to reach configuration files or credential stores.

Burp Suite covers most of this ground for manual testing; a solid scenario also requires actually understanding the target application’s stack, not just running a scanner against it.

Physical security

#

Physical security gets overlooked constantly, which is precisely why it’s worth testing. Tailgating (following an authorized employee through a badge-controlled door), dumpster diving (recovering discarded documents with real sensitive data in them), pretexting your way past reception, and lock picking are the standard scenario types. Any of them can end in a planted device, a rogue access point, or physically exfiltrated documents, and all of them require the same groundwork: knowing the target’s access controls, surveillance layout, and security staffing before you show up.

Insider threats

#

Insider scenarios are harder to detect than external ones because the attacker starts with legitimate access. Credential theft (keylogging or a remote access trojan on an employee’s machine), data exfiltration (moving sensitive data to cloud storage or a personal account), a simulated malicious insider abusing their own access, and social engineering aimed at coworkers rather than outsiders are the usual categories. Running these well means understanding the organization’s access controls and data handling policies well enough to know what “abuse” actually looks like in that environment.

Tools for scenario-based testing

#

• Metasploit Framework: Rapid7-maintained, open-source exploitation framework with a large library of exploits and payloads.
• Burp Suite: the standard web application testing platform, covering proxying, scanning, and manual manipulation for SQLi, XSS, CSRF, and the rest.
• SET (Social Engineering Toolkit): TrustedSec’s framework for phishing, spear phishing, and credential harvesting campaigns.
• Nmap: network mapping and port scanning, for both internal and external reconnaissance.
• Cobalt Strike: a commercial adversary simulation platform, now owned by Fortra (formerly HelpSystems), built around client-side attacks, C2, and post-exploitation. Cracked, pirated copies circulate widely enough that Fortra partnered with Europol on a 2024 takedown operation targeting infrastructure built on stolen builds, worth knowing since attackers use the same tool your red team does.
• Empire: originally “PowerShell Empire,” discontinued by its creators in 2019 once Microsoft’s PowerShell hardening (AMSI and friends) blunted its original approach. BC-Security maintains an active fork that’s grown well past its PowerShell-only roots, now supporting PowerShell, Python, C#, IronPython, and Go agents.
• Mimikatz: Benjamin Delpy’s credential extraction tool, still actively developed. Worth knowing going in: Credential Guard and LSASS running as a Protected Process (PPL) block the classic sekurlsa::logonpasswords approach on a properly hardened Windows box. Bypasses exist, but “Mimikatz just works” hasn’t been a safe assumption for a while.

The right tool depends on the scenario, the target environment, and the operator’s own skill with it, and every one of these needs to be used only within the signed RoE. Knowing the tools isn’t a substitute for understanding networking, operating systems, and the target organization’s actual environment; the tools execute the plan, they don’t make it.

Conclusion

#

Scenario-based testing works because it tests attack chains instead of isolated findings, which is closer to how a real intrusion actually plays out. Grounding scenarios in MITRE ATT&CK gives you a shared vocabulary with both threat intelligence and the defenders reading your report, instead of a scenario built on guesswork.

None of it means anything without signed Rules of Engagement first. Everything past that point, social engineering, web app attacks, physical access, insider simulation, only counts as red teaming if it’s authorized.