1. Viewing the Threat Storyline (Full Kill Chain Reconstruction)
Every event the agent captures — process launches, file writes, script execution, network connections, registry changes — is tagged with a shared Storyline ID. This lets the console reconstruct the complete attack chain from a single starting point instead of a list of disconnected events.
Where to find it:
In the console, open the Incidents / Alerts view
Click into any individual alert to open its detail view.
Open the 'Storyline' tab to view the process tree / graph — this shows the full kill chain: parent process → child processes → files dropped → network connections → any registry or persistence changes.
Click any node in the graph to drill into that specific event's detail.
2. Manual Threat Hunting (PowerQuery - Singularity Data Lake)
Manual hunting is done with PowerQuery, SentinelOne's query language for searching, filtering, and aggregating full agent telemetry stored in the Singularity Data Lake (this is the modern evolution of what was previously called "Deep Visibility" — some partners may still know it by that name). PowerQuery uses a pipeline-based syntax; it is not SQL, though it is loosely comparable to a query language like Splunk's SPL.
Where to find it:
In the console, navigate to Event Search and make sure the PowerQuery is toggled on.
Search by process name, file hash, path, network destination, user, and more, or write a query directly.
To dig deeper into a specific alert, copy its Storyline ID from the alert view and search for it in PowerQuery — this surfaces every related event across all endpoints sharing that Storyline ID, which is useful for spotting lateral movement.
3. Exporting Logs (Syslog & API)
Complete allows full logs to be exported out of the console for ingestion into a SIEM or other external system, via two methods:
Syslog:
Prerequisites:
SentinelOne Platform version Central Park or later
Agent version Windows/macOS/Linux 2.6 or later
If using TLS: access to the required certificates (server certificate, and client certificate/key if your Syslog server requires client authentication) — PEM format (.crt or .pem); passphrase-protected certificates are not supported
Setup steps:
Click the scope arrow at the top left of the console and select the Account or Site you want to configure Syslog for.
Open Settings → Integrations → Syslog.
Move the toggle to Enable Syslog.
Enter your Syslog server's hostname and port in the "Your Syslog Host" field.
Choose the connection type: select "Use TLS secure connection" for a secure connection, or leave it unselected to use UDP.
If using TLS, upload the server certificate (required to verify the Syslog server's identity), plus the client certificate and client key if your Syslog server requires client authentication.
Select the log format your Syslog server supports: CEF2, RFC-5424, STIX, or IOC (CEF2 is the common choice for most SIEMs).
Optionally, add a SIEM token to include in notifications, for filtering/forwarding rules on the Syslog server side.
Click Test to verify connectivity, then check your Syslog server logs for the message: "sentinel - SentinelOne Syslog connection established successfully!" — if you only see a generic "message was sent" note without this success message, treat it as a connection failure and adjust your settings.
Once the test passes, click Save.
API:
Go to Policy & Settings → User Management → Service Users.
Create a new Service User (recommended over a personal user token for integrations/automation), assign it Account or Site level permissions (not Global), and generate its API token from there — copy and store it immediately, as it cannot be viewed again after generation.
The full API reference is available directly from the console's built-in API documentation page.