When a large share of the addresses in a flood also belong to ordinary home broadband, and blocking them would cut off your own customers, you are facing an IoT botnet. It is DDoS attack infrastructure assembled from compromised connected devices, and the large, dispersed fleets it forms are what a DDoS test is built to emulate. Cameras, DVRs, home routers, and other embedded systems ship with weak default credentials, rarely receive patches, and stay powered on continuously, which makes them ideal recruits.
How any botnet enrolls and commands its members is the parent page's subject. This one is about what changes when the members are consumer devices.
What makes IoT recruits different
They cannot defend themselves and nobody is watching. An IP camera or DVR has no endpoint agent, no user who logs in, and often no update channel the owner knows about. Mirai showed in 2016 that a short list of factory logins was enough. The families that followed added exploits for known flaws in router and camera firmware, because a device that was vulnerable when it shipped tends to stay vulnerable for its whole working life.
Infection is temporary, recruitment is not. Much IoT malware lives only in memory, so a reboot or a power cut cleans the device. It does not matter. The same weakness is still there, scanning resumes, and the device is usually back in a fleet within hours. The fleet's size holds steady while its membership churns, and the public address of a home device often changes on the same cycle when the ISP hands out a new lease.
Each device is small; the count is the weapon. A home device sends through a residential uplink of a few to a few tens of megabits per second. The terabit-scale numbers come from hundreds of thousands of them at once. Because these are real hosts on real addresses, they can complete TCP and TLS handshakes and send valid HTTP, not just raw packets.
Why it matters under attack
The hard part is not the volume, it is where the volume comes from. IoT bots sit inside the same consumer ISPs, and often behind the same carrier-grade NAT addresses, as your legitimate users. One public IPv4 address behind CGNAT can stand for hundreds of subscribers, so blocking it to stop one infected camera drops every customer sharing it.
That puts the usual source controls in a bind. A per-source rate limit set low enough to catch a single device's share also catches a busy CGNAT address carrying real traffic. A block list built from yesterday's attack is partly wrong today, because the devices have rebooted, been reinfected and picked up new addresses. IP reputation helps against hosting ranges, and much less against consumer broadband that is mostly legitimate.
What a DDoS test measures about it
A test of an IoT-class source model is mostly a test of collateral. It records:
- The false positive rate of the source controls. How many legitimate sessions are lost when the flood shares address space with real users, measured with real user traffic running through the test, not inferred afterwards.
- Whether mitigation keys on behavior. Request patterns, protocol conformance and per-session rate rather than the address alone, since the address is the least reliable signal on the wire.
- How fast block lists go stale. Whether a rule built against one wave of sources still holds, or hurts, when the next wave arrives from the same networks on different addresses.
CGNAT is one of several places where an IP address stops meaning one person, and DDoS testing for mobile backends sets out the rest.