Category Archives: Security policies

Imperva Increases Self-Service Capability Fourfold with Custom Security Rules

Back in 2014, we introduced Rules (previously IncapRules) to give our customers advanced control over their application security.

Today we’re putting even more of this custom tuning power in the hands of our customers by quadrupling the number of filters available via self-service.

Rules Basics

Rules are an extensive policy engine developed in response to the emergence of increasingly advanced threats as well as the growing demand to add more logic at the edge. Advanced threats continue to drive the need for adaptive security solutions which enable real-time response and flexible, custom security policy enforcement.

Rules are built using filters, operators, and values. Filters are the core function which helps tune manual policies. Customers use filters for advanced bot protection, security against brute-force attacks, and more. Although about 90% of our customers use our out-of-the-box policies in their default preventative settings, leaving the burden of tuning to the Imperva security experts, there are times when some of our customers need to make specific adjustments to their security policies.

The Existing Filter Set

Traditionally, Imperva has limited to 20 the list of filters exposed to our customers. A set of parameters is available for self-service use when defining Rules.

Filters for Rules are divided into three logical groups:

  1. Clients: Information about the connecting client
  2. Requests: Information about the current request
  3. Counters\rates: A running count of the number of actions performed  

As one example, there’s an existing filter for the ID for the client application.

  • Googlebot (Search bot) (6)
  • cURL (Developer Tool) (47)

When adding or editing a rule in the Management Console, you start entering text in the value field to display a list of available values.

Example: ClientId == 15

The New Filters

Behind the scenes, the Imperva Support team and SOC alone have had much more power up until now in terms of custom tuning upon request, with access to approximately 100 different filters.

But by expanding the set of Rules available via self-service to a total of 48 filters, even more policy customization is possible without ever needing to contact the Support team.  

To complement existing self-service Rules for bot protection, protection against Account Takeover (ATO), application hardening, rate limiting, and Advanced Access Control (ACL), the new filters offer the following and more:

  • Advanced optionality when handling advanced bot scenarios
  • Logic based on popular technologies such as Drupal, PHP, Joomla, WordPress and others
    (the idea here is to simplify complex expressions by encapsulating the tech detection and rates within a single command)
  • Client certificate info such as CN, SHA1 and Serial Number


Here are three examples of new filters unveiled to customers:

(1) session-creation-ip_rate

If you set the value here to, say, 800, you will be able to capture sessions with more than 800 requests from a certain IP in 1 minute – a likely indicator of a DDoS attack.

(2) request-rate-ip_rate

This filter measures the rate of requests per IP over a 1-minute period, and if you expect no more than 100 requests, you can set the action to “block” or “alert” because that could indicate that an attacker is trying to scrape your website.

(3) login-bf-drupal_rate

Though we patch by default from the backend to mitigate known exposures such as the latest critical RCE vulnerabilities affecting Drupal, this filter may be useful for our more advanced customers who wish to add an extra layer of logic and protection.

The filter allows you to measure the rate of requests per IP over a period of time to a Drupal login page, helping in detection and prevention of brute-force attacks on Drupal login pages.

The Demand for Logic at the Edge

The customer policy rule engine has proven to be a powerful tool when you need to perform specialized adjustments for specific use cases. Advanced options for building custom security policies complement the default prevention settings in our cloud WAF for complete protection.  

But as organizations of all sizes shift to the cloud and our enterprise customer list has expanded rapidly in turn, the demand for more edge functionality has also increased. We’ve heard time and again that our customers find it very appealing to be able to add advanced logic rules at the edge.

Last year we announced the rollout of advanced Application Delivery Rules. And while we invested in building and improving the engine which drives both of these rule sets, we honed in on the need to (1) develop advanced filters which can help address emerging threats and exploitation and (2) expose logical parts of our classification engine and bot protection layers previously hidden from customer view.

The Move to More Control and Visibility

The newly visible Rules will provide a much more powerful tool for savvy customers who need to tune their policies in order to handle complex cases. This approach is yet another step we’re taking to put enhanced visibility and extended control in our customers’ hands and to stay ahead of the curve in handling the most sophisticated and automated attacks out there.

The post Imperva Increases Self-Service Capability Fourfold with Custom Security Rules appeared first on Blog.

DarkVishnya: Banks attacked through direct connection to local network

While novice attackers, imitating the protagonists of the U.S. drama Mr. Robot, leave USB flash drives lying around parking lots in the hope that an employee from the target company picks one up and plugs it in at the workplace, more experienced cybercriminals prefer not to rely on chance. In 2017-2018, Kaspersky Lab specialists were invited to research a series of cybertheft incidents. Each attack had a common springboard: an unknown device directly connected to the company’s local network. In some cases, it was the central office, in others a regional office, sometimes located in another country. At least eight banks in Eastern Europe were the targets of the attacks (collectively nicknamed DarkVishnya), which caused damage estimated in the tens of millions of dollars.

Each attack can be divided into several identical stages. At the first stage, a cybercriminal entered the organization’s building under the guise of a courier, job seeker, etc., and connected a device to the local network, for example, in one of the meeting rooms. Where possible, the device was hidden or blended into the surroundings, so as not to arouse suspicion.

High-tech tables with sockets are great for planting hidden devices

High-tech tables with sockets are great for planting hidden devices

The devices used in the DarkVishnya attacks varied in accordance with the cybercriminals’ abilities and personal preferences. In the cases we researched, it was one of three tools:

  • netbook or inexpensive laptop
  • Raspberry Pi computer
  • Bash Bunny, a special tool for carrying out USB attacks

Inside the local network, the device appeared as an unknown computer, an external flash drive, or even a keyboard. Combined with the fact that Bash Bunny is comparable in size to a USB flash drive, this seriously complicated the search for the entry point. Remote access to the planted device was via a built-in or USB-connected GPRS/3G/LTE modem.

At the second stage, the attackers remotely connected to the device and scanned the local network seeking to gain access to public shared folders, web servers, and any other open resources. The aim was to harvest information about the network, above all, servers and workstations used for making payments. At the same time, the attackers tried to brute-force or sniff login data for such machines. To overcome the firewall restrictions, they planted shellcodes with local TCP servers. If the firewall blocked access from one segment of the network to another, but allowed a reverse connection, the attackers used a different payload to build tunnels.

Having succeeded, the cybercriminals proceeded to stage three. Here they logged into the target system and used remote access software to retain access. Next, malicious services created using msfvenom were started on the compromised computer. Because the hackers used fileless attacks and PowerShell, they were able to avoid whitelisting technologies and domain policies. If they encountered a whitelisting that could not be bypassed, or PowerShell was blocked on the target computer, the cybercriminals used impacket, and winexesvc.exe or psexec.exe to run executable files remotely.



Shellcode listeners


Shellcode connects


Shellcode pipes