non-badged-logon

name	non-badged-logon
description	Investigate whether an account performed an interactive (console) logon without a corresponding building badge-in, which can indicate account/credential sharing, a remote actor using stolen local credentials, or badge-system evasion. Use when given authentication and physical access (badge) logs and asked to correlate a logon with physical presence.

Non-Badged User Logon (Account Sharing)

MITRE ATT&CK: T1078 (Valid Accounts) — this is a physical/cyber correlation heuristic rather than a technique; it's one of the few analytics in this repo that fuses a non-IT data source (badge access) with authentication logs.

1. Which question am I trying to answer?

Did account X log onto a system with Logon Type 2 (interactive/ console) despite not having badged into the building that day — suggesting the physical person at the keyboard is not the account owner (shared/ borrowed credentials), or that the "interactive" logon didn't actually originate from someone physically at that console?

2. Which direct evidence do I need?

Per interactive logon: Time, Source, Destination, User, Success/Failure, Logon Type (must be 2, and specifically not 10, which is remote — RDP sessions are expected to have no badge correlation and are out of scope for this analytic). Per user, per day: Time of most recent prior Badge Access and the building/site it occurred at.

3. Where do I get that data?

• Windows Security.evtx: Event ID 4624 filtered to Logon Type = 2 on the destination host — this is the console/interactive logon you're correlating against physical presence. Exclude Logon Type 7 (unlock), which reuses an already-established interactive session and doesn't represent a new arrival.
• Physical access control system (badge reader) logs — export per-user badge events with timestamp and door/building identifier. This typically lives in a separate system (Lenel, HID, Genetec, etc.) from IT logs and needs to be requested from facilities/physical security, often on a different retention schedule than IT logs — confirm retention overlap before assuming you can investigate historical incidents this way.
• Site/building-to-host mapping: you need to know which building a given destination host physically sits in, to correctly match "did this user badge into that building" rather than any building. Asset inventory/CMDB is the usual source for this mapping.

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

Provide two inputs: the auth events CSV (shared schema) and a badge log CSV with columns user, badge_time, building. Run:

python3 scripts/analyze.py --input auth_events.csv \
    --badge-log badge_events.csv --badge-window-hours 12

Logic: filter auth events to successful Logon Type 2. For each such event, find the most recent badge event for that user at or before the logon time; if none exists within --badge-window-hours hours before the logon, flag it as non-badged.

Tuning: 12 hours as a lookback window covers a full shift plus a reasonable grace period; shorten it in high-security environments where badge and logon should be tightly coupled (e.g. a SCIF/data-center), or lengthen it for sites with irregular shift patterns.

5. What answer does the analysis provide?

A list of (user, destination, logon time, last known badge, gap or "no badge found") findings. Interpretation — this analytic has more mundane explanations than most others in the repo, so treat a flag as a lead, not a conclusion:

• Remote-capable interactive sessions: some environments allow remote KVM/iLO/IPMI or virtual-console access that legitimately produces Logon Type 2 without physical presence — confirm whether the destination host has such capability before treating this as anomalous.
• Badge system gaps: tailgating (following someone through a badge door without badging), a malfunctioning reader, or a badge exemption (escorted visitor, facilities staff) all produce "no badge" without any credential misuse — check badge-system health/known exceptions for that building/day before escalating.
• Multi-building campuses: an employee legitimately badging into Building A but logging into a console physically in Building B (because the host inventory/CMDB mapping is wrong, or they moved between buildings without re-badging) is a data-quality false positive, not a security one — verify the host-to-building mapping first.
• A genuine hit — no badge anywhere on campus that day, for an interactive logon on a console that has no remote-KVM capability — is a strong indicator of shared credentials or a physically-present unauthorized individual, and should be corroborated with camera/visitor-log evidence where available before action is taken against the named employee.