Detection on Alternate Targets
Detection & Response rules run against
edr events by default, however, there are 4 other targets:
This article is to give some ideas of what they're used for, and how they're used.
You can run rules on detections generated by other rules. This allows you to further filter existing detections
and change add a response behavior to certain special cases.
detection target, the
events: specified refer to the
name of the detection specified in the
detection target supports all of the same operators and actions as regular
# Detection target: detection op: and rules: - op: is path: cat value: virus-total-hit - op: is path: routing/hostname value: ceo-laptop # Response - action: service request name: pagerduty request: group: lc-alerts severity: critical component: vip-alert summary: Alert on a VIP endpoint. source: limacharlie.io class: dr-rules
This rule takes a pre-existing detection report named
virus-total-hit and sends it to PagerDuty if it occurs on a specific hostname.
Deployment events relate to sensors connecting to the cloud:
sensor_clone event as an example. This event can happen when a sensor is installed in a VM image, leading to duplicate sensor IDs connecting to the cloud. When this is detected we can use this event to automate behavior to de-duplicate the sensor.
deployment target supports all of the same operators and actions as regular
# Detection target: deployment event: sensor_clone op: is windows # Response - action: task command: file_del %windir%\system32\hcp.dat - action: task command: file_del %windir%\system32\hcp_hbs.dat - action: task command: file_del %windir%\system32\hcp_conf.dat - action: task command: restart
This rule de-duplicates sensors on Windows by deleting
.dat files specific to the Windows installation and then issuing a
restart sensor command.
For samples of each
deploymentevent type, see Reference: Events.
Parsed artifacts can be run through the rule engine as if they were regular
edr events, but there are some key differences. Namely, they support a subset of operators and actions, while adding some special parameters.
This rule will target parsed
/var/log/auth.log entries to see if there are are auth failures.
# Detection target: artifact artifact type: txt artifact path: /var/log/auth.log op: matches re: .*(authentication failure|Failed password).* path: /text case sensitive: false # Response - action: report name: Failed Auth
is greater than
is lower than
external resources are supported within rules just like the
The only response action supported for the
artifact target is the
artifact path: matches the start of the artifact's
artifact type: matches the artifact's
artifact source: matches the artifact's
Note: for duplicate Windows Event Log ingestions, the rule engine will use the log's
EventRecordIDto ensure a rule will not run more than once over the same record.
For unparsed logs, it can be useful to use the
export_complete lifecycle events from the
artifact_event target to automate behaviors in response to artifacts.
For samples of
export_complete, see Reference: Events.
# Detection target: artifact_event event: export_complete op: starts with path: routing/log_type value: pcap case sensitive: false # Response - action: report name: PCAP Artifact ready to Download