RSS
Last updated: May 14, 2026 at 10:49 AM UTC
All 219 Vulnerability 76 Breach 45 Threat 91 Defense 7
Tag: mirai (2 articles)Clear

Brazilian anti-DDoS firm Huge Networks was running a Mirai botnet that knocked Brazilian ISPs offline for years - either to drum up business or because someone breached their CEO's SSH keys

Brian Krebs published an investigation showing that Huge Networks, a Brazilian DDoS protection firm, has been running the Mirai-based botnet behind a years-long DDoS campaign against other Brazilian ISPs. An exposed open directory revealed Portuguese-language Python attack scripts that relied on the personal SSH keys of Huge Networks CEO Erick Nascimento. The botnet ran on compromised TP-Link Archer AX21 routers and unmanaged DNS servers, attacking Brazilian IP prefixes for 10-60 seconds at a time. Nascimento says a January 2026 intrusion compromised his SSH keys; he denies running the attacks. ISPs say the attacks have been ongoing since December 2024.

Check
If you run a TP-Link Archer AX21 router or any consumer router for business use, factory-reset it and update to the latest firmware - they remain a primary Mirai botnet recruitment target.
Affected
TP-Link Archer AX21 routers and similar consumer-grade equipment remain widely used as Mirai botnet members. Brazilian ISPs are the targets, but Mirai variants are used worldwide. The deeper pattern: DDoS protection firms turning out to be the source of the attacks they bill to mitigate is recurring (Krebs identified the original 2016 Mirai authors as DDoS provider co-owners).
Fix
For TP-Link Archer AX21 owners: factory reset, update firmware, disable WAN-side admin access. Replace if firmware is end-of-life. For organizations evaluating DDoS providers: ask for clear separation between attack telemetry and customer acquisition, request audited proof of how attack traffic is sourced, and consider providers in jurisdictions with stronger anti-fraud regulations.

Mirai botnet exploits a year-old D-Link PoC to build fresh botnets on discontinued routers (CVE-2025-29635)

Akamai's Security Intelligence and Response Team caught a Mirai variant actively exploiting CVE-2025-29635, a command-injection flaw in discontinued D-Link DIR-823X routers, roughly one year after the vulnerability was publicly disclosed and its proof-of-concept exploit posted to GitHub (and later removed). The flaw lives in the sub_42232C function of the router firmware, where an attacker-controlled macaddr field is copied into a command buffer via snprintf and passed to system() without validation, enabling remote command execution through a crafted POST to /goform/set_prohibiting. Firmware versions 240126 and 24082 are affected. D-Link retired the DIR-823X line in 2025, so there is no vendor patch and no vendor patch coming. The Mirai variant, called 'tuxnokill' by its authors, drops from 88.214.20[.]14 via a simple shell script, supports multiple CPU architectures, uses XOR key 0x30 to obfuscate strings, and phones home to 64.89.161[.]130 on TCP port 44300. The same operator is chaining D-Link alongside CVE-2023-1389 (TP-Link AX21) and a ZTE ZXV10 H108L RCE, giving them a diverse pool of end-of-life consumer routers to enslave. At the time Akamai reported, CVE-2025-29635 was not yet on the CISA KEV catalog. The lesson: public PoCs against dead hardware do not stay dormant forever, and the 'wait for active exploitation' instinct gives attackers a year's head start.

Check
Check your external attack surface (including remote-worker home networks that terminate corporate VPNs) for any D-Link DIR-823X, TP-Link AX21, or ZTE ZXV10 H108L routers facing the internet.
Affected
D-Link DIR-823X firmware 240126 and 24082 (the entire discontinued product line is affected and will not receive a vendor patch). Also actively targeted: TP-Link AX21 routers vulnerable to CVE-2023-1389 and ZTE ZXV10 H108L devices.
Fix
Replace affected D-Link DIR-823X units with a supported model - there is no fix. For TP-Link AX21, apply the vendor firmware addressing CVE-2023-1389. Block outbound traffic to 88.214.20[.]14 and 64.89.161[.]130 at your corporate perimeter and DNS resolver, and hunt for any past connections to them in flow logs. For remote-worker environments, enforce corporate-approved home-router models or at minimum audit for end-of-life consumer hardware terminating VPN tunnels.