Residential IP blocks used to be considered low-value scanning targets, mostly because home routers and dynamic addresses looked unpredictable compared to neatly organized data center ranges. That assumption stopped holding around 2021, when Mirai-derived botnets and their many forks began treating residential and small-office ranges as a primary reconnaissance surface rather than an afterthought, and understanding botnet scanning patterns against these ranges now matters for anyone running a server on a home connection, a small business ISP block, or a self-hosted VPN endpoint.
Why Residential Ranges Became a Botnet Target
Cloud providers publish their IP ranges. AWS, Azure, and GCP all maintain public JSON files listing their CIDR blocks, which means attackers scanning those ranges know exactly what kind of infrastructure they’re hitting. Residential ISP blocks don’t come with that metadata, but they come with something more valuable in aggregate: sheer volume and weak, homogenous defaults.
A single ISP like Comcast or Deutsche Telekom controls millions of consecutive addresses, and a large percentage of the devices behind them are consumer routers running firmware that hasn’t been patched since it left the factory. Mirai’s original 2016 campaign proved the model — it compromised over 600,000 IoT devices, largely DVRs and routers, using a list of 61 hardcoded default credentials. Every major botnet since (Mozi, Gafgyt, the various Mirai forks tracked by researchers at Netlab 360) has kept the same playbook: scan wide, test shallow, compromise whatever answers.
The Actual Scanning Behavior You’ll See in Logs
Botnet reconnaissance against residential ranges rarely looks like a targeted attack. It looks like noise, and that’s the point. A few patterns show up consistently across honeypot telemetry:
Sequential sweeps in short bursts. A bot compromised from one residential IP will often scan neighboring /24 blocks first, since consumer ISPs allocate addresses in ways that cluster similar device types geographically.
Single-port, high-breadth probes. Rather than running a full port range against one target, botnet scanners typically check one or two ports — usually 23 (Telnet), 2323 (alternate Telnet), 7547 (TR-069/CWMP), or 5555 (Android Debug Bridge) — against thousands of addresses per minute.
Credential stuffing immediately on connect. There’s no reconnaissance-then-exploit delay. The connection attempt and the credential guess happen in the same TCP session, often within 200-400ms of the handshake completing.
Recompromise loops. Once a device is infected, it usually starts scanning from its own address within minutes, which is why honeypot operators see the same source IP show up scanning, go quiet for a few hours (likely a reboot or ISP dynamic reassignment), then resume.
The honeypot data collected from exposed services shows this cycle clearly — most residential-range scanning traffic originates from other compromised residential devices, not from dedicated attacker infrastructure. It’s a self-perpetuating swarm more than a coordinated campaign in the traditional sense.
Which Ports Get Hit and Why
Port 23 remains the single most-probed port against residential ranges, a fact that surprises people who assume Telnet died out years ago. It didn’t — it’s still the default management interface on a huge installed base of routers, IP cameras, and DVRs sold between 2012 and 2019 that are still plugged in.
Port 7547 deserves specific mention because of the 2016 Deutsche Telekom incident, where a Mirai variant exploiting a TR-069 misconfiguration knocked nearly a million routers offline in a single weekend. That CVE-adjacent misconfiguration (the underlying issue was never assigned a single CVE, but tracked broadly as a TR-069 ACS exploitation pattern) is still actively scanned for today, almost a decade later, because ISPs are slow to force firmware updates on customer-owned equipment.
UPnP (port 1900/UDP) and RDP (3389) round out the list for residential ranges specifically, the former because it’s often left open by default on home routers, the latter because remote-work setups since 2020 pushed a lot of small businesses to expose RDP directly rather than behind a VPN. The mechanics of why UDP-based services get exploited differently than TCP ones ties into how TCP and UDP handle connection state — UDP’s lack of a handshake makes it both easier to spoof and harder to rate-limit at the firewall.
Common Mistakes in Reading This Traffic
Security teams monitoring residential-adjacent infrastructure — MSPs with home-office clients, or companies with employees on residential VPN endpoints — tend to make three mistakes.
First, treating scan volume as a threat signal on its own. A residential range gets scanned constantly regardless of what’s actually running there; volume tells you almost nothing about targeting intent.
Second, assuming geographic scan origin correlates with geographic attacker location. Because the scanning device is itself compromised, an IP in Ohio hitting your firewall might be relaying instructions that originated from infrastructure in an entirely different region — attributing intent based on source geolocation alone is a common analyst error.
Third, dismissing low-and-slow single-port probes as irrelevant background noise. A seasoned SOC analyst treats a sudden spike in single-source, single-port 23 or 7547 traffic against a monitored range as worth a closer look, because it can indicate a botnet has recently updated its scanning module — this is exactly the kind of shift documented in research on how automated tooling is reshaping scanning behavior, where scan logic gets refreshed faster than defenders update their baselines.
What Actually Reduces Exposure
For a home network or small office on a residential connection, the fix isn’t exotic. Disable remote management on the router’s WAN interface — most consumer routers ship with this on by default, which is the root cause behind a large share of Mirai-family infections. Change default credentials on every IoT device, not just the router; DVRs and IP cameras are frequently the actual entry point even when the router looks clean. If RDP has to be exposed, put it behind a VPN like WireGuard rather than forwarding port 3389 directly, since RDP brute-forcing from botnet-controlled residential IPs is one of the most consistent patterns in exposure data going back years.
FAQ
Do botnets specifically target home networks over business networks?
Not by intent — they target address ranges indiscriminately and let device fingerprinting sort out what’s worth compromising. Residential ranges just happen to contain a higher density of unpatched consumer IoT gear, which is why the compromise rate looks higher there.
Is a dynamic IP address any protection against this kind of scanning?
Very little. Scanners work across entire CIDR blocks regardless of which specific address is currently assigned to which customer, so a new IP from your ISP gets scanned within hours, not months.
Can changing my router’s default port numbers stop botnet scans?
It reduces automated success rates slightly but doesn’t stop the scanning itself, since most botnet scanners check the well-known port regardless of what’s actually listening there, and full-range scans exist for exactly this reason.
The underlying lesson from years of botnet telemetry is that residential ranges aren’t a side effect of the internet’s scanning background noise — they’re the primary substrate that keeps Mirai-style botnets self-sustaining. Locking down router management interfaces and IoT credentials does more to break that cycle than any amount of traffic analysis after the fact.