Skip to content

Running Active Threat Verification Tests on Non‑Production Systems

Wallarm's Active Threat Verification turns attackers into your own penetration testers. After analyzing an attacker's request, it crafts and tests potential vulnerability‑exposing requests on your application. While the default configuration sends tests to the original request address, Wallarm recommends configuring the module to redirect tests to a staging environment. This configuration allows you to use production attack traffic to test pre-production applications and APIs. This article guides you on how to configure Wallarm for this recommended use case.

Testing on the production environment using real production data can pose risks, such as causing downtime due to extensive testing or compromising real user data. Testing on a staging or development environment eliminates these risks. This approach lets you test vulnerabilities using production-like data without the associated issues. In addition to that, it ensures the safety of your live systems while also identifying vulnerabilities during development.

To set up the module for non-production testing, follow these steps:

  1. Configure a non-production environment host.

  2. Configure a non-production authentication cookie or API key.

  3. Enable Active Threat Verification.

The following diagram demonstrates how the module works in this use case:

ATV scheme

1. Configure a non-production environment host

The Rewrite attack before active verification rule lets you modify the attack replay address by replacing either the original HOST header value or the request paths. To achieve this:

  1. Proceed to Wallarm Console → Rules → create the rule Rewrite attack before active verification.

  2. Fill in the rule creation form following the instructions:

    • If request is specifies the endpoints to apply the rule to.

    • Rules specifies the new value for the HOST header or for the request path (URL segment without the domain, e.g., /test-blogs/new).

      The value must be decoded and set using the template language Liquid as follows: placed in double curly braces {{}} and single quotes ''. For example: {{'example.com'}}.

    • Part of request: select either header: HOST or uri, based on the segment of the request you intend to modify.

  3. Wait for the rule compilation and uploading to the filtering node to complete.

For instance, the following is the rule for running attacks initially aimed at example.com on the test environment example-test.env.srv.loc. The format of the address is {{'example-test.env.srv.loc'}}.

!Example of the rule modyfying HOST

Your application's APIs may require authentication. However, since the module strips authentication data before replaying attacks, or because production authentication data is not valid for staging or development environments, vulnerabilities might go unnoticed.

To address this, consider setting up specific authentication parameters for active threat verification in your non‑production environments. This can be done when:

  • The data is included in request headers, and

  • The request headers are consistent between the original and the new non-production environments.

This method not only provides the necessary access but also ensures that you can securely control the replay process.

To furnish the replayed requests with necessary authentication details:

  1. Proceed to Wallarm Console → Rules → create the rule Rewrite attack before active verification.

  2. Fill in the rule creation form following the instructions:

    • If request is specifies the endpoints to apply the rule to.

    • Rules provide the cookie or token value designed for active threat verification requests.

      The value must be decoded and set using the template language Liquid as follows: placed in double curly braces {{}} and single quotes ''. For example: {{'example.com'}}.

    • Part of request: select header and indicate the header name for passing authentication data.

  3. Wait for the rule compilation and uploading to the filtering node to complete.

For instance, the following is the rule to ensure attacks replayed on example.com carry the value PHPSESSID=mntdtbgt87j3auaq60iori2i63; security=low in the COOKIE header.

The format of the header value is {{'PHPSESSID=mntdtbgt87j3auaq60iori2i63; security=low'}}.

!Example of the rule modifying COOKIE

3. Enable the module

Once you have specified all the necessary settings for running attack replays on non-production environments, enable the module to initiate the vulnerability detection process:

  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.

!Vuln scan settings

This action enables the module for all resources where the filtering node is configured. Attack replay will run considering the setting you have specified before.

You further have the ability to enable or disable the module for specific endpoints.

Monitoring and addressing detected vulnerabilities

You can opt to receive timely notifications regarding the detected vulnerabilities to the systems like Splunk, OpsGenie, etc. Integrating vulnerability notifications into your daily workflow significantly accelerates your response time to potential threats.

Opsgenie integration

All vulnerabilities should be fixed on the application side because they make your system more vulnerable to malicious actions. If a vulnerability cannot be fixed, using the virtual patch rule can help block related attacks and eliminate the risk of an incident.

Discovered vulnerabilities are also cataloged in the Wallarm Console UI's Vulnerabilities section. Here you can analyze and manage them.

Vulnerabilities tab