concurrent-logons

name	concurrent-logons
description	Investigate whether a single account has overlapping active sessions on multiple different hosts at the same time, which is impossible for one person acting alone and suggests credential sharing or compromise. Use when given authentication/session logs and asked to check for concurrent sessions, simultaneous logons, or shared-account use.

Concurrent Logons

MITRE ATT&CK: T1078 (Valid Accounts) — like impossible travel, this is a detection heuristic for compromised/shared credentials rather than a technique in itself.

1. Which question am I trying to answer?

Is account X logged into multiple different machines at the same time — i.e., do two or more of its sessions overlap in duration on different hosts?

2. Which direct evidence do I need?

Per session: Time (start), User, Destination, Success/Failure, Logon Type, plus a way to establish the session's end — either an explicit logoff event or a known/assumed session duration. Overlap can only be assessed with a start and end per session, which is what distinguishes this from the point-in-time analytics elsewhere in this repo.

3. Where do I get that data?

• Windows Security.evtx: pair Event ID 4624 (logon, capture the Logon ID) with 4634/4647 (logoff) sharing the same Logon ID to get an accurate session duration. Without a matched logoff, you only know the session started, not that it was still active later — see the caveat in step 5.
• RDP-specific session state: Microsoft-Windows-TerminalServices- LocalSessionManager Event IDs 21 (session logon), 23 (logoff), 24 (disconnect), 25 (reconnect) — useful when RDP sessions are disconnected rather than cleanly logged off, which 4634 alone won't capture.
• VPN/VDI broker logs, which often track explicit session start/end independent of the OS-level logon/logoff pair.
• Linux: last/utmp/wtmp session records, or loginctl list- sessions state if analyzing live.

4. How do I analyze that data to answer the question?

Extend the shared schema with an optional duration_minutes column when a matched logoff/session-end is known. Then run:

python3 scripts/analyze.py --input auth_events.csv \
    --assume-session-minutes 480

Logic: for each user, build a session interval [start, end] per event — using duration_minutes when present, otherwise falling back to --assume-session-minutes (default 8 hours, a typical workday) as an explicit, clearly-labeled assumption. Any two sessions for the same user on different destinations whose intervals overlap are flagged.

Tuning: if your source data reliably includes matched logoff events, pass real duration_minutes for every row and treat --assume-session- minutes as a fallback only — assumed durations are a materially weaker basis for a finding than measured ones, and the tool's output says so.

5. What answer does the analysis provide?

Pairs of overlapping sessions per user, each annotated with whether its duration was measured (real logoff pair) or assumed (fallback duration). Interpretation:

• Overlap built from two measured durations is strong evidence of concurrent use and should be escalated with high confidence.
• Overlap involving an assumed duration is a weaker signal — it may simply mean the user's actual session was shorter than assumed and didn't really overlap. Before escalating, check for the corresponding logoff event directly rather than trusting the assumption.
• Same user, same destination overlaps are not flagged by this analytic — reconnecting to the same host (e.g., RDP disconnect/reconnect) is normal and is not concurrent use in the sense this analytic targets.
• Service/shared accounts (e.g., svc-*, break-glass admin accounts) are expected to show concurrency and should generally be excluded rather than tuned around.

A confirmed concurrent-logon finding (measured, not assumed) on a named individual user account is a strong, fast indicator of credential sharing or compromise and typically warrants immediate session revocation.