Background
Recently, we encountered a security incident for one of our major BFSI clients. This client was hit by a DDoS attack. The victim received an email the previous day asking them to either pay certain ransom amount or become the victim of this attack. The severity of the attack would increase if the victim did not pay the ransom money to the cyber-terrorist group. The victim was using a well-known Cloud Service Provider’s Network to host one of their static web application.
Modus Operandi
The attacker started off with intimating the client over the email and social media. To fake the ownership of the client’s website, the attacker bought a free tier server from Cloud Service Provider (CSP) and changed one of the DNS alias of their server to the client’s application which also was hosted on CSP and the client was using its CDN (Content Delivery Network) services. Now since they were present on the same network, it was difficult for CDS to detect any huge traffic inside their own network.
Loader.io serves as an online stress testing service. Initially, loader.io provides an agent that one needs to place on the server under the test to claim the ownership of the server. Once the agent is successfully placed and gets executed, one can schedule a load test from loader.io site which will then start sending out packets on a huge scale. The number of packets gradually increases over the period of time.
 Figure 1: Attack Flow |
In the scenario that we investigated, loader.io was sending the packets to attacker’s website (abc.com). This in turn, due to its ‘A’ record, was forwarding those packets to client’s website (xyz.com). Now as the number of packets started increasing, client’s server started facing issues with resource allocation to process these packets. Being unable to process the packets, the server started becoming unresponsive which led to a DDoS (Distributed Denial of Service) attack.
The investigation was extensively carried out to check for loss of data or indicators of compromise but did not find any. The user agent that was used to send the HTTP request was of the syntax, “loader.io;<32_CHAR_HEXADECIMAL_STRING>” which led us to conclude that it was loader.io’s stress testing services that were used to exploit the client’s application.
