How Distributed Denial of Service (DDoS) Attacks Work

Posted by Craig Jorgensen
Craig Jorgensen


You might have read several of our other network security blogs covering topics that people in  the cybersecurity field need to know. Now is an excellent time to talk about Distributed Denial of Service (DDoS).

If you were to inspect the security landscape, you would find several instances where a cyberattack was not trying at stealing data, money, or assets. The goal may sometimes be to bring down a site, a service, or any such valuable network resource in such a way that it causes distress, loss of reputation, or financial loss. The irony of such DDoS is that usually zombie nodes or insecure machines of unsuspecting and unknowing users are hijacked to perform the attack. The target could be an entire network or even one host with the right access to abuse a specific service like an application, email, or database.

Conceptual digital image of lock on circuit background

Github Attack of 2018, and other DDoS examples

On Jan 3 of 2018, a DDoS pumped 1.3 terabits of traffic to flood GitHub over 15 to 20 minutes. But using Akamai, they managed to stay online.

In addition to Akamai's general DDoS defense infrastructure, the firm had also recently implemented specific mitigations for a type of DDoS attack stemming from memcached servers. These database caching systems work to speed networks and websites and not be exposed to the public internet. Since anyone can query them, they'll likewise respond to anyone, which is not a safe practice. About 100,000 memcached servers, mostly owned by businesses and other institutions, currently sit exposed online with no authentication protection. Attackers can thus, access them and send them a particular command packet that the server will respond to with a much larger reply.

DDoS perpetrators have various motives that drive their mindset. They may wish to gain notoriety by coming up with new ways to hurt a target, not necessarily an enemy. Some so-called hacktivists pick targets that have gained a lot of attention and prominence but they feel may wrong their cause or belief. Regardless, we must put safeguards in our infrastructure to protect such technology from becoming a target.


Types of DDoS Attacks

The attacker perpetrates such a crime by using someone else’s resources to attack a network. DDoS attacks are costly, yet they do not last long but still do plenty of damage. Popular DDoS attack techniques include ping of death, TCP SYN flood, and fast replicating worms and viruses.

I have seen some virulent email server targeting through network traffic which even industry-grade firewall and mail servers cannot do much to prevent, but the good news is the attacks are resource-intensive and quickly die down, usually moving to a new target.

The ping of death attack involves sending ICMP packets to choke the bandwidth. The TCP handshake involves multiple phases between client and server, allocating resources from a computer’s main memory. These phases expire after some time if the connection does not go through. Some smart hacker understood this code flow and brought down a machine by opening many unfinished TCP connections, often to the same network port. Since the server machine cannot handle multiple network connections to the same service, this created severe downtime and business loss.


Understanding the Steps and Techniques

Every DDoS attack has two steps:

  • Recruiting bots / forming botnets
  • The actual DDoS attack (flooding, stack abuse)

There are terms like bogons, botnet, smurf attack, TCP syncookie flood, UDP flood, DNS amplification, etc. We are not interested in exploring the meaning of each of these terms. But it is good to know that a botnet is nothing but a network of automatons or zombie computers that are used for launching a DDoS attack, and a TCP syncookie attack involves pumping TCP SYN packets without finishing a handshake, which can potentially crash some server machines.

1. The Bot Recruitment Phase

We don’t want to be in the unfortunate scenario of getting recruited as a bot - a silent perpetrator where your machine is used to attack others.

Recruiting a host to form part of a botnet involves the attacker running security scans on the hosts and finding vulnerabilities and weaknesses to be exploited. By installing a Trojan or a worm, attackers can abuse the hosts’ network resources.

2. DDoS from the Bots Phase

Once the botnet is ready, the attacker coordinates them using a CnC (command and control) center or a host that manages the whole attack metrics. Using this networked architecture, it forms an army of hosts participating in a coordinated manner to target some other network. Since today’s Internet has insanely high bandwidths, usually hosts connected to high-speed links are hired as bots, unbeknownst to the person to who the host belongs.

One cannot quickly fix such coordinated attacks because they don’t originate from one network or host. The only way to deal with them is by blocking packets from a large chunk of CIDR blocks. And that means the firewall has to stop this without manual intervention. The good news, though, is that the attackers quickly run out of resources since they must spend expensive network bandwidth to effect such an abuse.

Usually, flooding a network is the goal of DDoS attacks, but that is not always the case. In many cases, the bugs in IP fragmentation reassembly and some protocols like HTTP that do a slow read or a slow POST submission can also cause network abuse. Usually, the goal is to hurt the popular server or a company’s network to serve some devious purpose. 


DDoS Safeguards

Unfortunately, no safeguards exist for most attacks until they happen. When a new DDoS attack occurs, most networks will suffer until they can react and apply safeguards. Firewalls and specific network security rulesets help, and there is a concept of TCP scrubbing that involves detecting anomalous packets and responding appropriately. The good news, though, is that most DDoS attacks involve abusing existing bugs and bad implementations, and if we use good quality software and apply the latest patches, we can worry less.

Also, not trusting the Internet by applying appropriate firewall rules, and if all hosts are behind a NAT firewall, you are mostly safe. But we can’t run public servers behind a NAT. So they are vulnerable to DDoS, and in addition to having firewall rules inside the DMZ, we can also have some DDoS mitigation measures in the host itself.

Nowadays, most application servers run on a GCP or AWS cloud, so the data center headache has shifted from on-premise system admins to such provider companies. It is quite likely they are already familiar with these things and can protect you.

The way TCP syn flood, DNS amplification, UDP flood using the multicast address, and the whole family of abusive distributed attack infrastructure has taken on high-speed networks is quite remarkable. This is to be expected since as the good guys up their game in defensive techniques, the attackers go up ten notches to show their capability to adapt to newer bandwidths and network infrastructure.



DDoS attacks are as prevalent now as they have ever been. In our “always on” world and with the advancements in high throughput bandwidth available to even a home computer the potential to compromise hosts, recruit them into a botnet, and turn their resources towards a vulnerable target ups the ante on the damage that can be done. 

As security practitioners we must always be aware of the differing types of attacks out there and understand the risk they could pose to our organizations. That is the only way we can hope to effectively prepare for them.


Did you enjoy this content? Follow our linkedin page!

Looking for similar content?

Craig Jorgensen

Written by Craig Jorgensen

I'm a recent graduate from South Dakota State University with a degree in Computer Science. For me programming is both a passion and an occupation, but have been broadening my horizons as Customer Success Manager with Query.AI, where we are using Natural Language Processing to allow users to “talk to your data”.