Active Exploitation (RCE Verification)
A scanner says “vulnerable”, Active Exploitation proves it. In strictly graded modes a vulnerability is exploited in a controlled way to demonstrate its actual impact – without collateral damage. Every attempt is bound to explicit authorisation and fully audited.
Only with allowActiveExploitation active; reverse_shell requires a second opt-in.
What we check
Here is what the Active Exploitation covers – concrete and verifiable.
- oob_only: out-of-band callback (DNS/HTTP) proves the vulnerability without command execution
- command_proof: read-only command (id, hostname), stdout as proof
- reverse_shell: interactive listener – only with a second, explicit opt-in
- Exploit library: log4shell, spring4shell, java_deserialization, ssti, cmd_injection
- Automatic matching of suitable findings to available exploits
- Every attempt recorded as an ExploitSession with a full command audit
Your benefits
What the Active Exploitation actually gives you – beyond the pure technology.
No more debates
Concrete proof ends the debate over whether a finding is “only theoretical” – that dramatically speeds up prioritisation and sign-off for remediation.
Graded escalation
From a harmless out-of-band callback to an interactive shell – you decide how far testing goes, each step with its own opt-in.
No collateral damage
Read-only proofs and tight limits ensure the verification proves the issue without endangering systems.
Airtight evidence
Every command and session lands in the audit trail – ideal for compliance and internal sign-off processes.
How it works
- 1
Check the prerequisite
Active Exploitation only runs if the engagement has allowActiveExploitation set.
- 2
Match a finding
The dispatcher maps suitable findings to an entry in the exploit library.
- 3
Choose a mode
From oob_only via command_proof to reverse_shell – each with the required opt-in.
- 4
Proof & audit
The result is recorded as an ExploitSession with all commands in a tamper-evident way.
Typical findings
- Log4Shell with confirmed command executioncritical
- Java deserialization leads to RCE (command_proof)critical
- SSTI verified via out-of-band callbackhigh
- Command injection with read-only proofhigh
Example finding categories. Actual results depend on your environment.
Use cases
- Unambiguous proof of critical vulnerabilities for fast sign-off
- Validation of N-day exposure during acute threats
- Solid evidence for management and auditors
- Quality assurance of automated findings before escalation
Frequently asked questions
Is this dangerous for my systems?
The default modes are deliberately gentle: oob_only executes no commands at all, command_proof only harmless read-only commands. The interactive shell is a deliberate, doubly confirmed special case.
Who can trigger this?
Only inside an engagement with allowActiveExploitation active. reverse_shell additionally requires a second, explicit opt-in.
Is everything documented?
Yes. Every attempt is recorded as an ExploitSession including all ExploitCommands in the append-only audit trail.
Goes well with
Deep scan
The thorough check: active vulnerability tests with verification – not guesses, but proof.
Internal pentest
An authorised agent inside your own network: Active Directory, credential testing and lateral movement – with a signed scope.
Rapid Response
New critical CVE? One API call checks your entire fleet immediately – and you know within minutes whether you're affected.
Ready for the Active Exploitation?
Start with a free scan or talk to us about the plan that fits your use case.