Intruder — Payload Fuzzer & Attack Automation

How the Intruder Works

1. Load a request — Send a request from the Interceptor, Repeater, or scan findings. Or paste a raw HTTP request manually.
2. Mark injection points — Wrap values you want to fuzz with the § delimiter. PhantomYerra highlights each position in a different color.
3. Choose an attack mode — Sniper, Battering Ram, Pitchfork, or Cluster Bomb. Each mode determines how payloads are distributed across positions.
4. Configure payload sets — Assign a payload list (or generator) to each injection position.
5. Set extraction rules — Define grep patterns to extract specific data from responses (e.g., error messages, tokens, user data).
6. Launch the attack — PhantomYerra sends all requests, logs every response, and highlights anomalies in real time.

Marking Injection Points

Injection points tell the Intruder which parts of the request to replace with payloads. Wrap any value with § markers:

Auto-Detect Injection Points

Click Auto § and PhantomYerra automatically identifies and marks likely injection points:

• Query parameter values
• JSON object values (strings, numbers, booleans)
• XML element contents and attribute values
• Cookie values
• Form field values (application/x-www-form-urlencoded)
• Multipart form data field values
• Custom header values that appear user-controlled

Manual Point Controls

Four Attack Modes

1. Sniper

Tests one injection point at a time. Iterates through a single payload list, inserting each payload into each position sequentially while all other positions hold their original values.

Best for: Identifying which parameter is vulnerable. Testing a list of SQLi, XSS, or command injection payloads against each input.

2. Battering Ram

Inserts the same payload into ALL positions simultaneously. Iterates through a single payload list.

Best for: When the same value must appear in multiple locations (e.g., CSRF token in body AND header). Also useful when testing one payload against the entire request surface.

3. Pitchfork

Each position gets its own payload list. Payloads are used in lockstep — item 1 from list A with item 1 from list B, item 2 from each, and so on. The attack stops when the shortest list is exhausted.

Best for: Credential stuffing with known username:password pairs. Testing matched data sets where position 1 and position 2 are correlated.

4. Cluster Bomb

Tests every possible combination of payloads across all positions (Cartesian product). Each position gets its own payload list.

Best for: Brute-force attacks. Testing every username against every password. Can produce a very large number of requests (M x N x P...).

Payload Sets

Built-in Payload Lists

PhantomYerra ships with curated payload lists for common vulnerability classes:

Custom Payload Sources

• File — Load payloads from a text file (one per line). Supports any wordlist format.
• Clipboard — Paste payloads directly. One per line.
• Number range — Generate sequential numbers. Configure start, end, and step. Example: 1 to 10000 for IDOR testing.
• Character set — Generate all combinations of specified characters up to a given length. For brute-forcing short tokens or PINs.
• Dates — Generate date strings in a specified format across a date range. For testing date-based access controls or log injection.
• Null payloads — Send requests with the injection point value removed entirely. Tests for missing parameter handling.
• AI-generated — In AI-assisted mode, PhantomYerra generates context-aware payloads based on the target's technology stack, detected WAF, and previous responses.

Payload Processing

Apply transformations to each payload before insertion:

• URL encode — Encode special characters for query parameters
• Base64 encode/decode — Wrap payloads in Base64
• HTML encode — Entity-encode for HTML context injection
• Prefix/Suffix — Add static text before or after each payload
• Case modification — Convert to upper, lower, or mixed case (for case-insensitive filter bypass)
• Hash — MD5 or SHA-256 hash each payload (for testing hash-based comparisons)
• Skip if matches — Exclude payloads matching a regex pattern

Grep & Extraction Rules

Grep rules let you extract and flag specific data from every response. This turns the results table into a structured data extraction engine.

Grep Match

Define strings or regex patterns to flag responses that contain matching content. Each match appears as a boolean column in the results table.

Grep Extract

Extract specific values from each response using regex capture groups. Extracted values appear as columns in the results table.

Grep Payload

Check whether the payload itself appears in the response (reflected). Useful for XSS testing: if the payload is reflected unescaped, it is likely vulnerable.

Rate Limiting & Throttling

Control the speed and concurrency of the Intruder attack to avoid overwhelming the target or triggering rate-limiting defenses.

Analyzing Results

As the attack runs, results stream into a sortable, filterable table in real time.

Results Table Columns

Identifying Anomalies

• Status code changes — A payload that triggers a different status code (e.g., 500 vs 200) often indicates a vulnerability.
• Response length changes — Sort by length. Outliers (significantly larger or smaller responses) may indicate successful injection.
• Timing anomalies — Sort by time. Requests that take significantly longer may indicate time-based blind injection (SLEEP, pg_sleep, WAITFOR DELAY).
• Grep match hits — Filter to show only rows where your grep pattern matched (e.g., "SQL error" = true). These are your high-priority findings.
• Reflected payloads — If the "Payload Reflected" column is true and the payload contained script tags, that is a strong XSS indicator.

Drill Down

Click any result row to view the full request and response in a detail panel. From there:

• Send to Repeater — Move this specific request/response to the Repeater for manual follow-up.
• Capture as Evidence — SHA-256 hash and timestamp this pair as finding evidence.
• Create Finding — Directly create a vulnerability finding from this result, pre-populated with the payload, evidence, and response details.

Common Attack Workflows

Workflow 1: SQL Injection Discovery

1. 1

   Send Request to Intruder

   From the Interceptor or Repeater, send a request with dynamic parameters to the Intruder.

2. 2

   Mark Injection Points

   Auto-detect or manually mark all parameter values as injection points.

3. 3

   Select Sniper Mode + SQLi Payloads

   Use Sniper mode to test each parameter individually. Load the SQL Injection payload set.

4. 4

   Add Grep Rules

   Add grep match rules for common SQL error strings: SQL syntax, mysql_fetch, ORA-, unclosed quotation.

5. 5

   Launch and Analyze

   Run the attack. Sort results by the SQL Error grep column. Any "true" rows are confirmed injection points. Click to inspect the full error response.

Workflow 2: IDOR / Access Control Testing

1. 1

   Capture an Authorized Request

   Intercept a request like GET /api/users/123/profile that returns your own profile.

2. 2

   Mark the ID as Injection Point

   Mark §123§ as the injection point in the URL path.

3. 3

   Use Number Range Payloads

   Configure a number range from 1 to 1000 (or use known user IDs). Select Sniper mode.

4. 4

   Add Grep Extract

   Extract the username or email from each response: "email":"([^"]+)". This confirms you are accessing other users' data.

5. 5

   Analyze Results

   If responses return 200 with different users' data, IDOR is confirmed. The extracted emails/usernames in the grep column are the evidence.

Keyboard Shortcuts