Recommended resources
The freely available resources this lesson will direct you to.
Hello. This course begins with the decisions that make an offensive security engagement useful and safe: what you are trying to learn, what you are authorized to do, and what evidence will support your conclusions. Later modules move from planning into scripting, infrastructure, lab operations, and reporting.
This lesson establishes a distinction you will use throughout the course. A conventional penetration test asks, primarily, which weaknesses can be found and what can they enable? A cyber red-team operation asks whether a realistic, authorized adversary scenario can achieve a specified outcome—and how the organization prevents, detects, and responds to it. The two can use similar technical skills, but they are not interchangeable.
Start with the question the engagement must answer
Imagine an organization concerned about a restricted finance workflow. It could commission a penetration test of the application that supports that workflow. The testers would investigate weaknesses in that application and its agreed supporting systems, validate significant findings where permitted, and explain how to fix them.
Alternatively, the organization could commission a red-team operation: under agreed safety limits, can a simulated adversary reach a harmless marker placed inside the restricted workflow? If so, did defenses detect the activity, did anyone investigate it, and did the response interrupt it? The application might be involved, but the organizational outcome—and the defenses surrounding it—is the subject of the exercise.
Watch this short introduction before examining the formal definitions.
In “Introduction To Red Teaming,” HackerSploit introduces adversary behavior and contrasts objective-driven red teaming with vulnerability-focused penetration testing. Use it to hear the practical distinction, not as a substitute for written rules of engagement.
Watch the definition for its focus on defenders, processes, and technology. Then watch the comparison, where the presenter discusses validating weaknesses in a penetration test and pursuing an adversary-style outcome in a red-team engagement. Treat comments about how penetration tests usually operate as examples, not universal rules.
A penetration test is more than an automated scan. A scanner may flag a suspected flaw; a tester can investigate whether it is real, determine its consequences, and report actionable remediation. Penetration tests may also include post-exploitation work if the agreement permits it. The distinction is therefore not “pentesters find flaws; red teamers exploit them.” Both may demonstrate exploitation. What differs is the governing question and how much coverage each result is intended to provide.
[PDF] A Guide to Penetration Testing | CREST-approved
Read CREST’s “A Guide to Penetration Testing” for a grounded definition of a penetration test and an account of its limitations.
On p. 8, in Part 2, “Definition of a penetration test,” read the definition. Focus on the combination of investigation and validation. Then go to p. 10, “Penetration testing limitations,” and read the limitations list. Notice the selected target, point-in-time nature of the assessment, and need to interpret technical results in business terms.
A good penetration-test report might say that an authorization weakness in the finance application allowed an ordinary test account to view a restricted test record. Its evidence would show the permitted conditions under which the weakness was reproduced, the access obtained, the affected component, and a remediation recommendation. The test need not establish whether the security operations team would notice a longer campaign involving that weakness. That is a different question.
Red teaming changes the objective—not the requirement for boundaries
In this course, red-team operation means an authorized cyber adversary simulation. It pursues one or more outcomes chosen because they matter to the organization, while examining defenses across the relevant people, processes, and technology. Rather than trying to enumerate every weakness in a component, the team follows an agreed scenario and documents the weaknesses and decisions that mattered to its outcome.
Adversary simulation: what you need to know | National Cyber Security Centre
Read the National Cyber Security Centre’s guidance to connect the red team’s objective with what the organization hopes to learn about prevention, detection, and response.
In “What is adversary simulation?”, begin at the opening explanation; continue through the paragraph comparing adversary simulation with penetration testing. Then, under “Adversary simulation best practice” → “Phase 1: Prerequisites” → “Scoping,” read the scoping discussion. Focus on who sets the objectives, what must be formally agreed, and why initial information sharing can differ from a penetration test.
Here is the comparison in operational terms:
| Conventional penetration test | Red-team operation | |
|---|---|---|
| Primary objective | Identify and validate weaknesses in agreed systems; explain their impact and remediation. | Test whether an agreed adversary scenario can reach a significant outcome and how defenses respond. |
| Typical scope | Selected application, network, infrastructure, or other defined target. | The assets and paths needed for the agreed scenario; potentially several systems or processes, but only where authorized. |
| Starting information | May include detailed architecture, accounts, or system documentation to support coverage. | May begin with limited information to preserve realism; safety-critical information still needs to be shared. |
| Defensive visibility | Alerts and response can be useful observations, but are not necessarily the principal subject. | Prevention, detection, investigation, and response are often explicit subjects of the test. |
| Main reporting emphasis | Validated findings, affected systems, impact, and fixes. | The objective, the observed campaign path, defensive decisions and opportunities, limitations, and improvements. |
These are tendencies, not exclusive definitions. A penetration test can include social engineering or evaluate detection if commissioned to do so. A red-team operation can begin from an assumed breach, with access supplied rather than gained, if that better answers the organization’s question.
Most importantly, realism never means unrestricted access. Both engagements require authorization, an agreed scope, permitted methods, safety limits, and a way to halt or escalate a problem. A red team may have more freedom to choose among approved routes, but it does not acquire permission to target an unlisted third party, disrupt production, or collect real sensitive records simply because a real attacker might.
The diagram below illustrates why an outcome-focused operation can involve more than one system. It depicts initial access and activity across several sites over 38 days. That duration and those routes describe the depicted operation; they are not requirements for red teaming.
In the finance example, permission to test a restricted-workflow outcome would not by itself authorize phishing employees, accessing every connected server, or taking copies of finance data. Those choices must be settled in the engagement agreement. Later lessons will turn this principle into explicit scope boundaries and stop conditions.
What counts as evidence of success?
The word success needs care. A penetration tester can successfully demonstrate a weakness without compromising an entire organization. A red team can gather valuable evidence even when defenders block its objective. Neither result should be overstated.
For the penetration test, persuasive evidence ties a specific finding to a reproducible, permitted observation: the affected component, relevant test conditions, demonstrated access or behavior, impact, and recommended fix. A list of suspected vulnerabilities alone is weaker evidence than a validated finding; equally, a test that did not find a weakness cannot prove the system has none.
For the red-team operation, evidence must support both the objective result and what happened defensively. In our example, reaching a seeded, non-sensitive marker could demonstrate the agreed access outcome without copying real finance records. A time-stamped operator record and an independently checkable observation could establish that result. Defensive logs and the response team’s account would then help determine whether the activity was prevented, alerted on, investigated, escalated, or contained. Reaching the marker and being detected are not mutually exclusive: the team might achieve access and still reveal an effective detection opportunity.
Adversary simulation: what you need to know | National Cyber Security Centre
Return to the NCSC guidance for the evidence a red team should retain and the conclusions its report should draw.
Under “Adversary simulation best practice” → “Phase 2: Testing” → “Clean up,” read the activity-record paragraph. Then, under “Phase 3: Reporting,” read the reporting discussion. Notice the distinction between recording what actually happened and claiming to have discovered every possible vulnerability.
An honest red-team report separates at least three conclusions:
- Outcome: Was the agreed objective reached, blocked, or not established?
- Observation: What evidence shows what the operators and defenders actually did—and what remains unknown?
- Limitations: Which safety restrictions, supplied access, unavailable logs, or untested paths affect interpretation?
For example, “we saw no alert in the records provided” is narrower than “the organization cannot detect this activity.” Likewise, if a stop condition ended the exercise before the marker was reached, the team should record objective not demonstrated, along with any useful prevention or response observations. A credible result is one the organization can use to improve, not simply a declaration that attackers “won” or “lost.”
Conclusion
A conventional penetration test chiefly evaluates weaknesses in defined targets and supports specific fixes. A red-team operation chiefly evaluates an agreed adversary-style outcome and the defenses encountered along the way. Both can use similar techniques, both operate under explicit authorization, and both need evidence proportionate to their claims. Choose between them by the question the organization needs answered—not by which label sounds more advanced.
The next lesson takes the red-team objective one step further: translating a business concern into measurable operational success criteria, so that everyone can tell what was achieved and what remains uncertain.