Unit 4: Cookies and sessions · Lesson 6 of 6 · 22 min
Case file: the patch that did not log anyone out
After a gateway leaked session tokens, patching was not enough. Find the sessions that must be ended and the one already being reused.
case file
Citrix Bleed
Citrix NetScaler ADC and Gateway customers · 2023
CVE-2023-4966 in customer-managed NetScaler appliances leaked memory that could include valid session tokens, letting attackers take over signed-in sessions and skip MFA. It was exploited as a zero-day from at least August 2023 and later widely by ransomware affiliates.
What went wrong
Stolen sessions stayed valid after the software update because existing sessions were not ended.
What would have stopped it
- Patch internet-facing gateways urgently, then end every active and persistent session.
- Keep remote access session lifetimes short and bind sessions to client attributes.
- Isolate a vulnerable appliance if it cannot be patched and cleaned at once.
What defenders could have seen
- The same session ID used from different addresses or devices.
- Remote access sessions with no matching sign-in or MFA event.
sourcescisa.govdarkreading.com
mission
- You are
- The analyst closing out the gateway patch.
- Situation
- The shop patched its remote access gateway on 10 October at 18:00 after an advisory about leaked session tokens. Your lead asks whether you are done.
- Goal
- List every session that existed before the patch and check whether any is already being reused.
- Hand in
- revoke.txt, plus the session and user that need an incident ticket.
Why patching alone does not evict anyone
Press play or step through.
When was the patch?
cat cases/gateway/patch-note.txt
Gateway firmware 14.1-12.35 installed: 2026-10-10T18:00:00Z
Advisory: memory leak could expose session tokens. Patching stops new leaks; it does not end sessions that already exist.
you should see Installed at 2026-10-10T18:00:00Z, with a warning that it does not end existing sessions.
Count the sessions created before it
ISO timestamps sort as text, so a plain string comparison in awk works.
awk -F, 'NR>1 && $3 < "2026-10-10T18:00:00Z"' cases/gateway/sessions.csv | wc -l 12 awk -F, 'NR>1 && $3 < "2026-10-10T18:00:00Z" {print $1}' cases/gateway/sessions.csv > revoke.txt && wc -l revoke.txt 12 revoke.txt
you should see Twelve sessions predate the patch. All of them go on the revoke list, whether or not anything looks wrong.
Is one already being reused?
awk '{print $2, $3}' cases/gateway/gateway.log | sort -u | cut -d' ' -f1 | uniq -d session=d3fff047a371 grep 'd3fff047a371' cases/gateway/gateway.log 2026-10-08T17:33:00Z session=d3fff047a371 ip=10.30.1.23 event=login 2026-10-08T19:30:00Z session=d3fff047a371 ip=10.30.1.23 event=access 2026-10-11T03:12:44Z session=d3fff047a371 ip=203.0.113.77 event=access 2026-10-11T03:13:02Z session=d3fff047a371 ip=203.0.113.77 event=access
you should see One session was used from its owner's address and then, at 03:12, from 203.0.113.77 outside the company.
Whose session was it?
grep d3fff047a371 cases/gateway/sessions.csv
d3fff047a371,dana.r,2026-10-08T17:33:00Z,10.30.1.23
you should see dana.r's session from 8 October. Her account needs a password reset, a check of what that address did and an incident ticket.
defender tip Revoking sessions also logs out everyone legitimate. Tell users first; it is far cheaper than an attacker keeping access.
What a defender takes away
- 1A leaked session survives a patch, a password change and MFA.
- 2After any token leak, end every session that existed before the fix.
- 3One session ID seen from two addresses is a high-confidence alert.
Questions
0 of 3 solved
Answer each one from what you find on your lab machine.