41. Session Hijacking – Tokens, Cookies and Defence
41.7 Detection – Logs, Concurrent Sessions, SIEM Signals
Blue cannot prevent every steal – must detect odd use:
- Same session ID from two far cities in minutes
- Sudden User-Agent change mid-session
- Privilege action after long idle
- Many 401/403 then success from new IP
- Logout failed but cookie still accepted (invalidate bug)
Log what matters: session create, regenerate, destroy, login MFA result, IP, UA (privacy policy aware). SIEM / Wazuh / ELK – correlate; alert SOC (fictional Shahrukh) with runbook.
| Red team (attacker) does | Blue team (defender) detects / stops |
|---|---|
| Replays cookie from Kali while user still online | Concurrent session policy; step-up MFA; kill session |
| Spoofs UA to match victim | Combine IP+UA+behaviour; don't trust UA alone |
| Uses stolen session only for quiet data read | DLP / access logs on exports; anomaly baselines |
Ravindra Bagale's Tip
Students keep just one "login success" log line. Log the session lifecycle events – create, regenerate, destroy. These are what save you in an investigation. Got it?
Ravindra Bagale's Tip – मराठी
Students फक्त "login success log" ची एक line ठेवतात. Session lifecycle events log करा – create, regenerate, destroy. Investigation मध्ये हेच वाचवतात. समजले का?
Ravindra Bagale's Tip – हिंदी
Students सिर्फ़ "login success log" की एक line रखते हैं. Session lifecycle events log करो – create, regenerate, destroy. Investigation में यही बचाते हैं. समझ आया?
Lab
Add PHP/nginx log lines on OWN app: login, regenerate, logout. From Kali replay cookie while browser still logged in. Show two IPs in log for one SID. Write alert rule pseudo: same sid + distinct /24 within 5 minutes → ticket.