Ravindra BagaleCourses & study guides मराठी Track your progress

41. Session Hijacking – Tokens, Cookies and Defence

41.7 Detection – Logs, Concurrent Sessions, SIEM Signals

By Last updated:

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?

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.

Extended teaching notes

Why this lesson matters

Web flaws stay in the OWASP Top 10 because real apps still ship them. Your job is not to collect tool screenshots. It is to prevent and fix the class of bug on systems you own.

Apply the fix across stacks

Same class of bug, same idea in every language.

Java / Spring Boot

Parameterise queries, encode output, CSRF tokens, limited Actuator, dependency scanning.

ASP.NET Core

EF Core / parameterised SQL, Razor encoding, HTTPS, Data Protection.

Node.js / Express

helmet, parameterised SQL, npm audit, avoid eval and shell concat.

Python / Django / Flask / FastAPI

ORM, autoescape, pip-audit, Bandit; never shell=True with user input.

PHP / Laravel

PDO/Eloquent, Blade escaping, composer audit.

Go / Ruby

database/sql placeholders / ActiveRecord; html/template / ERB escaping; govulncheck / Brakeman.

nginx / Apache / Tomcat

Hide versions, TLS, security headers, least-open ports.

MySQL / PostgreSQL / MongoDB / Redis

Private networks, auth on, least-privilege users, no 0.0.0.0/0.

AWS / Azure / GCP

Roles not long-lived keys, private data stores, cloud audit logs on.

Real examples

Global: injection and XSS still appear in breach reports and bug bounties every year. Indian company (sample): a Bengaluru SaaS team maps each OWASP item to a CI check or a code-review question so new code cannot silently reintroduce it.

Mini case study

Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.

Defender's worksheet (do this today)

  1. Write the lesson title, date and the exact lab target you are allowed to use.
  2. List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
  3. Run one safe check from the lesson on a lab system only. Paste the command and output.
  4. Write a two-sentence fix you would give a teammate.
  5. Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.

Indian workplace (sample data)

Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).

Global practice

Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.

Everyday analogy

Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.

Key terms

  • Control: a safeguard (patch, config, process, detection).
  • Finding: a weakness backed by evidence.
  • Remediation: the fix plus how you verified it.
  • Scope: systems you have written permission to touch.
  • Least privilege: only the access the task needs.
  • Defence in depth: several layers so one failure does not end the story.

Common mistakes

  • Skipping written permission "just for a quick scan".
  • Practising on hostel, office or public targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
  • Publishing screenshots that contain secrets, cookies or internal hostnames.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Fix > spectacle.

Real incident: Microsoft 365 token spray – stolen sign-in sessions replayed into 79 organisations, no password needed (Oct 2026)

1. What happened

In this lesson you learnt that after you log in, the website gives you a session token (like a cookie). Whoever holds that token is "logged in". If an attacker copies it, they need no password and no MFA code.

  • On 22 October 2026, the security company Huntress reported a campaign against Microsoft 365 email accounts.
  • Between 14 July and 22 September 2026, Huntress responded to incidents at 79 organisations. It saw at least 497 successful sign-ins and more than 200,000 failed attempts from the attacker.
  • The attacker did not guess passwords. It replayed sign-in tokens stolen from victims. Huntress calls this "token spraying": like password spraying, but with stolen tokens.
  • Inside the accounts, the attacker registered at least 48 fake computers in the company directory (Microsoft Entra ID), wiped and replaced the victims' MFA methods in 19 organisations, and made hidden inbox rules.
  • In one case, the attacker sent a payroll-related email from a hacked mailbox to an outside accountant, and hid the replies. This is how business email compromise (BEC) fraud starts.
  • Strict Conditional Access rules worked: in one wave, 1,052 sign-ins were blocked, all at just four organisations. In the other organisations nothing stopped the attacker.

2. How the hack happened (public reporting only – high-level)

  1. The victim got a phishing link to a fake sign-in page. The page was a relay (adversary-in-the-middle, AiTM). It showed the real Microsoft login and the real MFA prompt.
  2. The victim typed the password and approved MFA. Microsoft gave a session token after MFA, and the relay kept a copy.
  3. Some victims were instead tricked into typing a code on Microsoft's real page (device-code phishing). That also handed tokens to the attacker.
  4. Within minutes (4 to 12 minutes in two cases Huntress timed), the attacker reused the token from rented servers. The token was made after MFA, so no MFA prompt appeared.
  5. To stay in after the token expired, the attacker added its own authenticator app and registered fake devices.
  6. It made inbox rules with short, forgettable names that deleted mail or moved it to quiet folders like RSS Feeds or Conversation History, so the owner would not see replies or warnings.
  7. It changed IP addresses between waves, so a block on one address did not stop the next wave.

3. How to stop it / defend (this lesson: detection – logs, concurrent sessions, SIEM signals)

Why: MFA protects the login. It does not protect the token made after login. So you must watch how each session is used, and kill a bad session fast.

Signals to alert on in your SIEM:

  1. A user's session used from a new country or a hosting/VPN network minutes after a normal login.
  2. The operating system or browser changes in the middle of one session (Huntress saw macOS change to Windows).
  3. MFA methods deleted and a new one added within minutes.
  4. A new device registered from a hosting network.
  5. A new inbox rule with a 1–3 character name, a rule that moves mail to RSS Feeds or Conversation History, or a rule that matches words like payroll or bank.
  6. Many Conditional Access blocks for one user. Treat this as "the password or token is valid", not as "we are safe".

Steps when you find one:

  1. Revoke all sessions of the user. A password reset alone is not enough: Huntress says an access token can still work for about 90 minutes.
  2. Reset the password.
  3. Remove unknown MFA methods and devices. A password reset leaves them in place.
  4. Delete the hidden inbox rules and warn contacts (accountant, bank) about any fake email.

The same "log out everywhere" idea in your own web app:

  • PHP: keep sessions in a database or Redis with the user id, and delete all rows for that user on password reset.
  • Node.js (express-session): use a Redis store, keep a list of session ids per user, and destroy them all on reset.
  • Java / Spring Security: use SessionRegistry.getAllSessions(user, false) and call expireNow() on each one.
  • .NET (ASP.NET Core Identity): call UpdateSecurityStampAsync(user), so old login cookies stop working at the next security-stamp check.
  • Python / Django: a password change already logs out other sessions; for a full kill, delete that user's rows from the session table.
  • JWT apps: keep access tokens short (5–15 minutes) and revoke the user's refresh tokens on the server.

4. How to take care so it won't happen again (checklist)

  • [ ] Use phishing-resistant MFA (passkeys or FIDO2 security keys) for email and admin accounts. They do not work on a fake site.
  • [ ] Turn on Conditional Access that requires MFA for all users, all apps and all client types, and allow only managed devices for staff where you can.
  • [ ] Block device-code sign-in unless a team really needs it.
  • [ ] Let only admins register devices, and stop normal users from approving new apps.
  • [ ] Every week, review new MFA methods, new devices, new inbox rules and forwarding rules.
  • [ ] Teach staff: never sign in or type a code from a link in an email. Open the app yourself.
  • [ ] Confirm any payment or bank-detail change by calling a number you already know, not one from the email.
  • [ ] Write a short runbook: revoke sessions → reset password → remove MFA methods and devices → remove rules → tell contacts.

Source: Huntress (Andrea Hatcher), "M365 Token Spray and Replay Campaign Compromises Business Email Accounts", Huntress Blog, 22 October 2026; Help Net Security, "Microsoft 365 accounts compromised at 79 organizations, no passwords needed", 23 October 2026; Infosecurity Magazine, "Widespread Token-Spraying Attacks Target Microsoft 365 Accounts", 23 October 2026.

Check if you're safe: Password Strength Checker