When Every Event Looks Normal: Logster and the Context Gap in Endpoint Detection

Chad Ray — Mon, 14 Sep 2026 08:39:40 +0000

A PowerShell process starts. A script appears in a temporary directory. A scheduled task is registered. A connection goes out to an unfamiliar address.

An analyst could find a reasonable explanation for each of those actions. Software deployment, perhaps. A maintenance job. An administrator troubleshooting a workstation.

But were they part of the same operation? Did the process that downloaded the script also arrange for it to run at the next login? Was that process launched by the expected management agent, or by something that had no reason to start a shell?

Those questions change the investigation. The challenge is getting enough context to answer them before the activity disappears into another day of logs.

Key takeways

Legitimate tools can perform malicious actions; their names alone rarely settle an investigation.

Relationships between processes, files, and connections help distinguish routine work from suspicious behavior.

Automated analysis is useful when it preserves evidence and reduces the work needed to investigate a finding.

Familiar tools leave ambiguous evidence

Living off the land means abusing tools and capabilities already available in the environment. Their legitimate uses give attackers room to blend into routine administration.

CISA and its partners describe this detection challenge in their joint guidance, Identifying and Mitigating Living Off the Land Techniques. They emphasize detailed logging, established baselines, and correlation to distinguish malicious activity from legitimate operations. Recognizing an executable is only one part of understanding its use. (CISA and partners, February 2024)

The wider threat data reinforces why signatures alone are insufficient. CrowdStrike's 2026 Global Threat Report states that 82% of detections in 2025 were malware-free. That describes CrowdStrike's observed detections, not all attacks worldwide, and malware-free activity is broader than living off the land. It does, however, show why detection cannot depend entirely on finding a malicious file. (CrowdStrike, 2026 Global Threat Report)

Consider this hypothetical Windows sequence:

A process launches PowerShell with an encoded command.
PowerShell writes a script into a temporary directory.
A child process registers a scheduled task that references that script.
The same process tree contacts an external destination and queries domain accounts.

This is an illustration, not a captured incident. It also isn't proof of compromise: administration software can perform similar operations. Some of the individual actions may already trigger good detections.

What makes the sequence worth investigating is the connection between the actions. A newly written script, a persistence mechanism pointing to it, and related discovery activity give an analyst a more specific question than “Was PowerShell running?”

Collecting the events is only the beginning

A searchable log store can contain every relevant record and still leave considerable work for the analyst.

The process creation event may live in one view, the file write in another, and the network connection in a third. Before making a judgment, someone has to establish which process performed each action, reconstruct its ancestry, and align the timestamps. Missing identifiers or incomplete collection make that harder.

Existing tools already address parts of this problem. Event correlation is an established capability: Elastic's EQL rules, for example, can match ordered sequences and join events through shared fields such as process or host identifiers. It would be inaccurate to say that rules only understand isolated events. (Elastic, Event correlation rules)

The practical challenge is coverage. A correlation rule describes a relationship its author anticipated. Detection engineers still have to choose which sequences matter, tune them against legitimate operations, and maintain them as the environment changes.

A useful additional capability would preserve the surrounding behavior even when it doesn't match a prewritten sequence. That gives both automated analysis and the person reviewing its result more evidence to work with.

A process tree helps, but the activity extends beyond it

A behavior graph connects the entities involved in an operation. Processes, files, and network destinations become nodes; actions such as spawning, writing, and connecting become edges. Timestamps help retain the order in which those actions occurred.

The value becomes clearer when you compare the questions available at each level:

Recorded activity	Context that helps explain it
PowerShell started	Which parent launched it, with what command line and account?
A script was written	Which process wrote it, and was it subsequently executed?
A scheduled task was registered	What does it run, and how does that target relate to earlier activity?
An outbound connection occurred	Which process opened it, and what else did that process do?

A graph does not make these actions malicious. It makes their relationships available for analysis. A management agent carrying out an expected deployment and an unexpected shell arranging persistence may use overlapping tools while producing different surrounding behavior.

Nor does proximity prove causation. Two events on the same host within a minute are not automatically related. Reliable process identity, explicit file references, and observed parent-child relationships matter more than simply drawing lines between nearby timestamps. This also connects detection quality to collection quality.

Making the context available before an analyst opens the alert

Once activity has been organized into a graph, a detector can assess a connected set of actions. Rules, graph models, and language models offer different ways to do that; the representation and the method used to evaluate it are separate choices.

A language model can receive a textual representation of the graph alongside instructions about suspicious behavior and legitimate operating patterns. The intended benefit is contextual assessment: examining what the connected actions suggest, then returning a structured result that the surrounding system can process.

Logster is one implementation of this approach. It is an endpoint threat detection platform for SOC teams, with ingestion paths for Windows Sysmon and PowerShell logs and Linux auditd and eBPF telemetry. Its pipeline normalizes incoming records and builds activity graphs over per-endpoint windows.

In the current implementation, an LLM classifier evaluates the serialized graph and supplies the verdict, subject to configured thresholds. The platform also provides alerts, graph views, and process trees for investigation. This brings the connection between collection, detection, and investigation into the same workflow: the relationships assembled for analysis can also help the analyst understand the finding.

That is the useful idea here. Instead of beginning every investigation by reconstructing how disconnected records fit together, the analyst can start with an assembled account of the observed activity and test whether the conclusion is supported.

The architecture alone does not establish detection accuracy or time saved. Those outcomes need to be measured against representative attacks and legitimate workloads.

The context still has limits

Any verdict is bounded by the evidence the system collected and retained.

A short activity window may miss an earlier action that explains what happened next. An endpoint graph cannot, by itself, establish the full story of an operation spanning several hosts. Missing script content or incomplete process ancestry can leave crucial questions unanswered.

Model input limits add another constraint. Logster's serializer includes mechanisms to compact and truncate oversized graphs to fit the available input budget. A model may therefore receive less detail than the complete collected window. Evaluating what survives that reduction matters as much as evaluating the model's answer.

A language model can also produce a plausible explanation that the records do not support. Its reported confidence should not be treated as a calibrated probability of correctness without validation. An analyst needs a way to inspect the evidence behind the conclusion.

Operational failures deserve equally clear treatment. In Logster's current classifier resolution path, a failed model call or missing verdict is reported as an error. Separately, model attack verdicts that fall below the configured probability or confidence thresholds are demoted to benign, with a suppression reason recorded. Both behaviors matter when measuring coverage: an unavailable decision and a suppressed finding need to be visible during evaluation.

These constraints leave plenty of room for conventional controls. Known malicious artifacts and well-understood behaviors still warrant direct detection. Contextual analysis adds value when the ambiguity lies in how otherwise familiar actions fit together.

Evaluate the investigation, not just the alert

A practical evaluation should pair a suspicious sequence with a legitimate workflow that uses similar tools. A scripted software deployment is a useful comparison for a sequence involving script execution, downloads, and scheduled tasks.

Ask the system to show what distinguishes them. Then inspect the evidence:

Does it preserve the process ancestry and relevant command lines?
Can the reviewer follow a file from creation to later use?
Are the claimed relationships observed, or inferred only from timing?
What happens when activity crosses a window boundary or telemetry is missing?
How often does it flag legitimate work, miss the test attack, or fail to produce a verdict?

Measure time to a supported decision alongside detection results. An alert that names a technique but leaves the analyst to reconstruct everything may offer less operational value than its demo suggests.

The next time a detection fires on a familiar administrative tool, follow the actions around it. Check who launched it, what it changed, and what followed. A useful endpoint detection system should make that investigation easier to begin and easier to verify.

Tags: Endpoint Detection, Living off the Land, Security Operations, Behavioral Analysis, Logster

DEV Community: Chad Ray