Login Activity Triage

The tool has two parts:

• LoginActivityTriageCli.exe — the engine. It reads EVTX (a single file, a folder tree such as a KAPE or Velociraptor collection, or this machine's live logs), normalises authentication and remote-access events, stitches them into remote sessions, runs the detection rules and writes CSV, JSON and HTML results. It never modifies the evidence.
• LoginActivityTriage.hta — the front end. It runs the engine and explores its results: overview, findings, sessions, timeline, pivots, IOC highlighting and export.

The engine can also be used on its own from a command prompt or a script (see Engine command line).

Install & requirements

• Windows 10 / 11 or Windows Server 2016+ (the HTA runs in mshta.exe, which ships with Windows).
• The .NET 8 runtime (or newer) for the engine. The HTA shows engine: will not start when it is missing.
• Keep LoginActivityTriage.hta and LoginActivityTriageCli.exe together in one folder (the exe may also live in a bin subfolder). LoginActivityTriage.ico from the release is optional: Help → Create desktop shortcut uses it. Copy the folder to a local disk: from a network share, Windows zone policy restricts the HTA's file access.
• Reading this machine's live Security log requires administrator rights; the HTA offers Relaunch elevated. Offline EVTX needs no elevation.

Get both files (or the bundle zip, which includes this manual) from the latest release, or build the engine from source:

dotnet test LoginActivityTriage.sln
dotnet publish src\LoginActivityTriage.Cli -c Release -o hta\bin

Quick start

1. Double-click LoginActivityTriage.hta. The header shows the app and engine versions; engine vX in green means it is ready.
2. Choose what to read: directory (recursive) for a collection folder (several hosts at once is fine), file for one .evtx, or This machine for the live logs.
3. Set the target hostname (or a case label such as CASE-ALL-HOSTS for a multi-host collection). It names the output folder _Processed\<host>\LoginActivityTriage next to the app.
4. Leave after-hours zone on auto (each host's own UTC offset, read from its System event 6013) and optionally set an engine window of dates.
5. Click Process → analyze. A console window shows the engine's progress; results load automatically when it finishes.
6. Start with the Overview and the Findings tab, then pivot into sessions and the timeline.

To reopen earlier results, click Load results… and pick any file in a results folder (one containing summary.json).

The main window

Control panel

Overview

• Statistic tiles: events, local hosts (logs collected), remote hosts (destinations they connected to), accounts, source IPs, findings by severity, and remote-exec / RDP / outbound session counts. Click a severity or session tile to jump to those rows.
• Findings by rule and Remote sessions by technique: click a bar to filter the matching tab.
• Most suspicious accounts / sources: a heuristic 0-100 score from failures, host fan-out, remote execution, remote-access tools, privilege, explicit credentials (used or used by others) and public source addresses. Click one to open its timeline. The score orders the investigation; it is not a verdict.
• The line under the tiles records the input, the event time range, the after-hours zones in use and the engine version: copy it into case notes as provenance.

Filters, sorting & export

• Search all columns: substring match across every column of the current tab (including Known hosts names).
• Host: on Remote sessions the list has two groups, Local hosts and Remote targets (address, resolved name and session count); a host matches either end of a connection. A host that does not exist on the tab you switch to is cleared.
• Technique (sessions, timeline), remote-exec only and failures only (timeline), and the from / to date window. The overview tiles and charts count every row whatever the dates; when the dates hide rows that match the other filters, the row count says how many (+N outside the dates) with a show all dates link.
• Sort: every column header has a ↕ button; click it (or the header) to sort, again to reverse.
• Click a row for every field in the detail card, with pivots: open the session, the session's events, a logon story (±30 minutes or ±2 hours of events sharing the user, IP or host), or the timeline for that user, IP or host. The card closes when you change tabs.
• Export view → CSV writes the full filtered set (not just the 5,000 rows drawn) to the results folder. Copy for case notes puts readable lines on the clipboard.

The tabs

Findings

Rule hits ranked by severity, each with a MITRE ATT&CK id, a count, the related event ids and a Reasoning field explaining why it fired and what to check. The severity buttons (All / Critical / High / Medium / Low) filter the list. See the Detection reference.

Remote sessions

Each row is one stitched session: an RDP session (from authentication through reconnects to logoff), a PsExec run, a PowerShell Remoting or WinRS shell, WMI / DCOM execution, a remotely created scheduled task or service, an executable written to an admin share, or an outbound connection this host made. Columns include the user, source address and workstation, logon id and type, credentials used, the commands observed, and a Confidence (see How sessions are stitched).

• InferredUser is an inference, never evidence: for an outbound session whose logs name no account, the only account that logged on interactively to that host. The Evidence field states the basis.
• Purple rows are inbound remote execution; green "→" pills mark outbound connections.

Timeline

Every normalised event in time order. By default it loads timeline.csv, a triage subset that leaves out routine successful network / domain-controller authentication and WinRM client errors outside a session; tick full events.csv to load everything (large sets open better in Timeline Explorer).

• Square activity labels mark the session and power story: Logon · console / network / RDP / cached / unlock, Logon failed, Logoff, Disconnect, Reconnect, Boot, Shutdown, Restart and Unexpected shutdown. Rounded pills are remote-access techniques.
• Row colours: red = failure, purple = remote execution, a yellow left edge = privileged, a red left edge = IOC hit.
• Hover a column heading for what the column holds, and a dotted-underlined LogonType or AuthPackage value for its meaning (the Remote sessions table shows the two columns too). SourceIp is the remote client: for an RDP logon, the machine the connection came from; the Workstation of a type 10 logon is the server's own name.
• Restarts and shutdowns (User32 1074) name the account and process that requested them.
• Click an EventId (or Open in Event Viewer on the detail card) to open the source .evtx in Windows Event Viewer already filtered to that one record, to read the raw event as Windows renders it. The app runs eventvwr /l:"<file>" /f:"*[System[(EventRecordID=<n>)]]"; results from This machine open the live channel with /c: instead. The evidence must still be at the path it was processed from. Event Viewer cannot open a file whose path is over 259 characters (deep Velociraptor / KAPE trees), so such a log is opened from a copy in %TEMP%\LoginActivityTriage-evx, which the app removes at its next start (only its own copies: a junction or link found in that folder is never followed, and a copy the Event Log service still holds open waits for the next start). The plain and the \\?\ form of a long source path both work. Event Viewer reads the file without changing it; Clear Filter in its Actions pane shows the whole log.

Users & Source IPs

Per-account and per-source-address roll-ups: first / last seen, hosts, successes, failures, inbound RDP, remote execution, remote-access tools, privileged logons, group changes and the suspicion score.

• Accounts are domain-aware: when one name is used by accounts of different domains (the local Administrator of several hosts, two forests), the Users tab shows separate DOMAIN\user rows. Events that recorded no domain stay on a bare-name row rather than being guessed into one of them.
• UsedOthersCreds counts 4648 hand-offs in which the account used someone else's credentials; CredsUsedByOthers counts the reverse.
• SystemAccount rows (computer, SYSTEM, service accounts) are listed but scored 0.
• The detail card shows the account's Sid as logged (also searchable and in Export view → CSV; not a table column). Group-membership events (4728 / 4732 / 4756) log a local member by SID only: the account's name comes from a Security event that pairs that SID with it (its 4720 creation, a 4624 logon), and the finding keeps the SID beside the name. A member that no event names stays listed by its SID. Two accounts are the same account only when their SIDs match: a second local backup on another host is not the one created there. A PowerShell remoting record from a RunAs / JEA endpoint names the connected user but is logged under the endpoint's own account, so it never lends that account's SID a name.

Local hosts & Remote hosts

Local hosts are the systems whose logs were collected: logons, failures, inbound and outbound RDP, remote execution, remote-access tools, service installs, privileged logons, log clears and the time zone read from event 6013.

Remote hosts are the systems the collected hosts connected to (outbound sessions and explicit-credential targets): connections by technique, which local hosts connected, the accounts and credentials used, and Collected when that system's own logs are in the evidence too.

Import log

What the engine read: per-file SHA-256 and size (the chain-of-custody record of exactly which bytes were analysed — quote them in the case notes), records read, events kept, duplicates, filtered and unreadable records, and errors. A file that is not a readable event log (corrupt, truncated, not EVTX) is listed as failed with the reason; the overview line warns when any source failed. Hover a column heading for its meaning. The temporary copy that Open in Event Viewer makes of a long-path log is checked against the recorded hash and refused if it differs.

IOCs & Known hosts

IOCs

IOCs (n)… opens a list of host names, IPs, user names, service or file names, one per line. Matching is case-insensitive across every column; matching rows get a red left edge and IOC hits only filters to them. A toolkit-wide IOC.txt next to the app is merged in at launch.

Known hosts

Known hosts (n)… maps IP addresses to host names. Type rows, Paste list… (CSV, tab-separated or hosts-file lines) or Load file…; Learned from these logs offers names the evidence resolved (a 4648 target server for an address, or the workstation name a client reported at logon — client-supplied, so treat with care). Each address appears once with how often and when it was seen; one seen with different names is shown as a conflict to label by hand, a name equal to the logging host itself is never offered, and add all leaves out conflicts and changes to your own labels. The scanned host's own address is added automatically after every Process (and when results without a knownhosts.csv are loaded) when its logs show it authenticating to itself. Case list: results in the standard _Processed\<host>\LoginActivityTriage layout also share _Processed\knownhosts.csv, so a label added on one host applies to every host processed into that folder (removing a row removes it for all of them; each save re-reads the list and applies only that window’s changes). Untick Share with every host in this case for results that must keep their own list — e.g. when one _Processed folder holds more than one customer — which leaves a knownhosts.private marker. When four or more addresses reported several names, the dialog folds those rows into one show line.

• Names appear as labels next to the IPs in every table, the detail card, the host filter, the overview and case notes, and they are searchable.
• Display only: the engine CSVs and Export view → CSV keep the logged values.
• Saved with the results as knownhosts.csv, per case — the same private address is a different machine at another site.

Detection reference

Thresholds use a 30-minute window unless stated. Severities can drop one level when the evidence for a session is weak.

How sessions are stitched

• Events are joined per host by logon session first (the 4624 logon id and its linked id), then by time. Two users' simultaneous sessions never merge; events without a logon id join only the single session that overlaps them in time with the same user.
• Logon ids are unique only within one boot, so every logon-id correlation stops at the next boot (System 6005, Security 4608). A logged-off RDP session accepts no later processes.
• RDP reconnects stay in their session: a reconnect authenticates with a short-lived logon that is logged off minutes later, while the session runs on under its original logon until the real logoff (4647 / LSM 23).
• Outbound credential hand-offs (4648) attach to a connection only when the technique and destination fit. RDP clients log the address while CredSSP's 4648 names the server: that name-for-address pairing is Medium confidence on one connection, High when the same pairing recurs on two or more connections, and withdrawn if the address or name is ever paired with something else.
• Confidence: High = a direct artifact plus a linked logon (or a destination-matched hand-off); Medium = a direct artifact without the logon, or an inferred pairing; Low = inferred only.

Event sources

Process creation (4688 / Sysmon 1) is kept only when it matches a remote-execution pattern or ran inside a remote logon session.

Engine command line

LoginActivityTriageCli -d <folder>     -o <outDir> [options]   recurse a folder of .evtx (KAPE / Velociraptor trees)
LoginActivityTriageCli -f <file.evtx>  -o <outDir> [options]   one EVTX file
LoginActivityTriageCli --live          -o <outDir> [options]   this machine's live logs (run elevated)

  --tz <id>        after-hours zone: auto (default, per host from event 6013), a Windows or IANA id,
                   a fixed offset such as UTC+10:00, local or utc
  --hours 7-19     business hours (22-6 = a shift across midnight)    --no-weekend   weekends are not after hours
  --keep-noise     keep machine / system-account logon noise
  --from <utc>     --to <utc>           ISO-8601 import window
  --no-hash        do not record the SHA-256 and size of each source log in files.csv
  --no-html        skip the HTML reports  -q              no per-file progress   -v   version

Results are written to a staging folder and published only when the run succeeds, summary.json last. After any failure the output folder still holds the previous run's files; run.log always describes the latest attempt.

The HTA also accepts a command line: mshta LoginActivityTriage.hta "<evtxDir | file.evtx | live | resultsDir>" ["<outDir>"] [/auto] [/tz:<id>] [/from:yyyy-MM-dd] [/to:yyyy-MM-dd] [/offline]. A results folder opens in the viewer; an EVTX source is prefilled and, with /auto, processed. /from /to set the date window. /offline (or the environment variable LAT_OFFLINE=1) keeps the app off the network: no GitHub update check and no downloads — for an analysis machine without internet access. Otherwise Update and Update engine verify each download against the release's SHA256SUMS.txt and discard a mismatch.

Output files

CSV files are UTF-8 with BOM (Excel and Timeline Explorer detect them), RFC-4180 quoted, timestamps ISO-8601 UTC with a trailing Z. Values a spreadsheet would execute as a formula are prefixed with an apostrophe; the HTA hides it.

Forensic notes & limits

• All times are UTC. Only the after-hours rule uses local time, per host.
• Absence of evidence is not evidence of absence. Detection depends on what was audited and collected: without the Security log there are no logons, 4697 or share access; without process auditing (4688 with command lines) or Sysmon there are no command lines.
• A 5145 records an access check, not a completed file copy. Confirm a dropped tool on the target (MFT, USN journal, Amcache).
• InferredUser, name-for-address pairings and Known hosts names are analyst aids, clearly marked; quote the underlying events in reports.
• Workstation names in failed logons are supplied by the client and can be forged.
• Suspicion scores rank where to look first; they are heuristics, not conclusions.
• The engine opens evidence read-only and writes only to the output folder.

Troubleshooting