Anatomy of a Botnet: How a DDoS Protection Firm Became a Source of Attacks

Overview

A troubling incident in Brazil has revealed a stark irony: a company tasked with defending networks from distributed denial-of-service (DDoS) attacks unwittingly enabled a massive botnet that targeted other Brazilian internet service providers (ISPs). This guide provides a detailed look at the technical chain of events uncovered by security researchers, from the exposure of privileged credentials to the misuse of insecure infrastructure for devastating DDoS campaigns. By understanding this case, network administrators and security professionals can learn crucial lessons about securing their own systems.

Prerequisites

To fully grasp the technical details, readers should have basic familiarity with:

• DDoS attacks: Understanding of distributed denial-of-service methods, especially reflection and amplification.
• DNS: How the Domain Name System works, including recursive and authoritative servers.
• Botnets: How compromised devices are orchestrated to launch attacks.
• Network scanning: Techniques like mass-scanning for open ports and services.
• SSH keys: Public-key authentication for remote server access.
• Python scripting: The malware in this case was written in Python.

Step-by-Step: The Attack Chain

1. Discovery of an Exposed Archive

The investigation began when a security source discovered a file archive in an open directory online. This archive contained several malicious Python scripts written in Portuguese, along with the private SSH authentication keys belonging to the CEO of Huge Networks — a Brazilian ISP specializing in DDoS protection. This was the first clue linking a legitimate security firm to the ongoing attacks.

2. Credential Compromise and Root Access

Using the exposed SSH keys, a threat actor gained root-level access to Huge Networks’ infrastructure. The CEO later claimed this was due to a security breach, possibly orchestrated by a competitor seeking to damage the company’s reputation. However, regardless of the motive, the attacker now had full control over the firm’s servers and network equipment.

3. Building the Botnet: Scanning for Insecure Devices

With root access, the attacker began mass-scanning the internet for two types of accessible resources:

• Insecure internet routers: Devices with default credentials or unpatched firmware that could be co-opted into a botnet.
• Unmanaged DNS servers: Open resolvers misconfigured to accept queries from any source on the internet.

These scans were automated using Python scripts found in the archive. The botnet created by compromising these devices allowed the attacker to issue commands to tens of thousands of enslaved machines simultaneously.

4. DNS Reflection and Amplification Technique

The attacker employed a classic but powerful vector: DNS reflection with amplification. Here’s how it works:

1. The attacker sends a spoofed DNS query to an open resolver — the query appears to come from the target’s IP address.
2. The resolver, believing the query is legitimate, sends a response to the spoofed address (the target).
3. Using an extension of the DNS protocol (EDNS0), the attacker crafts a query that is only ~100 bytes but triggers a response 60–70 times larger — sometimes exceeding 4,000 bytes.
4. By having thousands of compromised routers and servers send such queries simultaneously, the combined amplification overwhelms the target’s bandwidth.

This method is highly effective because it multiplies the attacker’s available firepower manyfold.

5. The Campaign Against Brazilian ISPs

For several years, this botnet launched repeated massive DDoS attacks exclusively against other Brazilian network operators. The targets were ISPs, not individual websites, suggesting a competitive or retaliatory motive. The Huge Networks infrastructure was used both as a command-and-control center and as a source of anonymized attack traffic.

Common Mistakes

Misconfigured DNS Servers (Open Resolvers)

Many network administrators leave their DNS servers open to the internet without restricting queries to trusted clients. This is the single biggest enabler of reflection attacks. Always configure DNS servers to respond only to queries from within your network or to authorized recursive clients.

Exposed SSH Private Keys

Storing private SSH keys in publicly accessible directories is a critical security failure. Keys should be password-protected, stored securely, and never placed on internet-facing systems without strong encryption. In this case, the CEO’s personal keys were left accessible online, granting full root access to the attacker.

Poor Network Segmentation

Even if one server is compromised, proper segmentation can limit the damage. In this incident, the attacker moved laterally from the exposed archive to core infrastructure. Firewalls, VLANs, and strict access controls between internal systems could have mitigated this.

Lack of Monitoring for Abnormality

Huge Networks itself, a DDoS mitigation provider, did not detect the anomalous traffic originating from its own network until outsiders discovered the open directory. Regular network flow analysis, unusual outbound traffic patterns, and monitoring of server resource usage can reveal a compromise.

Summary

This incident highlights how even companies specializing in cybersecurity can fall victim to breaches that then fuel further attacks. The combination of misconfigured DNS servers, exposed administrative credentials, and mass-scanning bots created a powerful amplification effect that plagued Brazilian ISPs for years. The key takeaways for any network operator are simple but vital: never expose private keys, harden DNS servers, segment internal networks, and actively monitor for suspicious activity. By learning from this case, defenders can better protect their infrastructure from becoming unwilling participants in the next DDoS nightmare.