The theft and reuse of an active authentication token so an attacker can enter an application without repeating the normal login process. It matters because a valid session can outlive the original password and bypass controls that only protect the sign-in step.
Expanded Definition
Session token hijacking is the abuse of a live session artifact, such as a bearer token, cookie, or opaque session identifier, after authentication has already succeeded. Unlike password theft, the attacker does not need to re-enter credentials if the session remains valid and the application does not bind that token tightly enough to context, device, or transaction risk. In NHI environments, the same pattern affects service-to-service tokens, API access tokens, and agent credentials, which is why guidance often overlaps with the controls discussed in the NIST Cybersecurity Framework 2.0 and NHI-specific hardening practices. Definitions vary across vendors on whether a stolen refresh token, replayed cookie, or intercepted bearer token all count as the same class of hijack, but the operational concern is consistent: the attacker inherits the session trust already granted by the platform. The most common misapplication is treating token theft as a login problem, which occurs when teams protect authentication events but leave active sessions unmonitored, unbound, and unrevoked.
Examples and Use Cases
Implementing token protection rigorously often introduces friction for users and automation, requiring organisations to weigh session continuity against stronger revocation, device binding, and short token lifetimes.
- A user copies a browser session cookie from a compromised laptop, then reuses it from another device to enter an internal dashboard without triggering MFA.
- An OAuth access token is harvested from a browser extension or log file and replayed against an API, similar to cases described in the Salesloft OAuth token breach.
- A CI/CD runner leaks a cloud session token into build output, echoing the kind of exposure highlighted in the Guide to the Secret Sprawl Challenge and then allowing lateral movement into deployment systems.
- An AI agent retains a long-lived bearer token after task completion, so a stolen transcript or memory dump becomes enough to impersonate the agent across tools.
- A contractor’s session remains valid after offboarding, and the attacker later reuses it to access records until the token expires or is revoked.
These patterns map closely to token-based identity risks discussed in the NIST Cybersecurity Framework 2.0, where asset visibility and access control both matter.
Why It Matters in NHI Security
For NHIs, session token hijacking is especially dangerous because machine identities often operate at high privilege, at scale, and with limited human observation. A stolen token can bypass password resets, lockout policies, and sometimes even MFA, turning one exposure into broad reuse across APIs, cloud consoles, and orchestration platforms. NHIMG research shows that 91% of former employee tokens remain active after offboarding, and 44% of NHI tokens are exposed in the wild, being sent or stored in tools like Teams, Jira, Confluence, and code commits. That combination creates a long tail of exploitable sessions even after the original incident is noticed. The issue is not just theft, but trust persistence: once a session is live, many controls stop checking the original identity proof and continue honoring the token until expiry or revocation. Strong governance therefore requires short-lived tokens, explicit revocation paths, log correlation, and continuous detection of anomalous replay. For broader context on how exposed credentials spread across AI and CI/CD systems, see the 2025 State of NHIs and Secrets in Cybersecurity and the State of Secrets Sprawl 2026. Organisations typically encounter the true impact only after a breach investigation reveals a valid session was reused, at which point token hijacking becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Session tokens are secrets whose exposure and reuse create direct NHI compromise risk. |
| NIST CSF 2.0 | PR.AC-1 | Identity and credential lifecycle controls apply to live session trust and access enforcement. |
| NIST Zero Trust (SP 800-207) | Zero Trust rejects implicit trust in a bearer token after initial authentication. |
Continuously verify session context and re-authorize sensitive actions instead of trusting login alone.
