Zero Assumptions · Week 7 of 25 · Pillar 2: Software stack & contextual risk
Your morning login was legitimate.
So the session running at 17:00 must be too.
Session tokens are hijacked, not phished. Once an attacker has your token, they don't need your password, your MFA, or your hardware key. They already passed authentication. The question is whether your SOC finds them before they find what they came for.
|
Last week we covered identity drift — the entitlement state that diverges from policy between assessment cycles. This week we look at a different gap: the time between when a legitimate user authenticates and when an attacker who has stolen that session is detected and contained.
The assumption that most identity architectures are built on: strong authentication at login means the session that follows is trustworthy for its duration.
The reality: session tokens are one of the most actively targeted artefacts in enterprise environments — and once stolen, they bypass every authentication control you have deployed, including FIDO2 hardware keys, because authentication already happened.
|
207 days
The average time for an organisation to identify a breach — nearly seven months during which an attacker operating on a stolen session has unrestricted access to every resource the legitimate user could reach, generating authentication events that look entirely normal.
Source: IBM Cost of a Data Breach Report 2024
|
How session hijacking bypasses your authentication stack
Modern authentication is designed to make the login event highly resistant to attack. FIDO2 hardware keys make phishing the credential essentially impossible. Conditional access policies ensure authentication only succeeds from compliant devices. MFA adds a second factor. All of this is correct and valuable.
The attack has moved downstream. Session hijacking doesn't target the login — it targets the token issued after the login succeeds. An attacker who obtains a valid session token can replay it against the same application without re-authenticating. From the application's perspective, every subsequent request is indistinguishable from a legitimate user action — because it carries a valid, recently-issued token from a genuine authentication event.
The three primary token acquisition techniques in active use: malware-based cookie theft from browser storage, AiTM (Adversary-in-the-Middle) proxy attacks that intercept the token in transit after authentication completes, and post-compromise token extraction from memory or credential stores on a compromised endpoint. All three have industrialised toolkits available at commodity prices.
The SOC response time problem
The 207-day average detection time is not a technology failure — it is a signal-to-noise problem. A SOC analyst reviewing alerts sees thousands of authentication events daily. A stolen session token generates authentication events that are structurally identical to legitimate ones: correct user identity, valid token, normal application access pattern. There is no failed authentication, no unusual credential, no malware signature. The only signal is behavioural — and behavioural anomaly detection requires a baseline, context, and time to establish both.
The problem compounds significantly at the weekend. Attackers know SOC staffing levels drop on Saturday and Sunday. The data reflects this directly.
|
50%
Of ransomware and major security incidents are initiated at the weekend — when SOC staffing is reduced, alert triage is slower, and the time from initial access to first human review is measured in hours rather than minutes. Attackers plan around your on-call rota.
Source: Cybereason — Organizations at Risk: Ransomware Attackers Don't Take Holidays
|
The combination is the real exposure: a stolen session token that generates no unusual authentication signals, acquired on a Friday afternoon, replayed through a weekend when your SOC is running at reduced capacity. By Monday morning the attacker has had 60+ hours of undetected access — and the Monday alert queue is too deep to triage the anomaly before lateral movement is complete.
| Phase |
Industry average |
What the attacker does during this window |
| Token theft to first access |
< 2 hours |
Establishes foothold, enumerates accessible resources |
| First access to lateral movement |
1–3 days |
Maps internal network, identifies high-value targets |
| Lateral movement to privilege escalation |
Days to weeks |
Acquires admin credentials, establishes persistence |
| Weekend initiation advantage |
+60 hrs undetected |
Full weekend of reduced SOC capacity — lateral movement completes before Monday triage |
| SOC detection (average) |
207 days |
Data exfiltration, ransomware staging, or persistent access sale |
| Containment after detection |
73 days |
Attacker has had 280 days total. Damage is done. |
|
73 days
The average time to contain a breach after detection — meaning the total average exposure window from initial compromise to containment is 280 days. An attacker with a stolen session and a weekend head start has the better part of a year before they are removed from the environment.
Source: IBM Cost of a Data Breach Report 2024
|
What changes the detection timeline is not more alerts and not more analysts on the weekend rota — it is architectural controls that limit what a stolen session can do and for how long it is valid, making the session itself a smaller, shorter-lived target regardless of when the attacker strikes.
|
The blueprint — three controls that close the session gap
1. Continuous access evaluation (CAE): Move from static session tokens to real-time policy enforcement. CAE allows your identity provider to revoke a session mid-flight — the moment a risk signal fires (impossible travel, device compliance change, user account modification) — rather than waiting for the token to expire. Microsoft Entra ID and Okta both support CAE; most organisations have not enabled it. Enabling CAE reduces the window between session theft and forced re-authentication from hours to seconds — including at 02:00 on a Saturday when no analyst is watching.
2. Short-lived token lifetimes with step-up authentication: Reduce access token lifetimes for sensitive resources to 1 hour or less. When the token expires, step-up authentication — requiring the hardware key again — gates re-entry. A stolen token acquired on Friday afternoon is dead before the attacker finishes the lateral movement phase. The weekend advantage disappears.
3. Device-bound session tokens: Bind session tokens to the hardware credential that generated them. A token issued to a FIDO2 authenticator cannot be replayed from a different device — the cryptographic proof required to use it is physically bound to the key. This directly closes the cookie theft and AiTM replay attack vectors at the architectural level, reducing your SOC's detection burden by eliminating the attack category rather than trying to detect it in real time.
|
|
Series recap — where we are
Pillar 1 (Weeks 1–5): EDR blind spots, AiTM bypass, deepfake helpdesk attacks, hardware supply chain risk, hybrid Kerberos blindspots.
Week 6 — Risk assessment integration: Annual assessments vs continuous monitoring. Catching entitlement drift before exploitation.
Week 7 — Session token vulnerability: Authentication is a moment. The session that follows lasts hours. 50% of incidents start at the weekend when your SOC is at minimum staffing. Your SOC has 207 days on average to find the attacker.
Week 8 (next): NIS2 puts personal liability on your board. Most directors don't know what that means for them yet.
|
Coming up next week
Week 8 — Boardroom accountability shift
Cyber liability no longer stops at the CISO's desk. NIS2 Article 20 places personal liability on management bodies — not the security team. Most boards haven't read it. Most CISOs haven't told them what it means for them personally.
Week 9 — Real-time signal orchestration
Your identity provider, EDR, SIEM, and network monitoring tools each generate risk signals independently. None of them talk to each other in real time. The attacker moves between the gaps.
|
Free passwordless audit
How long is your average session token valid — and what happens if it's stolen on a Friday afternoon?
In a free 30-minute passwordless audit we'll review your current session management configuration, identify your token lifetime exposure, and show you what CAE and device-bound session tokens look like operationally in your environment.
No sales deck. No follow-up unless you ask.
|
Authentication is an event. The session that follows it is a window. Your SOC's job is to close that window faster than 207 days — and the architecture's job is to make the window so short and so device-bound that a Friday afternoon theft yields nothing by Monday morning.
Mikael Rodin
Managing Director, Ciptor
P.S. If your session tokens live for 8+ hours and your SOC isn't running CAE — book a free 30-minute audit. That combination is the most common configuration we see before an incident, and the most preventable.
New to the series? Start at ciptor.com/zero-assumptions/zero-assumptions-vol-1/