Skip to content

Overview of Active Threat Verification

Wallarm's Active Threat Verification turns attackers into your own penetration testers. It analyzes initial attack attempts, then explores other ways the same attack could be exploited. This exposes weak spots in your environment that even the original attackers did not find.

The Active Threat Verification capabilities:

  • Real-time testing: Uses live attack data to spot current and potential future weak spots, keeping you one step ahead of hackers.

  • Safe & smart simulation: Skips sensitive authentication details and removes harmful code in tests. Simulates attack techniques for max security, not risking actual harm.

  • Safe non-production tests: Enables you to run vulnerability checks in a staging or development setup using real production data, but without the risks like system overload or data exposure.

How it works

The Active Threat Verification module operates on the Wallarm Cloud. Initially, the module gathers detailed information about malicious requests that the Wallarm filtering node detected and uploaded to the Cloud. Leveraging this acquired data, the module dynamically generates a set of approximately 100-150 test requests. These test requests target the same vulnerability types as the malicious ones but employ different payloads.

The resulting set of attack simulations is directed to the same address as the original malicious request. However, the module offers the flexibility to redirect these test requests to alternative destinations, such as staging or development environments.

By analyzing responses to the test requests, the module determines vulnerability to specific attack types. Discovered vulnerabilities are cataloged in the Wallarm Console UI's Vulnerabilities section. Additionally, you have the option to receive notifications about these findings.

The following diagram demonstrates how the module works:

ATV scheme

The generated requests carry the User-Agent: Wallarm Threat-Verification (v1.x) header, helping differentiate them from other requests.

Test request security

The Active Threat Verification module is designed to create test requests in the most secure manner possible, featuring the following key characteristics:

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

  • Authentication headers like Cookie, Authorization: Basic, and Viewstate are excluded from replayed requests. Further, as guided by the custom authentication headers and masking rule, any additional headers may be adapted or removed as required.


Consider the following real-world-like GET request initially detected by the Wallarm filtering node and uploaded to the Cloud: SELECT username, password

From the request, the module learns the following details:

  • The attacked URL is

  • The type of used attack is SQLi (according to the UNION SELECT username, password payload)

  • The attacked query string parameter is user

  • 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)

Leveraging this data, the module crafts a series of test requests. These requests focus on potential SQL injection vulnerabilities using varied payloads, such as:')+WAITFOR+DELAY+'0 indexpt'+AND+('wlrm'='wlrm;SELECT+PG_SLEEP(10)--'+OR+SLEEP(10)+AND+'wlrm'='wlrm'%23\x22%0a-sleep(10)%23';+WAITFOR+DELAY+'0code:10'--*'XOR(SLEEP(10))OR'|\x22XOR(SLEEP(10))OR\x22*/

Enabling the module

The module is disabled by default. To enable it:

  1. Ensure you have an active Advanced API Security subscription plan. The module is only available under this plan.

    If you are on a different plan, please contact our sales team to transition to the required one.

  2. Proceed to Wallarm Console → VulnerabilitiesConfigure by following the link for the US Cloud or EU Cloud, and toggle on the Active threat verification switch.

You further have the ability to adjust or customize the module's behavior for specific endpoints.


Active threat verification is unavailable for attacks that consist of hits grouped by originating IPs.