Skip to content

User Guide: Overview

The Logster console is the primary interface for SOC analysts. It surfaces aggregate views, per-endpoint drill-downs, inference detail, process trees, and MITRE ATT&CK TTP distributions — all scoped by a time range and optional hostname filter.

This guide teaches you how to use it effectively, from first login to recording analyst verdicts on real detections.

What this guide covers

Page You'll learn how to...
Overview (this page) Understand what the console is, how to log in, and how to orient yourself.
Using Console Navigate every view — Summary, Hosts, Timeline, Recent Attacks, Inference Detail, Process Tree, Endpoint Insights, Distribution, Analytics.

What the console is (and isn't)

The console is a read-only analytics view over the data populated by the Logster pipeline:

  • Normalized endpoint events — every Sysmon, auditd, or eBPF record the pipeline has seen.
  • Inference results — one record per inference run, with attack_prob, prediction, and the list of events that contributed to the prediction.

The analyst views are all aggregations over this data. When you change the time range or filter by hostname, every tile re-queries and redraws.

[!NOTE] The console is not where alert state transitions happen. Moving an alert from open to resolved, adding analyst notes, and submitting true/false-positive feedback all go through the Logster REST API. A production deployment typically wires the console's "mark as reviewed" buttons to those endpoints.

First login

  1. Make sure the Logster stack is running.
  2. Open http://localhost:5001 in a browser.
  3. The console presents a login screen. Sign in with the default credentials:
Field Default value
Username admin
Password admin
  1. On first login you are required to change the password before you can reach the console. Choose a new password (minimum 8 characters, and it must differ from admin). The new password is stored securely and survives container restarts.

[!IMPORTANT] Change the default password immediately. The admin / admin default exists only so the first login succeeds — it is not a production credential.

[!NOTE] A docker compose down -v wipes the stored user (it lives in the es_data volume), so the next start re-seeds admin / admin and the forced password change applies again.

Orienting yourself

The top bar of the console has two controls you will use on every session:

  • Time range picker. Every query the console issues is scoped to this range. Defaults to now-30m → now. Widen it if you are investigating a historical event, narrow it if you are watching a live incident.
  • Hostname filter. Scopes every tile to a single endpoint. Useful when you have already decided which host to drill into and want every panel to reflect that one host.

Console top bar — time range picker, endpoint filter, refresh cadence, and live-update indicator

Top bar: the Time Range picker and Endpoint filter scope every tile on the page. Refresh controls auto-reload results at the selected cadence; LIVE / Updated timestamp confirms the data is current.

Below the top bar, the console is organized into progressively more specific views:

  1. Summary — fleet-wide KPIs at a glance.
  2. Hosts — per-endpoint cards sorted by threat level.
  3. Attack Timeline — when attacks happened, bucketed over time.
  4. Recent Attacks — the raw list of attack-predicted inferences.
  5. Inference Detail — what a single inference run actually classified.
  6. Process Tree — how the processes in a detection relate.
  7. Endpoint Insights — behavioral baseline for one host.
  8. Distribution and Analytics — noise / trend / heatmap / TTP distribution.

See Using Console for the view-by-view walkthrough.

The triage workflow in one paragraph

A typical SOC analyst session goes like this: glance at Summary to see if anything is lit up in the last 30 minutes; if it is, jump to Hosts and pick the worst card by max_attack_probability; open Recent Attacks filtered to that host and click into the most recent attack inference; read the Inference Detail view to see which events the detection model flagged; open the Process Tree for the same inference to walk parent/child relationships; cross-check Endpoint Insights to see whether the user, binary, and network destination are normal for that host; confirm the MITRE TTPs on the Analytics page; record your verdict via POST /feedback.

MITRE ATT&CK TTPs in the UI

Alerts and inference documents carry a ttp_techniques field populated by the optional TTP analyzer service. Values are MITRE ATT&CK identifiers in the form Tnnnn or Tnnnn.nnn (for sub-techniques).

[!TIP] The canonical MITRE ATT&CK reference is https://attack.mitre.org. Look up each technique ID there for the full description, suggested detections, and known mitigations. When an alert shows multiple TTPs, treat them as simultaneous observations — the detection model matched all of them in that window, which is usually stronger evidence than a single technique.