DDoS Attack Scenario: When Your Website and Services Are No Longer Reachable

TL;DR

DDoS attacks target availability, not data. The damage comes from lost revenue, reputational harm, and the cost of mitigation.
Detection often comes from customers reporting issues or monitoring alerts. Quickly distinguishing between a DDoS attack and a technical outage is critical for the right response.
Immediate measures: Contact ISP, activate traffic scrubbing, deploy CDN, redirect emergency DNS, shut down non-essential services to free capacity for critical ones.
Customer communication during a DDoS attack must be fast, honest, and through alternative channels. A pre-prepared status page on external infrastructure is invaluable.
Prevention includes CDN with DDoS protection, Anycast DNS, rate limiting, geo-blocking as an emergency measure, and a tested DDoS response plan with an ISP escalation path.

Tuesday, 09:47 AM: The Onslaught Begins

Lichtblick GmbH operates an online shop for sustainable office supplies. 40 employees, two of them in IT. The shop generates 60 percent of total revenue; the rest comes from the brick-and-mortar store in Leipzig. The company hosts its shop at a German data center, operates a separate customer portal for business clients, and uses a cloud-based phone system (VoIP).

On Tuesday morning at 09:47 AM, IT manager Florian Roth's phone rings. It is a colleague from customer service: "Florian, three customers just called and say the shop is unreachable. I can't access it either." Florian opens his browser and navigates to the shop. The page does not load. He checks the monitoring dashboard. The web server's response times have exploded, the server is pinned at 100 percent CPU, and the network bandwidth is completely saturated.

Florian's first thought: a technical issue — maybe a faulty update or a database problem. He logs in via SSH to the server, which takes unusually long, and sees a flood of requests in the access logs that dwarfs anything he has ever seen: thousands of requests per second from hundreds of different IP addresses, all targeting the homepage and the shop's search function.

This is not a technical outage. This is a DDoS attack.

What Happens During a DDoS Attack

DDoS stands for Distributed Denial of Service. Unlike ransomware or data theft, the goal of DDoS is not to penetrate systems or steal data. The target is exclusively availability: the attacked service should no longer be reachable by legitimate users.

The attacker uses a botnet — a network of thousands or hundreds of thousands of compromised devices (computers, IoT devices, servers) that simultaneously send requests to the target. The sheer volume of traffic overwhelms the network connection, server capacity, or both.

DDoS attacks come in different variants:

Volumetric attacks flood the network connection with data traffic. A server with a 1 Gbit/s connection simply cannot withstand an attack of 10 Gbit/s, regardless of its computing power.

Protocol attacks (e.g., SYN Floods) exploit weaknesses in network protocols to fill connection tables of firewalls and load balancers, preventing the processing of legitimate connections.

Application attacks (Layer 7) send seemingly legitimate HTTP requests that overload the web server or database. A search query with a complex search term that triggers an expensive database query can bring a server to its knees with a thousand simultaneous executions, even when the network bandwidth is not saturated.

The attack on Lichtblick GmbH is a combination: a volumetric component filling the bandwidth and an application component specifically targeting the shop's search function.

Tuesday, 09:55 AM: The First Eight Minutes

Florian must act quickly and methodically. A DDoS attack cannot be resolved from the server itself, because the bandwidth the attacker controls is larger than the company's own. A functioning firewall configuration helps with basic defense but is not sufficient for volumetric attacks. The solution must happen upstream — at the internet provider or a specialized DDoS protection service.

Step 1: Confirmation and Classification

Florian confirms based on the logs and monitoring that this is a DDoS attack and not a regular traffic spike (e.g., from being mentioned on a news portal). The indicators are clear: traffic from hundreds of different IP addresses in many countries, no recognizable correlation with marketing activities, and the request patterns are atypical (thousands of identical requests per second).

Step 2: Contact ISP

Florian calls the data center's internet provider — the business customer hotline, not the general support number. He describes the situation: DDoS attack on the web server's IP address, estimated attack volume significantly exceeding available bandwidth.

The ISP has several options:

Blackhole routing (null routing): The ISP can discard all traffic to the attacked IP address (route it to a "black hole"). This stops the attack but also all legitimate traffic. The website is then protected from the attack but still unreachable. This measure is the emergency brake when nothing else works.

Traffic scrubbing: More advanced ISPs offer traffic scrubbing: traffic is routed through a filtering cluster that identifies and discards attack traffic while passing legitimate traffic through. The quality of scrubbing varies by ISP and attack type.

Upstream filtering: The ISP contacts its own upstream providers and requests filtering at a higher network level.

In Florian's case, the ISP offers traffic scrubbing but needs 15 to 30 minutes to activate it. Florian requests activation and simultaneously looks for a faster solution.

Step 3: Activate CDN

Florian had set up an account with a CDN provider (Content Delivery Network) months ago that offers DDoS protection as a feature. But he had never completed the integration because it was technically complex and "not an acute problem." Now the acute problem is here.

The CDN integration works in principle like this: the DNS record for the shop is pointed to the CDN's IP addresses. All requests then go to the CDN first, which has a globally distributed network with enormous capacity and filters DDoS traffic before forwarding clean traffic to the actual web server.

Florian changes the DNS records. But DNS changes take time to propagate. Depending on the TTL (Time to Live) of the existing DNS records, it can take 30 minutes to several hours until all users are routed through CDN protection. Florian had a TTL of 3600 seconds (one hour). That means: for at least one hour, some traffic will still go directly to the unprotected server.

Tuesday, 10:15 AM: Communication

While Florian coordinates the technical measures, communication begins on multiple channels.

Internal Communication

Florian informs management, customer service, and the marketing team. Customer service needs talking points for incoming calls, marketing must stop planned social media posts (a marketing campaign linking to an unreachable shop is counterproductive), and management needs to understand the financial impact.

The talking points for customer service: "We are currently experiencing technical disruptions with our online shop. Our IT team is working on a resolution. We expect the shop to be normally accessible again within a few hours. Your order data and customer account are not affected — this is not a data breach. If you would like to order now, you can call us and we will take your order by phone."

Customer Communication

This is where the value of a prepared status page shows. Lichtblick GmbH had set up a simple status page with an external service running on different infrastructure than the shop. This page is now activated and displays:

"Current status: Our online shop is currently experiencing limited availability. Cause: Technical disruption due to elevated data traffic. Our team is working on a resolution. Estimated timeframe: Restoration within the next few hours. Your data is not affected. Phone orders: 0800-XXXXXXX. Last update: 10:15 AM."

Florian posts the link to the status page on the company's social media channels and sets up an email redirect so that customers who contact support by email receive an automated reply pointing to the status page.

What Not to Communicate

Florian learned in a training session what not to communicate publicly during DDoS attacks:

Do not use the term "DDoS attack" in public communication if not necessary. "Technical disruption due to elevated data traffic" is sufficient for customers and avoids motivating copycats.
Do not provoke the attacker. Public statements like "We will not be extorted" or "The attack has not harmed us" can motivate the attacker to intensify the attack.
Do not share technical details (IP addresses, attack volume, protection tools used) publicly, as they help the attacker adjust their strategy.

Tuesday, 11:00 AM to 02:00 PM: The Defense Stabilizes

At 11:00 AM, the ISP's traffic scrubbing begins to take effect. Part of the attack traffic is filtered, and the network bandwidth eases somewhat. The server is still under load, but SSH login works reliably again.

At 11:30 AM, the DNS switch to the CDN begins to take effect. The first users are routed through the CDN, which effectively filters the application attack on the search function. The CDN provider has automatic rules that detect and block suspicious request patterns — for example, when an IP address makes a hundred search queries within one second.

By 12:30 PM, approximately 70 percent of traffic is routed through the CDN. The shop is reachable again for most users, though with elevated load times. Search queries are working again.

By 02:00 PM, the attack subsides significantly. DDoS attacks are not free for the attacker — botnets cost money to operate — and when the impact diminishes (because traffic is being filtered), the attack is often discontinued. The attack volume drops from peaks of over 8 Gbit/s to under 500 Mbit/s and then settles at a low level.

Technical Measures During the Attack

While the attack is ongoing, Florian implements additional measures:

Rate limiting: A rate limit is configured on the web server that restricts the number of requests per IP address per time unit. Legitimate users rarely make more than 10 requests per second; attackers often make hundreds.

Geo-blocking as an emergency measure: Analysis shows that the bulk of attack traffic originates from countries where Lichtblick GmbH has no customers. Florian temporarily activates geo-blocking at the CDN level to block traffic from these countries. This is not a permanent solution (it also blocks legitimate users from those regions), but it is effective as an emergency measure during an active attack.

Increased caching: Florian configures the CDN to serve as many pages as possible from cache, reducing the number of requests reaching the actual server. The homepage, product pages, and static assets are cached aggressively.

Reduce non-essential services: The internal blog, partner portal, and contact form are temporarily disabled to free server resources for the shop.

Tuesday, 03:00 PM: Background of the Attack

At 03:00 PM, an anonymous sender emails the info@ address of Lichtblick GmbH:

"We have demonstrated our capabilities. The attack will resume tomorrow at higher intensity unless 2 BTC are transferred to the following wallet. This is not negotiable."

Now it is clear: this is a DDoS-for-ransom attack (also called RDDoS). The attacker first conducted a "demonstration attack" and is now demanding a ransom to refrain from further attacks.

Do Not Pay

Florian and management agree: do not pay. If a cyber insurance policy is in place, the incident is reported there. The reasons are both principled and practical:

There is no guarantee the attack will stop after payment
Payment motivates the attacker to attack other companies
Payment can motivate the attacker to attack the same company again, since it is now known to be willing to pay
DDoS protection measures (CDN, scrubbing) are now active and will absorb a more intense attack

Criminal Complaint

The extortion email is secured as evidence (including the full email headers) and a criminal complaint is filed for computer sabotage and extortion.

Wednesday: The Second Attack and Prevention

On Wednesday morning, the attacker makes good on their threat. The attack resumes with higher intensity, this time with peaks of 15 Gbit/s and additional attack vectors (DNS amplification alongside the HTTP flood).

But Lichtblick GmbH is now prepared. The CDN protection is active, the ISP's traffic scrubbing is running, and Florian has lowered the DNS TTL to 300 seconds to respond faster if needed. The shop remains accessible to customers with somewhat elevated load times, but functionality is intact.

The attack continues until Thursday midday and then ceases.

Long-Term Prevention

In the week following the attack, Florian develops a DDoS prevention plan:

Keep CDN permanently active. CDN protection remains permanently active, not just in emergencies. DNS records permanently point to the CDN. The real server IP is never publicly disclosed (origin IP protection).

Harden DNS infrastructure. The DNS service is migrated to an Anycast DNS provider that is itself DDoS-protected. An attack on the DNS infrastructure would have the same effect as an attack on the web server: the domain would no longer resolve and the shop would be unreachable.

DDoS response plan. Florian documents the complete incident workflow as an incident response plan: who to call (ISP hotline number, CDN support number), which measures in which order, which communication templates to use. The plan is written so that a substitute colleague can follow it without prior knowledge.

Define ISP escalation path. Florian agrees with the ISP on a defined escalation path for DDoS attacks: direct extension to the NOC (Network Operations Center), guaranteed response time under 15 minutes, and the option to pre-configure traffic scrubbing so it only needs to be activated in an emergency.

Redundant infrastructure. For the most critical services (shop, customer portal) — identified through a Business Impact Analysis — a failover configuration is set up: if the primary server is no longer reachable, traffic is automatically redirected to a backup server in a different data center.

Maintain status page. The status page is operated permanently and updated promptly during every incident. Customers learn to check the status page first when problems arise, rather than overwhelming customer service.

Keep TTL low. The DNS TTL is permanently set to 300 seconds. In normal operations, this has no downsides (DNS resolution is fast anyway), but in an emergency, it allows a DNS switch within five minutes rather than one hour.

The Cost of a DDoS Attack

Florian prepares a damage report for management:

Direct costs:

CDN service (annual contract after activation): approx. 4,800 EUR/year
IT team overtime: approx. 2,500 EUR
Lost revenue during the outage (approx. 6 hours on the first day): estimated 8,000 to 12,000 EUR
Phone costs for customer service during the outage: approx. 500 EUR

Indirect costs:

Three customers placed their orders with a competitor and did not return
A business customer asked whether Lichtblick GmbH has a DDoS protection strategy before renewing their framework contract
The marketing team had to postpone a planned campaign because the shop was not reliably accessible on the campaign day

Total damage: Estimated 15,000 to 25,000 EUR, depending on long-term customer losses.

The investment in permanent DDoS protection (CDN, Anycast DNS, redundancy) is approximately 8,000 to 12,000 EUR per year. Given the damage from a single attack, this is a clear financial decision.

DDoS as a Diversionary Tactic

One aspect Florian raises in the lessons-learned workshop: DDoS attacks are sometimes used as diversionary tactics. While the IT team is busy with DDoS mitigation, the actual attack takes place on a different level — for example, a ransomware attack, an attempt to penetrate the network through a vulnerability, or a phishing campaign targeting employees.

In this case, there were no signs of a parallel attack. But Florian implements a rule as a consequence: during every DDoS attack, a parallel check for other forms of attack is conducted. A team member monitors the firewall logs and IDS (Intrusion Detection System) for suspicious activities unrelated to the DDoS traffic.

What This Case Teaches

DDoS attacks are among the incidents that can be prepared for most effectively, because the countermeasures are largely standardized and protection can be set up proactively before an attack occurs.

DDoS protection is not a luxury. Every company whose business depends on the availability of its online services needs a DDoS protection plan. The costs for CDN-based protection are in the low four-figure range per year. The costs of a successful attack are often many times that.

DNS is the bottleneck. The DNS switch to the CDN took one hour because the TTL was too high. That one hour was the most vulnerable phase of the entire incident. A low TTL and permanent CDN usage would have reduced the damage to minutes.

Communication via alternative channels. When the website is down, you need to be able to communicate through other channels: a status page on external infrastructure, social media, phone, email autoresponder. These channels must be prepared and tested — not set up for the first time during an emergency.

Don't pay, protect. DDoS-for-ransom only works if companies pay. Whoever pays once will be attacked again. The right response to extortion is investment in protection measures, not payment to criminals.

DDoS can hit anyone. Lichtblick GmbH is not a large corporation, not a financial services provider, not a critical infrastructure operator. It is a mid-market online retailer. DDoS attacks are so cheap to execute today (a few hundred euros for a multi-hour attack) that any company with an online presence can become a target. The question is not whether but when — and whether you are prepared for it. In ISMS Lite, emergency plans, availability requirements, and incident response workflows can be documented so you can respond in a structured manner when the time comes.