Detection on Alternate Targets¶

Detection & Response rules run against edr events by default, however, there are 7 other targets:

detection
deployment
artifact
artifact_event
schedule
audit
billing

This article is to give some ideas of what they're used for, and how they're used.

Target: detection¶

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.

In the detection target, the event: or events: specified refer to the name of the detection specified in the original detection's report action.

The detection target supports all of the same operators and actions as regular edr rules.

Example¶

# Detection
target: detection
op: and
rules:
- op: is
  path: cat
  value: virus-total-hit
- op: is
  path: routing/hostname
  value: ceo-laptop

# Response
- action: extension request
  extension name: ext-pagerduty
  extension action: run
  extension 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.

Target: deployment¶

Deployment events relate to sensors connecting to the cloud: enrollment, sensor_clone, sensor_over_quota, deleted_sensor.

Take the 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.

The deployment target supports all of the same operators and actions as regular edr rules.

Example¶

# 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 deployment event type, see Reference: Platform Events.

Target: artifact¶

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.

Example¶

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

Supported Operators¶

is
and
or
exists
contains
starts with
ends with
is greater than
is lower than
matches
string distance

Supported Resources¶

lookup and external resources are supported within rules just like the edr target.

Supported Actions¶

The only response action supported for the artifact target is the report action.

Special Parameters¶

artifact path: matches the start of the artifact's path string, e.g. /auth.log
artifact type: matches the artifact's type string, e.g. pcap, zeek, auth, wel
artifact source: matches the artifact's source string, e.g. hostname-123

Note: for duplicate Windows Event Log ingestions, the rule engine will use the log's EventRecordID to ensure a rule will not run more than once over the same record.

Target: artifact_event¶

For unparsed logs, it can be useful to use the ingest and export_complete lifecycle events from the artifact_event target to automate behaviors in response to artifacts.

For samples of ingest and export_complete, see Reference: Platform Events.

Example¶

# 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

Target: schedule¶

Schedule events are triggered automatically at various intervals per Organization or per Sensor, observable in rules via the schedule target.

For more information, see Reference: Schedule Events

Target: audit¶

Audit events are generated by the LimaCharlie platform and track changes and events from within the platform such as tasking, replays, hive changes, etc. These events can be viewed within the "Platform Logs" menu or by viewing events from the audit-logs sensor.

Event shape¶

Audit events are not wrapped in the usual routing / event envelope. The event your rule matches against is the audit record itself, so paths start at its top-level keys, with no event/ prefix:

Path	Contents
`etype`	The audit event type, e.g. `untag_sensor`. This is what `event:` / `events:` in the detect is matched against.
`oid`	The Organization the action happened in.
`time`	Event time, in milliseconds.
`ident`	The identity that performed the action.
`origin`	Where the action came from.
`msg`	A human-readable description.
`entity`	The object the action was performed on, e.g. `entity/sid` for sensor-scoped events.
`mtd`	Characteristics of the action, e.g. `mtd/tags` for tag changes.

For example, removing the no_ai tag from a sensor produces:

{
  "oid": "8cbe27f4-bfa1-4afb-ba19-138cd51389cd",
  "etype": "untag_sensor",
  "msg": "Removed tags [no_ai] from sensor.",
  "ident": "user@example.com",
  "origin": "user@example.com",
  "time": 1757592000000,
  "entity": {"sid": "f8a1d9c2-3b74-4e15-9a60-2d7c4e8b1f03"},
  "mtd": {"tags": ["no_ai"]}
}

Since mtd/tags is a list, matching a single tag in it requires the ? list wildcard. path: mtd/tags without it hands the operator the list itself, which no string operator ever matches:

target: audit
event: untag_sensor
op: is
path: mtd/tags/?
value: no_ai

Limitations¶

Audit events carry no sensor routing. Rules on this target compile normally either way, so the following fail at runtime rather than at save time:

op: is tagged and op: is platform read the sensor's tags and platform from routing. On an audit event they simply never match, silently.
action: add tag and action: remove tag require routing and error out on every match. Enough errors in a row will get the rule temporarily disabled.
{{ .routing.sid }} does not resolve. Use {{ .entity.sid }} instead, along with any other top-level key: {{ .etype }}, {{ .ident }}, {{ .mtd.tags }}, and so on.

action: task, action: report, action: output and action: extension request all work, and sensor-scoped actions resolve the sensor from entity/sid. To tag a sensor in response to an audit event, or to reach a sensor that may be offline, dispatch through an extension rather than acting directly:

target: audit
event: untag_sensor
op: is
path: mtd/tags/?
value: no_ai
respond:
  - action: extension request
    extension name: ext-reliable-tasking
    extension action: task
    extension request:
      sid: '{{ .entity.sid }}'
      ttl: 604800
      task: 'run --payload-name cleanup.cmd'

Target: billing¶

Billing events are generated by the LimaCharlie platform and are related to aspects of the platform such as quotas, thresholds, and other cost-associated events. For an example, see the Usage Alerts Extension documentation