Request Attacker

The Request Attacker is Ghost’s equivalent to Burp Suite’s Intruder — a parameterized attack tool that sends many variations of a request and analyzes the responses. Available in both manual UI and as an agent tool.

Attack Modes

Mode	Description	Total Requests
Sniper	One payload list, one position at a time. Other positions keep original values.	positions × payloads
Battering Ram	Same payload inserted into ALL positions simultaneously.	payloads
Pitchfork	Each position gets its own payload list, iterated in parallel (zip).	min(list lengths)
Cluster Bomb	Full Cartesian product of all payload lists across all positions.	product of all list lengths

How to Use

1. Select a flow in the traffic list
2. Open the Attacker Panel (Security mode toolbar button)
3. Mark insertion points — select text in the URL, headers, or body to mark as §payload§
4. Choose payload source:
   • Built-in wordlist (18 categories)
   • Custom list (paste or type)
   • Number sequence (start, end, step)
   • Null payloads (empty values)
5. Configure match rules (optional) — identify “interesting” responses
6. Set attack mode (Sniper, Battering Ram, Pitchfork, Cluster Bomb)
7. Launch — results stream in real-time

Embedded Wordlists

Ghost embeds 10 payload wordlists (~251 payloads total) via go:embed from the payloads/ directory:

Wordlist	Payloads	Purpose
sqli-generic	60	SQL injection testing — union, boolean-based, error-based, time-based payloads
xss-reflected	33	Cross-site scripting — script injection, event handler, SVG, and encoding bypass payloads
ssrf	29	Server-side request forgery — localhost variants, cloud metadata URLs, protocol handlers
command-injection	27	OS command injection — shell metacharacters, chained commands, blind injection
open-redirect	22	URL redirect testing — protocol-relative, double-encoding, domain confusion
path-traversal	21	Directory traversal — dot-dot-slash variants, encoding tricks, OS-specific paths
nosql-injection	17	NoSQL injection — MongoDB operator injection, JSON injection, boolean bypass
auth-bypass-headers	16	Authentication bypass — forwarded-for spoofing, internal-only headers
ssti	14	Server-side template injection — Jinja2, Twig, Freemarker, ERB expressions
http-methods	12	HTTP method fuzzing — testing how the server handles unusual methods

These wordlists are curated for quality over quantity — each payload is chosen to detect a specific vulnerability class with minimal false positives. You can also provide custom payload lists (paste or type), number sequences (start, end, step), or null payloads (empty values).

Match Rules

Define rules to flag “interesting” responses. Ghost supports 6 rule types:

Rule Type	What It Checks	Example Use
status_diff	Response status code differs from the baseline request	A 200 on a normally-403 endpoint means the auth bypass worked
length_diff	Response body length differs >20% from baseline	A much longer response might reveal extra data (IDOR, info leak)
body_contains	Response body contains a specific string	Flag responses containing “admin”, “root”, “stack trace”, or “error”
body_regex	Response body matches a regular expression pattern	Flag responses matching a regex like password\s*[:=]
time_gt_ms	Response time exceeds a threshold in milliseconds	Flag responses taking >5000ms (possible time-based SQL injection)
header_contains	A response header value contains a specific string	Flag responses with X-Debug: true or unusual CORS headers

Baseline Comparison

Before launching the attack, Ghost automatically sends the original (unmodified) request as a baseline. The baseline captures: status code, response body length, response time, body hash (FNV-64a), and headers. Each attack result is then compared against the baseline using three automatic checks:

• Status code change — any different status code is flagged (e.g., baseline returns 403, payload returns 200)
• Body length delta >20% — a significantly different response size suggests the payload changed server behavior
• Response time >3× baseline — a much slower response suggests time-based injection or heavy processing

Results that differ are marked as “interesting” with a DiffFromBase string showing exactly what changed (e.g., "status:200->500, length:+450").

Results Streaming

Attack results stream in real-time via WebSocket events:

• attacker:started — attack begun, total request count
• attacker:progress — per-request result (status, length, time, matched, payload)
• attacker:completed — attack finished, summary statistics
• attacker:error — attack failed

The UI shows:

• Progress bar with percentage and request count
• Live results table with sortable columns (payload, status, length, time, match)
• Summary with status distribution and top interesting results

Advanced Settings

Setting	Default	Maximum	Description
Threads	5	10	Concurrent requests (channel-based semaphore). Higher = faster but more aggressive.
Delay (ms)	50	—	Delay between launching each request. Prevents overwhelming the target.
Max requests	500	2,000	Safety cap on total requests per attack. Prevents accidental cluster bomb explosions.
Follow redirects	false	—	Whether to follow HTTP 3xx redirects. Off by default so you can see the raw redirect response.
Timeout (s)	30	—	Per-request HTTP client timeout. Requests exceeding this are marked as timed out.

Agent Integration

The attack_request tool lets the AI agent use the attacker programmatically:

{
  "tool": "attack_request",
  "input": {
    "flow_id": "01HWRFQP...",
    "mode": "sniper",
    "positions": [{"start": 42, "end": 48, "location": "body"}],
    "payloads": {"type": "wordlist", "name": "sqli"},
    "match_rules": [{"type": "status", "value": "200"}]
  }
}

The tool has a 5-minute timeout and is routed to active_test and exploit plan step categories.

Architecture

The attacker uses an async 202 pattern — POST /attacker/run returns immediately with 202 Accepted, and results stream via WebSocket events. This prevents HTTP timeout issues for long-running attacks.