AI Exploit Engine: Highlight-to-Hack

The following files were used as context for generating this wiki page:

Overview

The AI Exploit Engine integrates the existing WSHawk AI backend directly into the manual testing workflow inside ReqForge. Instead of generating generic word lists, it reads the exact context surrounding a selected parameter — the JSON structure, the field name, the data type, the nesting depth — and generates payloads that are specifically designed to break out of that particular syntax.

The feature is accessed by selecting a parameter value in the ReqForge editor, right-clicking, and choosing Generate AI Payloads. The result is a set of context-aware attack payloads that are automatically inserted into the Payload Blaster as a custom word list, with the injection marker (§) positioned at the highlighted value.

The underlying LLM integration reuses the provider configuration from the existing WSHawk AI engine (wshawk/ai_engine.py): Ollama for local inference and OpenAI-compatible providers for cloud inference.

For information about the Payload Blaster that the generated payloads are sent to, see Desktop Advanced Features. For information about the existing AI engine used for heuristic analysis, see WSHawkV2 Scanner Engine.

Context Detection

The quality of the generated payloads depends on accurate detection of the structural context around the selected value. The AI Exploit Engine classifies each selection into one of four primary categories:

JSON Context

Trigger: The ReqForge message body is valid JSON.

The engine identifies:

Data type of the selected value: string, integer, boolean, array, object.
Field name of the key associated with the selected value.
Nesting depth: whether the field is top-level or nested inside one or more objects.
Sibling fields: the names and types of other keys in the same object.

Examples of type-specific payload logic:

| Detected Type | Attack Vectors Generated | |--------------|-------------------------| | Integer | IDOR enumeration, SQLi (numeric context), NoSQLi ($gt, $lt), type confusion (pass string, array) | | String | SQLi, XSS, SSTI, path traversal, SSRF URL injection | | Boolean | Logic bypass (true as admin flag), type confusion (pass string "true") | | Object | Prototype pollution (__proto__, constructor), JSON injection | | Array | Array injection, array-to-string confusion |

XML Context

Trigger: The ReqForge message body is valid XML or the Content-Type header indicates XML.

The engine identifies:

Whether the selected value is in an element body or an attribute.
Whether there is an existing DOCTYPE declaration.
Namespace prefixes in use.

Attack vectors generated: XXE (file read, SSRF, denial of service), XML injection, SSTI via XSLT.

URL Parameter Context

Trigger: The cursor is inside a query string, path segment, or form-encoded body.

Attack vectors generated: SQLi, path traversal, SSRF, open redirect, parameter pollution.

Raw Frame Context

Trigger: The body is neither JSON nor XML (binary, plain text, or unrecognized format).

The engine operates in lower confidence mode and generates a general-purpose payload set covering common injection points.

Sources: ai_exploit_engine.py: context detection

Workflow

Step 1: Open the Target Frame in ReqForge

Navigate to the ReqForge tab in the WSHawk Desktop. Capture or manually construct a WebSocket frame containing the parameter you want to test. The frame appears in the editor with syntax highlighting.

Step 2: Select the Parameter Value

Click and drag to select the value of the target parameter. For JSON, select the value only — not the key or quotes. For example, in {"userId": 4891}, select 4891.

Step 3: Right-Click and Generate

Right-click the selection. The context menu shows:

Wrap in § — Adds the injection marker without generating payloads
Generate AI Payloads — Sends the selection and context to the AI Exploit Engine
Generate AI Payloads (Extended) — Same, but requests 30 payloads instead of 12

Click Generate AI Payloads.

Step 4: Review Generated Payloads

A panel slides out below the editor showing the detected context summary and the generated payloads. Each payload is displayed with its intended attack technique label.

Context: JSON → string field → "userId" → nesting depth 1

Generated 12 payloads:
  [SQLi]          4891' OR '1'='1
  [SQLi]          4891'; DROP TABLE users; --
  [SQLi]          4891 UNION SELECT null,null,null--
  [NoSQLi]        {"$gt": 0}
  [NoSQLi]        {"$regex": ".*"}
  [IDOR]          1
  [IDOR]          0
  [IDOR]          99999
  [XSS]           <script>alert(document.domain)</script>
  [SSTI]          {{7*7}}
  [SSTI]          ${7*7}
  [Type Confusion] ["4891"]

Each payload row has a checkbox (all checked by default), the technique label, and the payload string. Unchecking a row excludes that payload from the Blaster list.

Step 5: Send to Payload Blaster

Click Send to Blaster. The Payload Blaster tab activates with:

The full ReqForge message pre-loaded as the template.
The selected value replaced with the injection marker §.
The AI-generated payloads loaded as the word list.

The Blaster is ready to fire immediately.

Sources: ai_exploit_engine.py, renderer.js: ReqForge context menu

Prompt Construction

The AI Exploit Engine constructs a compact, structured prompt from the parsed context. The prompt is intentionally minimal — under 300 tokens — to reduce latency and maximize compatibility with small local models.

CONTEXT:
Format: JSON
Field: "userId"
Type: integer
Depth: 1 (top-level)
Siblings: "channel" (string), "sessionId" (string)

Full frame:
{"userId": 4891, "channel": "orders", "sessionId": "abc123"}

Selected value: 4891

TASK:
Generate 12 injection payloads for this field. For each payload,
output: TECHNIQUE|PAYLOAD on its own line.
Focus on: SQLi, NoSQLi, IDOR, XSS, SSTI, type confusion.
Format payloads as drop-in replacements for the selected value.
Output only the TECHNIQUE|PAYLOAD lines, no other text.

Response parsing:

The engine expects one TECHNIQUE|PAYLOAD line per payload. Any line that does not match this format is discarded. The engine retries once with a clarified prompt if fewer than 3 valid lines are returned.

Sources: ai_exploit_engine.py: prompt construction

Provider Configuration

The AI Exploit Engine uses the same provider configuration as the existing WSHawk AI engine:

Ollama (Local Inference)

# Default — no configuration required if Ollama is running locally
AI_PROVIDER = "ollama"
OLLAMA_BASE_URL = "http://localhost:11434"
OLLAMA_MODEL = "llama3"  # or any model available in your Ollama installation

Recommended models for exploit generation:

| Model | Parameters | Quality | Latency (per request) | |-------|-----------|---------|----------------------| | llama3 | 8B | Good | 3 – 8 seconds | | mistral | 7B | Good | 3 – 8 seconds | | codellama | 7B | Excellent for code/injection | 4 – 10 seconds | | deepseek-coder | 6.7B | Excellent for code/injection | 4 – 10 seconds |

OpenAI-Compatible Providers

AI_PROVIDER = "openai"
OPENAI_API_KEY = "sk-..."
OPENAI_BASE_URL = "https://api.openai.com/v1"  # or any compatible endpoint
OPENAI_MODEL = "gpt-4o-mini"

Any OpenAI-compatible API is accepted: OpenAI, Groq, Together.ai, Anyscale, LM Studio.

Fallback Behaviour

If the configured LLM provider is unavailable or returns an error:

The engine falls back to the built-in heuristic generator, which produces a static rule-based payload set for the detected context.
The payload panel displays a banner: AI provider unavailable — using built-in heuristics.
The user can still proceed to send the heuristic payloads to the Blaster.

The fallback set is smaller (typically 5-8 payloads) but always available regardless of AI configuration.

Sources: ai_exploit_engine.py: provider configuration

REST API Reference

POST /ai/context-exploit

Request:

{
  "frame": "{\"userId\": 4891, \"channel\": \"orders\"}",
  "selected_value": "4891",
  "selected_field": "userId",
  "context_format": "json",
  "count": 12
}

| Field | Type | Required | Description | |-------|------|----------|-------------| | frame | str | Yes | Full message body from ReqForge | | selected_value | str | Yes | The highlighted value | | selected_field | str | No | The key name — engine can detect this automatically | | context_format | str | No | json, xml, url, raw — auto-detected if omitted | | count | int | No | Number of payloads to generate (default: 12, max: 50) |

Response:

{
  "status": "success",
  "context": {
    "format": "json",
    "field": "userId",
    "type": "integer",
    "depth": 1,
    "siblings": ["channel", "sessionId"]
  },
  "payloads": [
    {"technique": "SQLi", "payload": "4891' OR '1'='1"},
    {"technique": "NoSQLi", "payload": "{\"$gt\": 0}"},
    {"technique": "IDOR", "payload": "1"},
    {"technique": "XSS", "payload": "<script>alert(document.domain)</script>"},
    {"technique": "SSTI", "payload": "{{7*7}}"},
    {"technique": "Type Confusion", "payload": "[\"4891\"]"}
  ],
  "provider": "ollama",
  "model": "llama3",
  "elapsed_ms": 4327.2
}

Error — provider unavailable:

{
  "status": "fallback",
  "msg": "AI provider unavailable — heuristic payloads returned",
  "payloads": [...]
}

Sources: gui_bridge.py: /ai/context-exploit route

Integration with Payload Blaster

When Send to Blaster is clicked, the following happens:

The ReqForge editor exports the current frame as the Blaster template.
The selected value in the template is replaced with § (the injection marker).
The checked payloads from the AI panel are written to a temporary word list.
The Blaster tab activates with the template and word list pre-loaded.
The word list label in the Blaster UI shows AI Generated (12 payloads) instead of the default list name.

No files are written to disk during this process. The word list lives in memory for the duration of the Blaster session. If the operator wants to save the list for future use, they can click Export Word List in the Blaster toolbar.

Technique Reference

The AI Exploit Engine instructs the LLM to label each payload with one of these standardized technique identifiers:

| Technique | Abbreviation | Target Vulnerability | |-----------|-------------|---------------------| | SQLi | SQL injection | Relational database query injection | | NoSQLi | NoSQL injection | MongoDB, CouchDB operator injection | | IDOR | Insecure Direct Object Reference | Horizontal/vertical privilege escalation | | XSS | Cross-Site Scripting | JavaScript injection into response | | SSTI | Server-Side Template Injection | Jinja2, Twig, Freemarker expression evaluation | | XXE | XML External Entity | File read, SSRF via XML parser | | Path Traversal | Path traversal | Directory traversal via ../ sequences | | SSRF | Server-Side Request Forgery | Internal network access via parameter | | Prototype Pollution | Prototype pollution | JavaScript __proto__ injection | | Type Confusion | Type confusion | Unexpected type coercion on the server | | Command Injection | Command injection | OS command execution via injected operators | | LDAP Injection | LDAP injection | Directory service query manipulation |

Limitations

Short field names with no semantic content. If the field is named a, x, or data, the engine has insufficient context to determine the most likely vulnerability class and will generate a broader, less targeted set.

Deeply nested structures. Structures nested more than 5 levels deep may cause the context summary to exceed the token budget. The engine automatically truncates parent context in this case, focusing on the immediate parent object.

Binary frames. Binary WebSocket frames cannot be parsed for JSON or XML context. The engine operates in raw mode and produces a generic payload set.

LLM hallucination. The engine filters out malformed output lines, but may occasionally produce a payload that is syntactically incorrect for the detected context. Review the generated list before running a large Blaster session.

Summary

The AI Exploit Engine closes the gap between automated scanning and manual testing. Instead of requiring the tester to manually identify the right injection syntax for each field and look up the appropriate payload list, the engine reads the structural context of the target field and generates payloads that are immediately applicable without modification. Combined with the Payload Blaster's rate controls and the DOM Invader's verification, the resulting workflow — highlight, generate, verify — covers the full cycle of manual parameter injection testing in a single integrated interface.

Sources: ai_exploit_engine.py, gui_bridge.py: /ai/context-exploit, docs/V3.0.3_RELEASE_GUIDE.md: Section 6