Alerts

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

A ×N badge means one rule matched N events on that host in a single detection pass — a burst of near-identical hits collapsed into one row so it reads as one incident rather than N. Hover it to see what differed between them. Nothing is discarded: the count is exact and every underlying event remains searchable.

Firewall Blocks

OPNsense pf filterlog, OpenWRT fw4/nftables, Linux iptables/nftables, and Windows Filtering Platform — normalized onto one action:"block" field, over the window you pick.

Geo IP

Where the IPs seen across your traffic in the window you pick below 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.

Alert Notifications

Sends a message to your phone when alerts land, using your own account — the same bring-your-own-credential bargain as the AI providers. Pushover is the quickest to set up, free at this volume, and the only one that can keep alerting until you acknowledge it. SMS through Twilio is optional and billed per message — switch it on only if you want texts as well.

Nothing sends until you switch it on. Each channel has its own on/off switch, so you can run Pushover alone, SMS alone, or both. When to notify below decides what is worth a message at all; each channel's own test button sends one real notification so you can prove the path works before anything depends on it.

If you do turn SMS on: Twilio bills per 160-character segment (70 if the text contains non-GSM characters), and US numbers need A2P 10DLC registration before delivery is reliable — an approval process on Twilio's side, not a setting here, and an unregistered sender is the usual reason a message is accepted and then never arrives.

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

This box's CPU, memory, disk and network, via Prometheus + windows_exporter/node_exporter (optional), and the SIEM itself on every install: OpenSearch, ingest, storage runway and the detection engine.

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.

Each rule name links through to the alerts behind that row, filtered to the same host, in a new tab.

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. The count beside each location in the picker is what that location holds over the window selected.

Process Injection

Sysmon event 8 records one process starting a thread inside another — the mechanism behind most classic injection. It is a remarkably quiet event type, which is what makes it worth reading in full: this page shows every distinct source → target pair it finds rather than a sample.

Ordered rarest-first, because the volume leader is legitimate. On a Windows desktop the compositor (dwm.exe) starts threads in csrss.exe constantly and will dominate any count-ordered list; the rows worth your attention are the ones that happened once.

A source of <unknown process> is kept rather than filtered out. Sysmon writes that when the source exited before it could be named — a thread injected by something that immediately vanished is not the less interesting kind.

Service shutdowns are hidden by default. Windows delivers a stop signal by creating a thread running CtrlRoutine in KERNELBASE.dll inside the target, which Sysmon reports as a remote thread from an unnamed source — identical in shape to injection, and entirely routine. They are recognised by their entry point, KERNELBASE!CtrlRoutine, rather than by which process they target, so nothing is hidden on the basis of its name. The count of what was hidden is shown above the table. Switch them back on if you are investigating a service that died unexpectedly — or if you want to check that every one of them really was a shutdown.

Timestomping

Moving a file’s creation date into the past is an anti-forensic move: it drops the file out of the window an investigator is looking at. Sysmon event 2 records the change, and keeps the old value alongside the new one, so the direction is knowable.

Direction is the whole filter. Most event 2 records rewrite the timestamp to the value it already had — a copy, a save, an unpack — and carry no signal at all. This page shows only the ones that move the clock backwards, and reports how far.

The honest baseline is small and dull: Windows Update restoring original timestamps on component files, and the occasional installer. That is the point. A program you do not recognise appearing in this list, or a familiar one reaching much further back than usual, is the finding.

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, and an editor or IDE polling its own API can sit at the very top of this list. The ranking is a reading order, not a verdict.

Two sources, and they are not equivalent. Sysmon’s network-connection event is the cleaner record — it names the binary by its real path — but the shipped SwiftOnSecurity config filters it hard for disk-volume reasons, so it sees a fraction of what the machine does. The Windows Filtering Platform’s event 5156 sees essentially every permitted outbound connection. It names the binary by device path rather than drive letter, but that costs you nothing here: the Console resolves it back by matching against Sysmon’s process record of the same binary on the same host — a different event from the network one filtered above, and one that is normally left on. Where there is nothing to resolve against, the device path is shown as recorded rather than guessed at. On most installs the coverage gap is large, which is why 5156 is the default — but you do not have to take that on trust: switch between the two sources and compare the connections scanned figure below.

Agent Silence

Every other page on this list asks what the telemetry shows. This one asks whether it is still arriving — because a source that has stopped reporting produces no findings anywhere else, and looks exactly like a quiet estate.

Two different failures, and they need different evidence. An agent can stop talking altogether, which the heartbeat shows. Or it can keep heartbeating, keep sending, and quietly stop reporting one source — the shape a stopped Sysmon service or a disabled log channel makes. The second is the one worth hunting: on the roster that host looks perfectly healthy, because it is. Only the missing channel gives it away.

A source counts as having a baseline only if it was reporting on at least three separate days, at a median of 50 events a day or more. The median is deliberate — one busy day of service restarts would otherwise set a bar that nothing normal could clear, and every quiet day afterwards would read as a collapse.

Downloaded & Run

The shape almost every phishing and drive-by infection takes: a file arrives from the internet, and then something runs it. Sysmon event 15 records the Zone.Identifier stream a browser writes beside a download — including the address it came from — and this page joins those downloads to the process starts that later executed them on the same host.

Only file types that run code, install something, or carry something that does are followed. Explorer marks every file it unpacks from a downloaded archive the same way a browser marks the archive itself, so without that filter a single unpacked archive can write hundreds of thousands of marks — nearly all of them ordinary data files — and bury every download worth looking at.

A program runs as its own process image. A script, installer or shortcut runs through another program — msiexec, powershell, wscript, rundll32 — which names it on its command line, so both are checked and the ran via column says which. A run is credited only on the same host and no earlier than the download.

What this cannot see. The join is on the file’s path, so a download renamed or moved before it ran is not matched, and neither is code run from inside an archive that was never extracted. A file that ran is not by itself a finding — people download and run installers all day. The reading order is: an unfamiliar source, a script or shortcut rather than an installer, and a delay measured in seconds.

New to the Fleet

Rarity asks what is rare in a window. This asks what had never been seen before it. A binary that has run on one host every week for a month is rare and dull; one that first appeared an hour ago is worth reading, however often it has run since.

Every value in the window is checked against the 30 days before it, and only the ones that baseline never saw are listed. That makes the baseline’s own extent part of the answer: on a new install, or with a short retention, “absent for 30 days” can only mean “absent since collection started”. The date it actually reaches back to is printed under the picker, and where there is no baseline at all the page says so rather than presenting a first week of collection as a fleet full of findings.

Seven things to watch, and they answer different questions. Executables is by path; file hashes is by content, so a familiar name with new content behind it shows there and not under executables. Parent → child needs neither program to be new — Word starting a command prompt is two ordinary programs in an order that never happened before.

Logon Anomalies

Four questions about Windows logons on one page: which accounts signed in from somewhere they never had before, who logged on over the network or by remote desktop, which programs used explicitly entered credentials, and where failed logons arrived in bursts.

Windows logs on as itself constantly, and on a typical machine the overwhelming majority of successful logons are the SYSTEM account with most of the remainder services — so those, and machine accounts ending in $, are set aside in the first two tables to keep a person’s logon from being buried under them.

The source of a logon is the remote address where the event carries one, else the workstation name the logon gave, else local. Both are supplied by the other end and neither is proof of anything — a workstation name is whatever the client claimed. They are how you spot a change, not an identity.

Counts are indicative rather than exact. The network and explicit-credential tables order by ascending count, which is approximate when a query spans shards, and any multi-day window spans several daily indices.

Credential Access

Two Windows audit events that record an intruder’s first moves after landing: reading stored credentials (event 5379), and listing who belongs to which group (events 4798 and 4799). Ordinary software does both all day, in tens of thousands of events a month on a single quiet machine, so both tables run rarest-first and flag what is out of shape rather than raising everything.

The reader is often unnamed, and that is honest rather than broken. Event 5379 identifies the reading process only by ID and start time, never by path. The name shown here is recovered by matching that against Sysmon’s own record of a process starting on the same host at the same moment. Where Sysmon never recorded the start — a process older than the retained data, or one its configuration does not capture — the row is left unnamed instead of guessed at. Expect most rows to be unnamed; the count of how many could be resolved is printed above the table.

An empty table is not proof of a quiet estate. Both event types depend on their audit subcategory being switched on, and on a host where it is off nothing is written at all.

Counts are indicative rather than exact. Both tables order by ascending count, which is approximate when a query spans shards, and any multi-day window spans several daily indices.

Services & Drivers

The two ways code arranges to run as SYSTEM, or inside the kernel, and to keep doing so after a reboot: a service installed to start with Windows (event 7045), and a driver loaded into the kernel (Sysmon event 6).

Both are rare on a settled machine — a month of installs and loads usually fits on a single screen, with every driver validly signed — so every row is shown rather than sampled, with what makes one unusual carried as a flag and sorted to the top. For a service: running from a folder an ordinary user can write to, an unquoted path whose executable name contains a space (which lets anyone able to write an earlier name run as the service’s account), launching a shell or script host rather than a program of its own, a driver registered outside the driver folders, or running as a named account rather than one of Windows’ own. For a driver: unsigned, a signature that will not validate, or loading from outside the driver folders.

The flags are shape, not verdict. Plenty of legitimate software installs a service that runs as a named service account, and a driver can sit outside System32\drivers for dull reasons. What makes a row worth pulling is a flag on something you cannot account for — especially a driver loading on exactly one host out of many.

System Impostors

Windows starts a small, fixed set of processes from a small, fixed set of folders, and most have exactly one honest parent: svchost.exe lives in System32 and is started by services.exe; lsass.exe lives in System32 and is started by wininit.exe. Malware borrows those names precisely because nobody looks twice at them — but a svchost.exe in a temp folder, or one started by Word, is not the one Windows shipped.

Every process carrying one of these names is listed, not only the odd ones, so a page with nothing flagged cannot be mistaken for a broken query: the note above the table says how many shapes were found and how many were unexpected. None unexpected is the healthy answer, and the usual one.

Anything suspicious is marked in red. The whole row takes a red edge and tint, and each reason appears as a red tag beside the process name — not in its Windows folder, unexpected parent, user-writable folder. A row with no red matched expectations exactly; those are listed anyway so that a page with nothing to report cannot be mistaken for a broken query.

A parent nobody recorded reads as unknown, never as wrong — Sysmon does not always capture one, and flagging those would invent an intrusion out of a missing field. Names with many legitimate parents (rundll32, msiexec, regsvr32, schtasks, dllhost, conhost) are checked on location alone. Both the 64- and 32-bit folders count as correct wherever Windows ships both.

Tampering

What an intruder does to stop being watched: clearing logs, stopping the event log service or Sysmon, changing what gets audited, disabling services, and moving the clock.

Every one of these also happens for entirely dull reasons, and in far greater numbers. A clean shutdown stops the event log service; Windows Update rewrites the auditing settings on thousands of system files; the time service nudges the clock. On a healthy machine essentially every event of each kind has one of those explanations — the audit-setting changes alone run to tens of thousands a month. Those are recognised and counted out by default — a stop is called routine only when a shutdown marker sits within ten minutes of it on the same host, and a clock change only when the time service moved it less than five minutes. The count of what was set aside is printed above the table, and the picker brings it all back as low-severity rows.

One honest gap. When a log is cleared (event 1102 or 104) the agent does not record which log was cleared or by whom — that detail travels in a part of the event it does not read — so the host and the time are the whole finding. It is still the loudest row on this page: clearing the Security log destroys the audit trail every other page here depends on.

ATT&CK Reference

Techniques seen in alerts over the window you pick, each linking to EasySIEM's own generated reference page.

AI Security Review

Sends a digest of whatever window you pick below to an AI model for an on-demand read on real threats and misconfigurations — either a server-health review (KPI overview, agent roster and resource health — deliberately no alert or firewall lists, so it never grows with alert volume), or a deep review of one agent (its alerts and rules, logons, rare executables, services, event sources, firewall blocks, installed software and CVE matches). Nothing runs automatically — this only happens when you click Run. Pick who answers under Model below: with Claude, Groq, OpenAI or DeepSeek, each click is one real API call to that provider using your own key; with Ollama, a model on hardware you choose answers instead — this machine by default, where the digest never leaves it.