Skip to content

Attack Analysis

This article describes how you can analyze attacks detected by the Wallarm node and take actions regarding them.

Attack analysis

All the attacks detected by the Wallarm platform are displayed in the Attacks section of the Wallarm Console. You can filter the list by attack date, type and other criteria, expand any attack and its included requests for detailed analysis.

If a detected attack turns out to be a false positive, you can immediately mark it as one to prevent alike false positives in future. Also, on the basis of the detected attacks, you can create rules and perform other Wallarm configurations to mitigate further alike threats.

Additionally, if the active verification is enabled, check its status right in the attack list.

In Wallarm:

  • Attack is a group of hits

  • Hit is a malicious request plus metadata added by node

  • Malicious payload is a part of request with attack sign

Read details here.

Each attack details contain all necessary information for analysis, such as attack's hits and malicious payload summary. To simplify analysis, only unique hits are stored in the attack details. Repeated malicious requests are dropped from uploading to the Wallarm Cloud and not displayed. This process is called hit sampling.

Hit sampling does not affect the quality of attack detection and Wallarm node continues protect your applications and APIs even with hit sampling enabled.

False positives

False positive occurs when attack signs are detected in the legitimate request.

To prevent the filtering node from recognizing such requests as attacks in future, you can mark all or specific requests of the attack as false positives. This automatically creates a rule to skip similar attack sign detection in similar requests, though it does not appear in the Wallarm Console.

You can undo a false positive mark only within a few seconds after the mark was applied. If you decided to undo it later, this can be done only by sending a request to Wallarm technical support.

The default view of the attack list presents only actual attacks (without false positives) - to change that, under All attacks switch from Default view to With false positives or Only false positives.

False positive filter

Responding to attacks

Is is important to understand if your applications and APIs are properly protected from the attacks to have the possibility to adjust the protection measures if necessary. You can use information from the Attacks section to get this understanding and respond correspondingly.

When dealing with this task, you will need to identify what type of attack took place, this will give you an understanding of what Wallarm's mechanisms provided protection and then adjust these mechanisms if necessary:

  1. Identify - in the Payload field context menu, select Show only, then pay attention to the Type filter and search field content.

  2. Check what was done for protection - note the Status column:

    • Blocked - all hits of the attack were blocked by the filtering node.
    • Partially blocked - some hits of the attack were blocked and others were only registered.
    • Monitoring - all hits of the attack were registered but not blocked.
    • Bot detected - this is bot, check action within the attack.
  3. If you think it was not an actual attack, mark it false positive.

  4. Understand - become aware of the Wallarm mechanism that detected and reacted to attack.

  5. Adjust - tune the Wallarm's behavior ("how" depends on mechanism).

Identify Understand Adjust
sqli, xss, rce, ptrav, crlf, nosqli, ssi etc. Standard tools for attack detection (libproton, libdetection and rules) Expand an attack and explore CVEs summary for the attack and CVEs for separate requests. Pay your attention to the node mode (final_wallarm_mode tag), visit Rules (US or EU), analyze them by application name from the attack. If necessary, adjust the rules or filtration mode for applications or their specific hosts or endpoints.
custom_rule User-defined detector Expand an attack and follow the Detected by custom rules link(s) - if necessary, modify the rule(s) including partial disabling it for particular branches.
vpatch Virtual patch Visit the Rules section (US or EU), search for "Create virtual patch" rules, if necessary, adjust the rule related to your attack. Have in mind that virtual patches work regardless of the filtration mode.
brute,
dirbust,
bola,
multiple_payloads
Trigger and IP lists: requests from denylisted IPs Expand an attack and after analyzing the requests, click the displayed trigger name (if presented) and modify its parameters. Also note trigger tags, then go to Triggers (US or EU) and find trigger by name, if necessary - adjust it.
If action is Blocked, this is done via denylist - go to IP Lists (US or EU) and search by IP: if necessary, adjust time period for IP staying in denylist.
blocked_source IP lists: requests from denylisted IPs Expand an attack and analyze requests from denylisted IP; after that, click the displayed trigger name and - if necessary - modify trigger settings. For manually denylisted IPs (blocked_source), go to IP Lists (US or EU) and search by IP: if necessary, adjust time period for IP staying in denylist.
Specific module or function:
api_abuse, account_takeover, security_crawlers, scraping (details)
- note the Bot detected status for all
API Abuse Prevention and IP lists: requests from denylisted IPs Expand an attack and analyze the heatmaps proving the confidence that it is a bot, note the date of the attack and source IP.
If action is Blocked, this is done via denylist - go to IP lists, filter by date and IP, click Reason column to see IP address details, explore these details, click Triggered profile, explore it and change if necessary.

Also, you can:
  • Add source IP to exception list for this IP never to be blocked. Also, you can remove IP from exception list (navigate to API Abuse PreventionException list)
  • Add source IP to denylist, even if API abuse configuration is not supposed to do it automatically.
Additionally you can: In IP Lists, click the IP address itself to go back to Events and see all related attacks.
bola BOLA autoprotection by API Discovery Expand an attack, if one does not contain link to trigger (which is the sign of manual protection from BOLA) then it is autoprotection provided by the API Discovery (US or EU) module. If necessary, navigate to the BOLA Protection (US or EU) section to either disable this protection or adjust template with its settings.
undefined_endpoint, undefined_parameter, invalid_parameter_value, missing_parameter, missing_auth, invalid_request (api_specification to search for all of them, details) API Specification Enforcement Expand an attack and follow the link to the violated specification. At the specification dialog, use the API specification enforcement tab to adjust settings, consider uploading the latest version of specification via the Specification upload tab.
gql_doc_size, gql_value_size, gql_depth, gql_aliases, gql_docs_per_batch, gql_introspection, gql_debug (graphql_attacks to search for all of them, details) GraphQL API Protection Expand an attack and follow the GraphQL security policies link - if necessary, modify existing Detect GraphQL attacks rule(s) or create additional ones for particular branches.

API calls to get attacks

To get the attack details, you can call the Wallarm API directly besides using the Wallarm Console UI. Below is the example of the API call for getting the first 50 attacks detected in the last 24 hours.

Please replacing TIMESTAMP with the date 24 hours ago converted to the Unix Timestamp format.

curl -v -X POST "https://us1.api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: <YOUR_TOKEN>" -H "accept: application/json"  -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}"
curl -v -X POST "https://api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: <YOUR_TOKEN>" -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}"

Getting 100 or more attacks

For attack and hit sets containing 100 or more records, it is best to retrieve them in smaller pieces rather than fetching large datasets all at once, in order to optimize performance. Explore the corresponding request example