SentinelOne An autonomous agent that models everything happening on an endpoint as a linked story, decides locally whether that story is malicious, and can undo it. Learn Storyline and the query syntax and you can answer almost any endpoint question in minutes.

Unlike products that ship telemetry to a cloud brain for a verdict, SentinelOne runs its detection engines on the endpoint. Consequence: detection and response continue with no network connectivity — relevant for laptops on hostile networks and for ransomware that severs connectivity first.

Platform notes: on macOS the agent uses Apple's Endpoint Security framework and therefore requires MDM-delivered system-extension approval and Full Disk Access. On Linux it typically runs in user space with eBPF, which matters for kernel-version compatibility on servers.

Every execution chain gets a Storyline ID. Related events inherit it, so a single identifier retrieves the whole incident rather than a pile of disconnected alerts.

Practical consequences worth internalising:

• Triage means examining one story, not correlating twenty alerts by hand.
• Rollback can be precise because the agent knows exactly which changes belonged to that story.
• Hunting by Storyline ID (src.process.storyline.id) is the fastest pivot in the product — find one bad event, retrieve everything connected to it.

Policy is set per Site and Group and inherits down from the Account level, so structure your groups to match how you want to differ: servers, workstations, developer machines (noisier by nature), executives.

Agent health is a security control. Track: agents not reporting for N days, out-of-date agent versions, agents in Detect mode that should be in Protect, and — on macOS — agents lacking Full Disk Access. A console that says "healthy" while an agent lacks permissions is the failure mode to design against.

Network isolation (Disconnect from Network) keeps the agent's own connection to the console alive so you can still investigate and run remote commands. Isolate early and apologise later; it is far cheaper than lateral movement.

Rules to hold to: never exclude a whole drive, a user profile, or %TEMP%; scope exclusions to the smallest group that needs them; record requester, reason and review date; and re-review quarterly. Attackers who know your exclusions will use them, and exclusion lists outlive the people who created them.

The src. / tgt. convention is the thing to internalise: src is the actor (the process doing something), tgt is the object acted upon (the file written, the process injected into).

Operators

=  !=            exact match / negation
in ( ... )       set membership
contains / containscis    substring (cis = case-insensitive)
matches          regular expression
AND OR NOT ( )   boolean composition

Everyday queries

// Office spawning a shell — the classic
src.process.parent.name in ("WINWORD.EXE","EXCEL.EXE","OUTLOOK.EXE","POWERPNT.EXE")
AND src.process.name in ("cmd.exe","powershell.exe","wscript.exe","mshta.exe")

// encoded PowerShell
src.process.name = "powershell.exe"
AND (src.process.cmdline containscis "-enc"
     OR src.process.cmdline containscis "frombase64string"
     OR src.process.cmdline containscis "downloadstring")

// execution from a user-writable staging directory
src.process.image.path containscis "\\appdata\\local\\temp\\"
AND src.process.publisher = ""

// LSASS access (credential dumping)
tgt.process.name = "lsass.exe" AND src.process.name != "MsMpEng.exe"

// macOS fake password prompt
src.process.name = "osascript" AND src.process.cmdline containscis "display dialog"

// suspicious DNS: long, high-entropy labels
event.dns.request matches "[a-z0-9]{25,}\\."

// pull the whole incident once you have one event
src.process.storyline.id = "A1B2C3D4E5F6"

PowerQuery: aggregation and pipelines

PowerQuery adds a piped, aggregate-capable syntax on the same data — this is where hunting gets genuinely powerful, because prevalence analysis is what separates "weird" from "rare and therefore interesting".

// rarest signed-less binaries in the estate
src.process.publisher = ""
| group count = count() by src.process.name
| sort -count
| limit 100

// which hosts ran a given hash
tgt.file.sha256 = "<hash>"
| group hosts = estimate_distinct(endpoint.name) by tgt.file.path

// beaconing candidates: repeated connections, few distinct destinations
event.type = "IP Connect"
| group conns = count(), dsts = estimate_distinct(dst.ip.address)
    by endpoint.name, src.process.name
| filter conns > 500 AND dsts < 3
| sort -conns

// PowerShell command-line prevalence — outliers rise to the bottom
src.process.name = "powershell.exe"
| group runs = count() by src.process.cmdline
| sort runs
| limit 50

STAR (Storyline Active Response) converts a saved Deep Visibility query into a rule that evaluates continuously and can act automatically.

Good STAR candidates are things that are unambiguous in your environment: execution from a specific staging path, a tool nobody legitimately runs, persistence created by a non-IT process, or the fake-password-prompt pattern on macOS. Poor candidates are broad behaviours with legitimate variants — those belong in the SIEM where they can be correlated with other signals rather than actioned alone.

• Network isolation — cut the host off while retaining agent connectivity.
• Remote Shell — a full interactive session on the endpoint. Access to this should be tightly restricted, MFA-protected and logged: it is the most powerful capability in the platform and, in an attacker's hands, a management-console-to-RCE path across the fleet.
• Fetch files — retrieve artefacts for analysis.
• Fetch logs — agent diagnostics for support cases.
• Kill / quarantine / remediate / rollback — the response ladder from Tier 0.
• Scripts (Remote Ops) — run vetted collection or remediation scripts at scale.

• To the SIEM — threats and, where volume allows, Deep Visibility events. Endpoint context is what turns a network alert into an incident, so at minimum send detections, agent health and console activity logs.
• To SOAR — isolate-on-alert playbooks, enrichment lookups, ticket creation.
• To the SSE/IdP — device health as a posture signal for conditional access and Netskope policy.
• API — the management API supports everything the console does: pulling threats, agent inventory, running queries and issuing response actions. Good uses include automated agent-coverage reconciliation against your asset inventory, which is exactly the evidence an auditor asks for.

• Unmanaged devices — contractors, personal machines, forgotten servers. Coverage reconciliation against asset inventory is the control, not the agent itself.
• Identity-only attacks — AiTM phishing, OAuth consent grants and session-cookie replay never touch an endpoint you monitor.
• BYOVD — bringing a vulnerable signed driver to attack the agent from the kernel.
• Tamper and uninstall — enforce tamper protection with a passphrase, and alert on agent uninstall, disable, or extended non-reporting.
• Living off the land at low volume — a single legitimate admin tool used once looks exactly like administration. Prevalence and context are the only defence.
• Exclusion abuse — see Tier 1; your own exclusion list is documented evasion guidance.
• macOS/Linux depth — telemetry is genuinely richer on Windows. Do not assume parity across platforms; test it.

The senior framing for a board or a client: EDR is a very strong control for endpoint execution and a weak one for identity abuse. That is not a criticism of the product — it is why the stack also contains an IdP, an SSE and a SIEM, and why the three must be correlated rather than run in parallel.