Skip to content
SecBytes
Menu
  • Home
  • Sumit Shrivastava (@invad3rsam)
  • Contact Me
Menu

DDoS Simulation using DNS Aliases

Posted on October 12, 2016December 12, 2016 by Sumit

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
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.

Share this:

  • Click to share on X (Opens in new window) X
  • Click to share on Facebook (Opens in new window) Facebook

Related

Post navigation

Shielding your browsing activities from the watchdogs →

Recent Posts

  • Setting Up Wazuh Server – Part 3 (Wazuh Dashboard)
  • Setting Up Wazuh Server – Part 2 (Wazuh Manager)
  • Setting Up Wazuh Server – Part 1 (Wazuh Indexer)
  • Guide to Creating Virtual Machines from Proxmox Templates
  • Self-Hosted Kubernetes Cluster in your Home Lab

Categories

  • Application Security Assessment (2)
  • Capture The Flag (1)
  • CVE (1)
  • DevSecOps (4)
  • Lab Solution (1)
  • Metasploit (2)
  • Miscellaneous (5)
  • Network Penetration Testing (3)
  • Phishing (1)
  • Tips and Tricks (8)

SecBytes

  • GitHub
  • Twitter
  • Facebook

RSS Exploit DB Update

  • [remote] FortiOS SSL-VPN 7.4.4 - Insufficient Session Expiration & Cookie Reuse June 20, 2025
    FortiOS SSL-VPN 7.4.4 - Insufficient Session Expiration & Cookie Reuse
  • [local] Microsoft Excel LTSC 2024 - Remote Code Execution (RCE) June 20, 2025
    Microsoft Excel LTSC 2024 - Remote Code Execution (RCE)
  • [remote] Ingress-NGINX 4.11.0 - Remote Code Execution (RCE) June 20, 2025
    Ingress-NGINX 4.11.0 - Remote Code Execution (RCE)

Legal

  • Disclaimer
  • Privacy Policy
  • Cookie Policy

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

© 2025 SecBytes | Powered by Minimalist Blog WordPress Theme