Skip to content

User Guide: Using Console

This page is the view-by-view reference for the Logster console. Each section explains what the view shows, where the numbers come from, and how to read them during an investigation.

Summary

The top of the console is a row of KPI tiles computed over the inference results in the selected time range. Each tile is a single straightforward aggregation — a count, average, max, or unique-count metric.

Tile What it means
Total inferences How many inference runs completed in the time range.
Total attacks Of those, how many came back with prediction == "attack".
Total benign The benign count. total = attacks + benign + errors.
Avg attack probability Average attack_prob across every inference.
Max attack probability Peak attack_prob. Rising max is the strongest early signal of a live attack.
Avg confidence Model confidence. Low confidence with moderate attack_prob usually means noisy input rather than a real attack.
Avg inference time (ms) Health signal. A sudden jump means inference is under load.
Hosts Unique endpoints that produced at least one inference in the window.

How to read it

  • If total attacks > 0 in a now-30m window, that's what you investigate next. Jump to Hosts or Recent Attacks.
  • If max attack probability is near 1.0 but total attacks is zero, the threshold is too high for that run — rare.
  • If avg inference time is spiking while hosts is stable, the fleet is getting noisier per host — tune inference.window / inference.interval.

Summary KPI row showing total inferences, attacks detected, benign, avg / max attack probability, and inference latency

Summary KPI row — six tiles over the selected time range. "Attacks Detected" and "Max Attack Probability" are the two tiles analysts read first.

Hosts

A card per endpoint. Each card shows:

  • Hostname
  • Total inferences in the time range
  • Attack count — how many inferences came back as attack
  • Average / maximum attack probability
  • Latest activity timestamp

How to read it

Sort mentally by max attack probability first, then by attack count. A host with max_prob = 0.97 and attack_count = 2 is almost always a better first stop than one with max_prob = 0.75 and attack_count = 40.

Cards are color-coded by severity on the UI side. The color mapping follows the same thresholds as the alerts service:

Color / label max_prob
CRITICAL >= 0.95
HIGH >= 0.85
MEDIUM >= 0.70
LOW < 0.70

Clicking a card sets the hostname filter for every other tile in the console.

Endpoint status card for logster-win showing inference and attack counts and severity banner

Endpoint Status — one card per host. Header banner turns to "Alerts" when attacks are detected; the four tiles (Inferences, Attacks, Avg / Max Probability) let you sort mentally by worst-first.

Attack Timeline

A bucketed date histogram over inferences. Each bucket carries four metrics:

  • attack_count — inferences with prediction == "attack"
  • benign_count
  • avg_attack_probability
  • max_attack_probability

How to read it

  • A flat benign line punctuated by a single attack spike = isolated suspicious window. Investigate that one bucket.
  • A rising avg_attack_probability over several consecutive buckets = a multi-step attack that the detection model is finding more incriminating over time. This is the "live incident" pattern.
  • A big max but a low avg = one loud window inside a quiet hour. Likely a short burst — PowerShell, lateral login, a scheduled task firing.

The timeline respects both the time range and the hostname filter, so you can scope it to a single host and see its activity at 1-minute resolution.

Activity Timeline chart showing attack probability spikes over a six-hour window, alongside classification distribution donut

Activity Timeline — avg / max attack probability line plus the red "attack indicator" bars at each spike. The right panel shows attack vs benign split for the same time range.

Recent Attacks

A sorted list of the most recent inferences where prediction == "attack", newest first, inside the current time range. Each row contains the full inference document: inference_id, endpoint_id, attack_prob, confidence, ttp_techniques, and event_ids.

Rows are the entry point for the Inference Detail view — clicking one opens the drill-down.

Inference Log table filtered to attacks, each row with timestamp, endpoint, prediction, probability, TTPs, and an Investigate button

Inference Log with "Attacks Only" checked — this is the "Recent Attacks" view. Each row carries the TTP chips and the Investigate button that opens the Inference Detail modal.

Inference Detail

The single most important investigation view. Given an inference_id, it returns:

  1. The full inference record — prediction, attack probability, confidence, threshold, window start/end, model name, TTP techniques.
  2. Every normalized event that contributed to that window, sorted by timestamp. For each event: event_type, image, command_line, parent_image, parent_command_line, user, hashes, and (for file events) target_filename.

How to read it

This is where you answer the question: "What is the model actually looking at that makes it think this is an attack?"

  • Start with the window time range. That's the 3-minute slice (by default) the detection model used.
  • Scan the event list top-to-bottom and look for one of the classic shapes:
    • powershell.exe with an -enc / base64 argument
    • wmic / schtasks / at.exe spawning under an unusual parent
    • LOLBins spawned by winword.exe, excel.exe, outlook.exe
    • whoami / net user / net group right after a user logon
    • File writes into C:\Users\Public\, %TEMP%\, or system dirs
  • Match what you see against the ttp_techniques field — it's the short-form story of what Logster thinks happened.

[!NOTE] If the event list is empty or very small, the detection model ran on a nearly-empty window. Those are the inferences that usually come back as error rather than useful verdicts — ignore them for triage and investigate ingestion gaps instead.

Inference Investigation modal showing inference ID, prediction, attack probability, confidence, endpoint, events in window, inference latency, TTPs, TTP explanation, and start of raw events

Inference Investigation modal — metadata tiles across the top, the MITRE TTP chips, a natural-language TTP explanation, and the scrollable Raw Events list below.

Process Tree

Takes the same inference_id and reconstructs a flat process timeline from every contributing event: pid, ppid, image, command_line, parent_image, user, and timestamp. The UI renders it as a tree anchored on parent/child relationships.

How to read it

Walk the tree from the root down. Most real attacks show one of two patterns:

  1. LOLBin chain: explorer.exe → cmd.exe → powershell.exe -enc ... or winword.exe → cmd.exe → mshta.exe.
  2. Service abuse: services.exe → svchost.exe → <something unexpected>.

If the parent of a suspicious process is itself suspicious, keep walking up. If the parent is explorer.exe or services.exe, you have probably found the initial execution.

Raw Events list in the Inference Investigation modal, each event card showing Image, CommandLine, Parent Image, Parent CmdLine, User, PID, Parent PID, and hashes

Raw Events inside the modal — each process card carries Image / Parent Image / Parent CmdLine / PID / Parent PID. Walk parent→child by matching Parent PID to PID of an earlier card. The current console renders the parent/child chain inline in this list rather than as a separate tree graph; the aggregate parent→child bars also appear in the Endpoint Insights "Process Relationships" panel below.

Endpoint Insights

A set of panels computed from the events index rather than inferences, so they describe raw host behavior regardless of model opinion. Use them to build a baseline.

Panel Endpoint What it answers
Event volume over time /insights/event-volume How noisy is this host right now?
User activity /insights/user-activity Who is actually doing things on this host?
Privilege levels /insights/privilege-levels What privilege is each action running with?
File activity /insights/file-activity Which files are being touched most?
Network destinations /insights/network-destinations Where is this host talking to?
Process relationships /insights/process-relationships What spawns what on this host?
Command lines /insights/command-lines Top command-line strings seen recently.

All insight panels accept a platform query parameter (windows, linux, or all). The Linux branch uses Painless runtime mappings to fish fields out of raw auditd/eBPF records — you don't have to think about this as an analyst; the same panel works across both platforms.

Endpoint Insights panels: event volume over time, user activity, privilege levels donut, file activity, network destinations, process relationships

Endpoint Insights — Event Volume across the time range, then per-host baselines: who's active (User Activity), at what privilege (Privilege Levels), file / network destinations, and the parent→child process chains.

Distribution — where is the noise coming from?

Three aggregations that answer different questions:

  • predictions — how many attack, benign, and error verdicts in the time range. A high error count means the inference service is feeding the detection model bad or undersized windows.
  • host_attacks — per-host total vs attacks. Lets you see which host is the biggest attack-generator.
  • probability_distribution — a histogram of attack_prob in 0.1 buckets. Shows you the overall skew of the fleet. A healthy fleet is heavily skewed toward the 0.0–0.1 bucket with a small tail above 0.7.

Analysis section showing Attacks by Endpoint bar, Probability Distribution histogram, Top Active Processes list, and TTP Distribution bars

Analysis — Attacks by Endpoint shows the per-host attack / benign split; Probability Distribution is the 0.1-bucket histogram of attack_prob (healthy fleets skew hard to 0.0–0.1 with a small tail above 0.7); Top Active Processes and TTP Distribution round out the noise picture.

Analytics

A cluster of deeper views.

Endpoint What it answers
/analytics/trend How does the current period compare to the previous period? (up / down / stable based on ±5%.)
/analytics/event-types Event type breakdown (process / file / network / script / syscall).
/analytics/top-processes Most-seen process images and their parents.
/analytics/endpoint-platforms Which endpoints reported Windows vs Linux events.
/analytics/heatmap Day-of-week × hour heatmap for attack inferences.
/analytics/threat-metrics Derived threatScore / threatLevel plus severity buckets and probability percentiles.
/analytics/ttp-distribution Top MITRE ATT&CK techniques across attacks.
/analytics/attack-timeline Bucketed attack history with per-bucket avg / max / high-severity counts.

The two most valuable tiles during an active investigation are Trend (is the attack rate rising?) and TTP distribution (which techniques dominate right now?).

[!NOTE] The console's threat score is a simple composite — 0.4 * attack_rate + 0.3 * avg_prob + 0.3 * max_prob, clipped to 0–100 and bucketed into low / medium / high / critical. It is a rule-of-thumb, not a formal model output. Use it as a quick indicator, not as your only signal.

Threat Overview panels: Threat Level gauge, Attack Trend current vs previous, Event Types donut, Detection Insights with model performance, detection rate, and probability percentiles

Threat Overview — composite threat score gauge, period-over-period Attack Trend (current vs previous window), Event Types donut, and Detection Insights with model latency, confidence, and P95 / P99 probability percentiles.

Reading MITRE ATT&CK TTPs

TTP IDs show up on inference records, in the alerts stream, and in the /analytics/ttp-distribution panel. The format is always Tnnnn[.nnn] — an MITRE ATT&CK technique or sub-technique identifier.

When an alert carries multiple TTPs, treat them as simultaneous observations: the detection model matched all of the listed techniques in that window. Multiple TTPs are stronger evidence than a single one.

The canonical MITRE reference is https://attack.mitre.org. Look up each ID there for the full description, the detections MITRE recommends, and known mitigations.

When something on the console looks wrong

  • All tiles empty, no errors. The time range has no data — widen it, or confirm that endpoints are reporting in and inferences are being produced.
  • error prediction count is high. The detection model is seeing under-sized windows.
  • Same attack keeps re-appearing every 30 seconds. The console shows every inference, not the deduplicated alert. For a de-duplicated view, query the REST API /alerts endpoint.
  • A host disappears. Check the time range and hostname filter — the view may have scoped it out.