Skip to main content
Solved

Runtime errors are seen while testing a rule which uses threat intel matches

  • February 20, 2026
  • 4 replies
  • 102 views

fazilfa
Forum|alt.badge.img+1

Hi Team,

I am getting runtime errors when testing a rule which uses threat intel matches.

My first rule is checking the principal or target ip against the threat intel.
 

events:

        (

            $network.metadata.event_type = "NETWORK_CONNECTION" or

            $network.metadata.event_type = "NETWORK_HTTP"

        )

        $network.security_result.action = "ALLOW"

       

        $network.principal.ip !=  ""

        $network.principal.port != 0

        $network.target.ip != ""

        $network.target.port != 0

 

        // Intel Match

        (

            $intel_feed.graph.metadata.vendor_name != "" or

            $intel_feed.graph.metadata.product_name != ""

        )

        $intel_feed.graph.metadata.entity_type = "IP_ADDRESS"

        (

            $intel_feed.graph.entity.ip = $network.principal.ip or

            $intel_feed.graph.entity.ip = $network.target.ip

        )

        $intel_feed.graph.metadata.threat.category_details = /exploit_ip/ nocase

 

        // Filtering due to runtime errors and noise

        $intel_feed.graph.metadata.threat.confidence = "HIGH_CONFIDENCE"    

        $ioc = $intel_feed.graph.entity.ip

       

    match:

       $ioc over 4h

 

    outcome:

        $user = array_distinct($network.principal.user.userid)

        $host = array_distinct($network.principal.hostname)

        $event_time = array_distinct(timestamp.get_timestamp($network.metadata.event_timestamp.seconds,"%Y-%m-%d %H:%M:%S %Z","GMT"))

        $first_seen = timestamp.get_timestamp(min($network.metadata.event_timestamp.seconds),"%Y-%m-%d %H:%M:%S %Z","GMT")

        $last_seen = timestamp.get_timestamp(max($network.metadata.event_timestamp.seconds),"%Y-%m-%d %H:%M:%S %Z","GMT")

        $event_count = count_distinct($network.metadata.id)

        $principal_ip = array_distinct($network.principal.ip)

        $target_ip = array_distinct($network.target.ip)

        $principal_port = array_distinct($network.principal.port)

        $target_port = array_distinct($network.target.port)

        $log_source = array_distinct($network.metadata.log_type)

        $intel_vendor = array_distinct($intel_feed.graph.metadata.vendor_name)

        $category = array_distinct($intel_feed.graph.metadata.threat.category_details)

        $risk_score = max(

        if($network.security_result.severity = "CRITICAL", 100) +

        if($network.security_result.severity = "HIGH", 75) +

        if($network.security_result.severity = "MEDIUM", 50) +

        if($network.security_result.severity = "LOW", 25))

 

    condition:

       $network and $intel_feed

error message:
 


 



My 2nd rule is just checking for inbound connection from threat intel IP’s and that is working fine. i am getting almost a 100 detections for 5 days time period


 

events:

        (

            $network.metadata.event_type = "NETWORK_CONNECTION" or

            $network.metadata.event_type = "NETWORK_HTTP"

        )

        $network.principal.ip !=  ""

        $network.principal.port != 0

        $network.target.ip != ""

        $network.target.port != 0

        // Intel Match

        (

            $intel_feed.graph.metadata.vendor_name != "" or

            $intel_feed.graph.metadata.product_name != ""

        )

        $intel_feed.graph.metadata.entity_type = "IP_ADDRESS"

        (

            $intel_feed.graph.entity.ip = $network.principal.ip or

            $intel_feed.graph.entity.ip = $network.target.ip

        )

        $network.principal.ip in %Updated_IP_Ranges.cidr and

        not ($network.target.ip in %Updated_IP_Ranges.cidr) and

        (

            $intel_feed.graph.metadata.threat.category_details = /fraud_ip|proxy_ip|compromised_ip|c2_ip/ nocase or

            $intel_feed.graph.metadata.threat.severity_details = /very-high/ nocase

        )

 

        // Filtering due to runtime errors and noise

        $intel_feed.graph.metadata.threat.confidence = "HIGH_CONFIDENCE"

        $network.security_result.action = "ALLOW"

 

        $src_ip = $network.principal.ip

        $ioc = $intel_feed.graph.entity.ip

       

    match:

       $ioc, $src_ip over 2h

 

    outcome:

        $user = array_distinct($network.principal.user.userid)

        $host = array_distinct($network.principal.hostname)

        $event_time = array_distinct(timestamp.get_timestamp($network.metadata.event_timestamp.seconds,"%Y-%m-%d %H:%M:%S %Z","GMT"))

        $first_seen = timestamp.get_timestamp(min($network.metadata.event_timestamp.seconds),"%Y-%m-%d %H:%M:%S %Z","GMT")

        $last_seen = timestamp.get_timestamp(max($network.metadata.event_timestamp.seconds),"%Y-%m-%d %H:%M:%S %Z","GMT")

        $event_count = count_distinct($network.metadata.id)

        $principal_ip = array_distinct($network.principal.ip)

        $target_ip = array_distinct($network.target.ip)

        $principal_port = array_distinct($network.principal.port)

        $target_port = array_distinct($network.target.port)

        $log_source = array_distinct($network.metadata.log_type)

        $intel_vendor = array_distinct($intel_feed.graph.metadata.vendor_name)

        $category = array_distinct($intel_feed.graph.metadata.threat.category_details)

        $risk_score = max(

        if($network.security_result.severity = "CRITICAL", 100) +

        if($network.security_result.severity = "HIGH", 75) +

        if($network.security_result.severity = "MEDIUM", 50) +

        if($network.security_result.severity = "LOW", 25))

 

    condition:

       $network and $intel_feed


Need some guidelines are best practice to avoid the runtime error
 

Best answer by jstoner

One additional line in the Intel Match section you could add that may improve performance is to add the following line:

$intel_feed.graph.metadata.source_type = "GLOBAL_CONTEXT" or $intel_feed.graph.metadata.source_type = "ENTITY_CONTEXT"

 

Global Context is the threat intel we provide. Entity Context would be threat intel you provide, ie MISP, STIX, etc. This eliminates any derived context data which is prevalence data. Some of the other filters like category details and threat confidence would as well but that source type much like entity type is a good way to remove large chunks of the entity graph from consideration. Not sure if that will solve this problem but something i would mention.

 

I also notice the join you have is ip = principal.ip or target.ip and I am wondering if that is causing more overhead.

 

You may want to consider using a data table or functions like this
net.ip_in_range_cidr($network.principal.ip, "10.0.0.0/8") or whatever non-routable internal netblocks are to reduce the number of network connection and network http events you have.

 

The goal with these suggestions is to make both sides of the join as compact as possible so that when you perform the join, it is as efficient as possible.

 

4 replies

Asura
Forum|alt.badge.img+3
  • February 20, 2026

Hello,

 

You can probably try to put at the top of your query the “restrictive” condition of each event, and then the join.

For instance:

        $intel_feed.graph.metadata.entity_type = "IP_ADDRESS"

$intel_feed.graph.metadata.threat.confidence = "HIGH_CONFIDENCE"

(

$intel_feed.graph.metadata.threat.category_details = /fraud_ip|proxy_ip|compromised_ip|c2_ip/ nocase or

$intel_feed.graph.metadata.threat.severity_details = /very-high/ nocase

)

(

$intel_feed.graph.metadata.vendor_name != "" or

$intel_feed.graph.metadata.product_name != ""

)

 

Same thing for the $network event.

 

If possible, you can additionally try to filter on a specific network log type(s) rather than going through all your log sources (which will definitely be an issue if you have a huge volume of log).

Same for the intel_feed (if you have more than one source).

 

Hopefully this should reduce the runtime of your query.


jstoner
Community Manager
Forum|alt.badge.img+23
  • Community Manager
  • Answer
  • February 23, 2026

One additional line in the Intel Match section you could add that may improve performance is to add the following line:

$intel_feed.graph.metadata.source_type = "GLOBAL_CONTEXT" or $intel_feed.graph.metadata.source_type = "ENTITY_CONTEXT"

 

Global Context is the threat intel we provide. Entity Context would be threat intel you provide, ie MISP, STIX, etc. This eliminates any derived context data which is prevalence data. Some of the other filters like category details and threat confidence would as well but that source type much like entity type is a good way to remove large chunks of the entity graph from consideration. Not sure if that will solve this problem but something i would mention.

 

I also notice the join you have is ip = principal.ip or target.ip and I am wondering if that is causing more overhead.

 

You may want to consider using a data table or functions like this
net.ip_in_range_cidr($network.principal.ip, "10.0.0.0/8") or whatever non-routable internal netblocks are to reduce the number of network connection and network http events you have.

 

The goal with these suggestions is to make both sides of the join as compact as possible so that when you perform the join, it is as efficient as possible.

 


NASEEF
Forum|alt.badge.img+8
  • Silver 2
  • March 13, 2026

hello jstoner
could you please help me with below

If I run the search below, I was expecting to see all malicious user emails reported by GTI. However, I’m not seeing any results, even when querying data from the past year.

I am able to retrieve some malicious IPs when using entity_type = "IP_ADDRESS", but the count is relatively low (around 50). I was expecting a significantly larger number of results.

Has anyone experienced something similar or can confirm whether this behavior is


could you please help me here as i am looking to match for email artifacts with gcti like ip , domain , sender email , hash etc

 


NASEEF
Forum|alt.badge.img+8
  • Silver 2
  • March 13, 2026

if i need to match all user email from proofpoint on demand with gcti reported malicious emails  is this the correct way