Skip to content

Attack Detection Procedure

The Wallarm platform continuously analyzes API traffic and mitigates malicious requests in real-time. From this article, you will learn resource types Wallarm protects from attacks, methods of detecting attacks in traffic and how you can track and manage detected threats.

What is attack and what are attack components?

Attack is a single hit or multiple hits grouped by the following characteristics:

  • The same attack type, the parameter with the malicious payload, and the address the hits were sent to. Hits may come from the same or different IP addresses and have different values of the malicious payloads within one attack type. New hit should arrive within an hour from the last - otherwise it will go to a separate attack.

    This hit grouping method is basic and applied to all hits.

  • The same source IP address if grouping of hits by source IP is enabled. Other hit parameter values can differ.

    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 button is unavailable for the attack.

The listed hit grouping methods do not exclude each other. If hits have characteristics of both methods, they are all grouped into one attack.

Hit is a serialized malicious request (original malicious request and metadata added by the Wallarm node). If Wallarm detects several malicious payloads of different types in one request, Wallarm records several hits with payloads of one type in each.

Malicious payload is a part of an original request containing the following elements:

  • Attack signs detected in a request. If several attack signs characterizing the same attack type are detected in a request, only the first sign will be recorded to a payload.

  • Context of the attack sign. Context is a set of symbols preceding and closing detected attack signs. Since a payload length is limited, the context can be omitted if an attack sign is of full payload length.

    Since attack signs are not used to detect behavioral attacks, requests sent as a part of behavioral attacks have empty payloads.

Learn how to analyze attacks in Wallarm →

Types of protected resources

Wallarm nodes analyze HTTP and WebSocket traffic sent to the protected resources:

Protected resource API can be designed on the basis of the following technologies (limited under the WAAP subscription plan):

  • GraphQL

  • gRPC

  • WebSocket

  • REST API

  • SOAP

  • XML-RPC

  • WebDAV

  • JSON-RPC

Attack handling process

To detect and handle attacks, Wallarm uses the following process:

  1. Checks IP lists to understand whether to process the request at all. Denylist blocks the request and allowlist allows it - both without further analysis.

  2. Determines the request format and parse every request part to apply basic detectors.

  3. Determines the endpoint the request is addressed to apply custom rules and specific module settings and understand the filtration mode.

  4. Makes a decision whether the request is a part of attack or not based on basic detectors, custom rules and specific module settings.

  5. Handles request in accordance with decision and filtration mode.

Attack handling process - diagram

Note that rules, settings and filtration mode can be inherited from the parent endpoint or application. More specific has priority.

Tools for attack detection

To detect attacks, Wallarm analyzes all requests sent to the protected resource using the following tools:

Basic set of detectors

Wallarm uses a basic set of detectors (libproton library, developed by Wallarm) to determine different attack type signs as token sequences, for example: union select for the SQL injection attack type. If the request contains a token sequence matching the sequence from the set, this request is considered to be an attack of the corresponding type.

Wallarm regularly updates list of detectors (token sequences) for new attack types and for already described attack types.

Wallarm additionally validates SQL injection attacks (libdetection library, developed by Wallarm). See how to manage.

Custom rules

Custom rules are used to fine-tune the behavior defined by basic set of detectors. Users create them in Wallarm Console and the set of them is uploaded to filtering node.

Specific module settings

Besides comparing against basic detectors or custom rules, requests are checked against settings, provided by different protection tools, such as:

Any of these tools can cause specific attack or vulnerability detection and request blocking.

Ignoring certain attack types

The rule Ignore certain attack types allows disabling detection of certain attack types in certain request elements.

By default, the Wallarm node marks the request as an attack if detecting the signs of any attack type in any request element. However, some requests containing attack signs can actually be legitimate (e.g. the body of the request publishing the post on the Database Administrator Forum may contain the malicious SQL command description).

If the Wallarm node marks the standard payload of the request as the malicious one, a false positive occurs. To prevent false positives, standard attack detection rules need to be adjusted using the custom rules of certain types to accommodate protected API specificities. Wallarm provides the Ignore certain attack types rule to do this.

Creating and applying the rule

  1. Proceed to Wallarm Console:

    • Rules → Add rule or your branch → Add rule.
    • Attacks / Incidents → attack/incident → hit → Rule.
    • API Discovery (if enabled) → your endpoint → Create rule.

  2. Choose Fine-tuning attack detection → Ignore certain attacks.

  3. In If request is, describe the scope to apply the rule to.

  4. Set whether to ignore only the signs of the specific attacks (select them) or signs of all attacks.

  5. In In this part of request, specify request points for which you wish to set the rule.

    All available points are described here, you can choose those matching your particular use case.

  6. Wait for the rule compilation to complete.

Rule example

Let us say when the user confirms the publication of the post on the database administrator forum, the client sends the POST request to the endpoint https://example.com/posts/. This request has the following properties:

  • The post content is passed in the request body parameter postBody. The post content may include SQL commands that can be marked by Wallarm as malicious ones.

  • The request body is of the type application/json.

The example of the cURL request containing SQL injection:

curl -H "Content-Type: application/json" -X POST https://example.com/posts -d '{"emailAddress":"johnsmith@example.com", "postHeader":"SQL injections", "postBody":"My post describes the following SQL injection: ?id=1%20select%20version();"}'

So you need to ignore SQL injections in the parameter postBody of the requests to https://example.com/posts/

To do so, set the Ignore certain attack types rule as displayed on the screenshot:

Example of the rule "Ignore certain attack types"

Note that options you add to In this part of request should go in a particular order to reflect in which order Wallarm will apply parsers to read the required request element.

Ignoring certain attack signs in the binary data

By default, the Wallarm node analyzes incoming requests for all known attack signs. During the analysis, the Wallarm node may not consider the attack signs to be regular binary symbols and mistakenly detect malicious payloads in the binary data.

Using the Allow binary data rule, you can explicitly specify request elements containing binary data. During specified request element analysis, the Wallarm node will ignore the attack signs that can never be passed in the binary data.

  • The Allow binary data rule allows fine-tuning attack detection for request elements containing binary data (e.g. archived or encrypted files).

Creating and applying the rule

  1. Proceed to Wallarm Console:

    • Rules → Add rule or your branch → Add rule.
    • Attacks / Incidents → attack/incident → hit → Rule.
    • API Discovery (if enabled) → your endpoint → Create rule.

  2. Choose Fine-tuning attack detection → Binary data processing.

  3. In If request is, describe the scope to apply the rule to.

  4. In In this part of request, specify request points in which you wish to set the rule.

    All available points are described here, you can choose those matching your particular use case.

  5. Wait for the rule compilation to complete.

Rule example

Let us say when the user uploads the binary file with the image using the form on the site, the client sends the POST request of the type multipart/form-data to https://example.com/uploads/. The binary file is passed in the body parameter fileContents and you need to allow this.

To do so, set the Allow binary data rule as displayed on the screenshot:

Example of the rule "Allow binary data"

Note that options you add to In this part of request should go in a particular order to reflect in which order Wallarm will apply parsers to read the required request element.

Monitoring and blocking attacks

Input validation attacks

Wallarm can process the input validation attacks in the following modes:

  • Monitoring mode: detects but does not block attacks.

  • Safe blocking mode: detects attacks but blocks only those originated from graylisted IPs. Legitimate requests originated from graylisted IPs are not blocked.

  • Blocking mode: detects and blocks attacks.

Detailed information about how different filtration modes work and how to configure filtration mode in general and for specific applications, domains or endpoints is available here.

Behavioral attacks

How Wallarm detects the behavioral attacks and acts in case of their detection is defined not by the filtration mode, but by specific configuration of these attack type protection.

False positives

False positive occurs when attack signs are detected in the legitimate request or when legitimate entity is qualified as a vulnerability. More details on false positives in vulnerability scanning →

When analyzing requests for attacks, Wallarm uses the standard ruleset that provides optimal API protection with ultra‑low false positives. Due to protected API specificities, standard rules may mistakenly recognize attack signs in legitimate requests. For example: SQL injection attack may be detected in the request adding a post with malicious SQL query description to the Database Administrator Forum.

In such cases, standard rules need to be adjusted to accommodate protected API specificities by using the following methods:

Identifying and handling false positives is a part of Wallarm fine‑tuning to protect your APIs. We recommend to deploy the first Wallarm node in the monitoring mode and analyze detected attacks. If some attacks are mistakenly recognized as attacks, mark them as false positives and switch the filtering node to blocking mode.

Attacks in Wallarm UI

Wallarm provides you with the comprehensive user interface displaying all detected attacks and details on them. You can use attack dashboards for quick visualization and set you custom notifications.

See details in the Attack Analysis article.

Attacks view