Alerts

Live query against alerts-* — Sigma, Suricata, and correlated detections. Last 24h by default; pick dates below to search further back.

Firewall Blocks

OPNsense pf filterlog, OpenWRT fw4/nftables, Linux iptables/nftables, and Windows Filtering Platform — normalized onto one action:"block" field, last 24h.

Geo IP

Where the IPs seen across your traffic (last 24h) are located — both ends of each flow, since behind NAT the geo-locatable party is usually the destination — nothing here is ever sent to a third party. The database ships in place already; re-run scripts\install-geoip-db.ps1 (Windows) or install-geoip-db.sh (Linux) any time to refresh it to a newer release.

Logs

Raw log search over every ingested event, as plain text, straight from the same OpenSearch store the rest of the Console reads — nothing extra to install. The box above matches plain text; for regular expressions, Lucene field queries like EventID:4625, excluding noise, or combining several conditions, click ⚙ Advanced.

Agent Health

Live roster from agent-heartbeat — one document per agent.id, updated on every check-in. In "Processes & Services," a row shown in red has a matching alert for that agent in the last 24h.

Agent Keys

Provisions a new agent identity the same way bin\genkey.exe -agent-id <id> -restart does — wires it into ingest-api's config.json and restarts the service so it's live. The key is shown once, right after you generate it, and never again.

New agents can verify this server's identity with its TLS certificate as ca_cert_path — optional but recommended: without it, an agent has to set insecure_skip_verify instead, which makes it trust any certificate a server presents, not just this one.

Custom Rules

Detections beyond the bundled SigmaHQ set — each one runs through the exact same engine every compiled Sigma rule does (server/detect's own poll loop), on the same schedule, producing alerts tagged custom so they're easy to tell apart on the Alerts page. A rule's query is a raw OpenSearch query_string (Lucene syntax) against events-*, e.g. CommandLine:*mimikatz* or EventID:4720 AND Channel:"Security".

CVE Watch

Cross-references every agent's own reported installed software against a CVE feed (optional, off by default -- see docs/SETUP.md §4b). A match raises a real alert tagged cve-watch on the Alerts page. Runs on its own schedule (12h by default) -- use Scan Now below to check right away instead of waiting.

The CVE list keeps itself current: newly published CVEs are pulled from the CVE Program's own delta feed every few hours and merged into the index — only what actually changed, never a re-download. No feed checkout or manual refresh needed. The tile below shows how current it is.

Data Retention

How long events-* (raw telemetry) and alerts-* (Sigma/Suricata detections) are kept before OpenSearch automatically deletes them — the same two ISM policies apply-retention-policy.ps1/.sh manage, so a change made here or from a script are both reading and writing the exact same settings.

Server Health

CPU, memory, disk, and network for this box, via Prometheus + windows_exporter/node_exporter — optional. Same metrics, and the same queries, as the provisioned "SIEM: Server Health" dashboard.

Hunting Rules

SigmaHQ maintains a separate rules-threat-hunting tree it publishes for periodic review rather than real-time alerting — deliberately broader and noisier than the rules that page your phone. EasySIEM compiles and runs it like any other ruleset, but tags every result rule.source: sigma-hunting so it never mixes into the Alerts feed. This is where to read it. Grouped by rule and host rather than listed as individual alerts: the question here is which broad patterns each machine shows, not what happened at 14:03. A rule firing on two hosts is two rows, because that is two investigations — the same scheduled task created on a domain controller and on a laptop are not the same finding.

Rarity

Least frequency analysis, or stack counting: group every value of one field and read the bottom of the distribution instead of the top. Almost every intrusion is rare before anyone knows to describe it, which is exactly what a signature cannot help with — so “ran once, on one host” is a better first question than any rule. Expect ordinary noise in the results: installer temp files and one-off updaters are genuinely rare too. The list is a place to start reading, not a list of findings.

Counts are indicative rather than exact. Ascending-order aggregation is approximate when a query spans shards, and any multi-day window spans several daily indices.

Process Pairs

Rarity asked of a relationship rather than a value. Single-field stacking misses the most useful shape in process telemetry: cmd.exe is never rare and neither is winword.exe, but winword.exe spawning cmd.exe is most of a macro-dropper detection. The pair carries a signal neither member does.

Parents recorded as - are excluded. Sysmon writes that for processes whose parent it did not capture — overwhelmingly services started by the service control manager at boot — and left in, they fill the whole first page with one-off pairs sharing a parent that isn’t one.

Linux Rarity

Least-frequency analysis over auditd. Order a term aggregation ascending and the tail of the distribution comes back first — the values that occurred once, on one host, which is what almost every intrusion looks like before anyone knows what to search for.

Separate from the Windows page because the two cannot share a dimension list. Every Windows dimension is gated on a Sysmon event ID; auditd sets none, and offers fields Sysmon has no equivalent for — full argv, the working directory a process ran from, the systemd unit that produced a log line.

Counts are indicative rather than exact. Ascending _count order on a terms aggregation is approximate when a query spans shards, and any multi-day window spans several daily indices.

Linux Process Pairs

The same pair-rarity question asked of auditd rather than Sysmon. It needs its own view because the two sources do not share a selector: Sysmon process creation is event ID 1, while auditd sets no event ID at all and is identified by EventType: process_creation. The Windows page therefore cannot see a Linux host, however much process telemetry it is sending.

What auditd adds is full argv. A bare pair like bash → chmod says nothing; chmod 600 /etc/easysiem/agent.json says all of it — so the command line is a column here rather than a drill-down. The filter offered is the user rather than a host count, because on a Linux fleet the uid a process ran under is what separates routine package machinery from someone at a shell.

Registry Persistence

Sysmon records every registry key and value written (events 12, 13 and 14), and nothing in this Console read them until now — which is awkward, because the registry is where persistence lives.

Plain rarity does not work here. The rarest registry keys on a healthy Windows machine are file associations and shell context-menu handlers — thousands of one-off entries that bury anything real. So this page is scoped to a catalogue of auto-start extensibility points, and “all” means the union of those rather than every write.

The path alone is not enough either. Most traffic under Image File Execution Options is MitigationOptions and AuditLevel — Office and Defender hardening config, written in bulk by installers — while Debugger, the value that actually hijacks a binary, should be rare or absent. Same story under \Services\, where ImagePath changes constantly and ServiceDll almost never does. So the value name is its own column, and a deliberately narrow set of names that are seldom written legitimately carries a check badge. Counts beside each location in the picker are measured on your own fleet, over the window selected.

Software

The same rarity question asked of what is installed rather than what ran. Every agent already reports its full software inventory on its own hourly schedule, so this needs no extra collection — and software present on exactly one machine in a managed estate is worth a look, whether it arrived with an attacker or just with someone who installed their own tools.

Unlike the other hunts this has no time window: a heartbeat carries current state, not history. It answers “what is on the fleet now”, not “what appeared this week”.

Beaconing

A Sigma rule asks whether traffic looks suspicious. This asks whether it arrives too regularly to be a person. Destinations are ranked by jitter — the coefficient of variation of the gaps between connections. Someone browsing produces wildly uneven gaps and a jitter near or above 1; something calling home on a timer produces a jitter near 0 whatever its interval happens to be, which is why the interval is shown but never used as a threshold. A 12-hour beacon is as much a beacon as a 60-second one.

Expect legitimate software at the top. Update checkers and long-poll clients are, correctly, the most regular things on a healthy network — measured on the machine this was built on, the lowest-jitter destination was an editor’s own API connection. The ranking is a reading order, not a verdict.

ATT&CK Reference

Techniques seen in alerts over the last 24h, each linking to EasySIEM's own generated reference page.

AI Security Review

Sends a digest of whatever window you pick below (KPIs, recent alerts, flagged firewall blocks, agent roster, server health) to Claude for an on-demand read on real threats and misconfigurations. Nothing runs automatically — this only happens when you click Run Analysis, and each click is one real API call to Anthropic using your own key.