Marketplace listings for compromised Chinese surveillance cameras are no longer a niche IoT story. Operators buy ready-made access, fold those endpoints into rented botnets, and point them at login forms, checkout APIs, and WordPress admin surfaces. The resulting floods look like noisy residential traffic rather than a handful of hosting ASNs you can drop in one change window.
Ninja Forms–class WordPress exploit waves and sold camera access often land in the same operational week. Compromised sites and IoT cameras both produce high source counts, low per-IP volume, and request patterns that sit just under naive rate caps. If your first move is a full scrubber diversion, you burn budget and latency before you know whether Layer-7 challenges would have held.
What the opening minutes usually look like
A typical camera-backed HTTP flood opens with a steep rise in unique source IPs across consumer and small-business ranges. Individual clients send modest request rates. The URIs concentrate on authentication, search, cart, or form-post endpoints. User-Agent strings rotate through common browser templates while TLS client fingerprints cluster into a small set of botnet libraries.
Compare that shape to a classic volumetric packet flood. Packet floods fill pipes and session tables at the edge. Camera fleets fill application workers, origin connection pools, and WAF challenge queues. Your CDN may still report healthy transit while origin CPU and database locks climb.
Telemetry that separates botnet floods from organic spikes
Pull these joins within the first fifteen minutes of an alert. They decide whether you stay on edge challenges or escalate to diversion.
Source diversity versus per-IP intensity
Track unique /24 and /32 counts against requests per source over sliding five-minute windows. Camera botnets produce thousands of sources with low individual rates. A flash crowd or partner integration spike produces fewer networks with higher per-IP intensity and stable TLS fingerprints.
- Flag when unique sources grow faster than 10x baseline while median requests per source stay near normal browsing levels.
- Join geo and ASN distributions. Residential and camera-heavy ASNs dominate botnet floods; cloud and mobile carrier mixes dominate many legitimate traffic surges.
- Keep a rolling top-N of JA3/JA4 or equivalent TLS fingerprints. Three to five fingerprints covering most malicious volume is a strong botnet signal.
Application path concentration
Score URI families separately from raw RPS. Floods aimed at /wp-login.php, /xmlrpc.php, checkout POSTs, or password-reset endpoints drive business impact long before total bandwidth looks alarming. Tag each high-value path with its own baseline and error-budget threshold.
Challenge and origin health together
Instrument WAF challenge issue rate, challenge solve rate, origin 5xx, queue depth, and upstream connect errors on the same dashboard. Rising challenge issuance with falling solve rates plus origin saturation means the botnet is consuming challenge capacity. Rising origin errors with stable challenge metrics means your origin budget is the constraint and diversion may be required sooner.
Immediate controls that hold without premature diversion
Start with controls that raise attacker cost while preserving known-good sessions. Escalate only when those controls stop protecting origin health.
Fingerprint-aware challenge escalation
Bind stricter challenges to TLS fingerprint clusters and URI families that exceed baseline, not to every visitor in a country. Example sequence for a login and checkout flood:
- Apply JS or managed challenges to the top fingerprint clusters hitting auth and cart paths.
- Add per-fingerprint and per-/24 request budgets on those paths, with separate budgets for authenticated sessions.
- Fail closed on challenge exhaustion for unauthenticated traffic to the hot paths while keeping static asset and health-check allowances intact.
Document the exact WAF rule IDs, thresholds, and rollback steps in the incident channel before you change production. Night shifts need authority to tighten challenges without waiting for a vendor bridge.
Origin connection and worker budgets
Set hard caps on concurrent origin connections per edge PoP and per critical path. Camera botnets that pass soft rate limits still pin application threads. Pair those caps with synthetic checks against login and checkout from trusted probes so you know whether legitimate users still complete flows.
When scrubbing becomes the right next step
Escalate to volumetric scrubbing or full traffic diversion when any of these hold for two consecutive measurement windows:
- Edge challenge queues saturate and solve rates collapse while malicious fingerprint volume keeps climbing.
- Origin connect errors or worker saturation continue after fingerprint challenges and path budgets are active.
- A second vector appears (SYN, ACK, or UDP reflection) alongside the HTTP flood, compressing session-table headroom at the perimeter.
Keep diversion timers tied to re-checks of application signals: successful login completion rate, checkout conversion probes, and API error budgets. Greening transit alone is not the exit criterion.
Runbook slice for the first hour
Use a fixed order so analysts do not improvise under pager noise.
- Confirm flood shape: unique sources, per-IP rate, hot URIs, TLS fingerprint concentration.
- Enable fingerprint and path-scoped challenges; record rule IDs and start time.
- Apply origin connection budgets on auth and transactional paths.
- Open parallel hunts for exploit probes on the same hosts (plugin scanners, admin path enumeration) because hybrid campaigns often pair floods with edge exploitation.
- If origin or challenge health still degrades, divert through the scrubber and keep application probes on a five-minute cadence.
- Export source samples, fingerprint lists, and URI histograms for ISAC and vendor sharing before the campaign rotates infrastructure.
Hardening that reduces the next camera-wave blast radius
After the incident, convert temporary controls into standing posture.
- Pre-stage WAF rules for auth, cart, and form endpoints with inactive higher challenge tiers ready to activate.
- Maintain a tested origin connection budget per critical service, reviewed after each capacity change.
- Keep a short list of trusted synthetic journeys (login, search, checkout) as the mitigation acceptance tests.
- Track IoT and residential ASN cohorts that repeatedly appear in camera-botnet floods so the next wave starts with known fingerprint and range context.
- Align WordPress and other CMS patch SLAs with flood playbooks; plugin exploit weeks raise both scan volume and the chance that compromised sites join the same attack sets.
Field checklist
Before the next sold-camera wave hits your edge, verify that your team can answer these without opening a vendor ticket:
- Which dashboards show unique sources, TLS fingerprints, and hot-path error budgets on one screen?
- Who can raise challenge strictness on auth and checkout within fifteen minutes?
- What origin connection and worker limits protect those paths today?
- Which two application probes decide that mitigation is working?
- What conditions force scrubber diversion, and who owns that call?
Camera marketplace access turns consumer devices into disposable HTTP clients at scale. Scoring source diversity and fingerprint concentration early keeps you on precise Layer-7 controls when those controls still work, and puts scrubbing in play only when origin health and challenge capacity demand it.
