Your client has just paid for a penetration test, received a tidy report, and filed it for the auditor. Nobody in the SOC saw the test run. Nobody can tell you whether an alert fired, whether an analyst investigated, or whether anyone could have stopped the tester before the objective was reached. That's the gap red team penetration testing is built to close, and it's the gap MSSPs get paid to prove they've closed.
Table of Contents
- What a Red Team Test Is Built to Prove
- Red Team Testing Compared With Pentests and Scans
- The Attack Chain From Recon to Exfiltration
- Rules of Engagement Written Before the First Packet
- Evidence and Outcomes Every Finding Needs
- A Worked Example From an MSSP Client Engagement
- Scheduling Recurring Red Team Tests Across Clients
- Choose a Hybrid Model and Confirm Your First Scope
What a Red Team Test Is Built to Prove
A clean pentest report can still hide a failed defense. Findings can be valid, remediation sensible, and every screenshot persuasive while the SOC stays silent: no triage, no isolation, no proof anyone would have stopped the same path under pressure. The invoice says assurance; the console shows nothing.
The question shifts from "which weaknesses exist" to a harder one: can an adversary reach a named objective, such as payment data or domain admin rights, and would the defenders notice, investigate, and contain the attempt in time? A red team test works like a controlled intrusion against live operations. The point is the guard's response when a door is tried, not the inspector's list of doors left open.
Three Things Being Measured
Score each step four ways: prevented, detected, investigated, or contained. An exploit that succeeds technically but triggers fast isolation argues one thing. The same exploit running unnoticed for days argues another. Keep the evidence for both, with timestamps, alert IDs, host actions, and analyst decisions, so an MSSP can rerun the identical chain after a control change and prove the delta instead of asserting it.
A red team test is a test of the defenders, not only the target.
Strong engagements use adversary emulation. The operator replays a relevant threat actor's behavior mapped to MITRE ATT&CK techniques, which tests behavioral detection and response rather than whether one tool or hash happened to be blocked. That gives the blue team something measurable to tune: a technique, a log source, a threshold, a handoff.
Before commissioning, force three written answers: what objective is being tested, which defenders are being measured, and what the client will change if the chain succeeds. If any answer is vague, the work collapses into an expensive pentest wearing a red team label.
Red Team Testing Compared With Pentests and Scans
| Aspect | Vulnerability Scan | Penetration Test | Red Team Test |
|---|---|---|---|
| Core question | Which known weaknesses exist? | Can a tester exploit the scoped systems? | Can an adversary reach a goal without being stopped or noticed? |
| Scope | Broad asset list | Defined systems and applications | Objective-driven, any route across people, process and technology |
| Defender awareness | Usually known | Usually known | Blue team unaware; small white cell knows |
| Main output | Vulnerability list with severity | Exploited findings with business impact | Attack narrative mapped to ATT&CK, with detection and response gaps |
| Detection tested | No | Incidentally | Core measure of the test |
Where the Choice Changes the Outcome
The core question row drives everything else. A scan inventories known weaknesses across a broad asset list, which makes it useful for hygiene and patching discipline. It doesn't prove exploitability, and it doesn't test a single detection. Treating scan output as assurance is the most common buying mistake at this tier.
A pentest goes deeper on defined systems. The tester attempts exploitation, confirms impact, and hands engineering a fix list. Defenders usually know it's happening, so detection is tested only incidentally. That's fine when the goal is validating a specific application before launch. It's not fine when the client thinks they've measured their SOC.
The scope row is where red teaming separates. The objective is fixed, the route isn't. Phishing, an exposed service, a stale account, a misconfigured cloud role, any of these can be the path if the rules allow it. That freedom is what makes the result representative of a real adversary, and it's also what makes the engagement harder to govern.
Defender awareness changes the evidence you collect. In a pentest, an analyst who knows testers are active will behave differently, consciously or not. In a red team test, a small white cell knows and the blue team doesn't, so alert quality, triage speed, and escalation decisions reflect normal operations.
Practical rule: A pentest that exploits a system without a single alert isn't a clean result. It's a detection gap that nobody scored.
Purple teaming sits between the two models. Red and blue work together in the open, running a technique, checking whether it was seen, tuning the detection, and running it again. You give up the authenticity of an unaware SOC, but you gain speed. For clients building detection coverage from a low base, purple teaming often delivers more improvement per day than a covert run that only confirms nothing was detected.
Use scans for hygiene, pentests for depth on defined targets, and red teams for detection and response maturity. Buying the wrong tier doesn't just waste budget. It produces confident answers to questions nobody asked.
The Attack Chain From Recon to Exfiltration
Run the test as a chain of attacker actions and score the defenders at every link. Each step ends with a verdict: prevented, detected, investigated, or contained. When a link breaks, the record has to show whether a control broke it or the operator just stopped pulling.
The structure underneath comes from PTES, which divides a test into seven phases, from pre-engagement interactions through reporting. The standard treats the engagement as more than vulnerability scanning, since testers establish authorization and objectives, model threats, analyze weaknesses, exploit in a controlled way, and determine post-compromise impact. The phase definitions are in the Penetration Testing Execution Standard reference summary. The five attack steps below sit inside that frame.
The Five Steps in Attacker Order
- Reconnaissance: The team builds the target picture from open-source intelligence, DNS records, exposed cloud assets, and staff roles that shape the phishing scope. The defender signal is external attack surface monitoring flagging assets the client didn't know were public.
- Initial access: Entry comes through a phishing lure, an exposed service, or a misconfiguration, limited to access methods approved in advance. The signal is an email gateway verdict, an authentication anomaly, or an EDR alert on unusual process execution.
- Execution and persistence: The operator sets a foothold that survives, a scheduled task, a new cloud identity, or a beacon that survives a reboot. The signal is an alert on the persistence mechanism itself, not only the initial payload.
- Privilege escalation and lateral movement: Credential access and movement toward the stated objective test whether segmentation and privileged access monitoring constrain an attacker already inside. The signal is an alert on credential dumping behavior or an account authenticating somewhere it never normally goes.
- Collection and simulated exfiltration: The team copies a small marked dataset, never real customer data, through a channel a real attacker would plausibly use. Every transfer is logged. The signal is egress filtering or data loss prevention recognizing the outbound movement.
Reporting sits outside the chain because it belongs to the defenders' side of the table. Each step gets mapped to an ATT&CK technique ID and backed by timestamps, commands, and affected assets, following the approach described in MITRE's evaluation methodology overview. That methodology rehearses the scenario so each action produces the expected telemetry, then scores defenders on prevention, detection, investigation, and response against the observable record. A step that runs without telemetry cannot be rerun. The client patches on faith, the MSSP has no baseline to retest after a control change, and the next engagement starts from zero instead of from evidence.
Rules of Engagement Written Before the First Packet
The Rules of Engagement (ROE) are the legal and operational boundary of the test, and they must exist before testing begins. NIST SP 800-115 requires an ROE to be established before a penetration test starts, giving the assessment team authorization for defined activities while specifying constraints and prohibited actions. NIST describes the assessment plan as covering scope, allowable and unallowable activities, methodology, logistics, and communications handling during testing. Getting these penetration testing requirements settled on paper is what separates an authorized test from an incident you're explaining afterward.
What the ROE Must Contain
- Named targets: IP ranges, domains, SaaS tenants, and cloud accounts in scope, plus what's out of bounds. Unlisted ranges and tenants pull third parties into scope without their consent.
- Allowed techniques: Whether phishing, persistence, privilege escalation, and social engineering are permitted. Silence here means testers guess, and guesses become disputes.
- Prohibited actions: Denial of service, data destruction, writes to production databases, and anything that could affect payment processing. Undefined denial-of-service rules can take payment processing offline mid-test.
- Testing windows and blackouts: Trading hours, peak payment days, and freeze periods when no activity runs. A test that collides with peak trading creates business damage no finding justifies.
- Emergency stop contact: A named person reachable during every testing window, plus the response expected from the client's SOC. Without one, the SOC treats your testers as a live breach and escalates accordingly.
- White cell roster: Exactly who knows the test is running. An unnamed white cell means analysts escalate the test as a real intrusion, burning incident response time.
- Written authorization: Signed by someone with authority over every in-scope asset. A signature from someone who doesn't own the SaaS tenant doesn't authorize testing it.
FedRAMP guidance adds useful discipline here, requiring the ROE to describe target systems, scope, constraints, notifications, and disclosures, with approval before testing begins. That model scales down well to commercial clients.
For MSSPs, add two more controls. Get a separate authorization for each client, never a blanket approval across tenants. Confirm that cloud and hosting providers allow the planned activity against their infrastructure. An unclear ROE doesn't stay a paperwork problem. It turns a test into an incident, usually at the worst possible hour.
Evidence and Outcomes Every Finding Needs
A red team finding without evidence is an opinion. MITRE's adversary emulation guidance supports measuring each emulated technique across four outcomes, prevented, detected, investigated, and contained, while retaining the exact procedure and telemetry needed to reproduce failures. Adding a fifth state, missed, covers techniques no control acted on. Strong penetration testing reporting records which state every technique reached, not just whether the attacker succeeded.
| Outcome | What It Means | Evidence to Keep |
|---|---|---|
| Prevented | Control blocked the technique before it ran | Blocked event log, control name, timestamp |
| Detected | An alert fired for the behaviour | SIEM or EDR alert ID, rule name, time from action to alert |
| Investigated | Analyst gathered enough context to judge the activity | Ticket, analyst notes, triage time |
| Contained | Response isolated the host, account or session | Response timeline, actions taken, time to containment |
| Missed | No control acted on the technique | Commands, timestamps, affected assets, proof of impact |
Proof Levels From Weak to Strong
Evidence quality varies, so grade it. A screenshot of a shell is the weakest useful proof, since it shows access at a moment but little about impact. Authenticated access confirmed with a non-destructive command is stronger. Post-exploitation impact, such as reading a marked file, shows what the access gained. Rollback verification closes the loop by proving the test left no lasting change behind.
This grading matters most for automated findings. MITRE describes adversary emulation as small-scale, repeated engagements that test whether analytics function as intended, prioritizing behavioral analytics over static indicators such as hashes or IP addresses, as set out in MITRE's adversary emulation plans resource. Automated agents tend to favour recall over precision, so every automated finding must reach a proof level before it enters the report. Mark anything without a confirmed exploit as unverified and exclude it from the executive summary until a human reproduces it.
Set human sign-off gates for three categories, any finding that touched production data, any finding rated critical, and any result an automated agent produced without a confirmed exploit. Each finding records the exact procedure, the telemetry generated, and the timestamps, so a second team can reproduce it cold.
Deliver two views of the same evidence. Leadership gets an executive summary tied to the objective and business impact. The SOC gets a technical appendix with technique IDs, alert IDs, and timelines. Both views trace back to one evidence package, which is what lets you rerun the chain later and compare results accurately.
A Worked Example From an MSSP Client Engagement
This is a composite drawn from typical MSSP work, not a named client. A regional payments company in PCI DSS scope asks its MSSP one question. Can an attacker reach the card database administrator role? The ROE approves phishing of a finance user, excludes payment processing servers from destructive actions, and sets a white cell of two people.
Day one, reconnaissance finds a public staff directory and an exposed VPN portal. Neither is a vulnerability on its own. Together they tell the team who to phish and where valid credentials would be useful. Day two, the phishing lure lands. The endpoint tool flags the macro, which looks like a win, but raises no alert on the follow-on PowerShell beacon. The first control saw the delivery and missed the actual foothold.
Day three, the team reuses a stale service account with domain admin rights to reach the file server holding the database credentials. No exploit was needed. An account that should have been retired carried standing privilege straight to the objective, and segmentation didn't intervene because the traffic looked like legitimate administration.
Scoring the Chain
Of nine techniques in the chain, two were prevented, zero were detected at the moment of execution, and zero were contained before the objective was reached. The report maps each step to ATT&CK, attaches timestamps and commands, and records the service account as a root-cause finding rather than burying it as one line in a vulnerability list.
The walkthrough below shows how this kind of chain is typically briefed back to client defenders.
The client removes the stale account and adds an alert rule for credential access behavior. The MSSP then reruns the same chain, same techniques, same order. This time seven of nine techniques are detected within minutes, and the path to the database credentials no longer exists.
The retest, not the first report, proves the improvement.
That before-and-after comparison is only possible because the first run kept reproducible evidence. Without timestamps, commands, and technique IDs, the retest would be a new engagement with new luck, and the client couldn't tell whether the fixes worked or the testers just had a worse day.
Scheduling Recurring Red Team Tests Across Clients
A test that runs once a year scores your defenders once a year. PCI DSS Requirement 11.4 sets the floor: internal and external penetration testing at least every 12 months, plus another test after any significant infrastructure or application upgrade or modification. Requirement 11.4.5 puts the same annual-plus-change cycle on the segmentation controls isolating the cardholder data environment. Compliance writes the floor into the contract. Everything above the floor is a scheduling decision you make per client.
| Trigger | Test Required or Recommended | Basis |
|---|---|---|
| Annual baseline under PCI DSS | Internal and external penetration test at least every 12 months | PCI DSS Requirement 11.4 |
| Significant infrastructure or application change | Additional test before the next annual cycle | PCI DSS Requirement 11.4 |
| Segmentation control change | Segmentation test confirming cardholder data isolation | PCI DSS Requirement 11.4.5 |
| Detection rule, EDR, or identity policy change | Rerun the affected ATT&CK technique sequence and rescore each step | Recommended practice, not a compliance mandate |
| Between human-led engagements | Automated validation runs on a provider-set schedule | Terms defined in the service contract |
The rerun row is what separates a red team program from a pentest calendar. When the client's SOC tunes a detection rule or the identity team changes a policy, you rerun the same chain and score each step again: prevented, detected, investigated, or contained. The score is what the client is buying, not the activity.
The Capacity Problem Behind the Calendar
DIGIT's penetration testing trends 2025 summary reported that 48% of CISOs named pentester availability as a top obstacle, for the third consecutive year. The same summary asked why organizations test at all: 32% said prioritizing security investments, 29% said regulatory compliance, and 28% each cited control validation and assessing potential attack damage.
Read those figures together. Compliance ranks behind proving that controls work, which is exactly the question a recurring scored chain answers. The constraint sits on your side of the table. Senior operators are scarce, and every client wants the scarce resource.
That constraint should shape how you schedule. Senior operators design objectives, interpret results, and sign off on scores. Automation handles breadth and repeated runs between engagements. Managing pentest engagements at scale as an MSSP depends on that division holding across the whole client base, not just the largest account.
Write the scheduling rules into the service agreement for each client. Avoid peak trading and payment days. Agree a blackout calendar and a shared calendar of change windows. Cap concurrent alerts to the client SOC so a validation run doesn't drown real incidents. The rule that matters most: any change to detection rules, identity policy, or EDR configuration triggers a rerun of the affected techniques. A calendar that ignores change windows tests an environment that no longer exists.
Choose a Hybrid Model and Confirm Your First Scope
The split has to be concrete. Automation runs the repeatable attack chains between human-led engagements. Humans own the objectives, the business-logic attacks that no scripted agent will find, and the sign-off a client can act on. The hybrid model earns its place only when each automated step produces evidence scored against the defenders: prevented, detected, investigated, or contained. A run that returns a list of findings without that scoring tells you nothing about whether the SOC saw anything.
ThreatExploit AI fits that validation layer. Its controller orchestrates the seven PTES phases across web, network, and cloud targets, produces PDF and JSON reports with screenshots, and maps findings to frameworks such as PCI-DSS, SOC 2, and ISO 27001. Treat any vendor performance claim as something to verify in your own proof of concept before you quote it to a client.
Five Steps to a Scoped Pilot
- Sign an ROE that names the automated agents and their allowed actions.
- Pick two or three in-scope assets for a two-week proof of concept.
- Verify a sample of automated findings against the evidence levels, with a human reproducing each one and scoring the defender response at every step.
- Set the human approval gate for critical and production-touching findings.
- Schedule reruns after each detection, identity, or EDR change, replaying the same chain so you can compare scores run over run.
Start with a scoped pilot rather than a full program. Three assets with reproducible evidence and per-step defender scores tell you more about fit than a platform-wide rollout that produces volume nobody can verify.
ThreatExploit AI gives MSSPs and consultancies an automated penetration testing platform that runs reconnaissance, exploitation, verification, and compliance-mapped reporting across web, network, and cloud targets, so your senior operators can focus on objectives, evidence review, and client sign-off instead of repetitive test execution. If you're building recurring red team validation into your service catalogue, start with a scoped pilot and visit ThreatExploit AI to see how the platform handles evidence-backed reporting for customer delivery.