Overview of Threat Replay Testing
¶
By replaying incoming real-world attacks as unharmful security tests, Wallarm's Threat Replay Testing addresses the challenge of finding vulnerabilities in applications and APIs that traditional security testing tools might miss.
The Threat Replay Testing capabilities:
-
Real-time analysis: It uses actual attack data to identify vulnerabilities that are being actively exploited or have the potential to be exploited in the future.
-
Comprehensive testing: By generating variations of real attacks, it explores different attack vectors and exposes weaknesses the original attackers may have missed.
-
Safe simulation: It removes harmful code and sensitive authentication details from the test requests, ensuring that the testing process doesn't cause any damage or compromise systems.
-
Non-production testing: It allows testing applications and APIs in a safe environment (typically staging) without risking production data or system stability.
How it works¶
The Threat Replay Testing 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 or both.
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:
The generated requests carry the User-Agent: Wallarm Threat-Verification (v1.x)
header, helping differentiate them from other requests.
Test request security¶
The Threat Replay Testing 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
, andViewstate
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.
Example¶
Consider the following real-world-like GET request initially detected by the Wallarm filtering node and uploaded to the Cloud:
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*/
Limitations¶
Threat Replay Testing is unavailable for:
-
Attacks with a request processing limit
-
Attacks for which the vulnerabilities have already been closed
-
Attacks that do not contain enough data for verification
See the list of the supported attack types in setup documentation.