D3-SDA Session Duration Analysis: Spotting Abnormal Logon Sessions and Verifying Coverage

A session that lasts far longer, or far shorter, than its owner's sessions usually do can be the only visible trace of a hijacked account or an unattended foothold. MITRE D3FEND names this countermeasure Session Duration Analysis (D3-SDA) and defines it as "Analyzing the duration of user sessions in order to detect unauthorized activity." It sits under the Detect tactic as a child of User Behavior Analysis (D3-UBA). This card covers what D3-SDA measures, which ATT&CK techniques D3FEND relates it to, the log sources that make session duration measurable, how to verify it and why it is a weak signal on its own. It is written for detection engineers and SOC leads; the UEBA foundations are in the UEBA Guide.

Key takeaways

• Duration is compared with history. D3FEND describes D3-SDA as comparing the duration of a logon session with a behaviour model built from that user's historical session durations.
• Measuring duration is the real work. You need a reliable start and end for each session: Windows 4624 paired with 4634 or 4647 by Logon ID, RADIUS accounting Acct-Session-Time for VPN, or gateway session logs for remote access.
• It relates to account misuse. Through the Authentication and Authorization artefacts, D3FEND relates D3-SDA to the same eight ATT&CK techniques as its UBA siblings, including Valid Accounts (T1078) and External Remote Services (T1133).
• A weak signal, best used as a feature. D3FEND warns of false positives and of attackers whose sessions look normal; session duration works best as one input to a risk score, not as a stand-alone alert.
• Session limits are the preventive pair. Bounded sessions, such as IAM role maximum session duration or conditional access sign-in frequency, cap how long an abused session can run and make outliers easier to see.

D3-SDA at a glance

How it works

D3FEND's description is two sentences: unauthorised sessions are detected by comparing a logon session's duration with a baseline behaviour model of historical session durations, and abnormalities may indicate suspicious activity. Turning that into a working analytic needs three decisions.

• What a session is: an interactive or remote desktop logon on a host, a VPN connection, a privileged access gateway session, a cloud console session or a federated web session. Each has different start and end events, and they should be baselined separately.
• How to pair start and end: on Windows, Microsoft documents that event 4634 "An account was logged off" can be correlated with event 4624 using the Logon ID, and that Logon IDs are only unique between reboots on the same computer, so the pairing key is host plus boot plus Logon ID. Event 4647 marks user-initiated logoff for interactive and remote interactive sessions. For VPN and network access, RADIUS accounting (RFC 2866) carries Acct-Session-Time (attribute 46, seconds of service, sent in Stop records) and Acct-Session-Id (attribute 44), which must match between Start and Stop records.
• What abnormal means: a per-identity distribution of durations by session type, with outliers above a high percentile flagged, plus rules for sessions that never end (no stop record), sessions at times the identity never works and very short sessions repeated many times.

Session duration is related to, but separate from, D3-WSAA Web Session Activity Analysis, which looks at what happens inside web sessions, and D3-UGLPA User Geolocation Logon Pattern Analysis, which looks at where sessions start.

Where identity fits

Non-human identities change the picture. A Windows service logon (Logon Type 5) or a batch logon (Type 4) can legitimately stay open for long periods, so applying human baselines to them only creates noise. The useful signal for workload identities is the opposite: a service account appearing in an interactive (Type 2) or remote interactive (Type 10) session at all. In cloud, short-lived credentials bound duration by design. AWS IAM role maximum session duration can be set from 1 hour to 12 hours, with 1 hour applied if no value is specified, so a role session that appears to outlive that limit points to a logging gap or a different credential, not a long session. See the Token and Session Security Guide for session lifetimes in depth.

ATT&CK techniques D3FEND relates to D3-SDA

Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-SDA. The rows below are inferred because D3-SDA analyzes the Authentication and Authorization artefacts, and these ATT&CK techniques produce or create those artefacts in the D3FEND ontology (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.

None of these techniques is detected by duration alone. The brute force rows are better served by D3-ANET Authentication Event Thresholding; duration adds context after access succeeds. Technique detail is in the T1133 External Remote Services Defensive Guide and the MITRE ATT&CK T1078 Valid Accounts Guide.

Session data sources

Web and cloud sessions are the hardest to measure, because many applications never log a logoff. For those, track time from sign-in to last activity, and lean on preventive limits. In Microsoft Entra ID, for example, Microsoft documents that the default user sign-in frequency is a rolling window of 90 days, and that sign-in frequency can be set in Conditional Access (Entra ID P1 or P2) to force reauthentication. Privileged session recording and review are covered in the Privileged Session Management Guide.

Implementation steps

1. Pick session types worth baselining. Start with remote access (VPN, RDP to servers, privileged gateway sessions), where durations are measurable and abuse is costly.
2. Prove you can pair start and end. Build the pairing query and measure the share of sessions with a matched end. If it is low, fix logging (logoff auditing, RADIUS Interim-Update, gateway export) before building any anomaly logic.
3. Baseline per identity and per session type. Use a learning window that covers normal working cycles; record percentiles, not just the mean, because duration distributions are skewed.
4. Define outliers and orphans. Flag sessions above a high per-identity percentile, sessions with no end after a set time and service accounts in interactive sessions. Thresholds are local choices; tune them in report-only mode first.
5. Feed a risk score, not a queue. Use duration anomalies to raise an identity's risk score and combine them with geolocation, resource access and authentication anomalies before alerting.
6. Add preventive limits. Set maximum session durations on remote access, idle timeouts on RDP and gateways and sign-in frequency on sensitive applications, so outliers are bounded.
7. Roll back safely. If tuning goes wrong, return to report-only mode and keep collecting; do not switch off logoff auditing.

How to verify it works

• Pairing health: report weekly the share of sessions per type with a matched end record; a sudden drop means a log source broke.
• Synthetic long session: with approval, hold a test account's VPN or RDP session well beyond its baseline and confirm the feature fires and raises the risk score.
• Service account test: perform an approved interactive logon with a test service account and confirm the rule fires.
• Emulation and replay: include remote access abuse in authorised adversary emulation and replay closed incidents to see whether duration features would have contributed.

Limits, bypasses and failure patterns

• Attackers with normal-looking sessions: D3FEND notes that attackers may not differ enough in session duration to trigger an alert. An intruder who logs in briefly during work hours is invisible to this analytic.
• Missing logoff events: disconnected RDP sessions, crashed VPN clients and web applications without logout create orphan sessions; without handling them, every analysis shows false long sessions.
• Logon ID reuse: pairing on Logon ID without host and boot context joins unrelated sessions, because Microsoft states Logon IDs are only unique between reboots on the same computer.
• Stolen tokens outlive the session you measure: session cookies and refresh tokens can be replayed from elsewhere while the original session looks normal. Session token theft needs its own controls; see the Session Hijacking and Cookie Theft Guide.
• Human baselines applied to workloads: service and batch logons swamp the results unless baselined separately or handled by type rules.
• Stand-alone alerting: duration alone has low precision; teams that alert on it directly tend to disable it after the first month.

Framework mapping

Practitioner checklist

• Choose remote access session types first.
• Measure the share of sessions with a matched end before building anomaly logic.
• Pair Windows sessions on host, boot and Logon ID, not Logon ID alone.
• Enable RADIUS accounting with Interim-Update for VPN.
• Baseline per identity and per session type, using percentiles.
• Treat service accounts in interactive sessions as a separate high-priority rule.
• Use duration as a risk score feature, combined with other UBA signals.
• Set maximum session and idle limits so outliers are bounded.

Standards and references

• MITRE D3FEND: Session Duration Analysis (D3-SDA)
• IETF: RFC 2866 RADIUS Accounting
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (AC-2(12), AC-12)
• Microsoft Learn: Event 4634, an account was logged off
• Microsoft Learn: Conditional Access adaptive session lifetime
• AWS: Update the maximum session duration for a role

Related NHI Mgmt Group resources: UEBA Guide · Token and Session Security Guide · Privileged Session Management Guide · D3-RAPA Resource Access Pattern Analysis · MITRE D3FEND Guide