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.

Possible statuses

Verification statuses are displayed in the Attacks section of the Wallarm Console, in the Active verification column:

Attacks with various verification statuses

  • Happening now Happening now: the attack is happening now; it will be verified when finished.

  • Verified Verified: the attack's target has been tested for being vulnerable. There are two possible outcomes:

    • Verified - not a threat. The testing did not find the attack's target being vulnerable to this attack type.

      ATV verified - not a threat

    • Verified - a threat. The testing found that the attack's target is vulnerable to this attack type. The vulnerability is created and the attack becomes the incident and moves to the Incidents tab.

  • Error Error: an attempt to verify an attack type that does not support verification:

  • Skipped Skipped: an attempt to verify an attack type has been skipped. Possible reasons:

    • Attacks sent via the gRPC or Protobuff protocol
    • Attacks sent via the HTTP protocol of the version different from 1.x
    • Attacks sent via the method different from one of the following: GET, POST, PUT, HEAD, PATCH, OPTIONS, DELETE, LOCK, UNLOCK, MOVE, TRACE
    • Failed to reach an address of an original request
    • Attack signs are in the HOST header
    • Request element containing attack signs is different from one of the following: uri , header, query, post, path, action_name, action_ext

  • Sheduled Scheduled: the attack is queued for verification. To raise the priority of the attack verification in the queue, click the verification icon and then Force verification.

  • Forced Forced: the attack has a raised priority in the verification queue.

  • Could not connect Could not connect to the server: it is not possible to access the server at this time.

Example

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

https://example.com/login&user=UNION SELECT username, password

From the request, the module learns the following details:

  • The attacked URL is https://example.com/login

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

https://example.com/login&user=1')+WAITFOR+DELAY+'0 indexpt'+AND+('wlrm'='wlrm
https://example.com/login&user=1+AND+SLEEP(10)--+wlrm
https://example.com/login&user=1);SELECT+PG_SLEEP(10)--
https://example.com/login&user=1'+OR+SLEEP(10)+AND+'wlrm'='wlrm
https://example.com/login&user=1+AND+1=(SELECT+1+FROM+PG_SLEEP(10))
https://example.com/login&user=%23'%23\x22%0a-sleep(10)%23
https://example.com/login&user=1';+WAITFOR+DELAY+'0code:10'--
https://example.com/login&user=1%27%29+OR+SLEEP%280%29+AND+%28%27wlrm%27%3D%27wlrm
https://example.com/login&user=SLEEP(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 → Vulnerabilities → Configure 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.

Limitations

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