Create a custom detector

At Hunters, we believe that we can cover ~80% of the attack surface by covering common detection use cases with our internal research and detection engineering teams, so that you can focus on customizing the 20% that's unique to your organization.

Hunters allows users to create their own Custom Detectors, which run continuously over your raw data as part of the Hunters Detection Engine, in addition to the library of detectors provided out-of-the-box by Hunters.

🚧 Attention

Currently, leads arriving from custom detectors will display a limited set of data and will not include all of the enrichment information available in a Hunters detector, such as entities, risk score, and Stories.

To get the most data out of custom detectors, we recommend using existing event sources rather than creating custom ones.

📘Learn more

Custom detectors run continuously on newly ingested data. Most custom detectors run in 5 minute intervals, however, time-windowed detectors like Group By detectors might take longer to generate leads, based on the time window size.


To create a custom detector:

  1. Navigate to the Detectors page.

  2. In the top-right corner, click New Detector
    The Custom Detector creation wizard opens.
     image

To create a Custom Detector you'll need to complete the following steps:


STEP 1: Define a query

To create a Custom Detector, you'll need to define the query that will be continuously executed on the raw data.

📘 What defines a query?

Each query should answer the following questions:

  • Which table will we query?

  • Which event will be looked at?

  • Which attributes will be extracted as part of the query?

To define a query:

  1. Name your new detector by replacing the placeholder heading.
    image

  2. From the top toggle, select one of the two detection modes offered:

    • Filter - This detection mode will execute the query on a row-by-row basis and generate leads for any row that fits the filter. For example, we could filter for specific process names, with specific flags in their command line.

    • Group by - This detection mode will group events over a time window based on a configurable grouping logic, with an option to generate leads only when the group fits a certain post-grouping condition. For example, we could group login events of a specific username over a 10-minute period, and see if the amount of logins passes a certain threshold.

  3. From the Event Source dropdown list, select from a list of built-in event sources.

    📘What is an event source?

    An event source is a definition that includes:

    • The table that will be queried

    • The specific events that will be filtered (since we'll usually want our query to be on a specific event like "process creation", and not on the entire raw table).

    • The specific attributes that will be extracted in the query

    We recommend using one of the built-in event sources suggested in the drop-down list. Those sources, created by the Hunters team, already contain the correct filters and extract all of the relevant attributes from the event. However, you can also create your own custom event source by clicking New event source. Learn more here.

  4. Continue according to the selected detection mode:

  1. From the Detection Logic field, define the attributes you want the detector to detect and under which conditions. This section will be pre-populated with the attributes that the event source extracts from the raw data.

    Click here to learn more about the available operators and functions.

  2. From the Test logic field, select the timeframe on which you want the test to run and then click the Play icon to see samples of events that will pass the query and generate leads. The results are populated inside a flexible grid component, so you can sort, filter and group them in order to best understand the output of your query.

    This can be an iterative process - you might dive into the test results and see some other cases you want to filter out, in which case you can go back to the detection logic, refine it and run the test again until you're satisfied with the results you see.

  3. Once you're satisfied with the defined logic, click Next to move to the next step.

  1. From the Detection Logic field, define the conditions your detector will follow:

    • Pre-grouping condition (optional) - decide which events in the table will be looked at before the grouping takes place. For instance, if we want the detector to detect "more than 5 executable files created in 10 minutes on a host", we'll add the condition "target_file_extension EQUALS .exe".

      Click here to learn more about the available operators and functions.

    • Grouping - use this option to define the grouping logic. This will include the time window size and the attributes by which we want to group. For our example, if we want a lead created per host, we'll group by 10-minute windows, and by the host's EDR agent ID.

      Use the Add Statistics field to provide statistical insights to the data. See a detailed explanation of the available operators.

      Click here to learn more about the available operators and functions.

    • Post-grouping condition (optional) - Use this option to apply grouping conditions on the grouped rows and on the aggregated attributes. In our case, the filter will be "number of executable files is larger than 5".

      For those familiar with SQL syntax, those steps are very similar to the `WHERE`, `GROUP BY` and `HAVING` steps respectively.

  2. From the Test logic field, select the timeframe on which you want the test to run and then click the Play icon to see samples of events that will pass the query and generate leads. The results are populated inside a flexible grid component, so you can sort, filter and group them in order to best understand the output of your query.

    This can be an iterative process - you might dive into the test results and see some other cases you want to filter out, in which case you can go back to the detection logic, refine it and run the test again until you're satisfied with the results you see.

  3. Once you're satisfied with the defined logic, click Next to move to the next step.

STEP 2: Set up scoring & alert generation

Our next step is to set scoring and alert generation settings. In other words, we will determine when a new lead is generated (based on the logic you set in the previous step), its risk score, and when it will generate an alert.

  1. Under Choose TTP, select any MITRE ATT&CK Technique associated with the custom detector you're creating. Hunters will use this to assign the base severity level to each lead generated.

    📘Note

    In case there's no specific technique that can be associated with the detector, or if you want to determine the base severity manually, check the Other checkbox.

  2. Define the detector's base risk by selecting a confidence level.

    📘 How does that work?

    Leads arriving from your custom detector will receive a base risk score based on the base confidence you select in this field.

    Risk score is a multiplication of Confidence (the likelihood of the event being malicious) and Severity (The potential impact and damage of the security event on the organization).

    If you've selected techniques in the previous field, the base Severity dropdown will be deactivated, as it's determined according to the selected techniques. If you've selected Other, then you can determine the base Severity yourself.

    Learn more about Risk Score.

  3. Under Create your alerts, define whether you'd like the detected leads to create alerts and starting from which confidence level.

  4. Under Set clustering logic, determine the grouping attribute that will be used to group leads together into a cluster.

  5. Once done, click Next.

STEP 3: Additional Configuration

With the query and scoring details set, we need to fill in a few more details before we're done.

  1. In the Description field, write a short description for the detector. This description will be available when interacting with the generated leads in different parts of the platform, and can help get your users up to speed on the detector's purpose and logic.
    For example: A hunting query for suspicious rundll32 executions

  2. Under String representation of the lead/alert, write a sentence describing what was detected in the lead originating from this detector. You can include variables to display specific attributes.
    For example: Rundll32.exe executed {target_process_name}

  3. Under String representation of the threat cluster, write a sentence describing what was detected in the cluter originating from this detector. You can include variables to display specific attributes.

  4. Finally, select the most important attributes of this detector:

    • Display Attributes: these are the attributes that will be displayed first in various screens (leads page, leads grid, investigation drawer, etc.)

    • Aggregate Attributes: these are the attributes that will be used to aggregate the different leads into threat clusters.

  1. Click Apply to create the detector.

🚧 Attention

Before clicking Apply, make sure you've renamed the new detector.

Available operators

Detection logic operators

You can use the following operators to create the detection logic statement:

Operator

Function

Example

EQUALS

Include only rows with attributes that are equal to the specified value.
Equivalent to the SQL = symbol.

To find only the creation of executable files, use:
target_file_extension EQUALS .exe

NOT EQUALS

Include only rows with attributes that are different from the specified value.
Equivalent to the SQL <> or != symbols.

To find the creation of all files but executable files, use:
target_file_extension NOT EQUALS .exe

LIKE

Include only rows with attributes that are similar to the specified value. Allows searching for patterns instead of full equality using the symbol %.
Equivalent to the SQL LIKE function.

Case-sensitive.

To find events where the target file path includes the term 'audit', use:
target_file_path LIKE %audit%

Note that this will not match 'Audit', as this is case-sensitive.

NOT LIKE

Include only rows with attributes that are not similar to the specified value.
Opposite of the LIKE statement.

Case-sensitive.

To find events where the target file path does not include the term 'audit', use:
target_file_path NOT LIKE %audit%

Note that while this will display results not like 'audit', it will display results like 'Audit', as this is case-sensitive.

LIKE (case insensitive)

Include only rows with attributes that are similar to the specified value, regardless of the letter case.

To find events where the target file path includes the term 'Audit', use:
target_file_path LIKE (case sensitive) %Audit%

NOT LIKE (case insensitive)

Include only rows with attributes that are not similar to the specified value, regardless of the letter case.

To find events where the target file path does not include the term 'Audit', use:
target_file_path NOT LIKE (case insensitive) %Audit%
Note that this will match 'audit', as this is case-insensitive.

IS ONE OF

Include only rows with attributes that are part of the specified list.

To find events where the target file path contains either '\ProgramData' or '\Users\Public' or '\Desktop', use:
target_file_path IS ONE OF %\ProgramData\%, %\Users\Public\%, %\Desktop\%

IS NOT ONE OF

Include only rows with attributes that are not part of the specified list.

To find events where the target file path does not contain either '\ProgramData\' or '\Users\Public\' or '\Desktop\', use:
target_file_path IS NOT ONE OF %\\ProgramData\%, %\\Users\\Public\%, %\\Desktop\%

IS EMPTY

Include only rows with attributes with an empty (null) value.

To find events in which there is no value for the destination port field, use:
destination_port IS EMPTY

IS NOT EMPTY

Include only rows with attributes with any value, which isn't empty (null).

To find events in which there is a value for the destination port field, use:
destination_port IS NOT EMPTY

LESS THAN

Include only rows with attributes that are lower than the specified number.
Available only for numeric value fields.

To return results with less than 5 events counted, use:
event_count LESS THAN 5

GREATER THAN

Include only rows with attributes that are greater than the specified number.
Available only for numeric value fields.

To return results with more than 5 events counted, use:
event_count MORE THAN 5

LESS THAN OR EQUAL

Include only rows with attributes that are lower than or equal to the specified number.
Available only for numeric value fields.

To return results with 5 or less events counted, use:
event_count LESS THAN OR EQUAL 5

GREATER THAN OR EQUAL

Include only rows with attributes that are greater than or equal to the specified number.
Available only for numeric value fields.

To return results with 5 or more events counted, use:
event_count GREATER THAN OR EQUAL 5

Statistics operators

When creating a Group by detector, you can use the following operators in the Statistics field:

Operator

Function

Example

MAX

From the grouped events, return the largest value for the selected field.

To find the highest Guard Duty Severity, use:
guardduty_severity MAX
This will go over the severity of each of the grouped events and will display only the highest value found.
If the available severity levels in the group are: 1, 3, 8, the displayed value will be: 8.

MIN

From the grouped events, return the lowest value for the selected field.

To find the lowest Guard Duty Severity, use:
guardduty_severity MIN
This will go over the severity of each of the grouped events and will display only the lowest value found.
If the available severity levels in the group are: 1, 3, 8, the displayed value will be: 1.

AGGREGATE

Return a comma-separated list of the values for the selected field from all grouped events.

To show a list of event types in the grouped events, use:
event_type AGGREGATE

Sample results:
Malicious, Malware, Attack

COUNT

Return a count of the values found for the selected field, excluding null values.

To show the number of the involved IP addresses in the grouped events, use:
user_IP COUNT
This will go over all of the values under the user_IP column and count 1 wherever a value exists. Then, the sum of this count will be displayed.

If the available IP addresses in the group are: 202.445.10.2
445.12.1.55
802.6.902.1
202.445.10.2
Then the result will be 4.

COUNT DISTINCT

Return a count of the unique values found for the selected field.

To show the number of unique IP addresses in the grouped events, use:
user_IP COUNT DISTINCT
This will go over all of the values under the user_IP column and count 1 for each unique IP. Then, the sum of this count will be displayed.

If the available IP addresses in the group are:
202.445.10.2
445.12.1.55
802.6.902.1
202.445.10.2
Then the result will be 3.