Reference: Authoring signals

You can use signals for the continuous, real-time evaluation of process, network, registry, and file events on Windows endpoints. Signals are available as a feed from Tanium, or you can author your own signals that are specific to your environment.

With signals you can detect suspicious or interesting process behavior by combining multiple search expressions. A narrow search scope helps you minimize false-positive alerts.

How signals work

Signals use a specific language syntax to build search expressions for process-related events on the endpoint.

Like other intel, signals get validated when they are added to the Threat Response service to ensure proper structure. The signals are compiled, then sent and applied to the appropriate computer groups.

Unlike other types of intel, the event recorder continuously inspects each process creation event in real time and starts the engine when a match occurs, rather than performing periodic scans. Each event gets evaluated against any signal definitions. Whenever a signal condition is matched, an alert is generated. The engine regularly polls the endpoints with a saved question to gather alerts that are written to the Alerts page.

Signal syntax

The syntax of signals are built from the supported objects, properties, conditions, and the search values into search expressions. One or more expressions make up the signal definition. The objects reference process-related events. For example, a file object is an operation on a file by a process. A signal can have multiple expressions in a single definition, connected with AND or OR operands. Use parentheses to dictate precedence.

Write a signal expression in one of the following formats:

  • object.propertyconditionvalue
  • object.propertycondition'value with spaces'

Each object is a type of process event and has one or more properties that narrow the scope of the event. The condition specifies how the object and property relate to the value provided. Not all conditions are supported with all object properties.

For full details about the supported objects, properties, and conditions, see the engine documentation.

The following sample expressions demonstrate combined expressions, precedence, and escaped special characters:

  • process.command_line contains 'evil' AND process.path starts with 'c:\\windows'
  • (file.path starts with 'c:\\temp' OR file.path ends with '.evil.tmp') AND process.path contains cmd.exe

Signals are not case-sensitive.

Signal use cases

Signals are designed to identify suspicious or malicious process activity in real time, and therefore are not intended to alert on large lists of file properties, such as hashes or file names. These use cases are better solved with background intel scanning or reputation alerting. For example, alerting on excel.exe is not very useful and creates a lot of unnecessary activity with little value.

However, a security operations center might want an alert if excel.exe launches Powershell.exe. and the parent process is ‘excel.exe’. For example,

process.path ends with ‘powershell.exe’ AND process.parent_path ends with ‘excel.exe’

Use signals to detect activity that, while not malicious, is unwanted within a specific group of computers. For example, the use of dsquery.exe or dsget.exe to administer Active Directory could be an unwanted activity. If your normal process is to use custom Powershell scripts, use of these other processes might signify that an intruder is trying to make modifications. If firewall settings are inherited through GPO settings, the use of netsh.exe on an endpoint might need to be understood.

Use signals to ensure that some activity has happened. For example, receiving alerts from servers when a critical application has launched following a reboot might be a signal to consider. Alerting that the w3wp.exe process has launched after an IIS server has rebooted might be something a Web Content team would want to see.

Signals must have a narrow scope, specific targets, and a clear intended use.

Testing signals

After you create a signal, test the signal in a lab before using it in a production environment. Verify that the signal is applied to the correct endpoints and returns the results that you expect.

  1. Create a signal. See Adding intel for more information.
  2. (Optional) If you want to evaluate a signal, you can run a quick scan for the signal and modify the signal as needed.
  3. Apply the signal to an intel configuration for a test computer group that has Threat Response tools installed.
  4. On one or more endpoints within the configured computer group, trigger the conditions of the signal.
  5. Confirm that the alert has been received by the Threat Response workbench.

Iterate on this process until you are satisfied with the results.

Last updated: 2/15/2019 10:35 AM | Feedback