Newly Observed High Severity Suricata Alert

IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Newly Observed High Severity Suricata Alert

This rule detects Suricata high severity alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response.

Rule type: esql

Rule indices: None

Severity: critical

Risk score: 99

Runs every: 5m

Searches indices from: now-7205m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

https://www.elastic.co/docs/reference/integrations/suricata

Tags:

Use Case: Threat Detection
Rule Type: Higher-Order Rule
Resources: Investigation Guide
Domain: Network
Data Source: Suricata

Version: 2

Rule authors:

Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Newly Observed High Severity Suricata Alert

This rule surfaces newly observed, low-frequency high severity suricata alerts within the last 5 days.

Because the alert has not been seen previously for this rule and host, it should be prioritized for validation to determine whether it represents a true compromise or rare benign activity.

Investigation Steps

Identify the source address, affected host and review the associated rule name to understand the behavior that triggered the alert.
Validate the source address under which the activity occurred and assess whether it aligns with normal behavior.
Refer to the specific alert details like event.original to get more context.

False Positive Considerations

Vulnerability scanners and pentesting.
Administrative scripts or automation tools can trigger detections when first introduced.
Development or testing environments may produce one-off behaviors that resemble malicious techniques.

Response and Remediation

If the activity is confirmed malicious, isolate the affected host to prevent further execution or lateral movement.
Terminate malicious processes and remove any dropped files or persistence mechanisms.
Collect forensic artifacts to understand initial access and execution flow.
Patch or remediate any vulnerabilities or misconfigurations that enabled the behavior.
If benign, document the finding and consider tuning or exception handling to reduce future noise.
Continue monitoring the host and environment for recurrence of the behavior or related alerts.

Rule query

edit

FROM logs-suricata.*

  // high severity alerts
| where event.module == "suricata" and event.kind == "signal" and event.severity == 1

| STATS Esql.alerts_count = count(*),
        Esql.first_time_seen = MIN(@timestamp),
        Esql.distinct_count_src_ip = COUNT_DISTINCT(source.ip),
        Esql.distinct_count_dst_ip = COUNT_DISTINCT(destination.ip),
        src_ip_values = VALUES(source.ip),
        dst_ip_values = VALUES(destination.ip),
        url_dom = VALUES(url.domain),
        url_path = VALUES(url.path) by rule.name, event.type

| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
  // first time seen is within 10m of the rule execution time
| where Esql.recent <= 10 and
// exclude high volume alerts such as vuln-scanners
  Esql.alerts_count <= 5 and Esql.distinct_count_src_ip <= 2 and Esql.distinct_count_dst_ip <= 2

// move dynamic fields to ECS quivalent for rule exceptions
| eval source.ip = MV_FIRST(src_ip_values),
       destination.ip = MV_FIRST(dst_ip_values),
       url.domain = MV_FIRST(url_dom),
       url.path = MV_FIRST(url_path)
| keep rule.name, event.type, Esql.*, source.ip, destination.ip, url.domain, url.path

« Newly Observed Palo Alto Network Alert Telnet Authentication Bypass via User Environment Variable »