Introduction
The NetBot tool is a versatile command and control center (CCC) for DDoS Botnet Attack Simulation & Load Generation, created by that is publicly available via GitHub (https://github.com/skavngr/netbot). This tool is a prototype that uses Python 3 to configure bots, set a CCC server for the bots to be connected to, as well as loading target information for the server.
As this tool is a prototype, it is made to simulate a Client-Server botnet environment using Proof-of-Concept (PoC) code to demonstrate security flaws in software or during a PoC exploit. It is also assists in simulating DDoS attacks towards the target to understand how DDoS attacks disrupts traffic of servers, services, and networks. The tool is straightforward and easy to grasp, making it accessible for users of all levels.
NetBot CLI Banner
Botnet
Botnet is a group of bots and devices (known as zombie bots) linked together to perform the same task, for distribution and scaling. Botnet attacks are used by cybercriminals to carry out intense scraping, DDoS, and other large-scale cybercrime. (MITRE Framework, Resource Development — Compromise Infrastructure: Botnet https://attack.mitre.org/techniques/T1584/005/)
Botnet attacks are far more dangerous than single malware attacks because rather than infecting a single device, botnets infect hundreds, thousands, or even millions of connected devices at once. This poses an exponential threat that is much harder to stop. Making them even more evasive is the fact that the attacker can use incoming software updates from infected devices to redirect or scale up their attack on the fly. This helps attackers stay ahead of countermeasures employed by their victims. Armed with a large force of zombie bots, a single attacker can do more than compromise whole networks. They can quickly replicate and distribute their malware, hijacking growing numbers of devices.
Botnet Attack Diagram
What is a Botnet (IoT Botnet)? (https://www.a10networks.com/glossary/what-is-a-botnet-iot-botnet/.)
Attack Walkthrough
We will start with a nmap scan on the network to find for an open port. The intent is to do a HTTP flood to the server by sending a lot of request packets to the HTTP website.
Take note, for this example, we hosted the webserver on port 8080 and will use port 8080. In normal circumstances, the port we want to monitor is HTTP or HTTPS.
nmap scan command
nmap scan results
Once the target has been found, we make sure that we have access to the HTTP website using the IP address found and port.
Accessing the Website
Next, we will check the response time of the server, record down on how fast the HTTP server will respond normally to requests when accessing the HTTP website. Use the root account and use the command to extract out the response time of the server.
for (( ; ; )); do - initiates a forever loop
curl -o /dev/null -s -w 'Response from Victim Server: %{time_total} seconds\n' http://192.168.1.45:8080 - send an HTTP request to a designated server, directing the output to /dev/null, muting the progress meter, and customizing the output format to display the total time taken for the request in seconds.
sleep 1 - after each request, the script pauses for 1 second before sending the next request.
done - marks the end of the loop
Retrieving Server Response Time
From the target machine, the current CPU is running at around 27% which is a normal rate when running processes, apps, and tasks in the background.
CPU Percentage in Task Manager
Graph of CPU
From kali, we will go to the netbot folder directory and edit the netbot_config.py file to set the target IP address and port 8080.
Edit nebot_config.py File
In this stage, we will start up the NetBot server which is the netbot_server.py python script as it will be where the botnets will connect to. We will be able to view how many bots are connected in the server.
netbot Server
1st bot (Ubuntu)
The first bot is using Ubuntu. We will go to the netbot folder directory and edit the file netbot_client.py. For this file, we will set the host IP address which is the server and leave the port as default. This will allow the bot to be connected to the server.
Edit netbot_config.py Command
Edit Host IP Address
Once the python script has been edited, we will run the netbot_client.py python script. In Figure 3.4, we can see that currently the server sends a “HALT” response. This response means that the attack is stopped, will not send the attack to the target machine.
Response from NetBot Server
At the server side, we are able to see that the IP address and port number of the bot that is connected to the server.
First Bot Connected to Server
From here, we will be able start the DDoS attack. To start the attack, we will edit netbot_config.py python script and change the ATTACK_CODE to “LAUNCH”. This will start the DDoS HTTP flood attack to the server of the target.
Change ATTACK_CODE to “LAUNCH”
In the Ubuntu bot, we can see that the attack has started after the change of the ATTACK_CODE which the bot is now sending HTTP request to the targeted server.
Response Changed to “LAUNCH”
Looking at the response time of the server, we can see that the response time increased after the attack started. Before the attack, the average response time was about 0.34 seconds, but currently the response time has increased to about 0.64 seconds.
Current Response Time After Start of Attack
2nd bot (CentOS 7)
The second bot is using CentOS 7. The steps are similar to the Ubuntu bot by editing the netbot_client.py python script, setting the host IP address.
Edit netbot_client.py Command
Edit Host IP Address
After editing the python script, will run it and from here, we can see that the server immediately sends the response to “LAUNCH” the attack since the first bot is already sending request packets to the target server.
Response from NetBot Server
From the server, the second bot has already been added into the list in the server with its IP address and port number.
Second Bot Connected to Server
With two bots attacking, the response time of the server increased again. where with first bot sending request packets, its respond time is 0.64 seconds and adding the second bot increased to about 1.10 seconds.
Increased Response Time with Two Bots
In the target machine, with the DDoS attack still running, we can see that the CPU increased all the way to 100%, where the server is running on the command prompt is at 88.5%. This affects the performance of the applications and servers running in the machine, might cause lag and overheating to it.
CPU Running at Full Capacity
Graph of CPU at 100%
Analysis
In the network traffic that has been captured, it shows the IP addresses that are connected to the HTTP website by sending GET requests packets to the HTTP website.
Network Traffic (Send Request Packets)
In one of the packets, it shows that the request was sent to the host with the IP address 192.168.1.45 to the server at port 8080. Once the request is sent, the server sends back a response which will allow the IP address 192.168.1.0 to have access to the HTTP website.
Network Traffic Information
The next set of network traffic shows that the two bots are connected to the server through the destination port 5555.
Network Traffic (Bots Connected)
In the packets, we can see that a command was sent to both bots, to do a HTTP flood on the target server IP address 192.168.1.45 at port 8080. The “HALT” command shows that the attack is paused, and the “LAUNCH” command shows that the attack will start immediately to flood the server. From the second bot, the “LAUNCH” command was sent immediately as it was connected to server after the attack has started.
Network Traffic Information (Bot 1)
Network Traffic Information (Bot 2)
Rule Creation
For the detection of the DDoS attack that was done, we will create an ESA rule that detects through the destination port, for the HTTP requests that was sent to the server. As there is a possibility that the DDoS traffic are encrypted, we will make use of the web server to detect on the number of HTTP request packets was sent within 1 minute and try track down the number of source IP addresses are sending these requests.
A post on Cloudflare's blog reports that over 60% of the attacks are under 500 Mbps, and almost 30% of the attacks are between 500 Mbps and 10 Gbps. The largest attack they have seen recently was about 550 Gbps. Source: https://blog.cloudflare.com/ddos-attacks-have-evolved-and-so-should-your-ddos-protection/
Take note that for a DDOS, the typical requests will be coming in at more than 1M requests per second, so in this case it is advisable to input in 60M requests (60000000) in the field "Occurs".
It is helpful to include the list of webservers IP address if known.
Also, the rule would need to be written to group by destination IP.
ESA Rule – DDoS Attack Detected
