AN1406: Analytic 1406
Detects use of session cookies or authentication tokens from unusual user agents or locations. Identifies token reuse without reauthentication or attempts to bypass MFA using previously stolen cookies.
Analyst context for executives and security teams
This analytic matters because stolen SaaS session cookies or authentication tokens can let an attacker act as a user without going through a normal login or MFA challenge. For executives and security leaders, the decision value is whether identity monitoring can see suspicious session reuse after authentication, not only failed logins or new sign-ins.
Executive priority
Prioritize this as an identity and SaaS monitoring control gap question: can the organization prove when a valid session token is reused from an unusual location or user agent, especially without reauthentication? This supports incident response decisions around account containment, MFA effectiveness, audit evidence for access monitoring, and resilience of business-critical SaaS workflows.
Technical view
For SOC, detection engineering, and IR teams, validate whether SaaS identity and application logs expose session cookie or token use, user agent, source location, reauthentication events, and MFA context. The analytic is scoped to SaaS and focuses on anomalous token reuse, including cases where a session appears valid but the user agent or location differs from expected behavior. Because no ATT&CK tactic or formal detection logic is supplied, local baselining and SaaS log semantics are required.
Likely telemetry
- SaaS authentication and session logs
- Identity provider sign-in logs
- User agent strings associated with authenticated sessions
- Source IP address and derived location for session activity
- MFA challenge and reauthentication events
Detection direction
- Validate that monitoring covers post-authentication session activity, not only initial login events.
- Correlate token or session use with changes in user agent, source IP, and location where the SaaS platform provides those fields.
- Tune for expected travel, VPN, proxy, mobile network, and browser update behavior to reduce false positives.
- Alert with higher priority when unusual session reuse occurs without a corresponding reauthentication or MFA event.
- Confirm whether each critical SaaS application exposes enough session-level data; lack of token/session visibility is a likely blind spot.
Mitigation priorities
- Inventory critical SaaS applications and confirm available authentication, session, MFA, and reauthentication logging.
- Require strong session management and reauthentication policies where supported by the SaaS or identity provider.
- Ensure incident responders have playbooks to revoke sessions or tokens and force reauthentication for suspected accounts.
- Use identity and access management controls to reduce persistent session risk, aligned to business tolerance for user friction.
- Preserve relevant SaaS and identity logs for investigation and compliance evidence.
Analyst notes and limits
The supplied object is a detection analytic, not a technique. Its value is strongest for cloud and identity monitoring programs that need to detect valid-token misuse after authentication. Glexia would treat this as a coverage validation item for managed detection, incident response readiness, and SaaS identity control assurance.
MITRE supplied no formal detection logic, no tactics, and no relationship context. The object only specifies the SaaS platform scope and a high-level behavior description. Actual detectability depends on each SaaS provider’s logs, identity provider integration, retention, and local baselines for normal user agents and locations.
Analytic 1406
Detects use of session cookies or authentication tokens from unusual user agents or locations. Identifies token reuse without reauthentication or attempts to bypass MFA using previously stolen cookies.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 38503f1b153a… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1406Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.