Using Search

You can search for virtually any attribute of attacks, incidents, and vulnerabilities.

Wallarm is equipped with a query language similar to human language, which makes submitting queries intuitive.
Queries can be refined using special modifiers, which are described below.

When values of different parameters are specified, the results will meet all those conditions.
When different values for the same parameter are specified, the results will meet any of those conditions.

To search within a single application, specify in the search string pool:<application name>,
where <application name> is set on the Applications tab in the Settings section.

vulns 01/01/2019-01/10/2019: to search for vulnerabilities within a certain period of time.

xss 01/14/2019: to search for all vulnerabilities, suspicions, attacks, and incidents of cross-site scripting on 14 January 2019.

p:xss 01/14/2019: to search for all vulnerabilities, suspicions, attacks, and incidents of all types within the xss HTTP request parameter (i.e. http://localhost/?xss=attack-here) as of 14 January 2019.

attacks 2-9/2018: to search for all attacks from February to September 2018.

rce /catalog/import.php: to search for all RCE attacks, incidents, and vulnerabilities on /catalog/import.php path since yesterday.

In addition to using the search string, you can retrieve data using filters (see Using Filters).

Parameters you enter into the search string will automatically duplicate in the filters and vice versa.

Save as a filter

Any search query or combination of filters can be saved using the Save as template button and quickly accessed later with the Searches drop-down list.

info: to search for attacks/vulnerabilities of information disclosure.

An attack or vulnerability name can be specified in both uppercase and lowercase letters: SQLI, sqli, and SQLi are equally correct.

Search by the Attack Target or the Vulnerability Target

Specify in the search string:

client: to search for client data attacks/vulnerabilities.

database: to search for database attacks/vulnerabilities.

server: to search for app server attacks/vulnerabilities.

Search by Risk Level

Specify the risk level in the search string:

low: low risk level.

medium: medium risk level.

high: high risk level.

Search by Vulnerability Identifier

To search for a certain vulnerability, specify its identifier. It can be specified in two ways:

either fully: WLRM-ABCD-X0123

or in abbreviated form: X0123

Search by Vulnerability Status

Specify vulnerability status in the search string. Vulnerability can have one of the three statuses:

open: currently relevant vulnerability;

closed: fixed vulnerability;

falsepositive: vulnerability marked as false.

Search by Event Time

Specify time range in the search string. If the time interval is not specified, the search is conducted within the events occurred during the last 24 hours. Use the following data format: MM/DD/YYYY (for example, 01/14/2014). If year is not specified, the current year is used. Thus, 01/14 is the same as 01/14/2019.

Search by IP Address or Address Range

It is possible to search by the total number of IP addresses that are related to an incident (only for attacks and incidents).

Examples:

xss ip:100+ will search for all incidents and attacks of the cross-site scripting type and will not return anything if less than 100 different IP addresses were registered as the attackers with this attack type.

xss p:id ip:100+ will search for all attacks and incidents of XSS type related to the id parameter (?id=aaa) and will display a result only if the number of different IP addresses exceeds 100.

Search by Server Response Status

To search by server response status, specify statuscode: prefix.

Response status can be specified as:

a number from 100 to 999.

«N–M» range, where N and M are figures from 100 to 999.

«N+» and «N-» ranges, where N is a number from 100 to 999.

Search by Server Response Size

To search by the server response size, use the s: or size: prefix.

You can search for any integer value. Figures above 999 can be specified without a prefix. The «N–M», «N+» and «N-» ranges can be specified, where figures above 999 can also be specified without a prefix.

Search by HTTP Request Method

To search by HTTP request method, specify the method: prefix.

To search for GET, POST, PUT, DELETE, OPTIONS: if upper-case is used, then the search string can be specified without a prefix. For all other values, a prefix should be specified.

Search by Domain

To search by domain, use the d: or domain: prefix.

Any string, that may be a domain of the second or a higher level can be specified without a prefix. Any string can be specified with a prefix.

You may use masks within a domain. The symbol * replaces any number of characters; the symbol ? replaces any single character.

Search by Path

To search by path, use the u: or url: prefix.

Strings that start with / are processed without a prefix. Any string can be specified with a prefix.

Search by Parameter

To search by parameter, use the p:, param:, or parameter: prefix and also the = suffix.

For example, if you need to find attacks aimed at the xss parameter but not at XSS-attacks (for instance, SQL-injection attack having xss in the GET-parameter), specify attacks p:xss in the search string.

A string that does not start with / and ends with = is considered to be a parameter (wherein the ending = character is not included in the value). Any string can be specified with a prefix.

Search for Anomalies in Attacks

To search for anomalies in attacks, use the a: or anomaly: prefix.

To refine an anomaly search, use the following parameters:

size

statuscode

time

stamps

impression

vector

Example:

attacks sqli a:size will search for all SQL-injection attacks, that have response size anomalies in their requests.

Search by Request Identifier

To search for attacks and incidents by request identifier, specify the request_id prefix.
The request_id parameter has the following value form: a79199bcea606040cc79f913325401fb. To make it easier to read, in the examples below this parameter has been replaced by the placeholder abbreviation <requestId>.

Examples:

attacks incidents request_id:<requestId>: to search for an attack or an incident with the request_id equal to <requestId>.

attacks incidents !request_id:<requestId>: to search for attacks and incidents with the request_id not equal to <requestId>.

attacks incidents request_id: to search for attacks and incidents with any request_id.

attacks incidents !request_id: to search for attacks and incidents without any request_id.