Botnets on the subscriber network: when DDoS comes from inside
ISP anti-DDoS defense has historically been designed for attacks from outside: traffic from external sources saturating a link, overwhelming a server, or exhausting firewall sessions. The mental model is a wall: we protect the inside from the outside.
But there is a class of attacks that model handles poorly: those that originate inside the ISP’s own network, from subscribers’ devices.
Modern botnets recruit home devices—Android set-top boxes, home routers, IP cameras, smart TVs—that, once compromised, act as attack agents from inside the network. For an ISP, the problem is not only that customers involuntarily participate in attacks on third parties: that malicious traffic can saturate internal network segments, degrade experience for other subscribers, and drive significant operational cost.
How a subscriber device becomes a bot
The most common infection vector on home devices is not a sophisticated exploit. It is two simple, massive mechanisms:
1. Default credentials never changed
Most home routers and IoT devices ship with default admin credentials (admin/admin, admin/1234, or similar). If the device’s management interface is exposed to the internet—which happens when the ISP does not filter management ports on the access network—any automated scanner can compromise the device in minutes.
2. Debug or management ports exposed
Many low-cost Android set-top boxes and devices have Android Debug Bridge (ADB) enabled by default on TCP port 5555. ADB was built for development and debugging, not production. A device with exposed ADB lets a remote attacker run arbitrary commands without authentication. That is enough to install botnet agents, change configuration, or tunnel traffic through the device.
3. Embedded residential proxy SDKs
A less known but growing category: some low-cost devices (especially in IPTV and streaming) include third-party SDKs that monetize the device by turning its internet connection into a residential proxy sold on the proxy market. The device user does not know their connection is being resold. The manufacturer gets paid for including the SDK.
From the ISP’s perspective, traffic from these SDKs is indistinguishable from legitimate traffic with shallow inspection, which makes it hard to detect with static rules.
Impact on the ISP network
When a fraction of subscribers run compromised devices acting as bots, effects on the network are concrete:
Access network congestion: Attack traffic is generated across segments where infected subscribers sit. On PON and DOCSIS networks this can cause asymmetric uplink congestion (attacks are mostly outbound), degrading experience for everyone on the same segment, not only the infected.
Unexpected inter-AS traffic: If bots are used for proxying or volumetric attacks, the ISP sees a sustained increase in outbound traffic that can affect transit costs and peering agreements.
Hard-to-close support tickets: A subscriber whose router is compromised may see slowness, sporadic outages, and odd behavior with no obvious physical-layer cause. A support tech not looking at device traffic cannot diagnose it correctly.
IP reputation: The ISP’s IPv4 blocks can end up on blocklists (SpamRaus, Spamhaus, SORBS) if compromised devices participate in spam or mass scanning campaigns. That affects all ISP customers, including those without infected devices.
Legal exposure: In countries where regulation requires ISPs to act to prevent use of their network for attacks (Brazil has specific ANATEL rules; Argentina has ENACOM resolutions), inaction on known botnets can have regulatory consequences.
Detection: what to look for on your network
Detecting botnet activity on the subscriber network does not require full DPI (Deep Packet Inspection). Simpler, lower-cost signals already indicate the problem:
Anomalous NetFlow / sFlow: A normal residential subscriber does not generate thousands of distinct flows per minute to random external IPs. NetFlow analysis with thresholds on unique destinations per subscriber is one way to detect mass scanning or distributed DDoS.
Known botnet/C2 ports: Common IoT botnets use specific ports for command-and-control (C2) communication. Perimeter filters that detect traffic to known C2 destinations (using threat intelligence feeds such as Emerging Threats, Spamhaus, or commercial sources) can identify infected devices.
Exposed ADB: Periodic scans of the subscriber network for open TCP port 5555 identify all devices with ADB enabled. That is a high-risk indicator even if the device is not yet compromised.
Asymmetric traffic volume: Upload/download ratios far outside normal for a residential customer (e.g., a home user uploading 10x what they download for hours) signal botnet or proxy activity.
DNS anomalies: Bots often query algorithmically generated domains (DGAs—Domain Generation Algorithms) with recognizable patterns. A resolver with query logging can spot these patterns.
Mitigation: what the ISP can do
The ISP has tools subscribers do not:
Block management ports on the access network
TCP ports 5555 (ADB), 23 (Telnet), 2323 (alternate Telnet), and 7547 (TR-069/CWMP exposed without authentication) should not be reachable from the internet toward subscriber CPE. An ACL on the access network edge filtering inbound traffic to these ports massively reduces attack surface.
! Ejemplo: bloquear tráfico entrante a puertos de administración de dispositivos CPE
! (aplicar en interfaz hacia internet/uplink, sentido entrante)
ip access-list extended BLOQUEO-PUERTOS-ADMIN-CPE
deny tcp any any eq 23
deny tcp any any eq 2323
deny tcp any any eq 5555
deny tcp any any eq 7547
permit ip any any
Active notification of compromised subscribers
When botnet activity is detected from a subscriber, proactive notification helps the customer fix the issue (reducing support tickets) and demonstrates an active security posture that supports the ISP legally.
Mechanisms range from email to a captive portal that shows the notice when the subscriber browses (a technique used by ISPs in Europe and the United States).
Sinkholing known C2
An internal DNS resolver that redirects known C2 domains (using up-to-date threat intelligence feeds) to an ISP-controlled IP breaks communication between bots and the attacker. Infected devices are isolated from C2 without needing to contact the subscriber.
Scan and flood rate limiting
On the BNG or aggregation device, per-subscriber uplink rate limiting for traffic matching flood patterns (high SYN rate, ICMP flood, UDP flood to many destinations) limits how much impact one compromised subscriber can have on the rest of the network.
Threat intelligence feeds
The security community publishes updated lists of IPs, domains, and ranges tied to botnet infrastructure. CAIDA, Shadowserver, Team Cymru, and Spamhaus are high-quality, low-cost sources. Integrating these feeds into the ISP’s filtering system is one of the best effort-to-result measures.
The ISP’s role as a cybersecurity actor in Latin America
Cybersecurity narratives in Latin America often focus on the end user as victim or uninformed. But ISPs occupy a unique infrastructure position: they can see and control traffic in ways no home antivirus or firewall can match.
This is not about surveillance or content inspection. It is about mitigating, at the network layer, clearly malicious behavior that harms third parties and degrades the ISP’s own network.
ISPs that take an active stance on subscriber botnets protect their network—and build a competitive differentiator while meeting regulatory obligations more robustly.
Want to review your network’s exposure to subscriber botnets?
At Ayuda.LA we analyze exposure and help implement controls at the access and core layers. No hardware sales, no conflict of interest.
Learn more about our ISP cybersecurity services.
Questions about botnet detection or access-network security? Write to [email protected]—we reply to every message.