A scanner finds known bugs. A red team finds out whether someone could actually achieve a goal against you, like stealing your customer data, by stringing together whatever weaknesses they find along the way. That's the difference that matters, and it's why this is the capstone of the Break pathway: it pulls together everything before it into a realistic, objective-driven exercise. You don't need a specialist team to start. Any development team can run a lightweight version.
Where it sits among the three
| Activity | Goal | Duration |
|---|---|---|
| Vuln scan | Find known CVEs | Minutes |
| Pen test | Find and exploit vulnerabilities | Days |
| Red team | Achieve an objective like a real attacker | Weeks |
Pick an objective, not a checklist
The thing that makes a red team exercise different is that you define a concrete goal and then find any path to it, rather than ticking off a list of controls:
| Objective | What it tests |
|---|---|
| Exfiltrate 1,000 customer records | Data access controls |
| Get a shell on production | Infrastructure and detection |
| Deploy a backdoored build | CI/CD security |
| Reach the production database from a dev laptop | Lateral movement |
Get authorisation first
This is not optional. Get written authorisation, and define the scope, the rules of engagement, and who's in on it before you touch anything. Attacking systems without that, even your own employer's, can be a criminal matter.
The phases
A realistic exercise mirrors how a real intrusion unfolds:
- Recon. DNS enumeration, technology fingerprinting, OSINT.
- Initial access. A web vulnerability, phishing, an exposed service, a supply chain weakness.
- Post-exploitation. Once you're in, see how far you can reach:
aws sts get-caller-identity
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
env | grep -i secret
- Objective. Document what you could access. Demonstrate the reach; never actually exfiltrate real data.
- Report. The attack path, a timeline, where detection failed, and what to fix.
Lighter versions you can run this week
You don't have to commit to a multi-week operation to get value:
- Threat model, then attack. After threat modelling a feature, take your top three threats and try them against staging.
- Purple team. Sit the attacker and defender in one room: the attacker explains a technique, the defender checks whether it was detected, and you both review the gap. It's the fastest feedback loop in security.
What you'll almost certainly find
These show up so reliably they're worth checking for proactively: internal tools with no auth, IAM roles scoped far too broadly, credentials sitting in environment variables, no network segmentation, and no detection of lateral movement once an attacker is inside.
Define the objective, get the authorisation, simulate the real phases, and document both the attack paths and the detection gaps. The whole point is to find and close those gaps on a calm afternoon, before a real attacker finds them on a bad one.