From first log to investigation

1. Request pilot access

On the Ancient pilot page, choose Request pilot access. Tell us what you want to monitor and use the work email of the person who will manage the workspace.

After pilot approval, use that same address in the workspace portal. Verify your email, sign in and request a workspace. Your workspace request is reviewed separately.

When the activation email arrives, follow its link to set your console password and enable MFA. Save your recovery codes privately. Use the console address for your workspace when signing in again.

2. Connect your first Linux source

In your workspace console, open Sources, select Add source and create a Server source for the host. Save the ingestion key when it appears. In Source packages, apply the Linux package to that source.

Open Setup agent for the same source. Choose Linux, then use Copy installation command in Configuration. Run it on the Linux host you want to monitor with an account that can administer the host. Enter the ingestion key at the hidden prompt.

For Windows or web server logs, use the corresponding package and follow its setup steps. For a sender you already operate, use an Application or WAF source.

3. Verify delivery and open Search

Perform a normal action your collector monitors, such as an authorized sudo /usr/bin/true on a Linux host that collects sudo logs. Open the source’s Delivery diagnostics and refresh. Look for a new stored event and its timestamp.

On the source’s Investigate stored logs panel, choose Open in Search for all events from that source, or Search log type next to a specific type. To count events by log type, run this query with your source name and open Statistics.

search source:"Example Linux" | stats count by sourcetype

If delivery is still empty, check that you’re viewing the same workspace and source you configured. On Linux, sudo ancient-agent diagnose checks the clock, HTTPS and whether the agent can read the selected inputs. Refresh delivery again after generating a supported event.

4. Investigate the event

In Search, expand an event and choose Inspect event to see its recorded fields. For Linux audit events with an Audit ID, choose Find related audit records to see other records from the same operation.

In the source’s Detection inputs observed section, see which rules can use the event types Ancient has received. A stored event produces an alert only when it meets an enabled rule’s conditions. Open Alerts to review any resulting alert.

Search with Ancient SPL

Open Search, select Live data or Demo data, and set the time range. Start with search and add stages with |. Stages run in order. Use Events for matching records and Statistics for grouped results.

Find and inspect records

search source_id:"YOUR_SOURCE_ID" type:auth.login_failed
| table _time,host,actor,ip,sourcetype
| head 20

Copy the source ID from Sources. IDs distinguish sources that share a display name. Quote values with spaces. Use where for comparisons and compound conditions, for example where status >= 500 and status < 600.

Count errors and plot trends

search type:http.request
| where status >= 500 and status < 600
| stats count by source,status
| sort -count
| head 10

search type:http.request
| timechart span=1h count by status

search and where

Filter records by indexed terms or field expressions.

fields and table

Select output fields or define table columns.

stats, timechart and top

Aggregate, group into time buckets or rank common values.

sort and head

Order and limit the current results.

eval, rename and dedup

Derive values, rename fields or keep the first row per key.

Ancient scans at most 10,000 candidate events per SPL query. When Search reports a scan limit, narrow the time range or add indexed filters before interpreting totals. Fields such as event.code and process.name depend on the source package.

Write and preview a detection rule

First search for the event type you want to detect and inspect actual records. Use those field names and values when authoring the rule. In Settings, open the detection rules workspace as an administrator.

1. For a threshold rule, choose the exact event type, event count, time window and severity. Thresholds group by source and IP. For example, use auth.login_failed, five events in 300 seconds and High severity for repeated remote login failures.
2. Use a sequence when ordered events matter. Pick a grouping field and a time window that represents one entity’s activity. Use Sigma when you need field-level matching such as event code and sourcetype.
3. Preview against a representative time range and review which retained events would match. Verify both expected matches and routine events that should be excluded.
4. Save the rule disabled. Review severity and notification routing, then enable it. Generate an authorized matching event and verify the resulting alert under Alerts.

Sigma example

title: Windows Security audit log cleared
logsource:
  product: ancient
level: high
detection:
  selection:
    sourcetype: "windows:security"
    event_type: audit.log_cleared
    event.code: "1102"
  condition: selection

Use the supported Sigma subset shown in the rule editor. Ancient reports unsupported fields and modifiers during preview. Preview uses stored events and does not produce alerts. Built-in source package starter detections activate when the package is applied.