Yes, the rule host_with_recurring_malware_infection accurately addresses the "recurring malware on host" use case. Here's a detailed breakdown:

Rule Logic:

1. 
   

   Event Filtering: The events section filters for specific events:

   
   
   
   
   • $event.metadata.event_type = "PROCESS_LAUNCH": Focuses on process launch events, indicating new processes being created.
   
   
   • $event.metadata.vendor_name = /Cylance/ nocase and $event.metadata.product_name = /PROTECT/ nocase: Specifically targets events originating from Cylance Protect.
   
   
   • $event.metadata.product_event_type = /Threat/ nocase: Further narrows down to events classified as "Threat" by Cylance Protect.
   
   
   • $event.security_result.summary != /(Waived|Cleared)/ nocase: Excludes events where the threat was waived or cleared, indicating potential false positives or handled threats.
   
   
   • $file_hash = strings.coalesce($event.target.process.file.md5, $event.target.process.file.sha256): Extracts the file hash of the launched process, prioritizing MD5 and falling back to SHA256 if MD5 is missing. This is crucial for identifying recurring malware based on its hash.
   
   
   • $file_name = $event.target.process.file.full_path: Extracts the full path of the launched process's executable.
   
   
   • $targeted_host = strings.to_upper(strings.coalesce($event.target.hostname, $event.principal.hostname)): Extracts the hostname, prioritizing the target hostname and falling back to the principal hostname. It converts the hostname to uppercase for consistent matching.
   
   
   
   


2. 
   

   Time Window and Aggregation:

   
   
   
   
   • $targeted_host over 60m: The match section establishes a 60-minute window for analysis. It groups events based on the $targeted_host, meaning it looks for multiple events with the same hostname within that hour.
   
   
   
   


3. 
   

   Trigger Condition:

   
   
   
   
   • #event > 1: The condition section specifies that the rule should trigger only if there are more than one distinct event (#event > 1) within the defined time window and matching the filtering criteria.
   
   
   
   

How it Addresses Recurring Malware:

The rule effectively detects recurring malware by combining:

• Malware Hash Identification: It extracts the file hash ($file_hash) of the launched process, which is a strong identifier for specific malware.


• Time Window Analysis: The 60-minute window and #event > 1 condition ensure that multiple occurrences of the same malware (identified by its hash) are detected on the same host within a relatively short timeframe. This suggests persistent or recurring malicious activity.

Applying to Cylance Protect Logs:

The rule is tailored to work with Cylance Protect logs by specifically filtering for events from this product and using fields relevant to Cylance's event structure, such as product_event_type and security_result.summary.

Output:

The rule outputs a risk_score of 40, indicating a low severity level. However, the more crucial output is the detection itself, which highlights the $targeted_host, $file_hash, and $file_name associated with the recurring malware. This information helps analysts identify the affected host, the specific malware involved, and the location of the malicious executable, enabling further investigation and remediation efforts.

Based on its logic and alignment with the given Cylance Protect logs, the host_with_recurring_malware_infection rule accurately and effectively addresses the "recurring malware on host" use case. It filters for relevant security events, extracts key malware identifiers, performs time-based analysis to identify recurring patterns, and generates meaningful alerts for investigation.

More Specific Threat Filtering:

• Expand security_result.summary Exclusions: The current rule only excludes summaries containing "Waived" or "Cleared". Consider expanding this to exclude other benign summaries like "Clean", "No Action Taken", or product-specific messages indicating non-malicious detections.


• Leverage security_result.category: Cylance Protect categorizes threats (e.g., SOFTWARE_MALICIOUS, EXPLOIT). Utilize this field to filter for categories relevant to recurring malware. For instance, focus on SOFTWARE_MALICIOUS and SOFTWARE_SUSPICIOUS categories and exclude others.


• Check Threat Name (if available): Some Cylance logs include a threat_name field. If present, use it to filter out known good or low-risk threats (like "PUP - Generic").

Enhance Output:

• Include More Context: Add more fields to the outcome, such as:
  
  
  
  • $principal_user_id: The user associated with the process.
  
  
  • $principal_process_command_line: The full command line used to launch the process.
  
  
  • $security_result.category: The category of the threat.
  
  
  • $security_result.threat_name: The name of the detected threat.
  
  
  
  


• Prioritize Outcome Variables: Use distinct aggregations (e.g., array_distinct) for outcome variables to avoid redundant data.

@raybrian  : No i believe this alert captures more than 1 malware on the same host instead of recurring malware , as in case of recurring malware i believe one the match section should contain hash and host .second there needs to be mechanism where it knows that this malware has triggered previously which i dont see here

I'm not familiar with what the cylance data set looks like but looking at the rule, i'd say that you will need to do something more than just count the events. I'm thinking like getting a security_results.rule_id or similar to accompany the targeted host. The other thing that would be helpful to understand is what are you defining as a recurring malware? How often should it occur for it to be considered recurring?

@jstoner : 
The other thing that would be helpful to understand is what are you defining as a recurring malware? 
Same malicious file hash on the same machine in a span of 1 week .
Can you give a possible query of how you think it should like you can replace cylance with any other edr and provide the query ?

The bigger challenge that I see at the moment is that because rules have a match window of 48 hours at the moment that this will be a challenge. A search might be a method to see these rows in the near term. As we go into 2025, we have a number of initiatives in flight that should make this kind of use case more readily achievable in a few different ways.

Here is a search using suricata as a for instance where I can get my system and the underlying ruleid and rulename that would allow you to see this via search...

metadata.event_type = "SCAN_NETWORK"
metadata.product_name = "Suricata"
match:
 principal.hostname, security_result.rule_id, security_result.rule_name
outcome:
 $instance = count(metadata.event_type)
order:
 $instance desc