Supported Keys and Operators



This article serves as a quick reference for the supported operators and keys that Threat Stack uses for event queries, alerts, and rule creation. Learn more about how Threat Stack uses Linux syscalls for events in the Event Based Rules Syntax article.

Supported Keys

Threat Stack supports the following keys, additionally you can review the Linux Syscall Reference.

Key Type Value Description Value Description Present in Event Types
event_type string One of the following values: audit, file, host, login, or cloudtrail all
exe string The executable in the event, example exe=/bin/exe audit, file (some)
pid integer Process Id audit, file (some), host (some)
arguments string Arguments string, examples argv and "ls -al /my/path" audit, file (some)
src_ip string IP address string, example "" network
dst_ip string IP address string, example "" network
cwd string current working directory, example "/my/blah/path" all
ppid integer parent process ID audit, file (some), host (some)
timestamp integer epoch timestamp in milliseconds all
domain string domain name string network, audit (some)
ip string IP address string alias, src_ip or destination ip, example audit (some), network
src_port integer source port network
dst_port integer dest port network
port integer port, alias for src_port or dst_port network, audit (some)
protocol string network protocol string, "tcp", "icmp", "udp" network
group string user group, example "wheel" audit, host (some), file (some)
user string user, example "root" audit, host (some), file (some)
connection.addr string IP address string, src_ip or dst_ip, example audit
connection.src_addr string Source IP address, aliased by src_ip  
connection.port integer tcp or udp port connected to by a network process audit
connection.src._port integer Source port, aliased by src_port  
command string command or exe run by a user or process. similar to key=exe but does not require full path to the exe audit
type string type of syscall, e.g start, connect, accept, bind  
syscall string syscall name, e.g. start, connect, accept, bind  
sudoer string Displays all sudo events for a user. e.g. sudoer = "sam"  

In the Threat Stack application we have a quick reference called the Search Language Tutorial that you can access from the Events page.


Supported Operators

As you review the supported operators remember that parenthesis can be used to group expressions. For example, arguments like "bob" and pid > 0) or exe = "/bin/ls".

Operator Example
= - matches 'equals' exe = "/bin/ls"
> - matches 'greater than' pid > 0
< - matches 'less than' pid < 1000
>= - matches 'greater than or equal' pid >= 1000
<= - matches 'less than or equal' pid <= 1000
like - match a substring contained within a value. The blob * should not be used. arguments like "bob"
and - boolean operator that joins two filters in an 'and' expression arguments like "bob" and exe = "/bin/ls"
or - boolean operator that joins two filters in an 'or' expression arguments like "bob" or exe = "/bin/ls"
starts_with - match a substring contained within a value. This should be used with an IP range in lieu of a wildcard * or CIDR notation ip starts_with "10.13." which is equal to 10.13.* or Note: the trailing . is needed because without this "10.13" would also match 10.13x.
Was this article helpful?
1 out of 2 found this helpful
Have more questions? Submit a request


  • could you give an example using the "in" operator?

  • Kesten, We do not support "in" operator yet.  It is on the short term (next quarter) roadmap 

  • I must be reading this wrong. Is it really the case that event name is NOT a supported key for filters? So, for alert:

    CloudTrail Activity (Delete API Call): {{eventName}} by {{user}}

    You can't suppress based on eventName? Please tell me I'm missing something.

  • JB, you can suppress based on eventName for cloudtrail events.

  • Ok, thanks. It isn't noted above with the other valid keys, and doesn't work as expected when I try to apply it. At the very least, it looks like it doesn't support the same "like" syntax as other keys.

    I'll gather details and open a support ticket.

  • are there plans to be able to formulate rules based on tags?

  • Larry, yes in the pipe .

  • Still running into the same issues as a year ago - the "like" syntax does not seem to work _at all_. I can use a filter with 'arguments = "blah blah" ' and it works, but even changing the syntax to 'arguments like "blah blah"' causes it to fail. Cannot get "like" to return success for any filter, ever, at least in the arguments field. Is anyone having success with this? If so, I would greatly appreciate an example, as I suspect there's an element to the syntax that I'm missing.

Article is closed for comments.