Best practices for configuring the Active threat verification feature¶
One method Wallarm uses to detect vulnerabilities is Active threat verification which lets you turn attackers into penetration testers and discover possible security issues from their activity as they probe your apps/APIs for vulnerabilities. This module finds possible vulnerabilities by probing application endpoints using real attack data from the traffic. For the module to operate securely, please learn its configuration best practices from this article.
By default Active threat verification is disabled. To enable the module, know how to control the Attack rechecker.
Active threat verification if hits are grouped by IP
If an attack is hits grouped by originating IPs, active verification of this attack is unavailable.
How the Active threat verification feature works¶
Based on the initial detected attacks, the Active threat verification module creates a lot of new test requests with different payloads attacking the same endpoint. This mechanism allows Wallarm to detect vulnerabilities that could be potentially exploited during attacks. The process of active threat verification will either confirm that the application is not vulnerable to the specific attack vectors or find actual application security issues.
The Active threat verification process uses the following logic to check the protected application for possible Web and API security vulnerabilities:
For every group of malicious request (every attack) detected by a Wallarm filtering node and uploaded to the connected Wallarm Cloud, the system analyzes which specific endpoint (URL, request string parameter, JSON attribute, XML field, etc) was attacked and which specific kind of vulnerability (SQLi, RCE, XSS, etc) the attacker was trying to exploit. For example, let's take a look at the following malicious GET request:
https://example.com/login?token=IyEvYmluL3NoCg&user=UNION SELECT username, password
From the request the system will learn the following details:
- The attacked URL is
- The type of used attack is SQLi (according to the
UNION SELECT username, passwordpayload)
- The attacked query string parameter is
- Additional piece of information provided in the request is the request string parameter
token=IyEvYmluL3NoCg(it is probably used by the application to authenticate the user)
- The attacked URL is
Using the collected information the Active threat verification module will create a list of about 100-150 test requests to the originally targeted endpoint but with different types of malicious payloads for the same type of attack (like SQLi). For example:
https://example.com/login?token=IyEvYmluL3NoCg&user=1')+WAITFOR+DELAY+'0 indexpt'+AND+('wlrm'='wlrm https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+SLEEP(10)--+wlrm https://example.com/login?token=IyEvYmluL3NoCg&user=1);SELECT+PG_SLEEP(10)-- https://example.com/login?token=IyEvYmluL3NoCg&user=1'+OR+SLEEP(10)+AND+'wlrm'='wlrm https://example.com/login?token=IyEvYmluL3NoCg&user=1+AND+1=(SELECT+1+FROM+PG_SLEEP(10)) https://example.com/login?token=IyEvYmluL3NoCg&user=%23'%23\x22%0a-sleep(10)%23 https://example.com/login?token=IyEvYmluL3NoCg&user=1';+WAITFOR+DELAY+'0code:10'-- https://example.com/login?token=IyEvYmluL3NoCg&user=1%27%29+OR+SLEEP%280%29+AND+%28%27wlrm%27%3D%27wlrm https://example.com/login?token=IyEvYmluL3NoCg&user=SLEEP(10)/*'XOR(SLEEP(10))OR'|\x22XOR(SLEEP(10))OR\x22*/
Malicious payloads do not harm your resources
Malicious payloads of generated requests do not include real malicious syntax, they are intended just to imitate the attack principle. As a result, they do not harm your resources.
The Active threat verification module will send generated test requests to the application bypassing the Wallarm protection (using the allowlisting feature) and verify that the application at the specific endpoint is not vulnerable to the specific attack type. If the module suspects that the application has an actual security vulnerability, it will create an event with type incident.
User-AgentHTTPS header value in the requests
User-AgentHTTP header in the Active threat verification module requests will have the value
Wallarm Threat-Verification (v1.x).
Potential risks from the Attack rechecker activity¶
In rare cases when a legitimate request is detected by Wallarm as an attack, the request will be replayed by Attack rechecker. If the request is not idempotent (for example, an authenticated request creating a new object in the application), then the Attack rechecker requests may create many new unwanted objects in the user account or perform other unexpected operations.
To minimize the risk of the described situation, Attack rechecker will automatically strip the following HTTP headers from the replayed requests:
In cases when the application uses a non-standard authentication method or does not require authenticating the requests, Attack rechecker may replay any request from the traffic and harm the system. For example: repeat 100 and more money transactions or orders. To minimize the risk of the described situation, it is recommended to use testing or staging environments for attack replaying and mask non-standard request authentication parameters.
Attack rechecker configuration best practices¶
Configure proper data masking rules¶
If your application uses non-standard types of authentication (for example, request string token or custom HTTP request header or JSON attribute in POST body), then you should configure a proper data masking rule to prevent the filtering nodes from sending the information to the Wallarm Cloud. In this case, the replayed Attack rechecker requests will be not authorized by the application and not cause any harm to the system.
Know how to control the Attack rechecker¶
The global on/off switch of the Attack rechecker module is located in Wallarm Console → Vulnerabilities. By default this module is disabled.
Configure proper white-listing rules for scanner IP addresses¶
The configuration is required for the Attack rechecker module to reach the tested application without getting their requests blocked by the filtering nodes.
Instructions for NGINX-based Wallarm nodes (including AWS / GCP images, Docker node container)
The Attack rechecker functionality will not work if its IP addresses are not properly white-listed.
Configure proper notification and escalation rules for detected security incidents¶
Wallarm provides integrations with third-party messaging and incident management services like Slack, Telegram, PagerDuty, Opsgenie and others. It is highly recommended to configure your Wallarm Cloud instance to use the integrations to dispatch notifications about discovered security incidents to your information security team.
Know how to handle potential leaks of sensitive data from filtering nodes to the Wallarm Cloud¶
If you discover that your filtering nodes have dispatched some detected false positive requests with included sensitive information such as authentication tokens or username/password credentials to the Wallarm Cloud, you can ask the Wallarm technical support to delete the requests from the Wallarm Cloud storage. Also, you can configure proper data masking rules. It is not possible to modify already stored data.
Optional: Enable/disable Attack rechecker tests for specific applications, domains or URLs¶
If some application endpoints are not idempotent and don’t use any request authentication mechanism (for example, the self-registration of a new customer account) it is recommended to disable the Attack rechecker feature for the specific endpoints. Wallarm provides the customers with the ability to control which specific customer applications, domains or URLs should have the Attack rechecker scanner enabled or disabled by using the rule Set mode of active threat verification.
Optional: Configure Attack rechecker request rewriting rules (run tests against a copy of the application)¶
If you want to run checks against the copy of the application and completely avoid scanning the production application, then it is possible to create a rule which instructs the Attack rechecker to modify certain elements in replayed attack requests.