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.

Connections

The busiest alert rules and everything linked to them, live: the agents, processes, accounts and IP addresses their alerts name, and the process starts, connections, DNS lookups, logons, firewall blocks and service installs around those. Moving dots are the last five minutes of activity, and a rule flashes when a new alert arrives. Click anything for its links; double-click it, or type it below, to focus on it.

Network Map

Every device on this network, found by scanning it from the Console, and the alerts about each. A device's ring takes the colour of its worst alert, and alerts between devices, or with the internet, run along the lines between them. An alert is matched to a device by its address, by the EasySIEM agent on it, or by any name it answers to. Click a device for its details.

Authentication

Successful and failed sign-ins on every agent: Windows logons (Security events 4624 and 4625 — successes are people's logons, not Windows' own service and machine accounts), SSH on Linux, OPNsense and OpenWRT, and sudo or su on Linux. For Windows logon patterns — new sources, remote logons, bursts — see Logon Anomalies.

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 Resources

What each monitored machine is doing to itself — reported by its own agent on every heartbeat, so roughly every 30 seconds, with network traffic averaged over that interval. Busiest first, because the one worth seeing is the one in trouble.

Agent Alerts

Alerts about the endpoints themselves: one that stops reporting, whose CPU, memory or network bandwidth stays high, or that someone signs in to. Choose them once for every endpoint, then give any endpoint settings of its own. Each agent reports its CPU, memory, disk and network traffic on every heartbeat, about every 30 seconds, and its sign-ins from the machine's own logs — SSH on Linux, OPNsense and OpenWRT, and Windows remote desktop, keyboard sign-ins and unlocks. The Console checks them once a minute.

These are ordinary alerts: they appear on the Alerts page, and reach Pushover or SMS through Alert Notifications like any other, at the severity you choose for each condition. Nothing is sent until you switch a condition on.

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.

Paired Phones

A phone paired here can read this SIEM from anywhere — alerts, agent health, agent resources — and can change nothing. Scanning the code below is the whole of it: the phone never needs to be on this network, and the relay that carries the pairing cannot read it, forge it or complete it.

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".

Allow List

Activity you have checked and know to be fine — a backup job, a remote-support tool, a helper your browser starts — so it stops raising alerts. Each entry describes the events to leave out, and can be limited to one rule and one endpoint and given a last day. It applies to Sigma and custom rules; EasySIEM already leaves out its own components.

An entry silences whatever it matches, including an attacker who imitates it, so keep it as narrow as the activity allows: a full path rather than a file name, one rule rather than every rule. The quickest start is Allow… on the alert itself, which drafts an entry from that alert’s own event.

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.

Click a rule, a host or an ATT&CK technique for where it leads: the alerts behind it, and for a host its profile, its log lines, the Graph and the other hunting pages.

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.

Process Ancestry

Process Pairs stacks one link. This stacks the whole chain. The shape worth finding is often one where every individual link is ordinary and only the sequence is not: winword.exe → cmd.exe is suspicious on its own, but explorer.exe → cmd.exe → powershell.exe → rundll32.exe is four links that each occur thousands of times a day. Pair-stacking buries that chain; chain-stacking surfaces it.

Chains are rebuilt from Sysmon’s own ProcessGuid/ParentProcessGuid linkage, so they follow the real parent, not a matching program name. Consecutive repeats of one program are folded — a shell that re-execs itself five times is shown as bash.exe ×5, one shape rather than five levels — and a leading … means the oldest ancestor started before the window, which on a short window is normal rather than a finding.

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.

Disguised Commands

What a command line gives away about itself, in two lists. The first is the tricks that keep a command from reading as what it is: PowerShell’s -EncodedCommand — decoded here, so you read what it says; code fetched from the internet and run in one line; escape characters sprinkled through words and commands assembled from fragments; and the Windows programs that fetch or run code for someone else — certutil, bitsadmin, mshta, rundll32, regsvr32. On Linux: decoding something and piping it into a shell, a download piped into a shell, and reverse shells.

The second is the longest command lines, stacked by program. A thousand characters and more is where encoded payloads hide — and where build tools, browsers and scripts that pass long argument lists live every day, so it is a list to read by program and parent, not a finding in itself.

Every check belongs to one program. A caret is cmd.exe’s escape character and part of every grep pattern; -e is PowerShell’s encoded command and bash’s exit-on-error. And findings are stacked by machine, program, parent, account and what was found, because the same script runs the same way many times: a tool that starts PowerShell with an encoded command hundreds of times a week is one row, decoded, with that tool as its parent.

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.

Odd DNS Names

Every name a Windows machine looked up (Sysmon event 22), read for the shapes malware leaves in DNS and people do not: a random-looking domain, made up by malware that generates its own; many different names under one domain, which is how a DNS tunnel carries data out; a domain one letter away from a well-known one, or from one this fleet uses every day — micros0ft, paypa1 — and international (punycode) names; a free dynamic DNS or tunnel service, where anyone can have a name in seconds; and a program other than a browser that keeps asking for names that do not exist, which is what made-up domains look like from the machine.

Beside each name, the programs that looked it up: rundll32 resolving a random name is not the browser doing it.

What is left out on purpose. Clouds and CDNs name things randomly by design — a CloudFront distribution, an Azure key, a Chrome extension’s id — so names under them are never called random. A random-looking subdomain on its own is not flagged either: software vendors put customer ids in them all day, so subdomains only count toward a tunnel. A browser’s failed lookups are ad and tracker blocking, not a program guessing. Names no public DNS answers — wpad, .local, a single word — are skipped.

An empty table is the usual answer on a healthy fleet. Only Windows machines running Sysmon record their lookups.

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.

Suspicious Processes

What is running right now on each Windows endpoint, with anything that should not be there first. Every Windows agent lists its running processes about once an hour; each one is matched to its own start in the last week for its command line, then checked the way the other hunting pages check what they find: a Windows name in the wrong folder or under the wrong parent, a system account running a program any user could have replaced, a name one letter off a Windows one outside the Windows and program folders, a file name dressed up as a document, a command line disguised the way Disguised Commands looks for, and an interpreter started by a document or a browser.

Red flags mark what should not be running at all, and amber ones what is worth a look. The alerts column counts the alerts that named each program on that endpoint in the last week — context rather than a flag, because a busy program collects alerts all day. Linux, OPNsense and OpenWrt agents do not list their running processes yet.

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.

Eight 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. Outbound addresses is per machine rather than fleet-wide: a server talks to the same few places, so its first connection to a new one stands out whoever else has been there. Clouds hand out addresses from inside their ranges all day, so an address in a network (a /24) the machine had already used is counted under the table instead of listed.

Logon Anomalies

Six questions on one page. Two are asked of every platform — Windows, and SSH on Linux, OPNsense and OpenWRT: where a run of failed sign-ins ended in a successful one, the moment a guessed password works; and which accounts signed in at an hour they almost never use. The other four are about Windows logons: 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.

Recon Bursts

Someone who has just landed on a machine asks it where they are: whoami, net user, ipconfig, systeminfo, nltest on Windows; id, uname, ip, ps, who on Linux. Each of those runs all day for ordinary reasons, one at a time — which is why a rule for each one fires on any machine being administered — but several different ones from one account within ten minutes is a person, or a script, taking stock.

So this counts different tools, not runs: uname three times over is one tool. A burst is a run of these by one account on one machine with no gap longer than ten minutes, and its size is the most different tools any ten minutes of it held. Windows bursts of three and up are listed, and Linux bursts of four and up — every SSH login to an Ubuntu machine runs uname, id and who through its login messages, so three there is a login.

Flagged in red: five or more different tools; the domain-mapping tools (nltest, dsquery, adfind, setspn); and a parent with no business running them — Office, a script host, a program in a user-writable folder, or a web server, which is what a web shell looks like. The rest are worth a glance: an administrator at work looks exactly the same, and only you know who that was.

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.

Scheduled Tasks & Cron

Persistence that survives a reboot without touching a service or a Run key: a scheduled task on Windows, a crontab line on Linux. Both are ordinary administration, which is exactly what makes them good hiding places — one more task among hundreds, named like something the operating system ships.

Two tables, because they answer different questions. Schedule changes is who created, altered or removed a schedule, and is where an intrusion shows up as it happens. What cron is running is the work the schedules are actually doing, which is how persistence planted before this window — or before EasySIEM was installed at all — still gets found.

Read the evidence sources first. Every source on this page can be switched off, and a silent one produces an empty table that looks exactly like a quiet estate — so the first table below reports what actually reached this console, measured on your own fleet over the window you pick.

The distinction that matters most is between the two Windows sources. Process creation only catches a schedule change when somebody typed a command, so it sees schtasks.exe, at.exe and the PowerShell scheduled-task cmdlets. Task registration also catches a task created through the COM API, where there is no command line to observe — which is how installers and intruders alike tend to create them. If only the process source is arriving here, read this page as a partial view rather than an all-clear.

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.