Platform
How a mission actually runs
Four phases, in order, each constraining the next. This is the sequence a human red team follows, run as often as you deploy.
Phase one
Reconnaissance
The mission starts where an attacker starts: outside, with no privileged knowledge of the estate.
- Surface discovery
- Hosts, subdomains, endpoints and services that are actually reachable, not the ones on the asset register.
- Technology fingerprinting
- Frameworks, versions and infrastructure, inferred from behaviour rather than assumed.
- Exposure mapping
- What is visible without credentials, which is the set an opportunistic attacker works from.
Phase two
Enumeration
Turning a map into a target list, ranked by what is likely to yield.
- Service and version analysis
- What is running, at what version, and what that implies about known weaknesses.
- Configuration review
- Defaults left in place, permissive settings, and headers that reveal more than intended.
- Authentication surfaces
- Login flows, token handling and session behaviour, which is where privilege problems begin.
Phase three
Exploitation
The step that separates a pentest from a scan, and the step that sits behind your approval gates.
- Chaining
- Combining findings that are individually unremarkable into a route that actually reaches something.
- Adaptive approach
- When the first route fails, the agent forms another rather than reporting the attempt.
- Business logic
- Flaws specific to how your application works, which no signature database contains.
- Bounded by scope
- Everything happens inside the estate you authorised, under the controls you set.
Phase four
Validation and reporting
A finding that cannot be reproduced is an opinion. Validation is what turns it into evidence.
- Reproduction
- The chain is run again to confirm the result was not incidental.
- Impact capture
- Evidence of what was actually reached, recorded with the finding.
- Severity in context
- Rated against your environment rather than a generic scoring table.
- Remediation and retest
- What to change, and confirmation once it has been changed.
A word we do not use
Why we say recurring, not continuous
Most of this category advertises "continuous" testing. We do not, because for black-box penetration testing it is not true, and the distinction matters to anyone who has to authorise the work.
Real penetration testing is intrusive by nature. It sends traffic that looks like an attack, attempts exploitation, and touches production systems. A process that genuinely never stopped would be indistinguishable from a sustained attack on your own estate, and no responsible provider would run one.
What Revelion runs instead is discrete authorised missions, on whatever cadence you set. That can be several times a day, after every deployment, or weekly. Each one starts, does its work inside declared scope, and finishes. There are gaps between them, and those gaps are deliberate.
The practical result is coverage that is near-unbroken even though the testing is not. Your assurance stays current because missions run often enough to keep pace with how you ship, not because a process runs without pause. That is a smaller claim than the industry standard, and it is one we can actually defend.
Why this order
The sequence is the point
Each phase constrains the next. Reconnaissance decides what enumeration examines; enumeration decides what exploitation attempts; exploitation decides what is worth validating. Skip a phase and the output degrades into guesswork.
It is also why a scanner cannot reach the same result by running faster. A scanner performs phase two and reports it as though it were phase four. The intermediate reasoning, deciding which combination of weaknesses is worth trying against this specific estate, is the work.
This is the method. The results are next door.
See the benchmarks