Building Custom SIEM Detection Rules in Elastic Security

Wylie Bayes

• 2 min read

Elastic Security comes with hundreds of pre-built detection rules out-of-the-box, created and maintained by Elastic’s security research team. While these rules provide a fantastic baseline, every corporate environment is unique. A behavioral pattern that is highly malicious in one company might be a standard daily task for the IT team in another.

To maximize the value of your SIEM, you must tailor its logic to your specific environment. In this post, we will explore the Elastic Detection Engine and learn how to build custom rules using Kibana Query Language (KQL) and Event Query Language (EQL).

The Detection Engine Overview

The Detection Engine is the brain of the Elastic Security app. It runs continually in the background, executing queries against your Elasticsearch indices at regular intervals (e.g., every 5 minutes). If the data returned matches the rule's logic, the engine generates an alert in the centralized queue for analysts to triage.

When creating a custom rule, Elastic offers several distinct rule types:

  1. Custom Query: Evaluates a single KQL or Lucene query.
  2. Threshold: Triggers when a query returns a result count that exceeds a defined limit.
  3. Event Correlation: Evaluates a sequence of related events using EQL.
  4. Indicator Match: Compares incoming logs against active threat intelligence feeds.

Building a Custom Query Rule (KQL)

Let's build a simple custom query rule to detect a "Living off the Land" technique. We want to know if certutil.exe is being used to download files from the internet, which is a common way attackers bypass web filters.

  1. Navigate to Security -> Rules -> Detection rules (SIEM) and click Create new rule.
  2. Select Custom query.
  3. Input the following KQL query:
    process.name : "certutil.exe" AND process.command_line : (*-urlcache* OR *-f*) AND NOT user.name : "SYSTEM"
  4. Configure the Schedule: Set the rule to run every 5 minutes with a 1-minute lookback overlap (to account for minor data ingestion delays).
  5. About the Rule: Map it to the MITRE ATT&CK framework. In this case, Tactic: Command and Control, Technique: Ingress Tool Transfer. Set the severity to High.

If a developer runs this command, an alert fires instantly.

Building an Event Correlation Rule (EQL)

KQL is excellent for finding single isolated events. However, advanced attacks often involve a sequence of actions. To detect a chain of events, we use the Event Query Language (EQL).

Let's create an EQL rule to detect a malicious macro. We want an alert if a Microsoft Office document spawns a command shell (cmd.exe or powershell.exe) within 30 seconds.

  1. Create a new rule and select Event Correlation.
  2. Input the following EQL sequence:
    sequence by host.name, user.name with maxspan=30s
  [process where process.name in ("winword.exe", "excel.exe", "powerpnt.exe")]
  [process where process.parent.name in ("winword.exe", "excel.exe", "powerpnt.exe") 
   and process.name in ("cmd.exe", "powershell.exe")]

How this works:
The sequence keyword tells Elastic to look for events happening in a specific order.
The by keyword ensures the correlation only applies if both events happen on the same host by the same user.
The maxspan restricts the time window. If Word opens, and 2 hours later PowerShell opens, it won't alert. It must happen within 30 seconds, indicating automated macro execution.

Rule Tuning and Exceptions

A new rule will almost always generate false positives. Do not immediately delete a noisy rule; tune it instead using Exceptions.

Elastic makes adding exceptions incredibly easy. From an active alert, you can click "Add exception" and specify conditions. For example, if the Helpdesk team uses a specific script that violates the EQL rule above, you can add an exception: Do not alert if process.command_line matches C:\IT_Scripts\Update.ps1.

By layering exceptions, you carve away the legitimate business noise until only the true anomalies remain.

Conclusion

The ability to craft highly specific, chained detection logic is what separates a world-class SIEM from a generic log aggregator. By mastering KQL for single-event queries and EQL for behavioral sequences, Blue Teams can create an impenetrable net tailored precisely to their organization's unique digital footprint.