A Krebs on Security investigation published in late April 2026 revealed that Huge Networks — a Miami-founded anti-DDoS firm operating in Brazil — ran infrastructure tied to a sustained Mirai-based botnet campaign targeting the small regional ISPs it was positioned to protect. Whether the attacks originated from a malicious insider, a compromised development server, or deliberate sabotage-for-hire remains legally unresolved, but the operational outcome is identical in each scenario: a security vendor’s infrastructure was weaponized against the customers it was supposed to defend. This article uses the Huge Networks case to build a practical framework for auditing, monitoring, and contractually protecting your organization against a DDoS mitigation provider compromise.
Huge Networks: How an Anti-DDoS Firm Became the Threat
Huge Networks was incorporated in Miami in 2014 and marketed DDoS mitigation services in Brazil. Evidence published by Krebs on Security shows that attackers — acting from within or through the company’s infrastructure — built a Mirai-based botnet by mass-scanning the internet for TP-Link Archer AX21 routers running firmware versions before 1.1.4, all of which are vulnerable to CVE-2023-1389.
Private SSH keys belonging to CEO Erick Nascimento were found embedded in recovered Python malware scripts written in Portuguese. Bash command history extracted from an exposed file archive documented the botnet construction process step by step. A DigitalOcean server at 174.138.89.122 served as the campaign’s coordination point, while two command-and-control nodes — hikylover[.]st and c.loyaltyservices[.]lol — received telemetry from infected routers.
Nascimento acknowledged a breach of two development servers in January 2026 that also exfiltrated his personal SSH keys, and publicly attributed the attacks to a competitor. He referenced “strong evidence stored on the blockchain” but provided no verifiable documentation. No charges have been filed as of the time of publication.
The Exploit: CVE-2023-1389 and Mirai’s Persistence
The botnet’s expansion relied on CVE-2023-1389, an unauthenticated command injection vulnerability in the locale API of the TP-Link Archer AX21 web management interface. The vulnerability carries a CVSS v3 score of 8.8 (High), with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
The root cause: the country parameter in the locale API’s write operation is passed directly to popen() without sanitization. An unauthenticated attacker sends a crafted POST request to the management interface and achieves remote code execution as root. TP-Link released firmware version 1.1.4 Build 20230219 on March 14, 2023, to address the flaw. A public proof-of-concept is available on Exploit-DB (EDB-51677), making mass exploitation of unpatched devices trivial.
Despite a patch published more than three years ago, FortiGuard Labs documented continued CVE-2023-1389 exploitation through 2025 by multiple Mirai variants, Moobot, Miori, and Gafgyt. The flaw persists in production because unmanaged CPE devices at small ISPs and residential networks are rarely updated.
Once a router was compromised, the botnet launched DNS amplification and reflection attacks exclusively against Brazilian IP address prefixes. The scripts show each targeted prefix was hit for 10 to 60 seconds using four parallel attack processes before the botnet rotated to the next target — a pattern designed to sustain distributed pressure across many networks simultaneously while evading per-target volumetric detection thresholds.
MITRE ATT&CK Mapping
| Technique ID | Name | Application | |—|—|—| | T1595.001 | Active Scanning: Scanning IP Blocks | Mass-scanned the internet for exposed TP-Link AX21 devices | | T1190 | Exploit Public-Facing Application | Exploited CVE-2023-1389 for unauthenticated RCE on routers | | T1059.006 | Command and Scripting Interpreter: Python | Portuguese-language Python scripts orchestrated botnet construction | | T1583.005 | Acquire Infrastructure: Botnet | Compromised routers absorbed into a persistent Mirai-based botnet | | T1498.002 | Network Denial of Service: Reflection Amplification | DNS amplification attacks launched against targeted Brazilian ISP prefixes | | T1036 | Masquerading | Operated publicly as a legitimate anti-DDoS vendor while generating attack traffic |
Indicators of Compromise
| Type | Indicator | Context | |—|—|—| | IP | 174.138.89.122 | DigitalOcean coordination server for botnet infrastructure | | Domain | hikylover[.]st | Mirai C2 server receiving router telemetry | | Domain | c.loyaltyservices[.]lol | Mirai C2 server receiving router telemetry | | CVE | CVE-2023-1389 | TP-Link Archer AX21 firmware < 1.1.4 — exploited for botnet expansion | | File artifact | Portuguese-language Python malware scripts | Recovered from exposed archive on Huge Networks servers |
Block the C2 domains at your DNS resolver and upstream BGP filtering layer. The DigitalOcean IP address may be reassigned; verify current registration in ARIN before adding it to block lists.
Detecting Attack Traffic From Your Own Mitigation Vendor
This is the core operational problem the Huge Networks case surfaces: attack traffic that originates from a vendor’s scrubbing center or peering infrastructure is indistinguishable from legitimate mitigation traffic at a cursory glance. The following controls reduce your detection window to hours rather than weeks.
1. Baseline your traffic before activating any vendor redirect
Before routing production traffic through a mitigation provider’s GRE tunnel or BGP anycast redirect, run a minimum 30-day baseline of your upstream traffic profile: total pps/bps per ASN, DNS query volume per source IP, and ICMP/UDP/TCP ratio per destination prefix. Store the baseline in your SIEM and alert on deviations exceeding three standard deviations from the rolling mean.
2. Treat your mitigation provider’s ASN as an untrusted external
Your firewall and SIEM should log and analyze all traffic sourced from your DDoS vendor’s published IP ranges — including traffic entering your scrubbing tunnel. If the vendor claims to deliver only clean traffic, any raw DNS amplification traffic (high response-to-query ratio, spoofed source IPs, UDP port 53 bursts) arriving from their CIDR is an immediate anomaly.
# Enumerate all prefixes announced by a vendor ASN using bgpq4
bgpq4 -J AS12345 | jq '.prefixLists[].rules[].prefix'
Load the resulting prefix list into a SIEM lookup table and create an alert rule that fires when traffic matching amplification signatures (DNS: response > 10× query size; NTP: mode-7 response from unexpected source) arrives from a vendor-controlled CIDR.
3. Deploy an independent passive tap before the vendor redirect
A vendor controlling your traffic scrubbing also controls what you see after scrubbing. Deploy a passive tap or SPAN port on your ingress before traffic enters the vendor redirect, and run independent NetFlow or sFlow collection on the raw, unmitigated stream. Tools such as ntopng or Elastic’s Packetbeat can ingest this feed and surface DNS amplification patterns independent of anything the vendor reports.
4. Correlate attack timing against vendor-reported incident logs
In the Huge Networks campaign, the botnet struck each prefix for 10 to 60 seconds in a structured rotation. If your peering partners or upstream providers report inbound DDoS pulses that correlate in timing with your vendor’s own mitigation activity windows, treat that as a high-priority anomaly. Require your vendor to deliver per-attack timestamps and source IP distributions in near-real-time — any refusal or unexplained delay in log access is itself a signal.
5. Monitor BGP for unauthorized route announcements
Services such as BGPmon and Routeviews surface unexpected route origination events from your ASN or your vendor’s ASN. A compromised vendor might announce additional prefixes or hijack your routes during an active attack campaign to redirect traffic flows.
Vendor Vetting Framework: Technical and Contractual Controls
Supply chain compromise — where the trusted intermediary becomes the threat actor — is not a new pattern. It surfaces in software development (the Checkmarx/Lapsus supply chain attack), package ecosystems (DPRK npm malware dependency campaigns), and now managed security services. Treat DDoS mitigation providers as privileged third parties with full visibility into your traffic, not as passive appliances.
Pre-engagement due diligence
- Request the vendor’s most recent third-party penetration test report (within 12 months) and their current SOC 2 Type II or ISO 27001 certificate. Ask for scope details — a certificate that excludes scrubbing infrastructure is a red flag.
- Request a complete list of all IP ranges, ASNs, and data center providers involved in traffic handling. Cross-reference these against public routing data in RIPE, ARIN, and Hurricane Electric’s BGP Toolkit.
- Review the vendor’s ARIN/RIPE abuse contact history. A vendor with no active abuse@ response trail is a signal of either poor operational hygiene or deliberate obscurity.
- Run the vendor’s ASN through BGP history tools to check for route hijacking incidents or abuse report patterns in the preceding 24 months.
Contractual controls
- Include a right-to-audit clause explicitly covering scrubbing infrastructure and traffic logs, not just the vendor’s corporate security posture.
- Define “attack traffic” by technical signature (DNS amplification, NTP reflection, SSDP, ICMP flood), and require the vendor to indemnify you for any such traffic sourced from their own network ranges.
- Require a mandatory incident notification SLA: the vendor must notify you within two hours of any compromise affecting their infrastructure or any infrastructure used to process your traffic.
- Specify that per-attack logs including source IP distributions are retained for 90 days minimum and accessible to you on demand via API or portal.
Architectural controls: vendor-agnostic mitigation
Avoid single-vendor dependency at the BGP redirect layer. A resilient architecture routes attack traffic through multiple independent scrubbing providers — at minimum one provider per major upstream transit path — so that compromise of one vendor does not grant an attacker full visibility and control over your inbound traffic.
[Your ASN]
├── Primary upstream (Vendor A BGP redirect, monitored via SIEM lookup)
├── Secondary upstream (Vendor B or on-premises scrubber)
└── Out-of-band passive tap → Independent NetFlow/SIEM (pre-redirect)
Multi-provider configurations also enable log comparison: if Vendor A reports clean traffic but your tap shows amplification arriving from Vendor A’s CIDR, the discrepancy is immediately actionable. Like the SAP npm supply chain compromise, the Huge Networks case demonstrates that the supplier relationship is itself an attack surface that adversaries — or insiders — will exploit when other entry points are hardened.
Conclusion
The Huge Networks case closes a trust assumption that most network security teams leave open: the belief that a DDoS mitigation vendor is a passive pipe rather than an active network participant with privileged access to your traffic flows, BGP announcements, and scrubbing telemetry. Whether the botnet activity in this case was insider-driven or the result of an external breach, the blast radius was the same — attack traffic originated from or through a vendor customers were paying to stop exactly that. Baseline your traffic before activating any vendor redirect, treat your mitigation provider’s ASN as an untrusted external in your SIEM, and contractually require the right to audit logs and the obligation to notify on compromise. Any vendor that resists those terms is telling you something worth hearing before you route your traffic through them.
For any query contact us at contact@cipherssecurity.com
