Training catalogs often reward finding the next misconfiguration fast. Enterprise assessments also need operators who can emulate adversary progressions: chained behaviors, priorities, and stops that resemble plausible campaigns - not isolated bug bounties.
Both skills matter. Confusing them in curriculum design produces operators who ace labs but cannot narrate why a path was chosen.
Vulnerability chasing (what it optimizes)
Vulnerability chasing optimizes for:
- Speed to a critical finding
- Breadth across superficial checks
- Tool coverage metrics
It under-teaches:
- Stopping rules and scope discipline
- Tradeoffs between stealth and tempo
- Reporting that defenders can operationalize
Adversary emulation (what it optimizes)
Adversary emulation optimizes for:
- Ordered behaviors with documented objectives
- Realistic constraints (time, detection, access quality)
- Repeatable narratives tied to threat models in scope
It still uses vulnerabilities - they are enablers, not the scoreboard.
Why the distinction matters for learners
A learner trained only to hunt findings will often ask the wrong question first: “What can I pop fast?” An operator trained around emulation asks better questions:
- What objective is plausible in this scenario?
- Which path best fits the assumptions and constraints?
- What evidence do I need to justify the path I chose?
- What should I explicitly avoid because it adds noise without improving the outcome?
That shift changes how the entire run is documented and reviewed.
Compare on a single scenario
Imagine a lab with a known weak service configuration.
| Approach | Success looks like |
|---|---|
| Vulnerability chase | “Found critical issue in hour one.” |
| Adversary emulation | “Achieved objective X via path Y; documented Z stops.” |
The second answer includes evidence and scope language hiring teams expect.
A better grading model
If you want training to favor emulation, the rubric has to stop rewarding isolated wins. Grade for:
| Criterion | Vulnerability-chasing bias | Emulation-ready standard |
|---|---|---|
| Success condition | Critical issue found | Objective reached with defensible path |
| Evidence quality | Screenshot proves exploit worked | Timeline shows why each step mattered |
| Scope handling | Mentioned late or ignored | Present from planning through debrief |
| Defensive insight | Optional extra credit | Expected part of the final narrative |
Operators adapt quickly to the metric. If the metric is shallow, the learning becomes shallow too.
Curriculum design implications
- Grade chains and decisions, not CVE count.
- Require negative results and deprioritized paths in reports.
- Pair offense runs with defensive feedback.
This also keeps curriculum honest. Some modules should absolutely teach vulnerability depth. They just should not masquerade as adversary-emulation practice when the scenario never asks the learner to prioritize, stop, or justify tradeoffs.
HackerForce Armory missions follow this bias - see realistic mission design and the live catalog at The Armory.
When vulnerability depth still belongs
Deep vulnerability work belongs in specialized modules and authorized assessments - not as a substitute for operational narrative in core Red Team training. Use chasing drills as supporting reps, not the spine.
Continue the thread in Intelligence Reports or discuss emulation framing on Discord.
