The Virus: DDOS

DDOS

DDOS Extortion – Biting the DDOS Bullet

21:08

It started with a five minute long DDoS attack which established that the cybercriminals meant business and could cause impact, this small sample attack stopped all business for five minutes. They then sent an email demanding payment of the ransom in bitcoins within 48 hours, otherwise a second and far more damaging DDoS attack would ensue and the ransom amount would be raised.

This type of attack: ‘DDoS Extortion’ has become increasingly popular during the past year and the official

guidance to companies who find themselves in a DDoS Extortion situation, as recently reiterated by the FBI, is: Do Not Pay the ransom but rather focus efforts at strengthening DDoS mitigation.

The ‘target’ in this case was a leading ecommerce corporation and downtime was not an option both in terms of possible transaction loss and equally importantly reputational damage. The company had already invested in multi-layered DDoS mitigation strategy. The five-minute outage caused by the extortionists had senior IT management under pressure and they knew that serious financial loss as well as impact to their reputation was possible.

"DDOS mitigation does not boil down to one device that ‘bites the DDoS bullet."

DDOS Testing

Testing DDoS mitigation systems is done by generating traffic which simulates real DDoS attacks in a completely monitored and controlled manner. Control is key because DDoS mitigation does not boil down to one device that ‘bites the DDoS bullet’ but is rather a chain of devices that need to be configured much like an orchestra in order to work in complete harmony. Testing this way allows a company to verify that each element of their DDoS mitigation systems is working as expected and that together they are configured for optimal protection.

DDoS testing typically impacts the tested environment and therefore is conducted during maintenance windows to ensure minimal disruption to ongoing operations. This means the company’s key team members are usually all on site and because maintenance windows usually last 3-5 hours – time is of the essence.

For this reason effective DDoS testing allows for:

i. Quickly switching from one type of test to another once you have evaluated how the environment responds to a test (there are numerous types of tests ranging from Layer 3, Layer 4 to Layer7), and

ii. Ramping up test bandwidth to simulate a realistic load level

We received a call on Saturday afternoon describing the ransom scenario and possibilities of a large attack and our SOC team was at the customer’s premises the following morning.

“It’s all about knowing which attacks to simulate and getting as many of them done, in as little time as possible. You know that clock is ticking..”

Our ‘Emergency BaseLine DDoS Testing’ as we have come to call it, is comprised of the following three stages:

1. Reconnaissance – Working with the company to understand as much as possible about relevant subnets and foot-printing the environment with port scanning and DNS enumeration.

2. Testing – Simulating a variety of tests to identify points of failure

3. Troubleshooting & Hardening – Resolving immediate critical issues and troubleshooting the necessary network points to have a DDoS mitigation defense ready for the threatened attack.

Matthew Andriani, MazeBolt’s CEO is quoted saying: “It’s all about knowing which attacks to simulate and validate quickly the various DDoS mitigation algorithms, challenges and False positives in the time given, in this case the MazeBolt SOC utilizing our Threat Assessment Platform (TAP) did an excellent job in hardening and validating the environment to withstand attacks in under eight hours end to end”.

By the time the day was over we had simulated a total of fifteen different types of DDOS attacks all of which highlighted problems in the company’s DDOS mitigation apparatus. By working through all critical issues with the customer’s team, and vendors where required, we were able to reconfigure the devices in points which failure was identified. The configurations deployed were then retested to validate the environment had been hardened sufficiently.

Fortunately, as fate would have it, in this case, the threatened second attack never came.