Feat/new attacks

.doc-agent/glossary.md

@@ -39,7 +39,8 @@
 | hit | Serialized malicious request (original request + metadata from Node) | | |
 | malicious request | Request with attack signs detected by Node | | invalid request |
 | legitimate request | Request without attack signs | | |
-| malicious payload | Part of request containing attack stamps (identifier + context) | payload | attack vector |
+| malicious payload | Part of request containing attack stamps (identifier + context) | payload | |
+| attack vector | Record of attack evidence for one grouped set of malicious requests, as returned by the Attacks API and shown as a row in the **Attacks** section | | malicious payload |
 | false positive | Mistaken detection of attack or vulnerability | | false attack, false vulnerability |
 | security issue | Error in application that can be exploited by attacker. Detected via: Passive detection, Threat Replay Testing, Schema-Based Testing, API Attack Surface Management | vulnerability, issue | |
 | vulnerability | See **security issue** | security issue, issue | |

docs/5.0/updating-migrating/older-versions/what-is-new.md

@@ -269,7 +269,7 @@ The Wallarm NGINX‑based filtering nodes now collect statistics on requests tha
 
 When using automatic IP blocking (e.g., with the brute force trigger configured), now you can analyze both the initial triggering requests and the samples of subsequent blocked requests. For requests blocked due to manual denylisting of their sources, the new functionality enhances visibility into blocked source actions.
 
-We have introduced new [search tags and filters](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) within the **Attacks** section to effortlessly access the newly introduced data:
+We have introduced new [search tags and filters](../../user-guides/search-and-filters/use-search.md#filters) within the **Attacks** section to effortlessly access the newly introduced data:
 
 * Utilize the `blocked_source` search to identify requests that were blocked due to manual denylisting of IP addresses, subnets, countries, VPNs, and more.
 * Employ the `multiple_payloads` search to pinpoint requests blocked by the **Number of malicious payloads** trigger. This trigger is designed to denylist sources that originate malicious requests containing multiple payloads, a common characteristic of multi-attack perpetrators.

docs/6.x/updating-migrating/older-versions/what-is-new.md

@@ -423,7 +423,7 @@ The Wallarm NGINX‑based filtering nodes now collect statistics on requests tha
 
 When using automatic IP blocking (e.g., with the brute force trigger configured), now you can analyze both the initial triggering requests and the samples of subsequent blocked requests. For requests blocked due to manual denylisting of their sources, the new functionality enhances visibility into blocked source actions.
 
-We have introduced new [search tags and filters](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) within the **Attacks** section to effortlessly access the newly introduced data:
+We have introduced new [search tags and filters](../../user-guides/search-and-filters/use-search.md#filters) within the **Attacks** section to effortlessly access the newly introduced data:
 
 * Utilize the `blocked_source` search to identify requests that were blocked due to manual denylisting of IP addresses, subnets, countries, VPNs, and more.
 * Employ the `multiple_payloads` search to pinpoint requests blocked by the **Number of malicious payloads** trigger. This trigger is designed to denylist sources that originate malicious requests containing multiple payloads, a common characteristic of multi-attack perpetrators.

docs/6.x/user-guides/search-and-filters/attack-filters.md

@@ -0,0 +1 @@
+--8<-- "latest/user-guides/search-and-filters/attack-filters.md"

docs/7.x/user-guides/search-and-filters/attack-filters.md

@@ -0,0 +1 @@
+--8<-- "latest/user-guides/search-and-filters/attack-filters.md"

docs/latest/about-wallarm/credential-stuffing.md

@@ -86,7 +86,7 @@ On adding the new rule, it is turned on automatically. Use **on/off** switcher t
 
 ## Viewing compromised credentials usage attempts
 
-The number of attempts to use compromised credentials in the last 7 days is displayed in the **Credential Stuffing** section. Click the counter and you will be redirected to the **Attacks** section that will display all [`credential_stuffing`](../user-guides/search-and-filters/use-search.md#search-by-attack-type) attacks for the last 7 days.
+The number of attempts to use compromised credentials in the last 7 days is displayed in the **Credential Stuffing** section. Click the counter and you will be redirected to the **Attacks** section that will display all [credential stuffing](../user-guides/search-and-filters/attack-filters.md#filter) attacks for the last 7 days.
 
 Expand any of the attacks to see the list of logins which passwords were compromised.
 

docs/latest/about-wallarm/protecting-against-attacks.md

@@ -1,4 +1,4 @@
-[rule-creation-options]:            ../user-guides/events/check-attack.md#attack-analysis_1
+[rule-creation-options]:            ../user-guides/events/check-attack.md#responding-to-attacks
 [request-processing]:               ../user-guides/rules/request-processing.md
 [api-discovery-enable-link]:        ../api-discovery/setup.md
 [ip-lists-link]:                    ../user-guides/ip-lists/overview.md
@@ -35,7 +35,7 @@ The Wallarm platform continuously analyzes API traffic and mitigates malicious r
 
     This hit grouping method works for all hits except for the ones of the Brute force, Forced browsing, BOLA (IDOR), Resource overlimit, Data bomb and Virtual patch attack types.
 
-    If hits are grouped by this method, the [**Mark as false positive**](../user-guides/events/check-attack.md#false-positives) button is unavailable for the attack.
+    If hits are grouped by this method, [marking the whole attack as a false positive](../user-guides/events/check-attack.md#false-positives) is unavailable.
 
 The listed hit grouping methods do not exclude each other. If hits have characteristics of both methods, they are all grouped into one attack.
 
@@ -214,7 +214,7 @@ When analyzing requests for attacks, Wallarm uses the standard ruleset that prov
 
 In such cases, standard rules need to be adjusted to accommodate protected API specificities by using the following methods:
 
-* Analyze potential false positives (by filtering all attacks by the [tag `!known`](../user-guides/search-and-filters/use-search.md#search-by-known-attacks-cve-and-wellknown-exploits)) and if confirming false positives, [mark](../user-guides/events/check-attack.md#false-positives) particular attacks or hits appropriately. Wallarm will automatically create the rules disabling analysis of the same requests for detected attack signs.
+* Analyze potential false positives and, if confirming them, [mark](../user-guides/events/check-attack.md#false-positives) particular attacks or requests appropriately. Wallarm will automatically create the rules disabling analysis of the same requests for detected attack signs.
 * [Disable detection of certain attack types](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-types) in particular requests.
 * [Disable detection of certain attack signs in binary data](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-signs-in-the-binary-data).
 * [Disable parsers mistakenly applied to the requests](../user-guides/rules/request-processing.md#managing-parsers).
@@ -248,7 +248,7 @@ Wallarm provides you with the comprehensive user interface displaying all detect
 
 See details in the [Attack Analysis](../user-guides/events/check-attack.md) article.
 
-![Attacks view](../images/user-guides/events/check-attack.png)
+![Attacks view](../images/user-guides/events/attacks-page.png)
 
 <!-- ## Demo videos
 

docs/latest/admin-en/configuration-guides/protecting-against-bola-trigger.md

@@ -66,7 +66,7 @@ To test the trigger described in the [Configuring](#configuring) section:
 
     The number of displayed requests corresponds to the number of requests sent after the trigger threshold was exceeded ([more details on detecting behavioral attacks](../../attacks-vulns-list.md#attack-types)). If this number is higher than 5, request sampling is applied and request details are displayed only for the first 5 hits ([more details on request sampling](../../user-guides/events/grouping-sampling.md#sampling-of-hits)).
 
-    To search for BOLA attacks, you can use the `bola` search tag. All filters are described in the [instructions on search use](../../user-guides/search-and-filters/use-search.md).
+    To find BOLA attacks, set the **Attack Type** filter to **Broken Object Level Authorization**. Filtering is described in [Attack Search and Filters](../../user-guides/search-and-filters/attack-filters.md).
 
 ### Requirements and restrictions
 

docs/latest/admin-en/configuration-guides/protecting-against-bruteforce.md

@@ -82,7 +82,7 @@ To test the trigger described in the [Configuring](#configuring) section:
 
     The number of displayed requests corresponds to the number of requests sent after exceeding the trigger threshold ([more details on detecting behavioral attacks](../../attacks-vulns-list.md#attack-types)). If this number is higher than 5, request sampling is applied and request details are displayed only for the first 5 hits ([more details on request sampling](../../user-guides/events/grouping-sampling.md#sampling-of-hits)).
 
-    To search for brute force attacks, you can use the `brute` filter. All filters are described in the [instructions on search use](../../user-guides/search-and-filters/use-search.md).
+    To find brute force attacks, set the **Attack Type** filter to **Brute force**. Filtering is described in [Attack Search and Filters](../../user-guides/search-and-filters/attack-filters.md).
 
 ### Requirements and restrictions
 

docs/latest/admin-en/configuration-guides/protecting-against-forcedbrowsing.md

@@ -80,7 +80,7 @@ To test the trigger described in the [Configuring](#configuring) section:
 
     The number of displayed requests corresponds to the number of requests sent after exceeding the trigger threshold ([more details on detecting behavioral attacks](../../attacks-vulns-list.md#attack-types)). If this number is higher than 5, request sampling is applied and request details are displayed only for the first 5 hits ([more details on request sampling](../../user-guides/events/grouping-sampling.md#sampling-of-hits)).
 
-    To search for forced browsing attacks, you can use the `dirbust` filter. All filters are described in the [instructions on search use](../../user-guides/search-and-filters/use-search.md).
+    To find forced browsing attacks, set the **Attack Type** filter to **Forced browsing**. Filtering is described in [Attack Search and Filters](../../user-guides/search-and-filters/attack-filters.md).
 
 ### Requirements and restrictions
 

docs/latest/admin-en/configuration-guides/protecting-with-thresholds.md

@@ -67,4 +67,4 @@ The following is the testing example for the [pre-configured trigger](#pre-confi
 
     ![Three malicious payloads in UI](../../images/user-guides/triggers/test-3-attack-vectors-events.png)
 
-    To search for the attacks, you can use the `multiple_payloads` [search tag](../../user-guides/search-and-filters/use-search.md#search-by-attack-type).
+    To find these attacks, use the [**Attack Type** filter](../../user-guides/search-and-filters/attack-filters.md#filter).

docs/latest/admin-en/configure-wallarm-mode.md

@@ -1,6 +1,6 @@
 [api-discovery-enable-link]:        ../api-discovery/setup.md
 [link-wallarm-mode-override]:       ../admin-en/configure-parameters-en.md#wallarm_mode_allow_override
-[rule-creation-options]:            ../user-guides/events/check-attack.md#attack-analysis_1
+[rule-creation-options]:            ../user-guides/events/check-attack.md#responding-to-attacks
 [acl-access-phase]:                 ../admin-en/configure-parameters-en.md#wallarm_acl_access_phase 
 [img-mode-rule]:                    ../images/user-guides/rules/wallarm-mode-rule.png
 

docs/latest/admin-en/export-to-cloud.md

@@ -40,11 +40,7 @@ This is what data is sent from Wallarm node to Cloud and how you can control it:
 
 **What data is sent and how to control**
 
-* In [Attacks](../user-guides/events/check-attack.md), you see information on all malicious requests ([input validation](../attacks-vulns-list.md#attack-types) attacks) and malicious behavior ([behavioral](../attacks-vulns-list.md#attack-types) attacks) registered by Wallarm, except:
-
-    * Incidents - displayed separately
-    * Attacks displayed exclusively in API Sessions
-
+* In [Attacks](../user-guides/events/check-attack.md), you see information on all malicious requests ([input validation](../attacks-vulns-list.md#attack-types) attacks) and malicious behavior ([behavioral](../attacks-vulns-list.md#attack-types) attacks) registered by Wallarm, except incidents - they are displayed separately.
 * [Incidents](../user-guides/events/check-incident.md) are attacks that successfully exploited the [security issue](../about-wallarm/detecting-vulnerabilities.md) (vulnerability) previously [detected](../about-wallarm/detecting-vulnerabilities.md#detection-methods) by Wallarm. These attacks were detected, but not blocked by Wallarm due to the current settings (`monitoring` [filtration mode](../admin-en/configure-wallarm-mode.md) or others). Information on an incident is the same as for an attack, plus a link to the security issue.
 * For input validation attacks, full HTTP data of the malicious request is sent.
 

docs/latest/admin-en/using-proxy-or-balancer-en.md

@@ -11,7 +11,7 @@ The Wallarm node reads a request source IP address from the NGINX variable `$rem
 
 ![Using balancer](../images/admin-guides/using-proxy-or-balancer/using-balancer-en.png)
 
-The request source IP address identified by the Wallarm node is displayed in the [attack details](../user-guides/events/check-attack.md#attack-analysis) in Wallarm Console.
+The request source IP address identified by the Wallarm node is displayed in the [attack details](../user-guides/events/check-attack.md#attack-details) in Wallarm Console.
 
 ## Possible problems of using a proxy server or load balancer IP address as a request source address
 

docs/latest/agentic-ai/ai-payload-inspection.md

@@ -174,4 +174,4 @@ When AI payload violations are detected, they show up in [API Sessions](../api-s
 
 You can find sessions with corresponding attack types using the **Attack** filter - use the corresponding attack type to display only sessions with these attacks.
 
-Note AI payload inspection attacks are displayed exclusively in the **API Sessions** section (and not displayed in the [**Attacks**](../user-guides/events/check-attack.md) section).
+AI payload inspection attacks are displayed both in **API Sessions** and in the [**Attacks**](../user-guides/events/check-attack.md) section.

docs/latest/api-abuse-prevention/exceptions.md

@@ -18,7 +18,7 @@ There are two ways of adding IP addresses to the exception list:
 
     ![API Abuse prevention - adding items from inside exception list](../images/about-wallarm-waf/abi-abuse-prevention/exception-list-add-from-inside.png)
 
-* From the **Attacks** section: use the `api_abuse`, `account_takeover`, `scraping` and `security_crawlers` search keys or select the appropriate options from the **Type** filter, then expand the required event and click **Add to exception list**.
+* From the **Attacks** section: set the [**Attack Type** filter](../user-guides/search-and-filters/attack-filters.md#filter) to **Suspicious API activity**, **Account takeover**, **Scraping**, or **Security crawlers**, open the required attack, select a request on the **Requests** tab, and click **API Abuse exception list**.
 
     ![API Abuse prevention - adding items from inside exception list](../images/about-wallarm-waf/abi-abuse-prevention/exception-list-add-from-event.png)
 

docs/latest/api-abuse-prevention/exploring-bots.md

@@ -23,14 +23,14 @@ Note that bot detection relies on the traffic - if there is not a sufficient amo
 
 ## Attacks
 
-You can explore attacks performed by bots in Wallarm Console → **Attacks** section. Use the `api_abuse`, `account_takeover`, `scraping` and `security_crawlers` search keys or select the appropriate options from the **Type** filter.
+You can explore attacks performed by bots in Wallarm Console → **Attacks** section. Set the [**Attack Type** filter](../user-guides/search-and-filters/attack-filters.md#filter) to **Suspicious API activity**, **Account takeover**, **Scraping**, or **Security crawlers**.
 
 ![API Abuse events](../images/about-wallarm-waf/abi-abuse-prevention/api-abuse-events.png)
 
 Note that:
 
 * Even if the bot IP is placed into the denylist by API Abuse Prevention, by default, Wallarm collects and [displays](../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) statistics regarding blocked requests originating from it.
-* The detailed information on the bot attack is stored for 31 days: while the attack itself may remain in the **Attacks** section for a longer time, after 31 days, if you expand it, no detector values or heatmaps will be presented - `Not enough data` message will be displayed instead.
+* The detailed information on the bot attack is stored for 31 days: while the attack itself may remain in the **Attacks** section for a longer time, after 31 days, when you open it, no detector values or heatmaps will be presented - `Not enough data` message will be displayed instead.
 
 **Detector values**
 

docs/latest/api-protection/business-logic-abuse-detection.md

@@ -158,4 +158,4 @@ When business logic abuse is detected, it shows up in [API Sessions](../api-sess
 
 You can find sessions with corresponding attack types using the **Attack** filter - use the **Custom logic abuse** attack type to display only sessions with these attacks. 
 
-Note that business logic abuse is based entirely on [API sessions](../api-sessions/overview.md). Because of that, the attacks found by these mitigation controls are displayed exclusively in the **API Sessions** section (and not displayed in the [**Attacks**](../user-guides/events/check-attack.md) section).
+Note that business logic abuse is based entirely on [API sessions](../api-sessions/overview.md). The attacks found by these mitigation controls are displayed both in **API Sessions** and in the [**Attacks**](../user-guides/events/check-attack.md) section.

docs/latest/api-protection/enumeration-attack-protection.md

@@ -218,4 +218,4 @@ You can find sessions with corresponding attack types using the **Attack** filte
 
 Note that enumeration mitigation controls described in this article base their traffic analysis and corresponding actions entirely on [API sessions](../api-sessions/overview.md) which significantly improve their work: if previously you had several nodes and, for example, a brute force [rule](../user-guides/rules/rules.md), your network load balancer could separate attack requests into different nodes and for each node the brute force counter worked separately. This could lead to missing some brute force attacks. The improved approach of mitigation control in this example is that it relies on session, no matter which node the traffic went through.
 
-Because of that, the attacks found by these mitigation controls are displayed exclusively in the **API Sessions** section (and not displayed in the [**Attacks**](../user-guides/events/check-attack.md) section).
+The attacks found by these mitigation controls are displayed both in **API Sessions** and in the [**Attacks**](../user-guides/events/check-attack.md) section.

docs/latest/api-protection/file-upload-restriction.md

@@ -116,7 +116,7 @@ Violations of file upload restriction policies are displayed as [file upload vio
 
 ![File upload restriction - detected attacks](../images/api-protection/mitigation-controls-file-upload-detected.png)
 
-You can switch between **Attacks** and **API Sessions** views using buttons in request details. All the attacks/sessions with this attack type can be found with the attack type filter set to **File upload violation** (also, use `file_upload_violation` [search tag](../user-guides/search-and-filters/use-search.md#search-by-attack-type) in **Attacks**).
+You can switch between **Attacks** and **API Sessions** views using buttons in request details. All the attacks and sessions with this attack type can be found with the [**Attack Type** filter](../user-guides/search-and-filters/attack-filters.md#filter) set to **File upload violation**.
 
 ## Comparison to other measures for preventing unrestricted resource consumption
 

docs/latest/api-protection/graphql-rule.md

@@ -72,7 +72,7 @@ To set and apply GraphQL policy:
 
 <!--## Exploring GraphQL attacks
 
-You can explore GraphQL policy violations (GraphQL attacks) in Wallarm Console → **Attacks** section. Use the GraphQL specific [search keys](../user-guides/search-and-filters/use-search.md#graphql-tags) or corresponding filters:
+You can explore GraphQL policy violations (GraphQL attacks) in Wallarm Console → **Attacks** section. Set the [**Attack Type** filter](../user-guides/search-and-filters/attack-filters.md#filter) to the corresponding GraphQL violation:
 
 ![GraphQL attacks](../images/user-guides/rules/graphql-attacks.png)-->