| 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.
