Overview of Threat Replay Testing¶
Wallarm's Threat Replay Testing 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 Threat Replay Testing 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 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.