Reference: Authoring Signals

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

For Tanium Cloud customers, Tanium collects and uses metadata to continually improve the effectiveness of Signals.

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 recorder continuously inspects each process creation event in real time and Threat Response reports a finding when a match occurs, rather than performing periodic scans. Each event gets evaluated against any Signal definitions. Whenever a Signal condition is matched, a finding is generated. Threat Response 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 operators. Use parentheses to dictate precedence.

Write Signal expression in one of the following formats:

object.property condition value
object.property condition '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.

You cannot have more than 55 unique terms in a Signal.

Property values can be an integer, a simple alphanumeric string, or they can be more complex and include other characters, such as spaces, backslashes, and hex-encoded values. For searches with non-alphanumeric values or spaces, enclose the value in single quotes. To escape special characters within the single quotes, the following sequences are supported:

\r For carriage return
\n For newline
\t For tab
\\ For the backslash itself
\' For a single quote within the quotes
\x To allow a single-byte hex-encoded sequence. For example \x20 would translate to a single space.

The hex-encoding is required to handle UTF-8 characters outside of the single-byte character set. Any UTF-8 character can be added via the hex-encoding, if needed.

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

Windows: process.command_line contains 'evil' AND process.path starts with 'c:\\windows'
Linux: process.command_line contains 'evil' AND process.path starts with '/usr/sbin/'
Windows: (file.path starts with 'c:\\temp' OR file.path ends with '.evil.tmp') AND process.path contains cmd.exe
Linux: (file.path starts with '/var/tmp/' OR file.path ends with 'evil.gz') AND process.path ends with 'sh'

You can use modifiers in parenthetical groupings to change the behavior of all items within that grouping. A modifier is an identifier that precedes an open parenthesis. One example is for event grouping:

group(file.operation is 'create' and file.path contains 'foo')

Without the group this would appear as a boolean grouping prioritized in operation by the ()'s and could be satisfied with two different events, however in this case the group modifier is applied thus changing the matching behavior so that both conditions must match a single event.

Event groups do not support terms that contain process events.

An event group modifier is a modifier with the name group and indicates that you intend to match all conditions in the group against a single event. For example, to ensure that matches happen against the same file event, you should group those events. You can then include multiple groups to achieve matches against different events in time. One example would be:

group(file.operation is 'create' and file.path contains 'foo') and group(file.operation is 'delete' and file.path contains 'bar')

This signal would only match if at some point a process creates a file containing foo and at a different time deletes a file with name containing bar, but will not match if the created file contained bar and the deleted file contained foo.

An event group modifier can only apply to objects of the same type. So, you may not mix file and registry events in the same group, though you may mix groups containing those into the same expression as:

group(registry.key_path contains 'alpha' and registry.value_name contains 'a') and group(file.path.contains 'beta' and file.path ends with '.b')

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’.

A comparable example for Linux could be: process.path ends with 'sshd' AND process.parent_path ends with 'systemd'.

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.

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

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