Case study
A 10,000-Bot Swarm, Contained in an Evening
A distributed scraping botnet hit a Canadian online store. AI agents ran the forensics, a senior engineer made every call, and an automated defense now stands watch. This is how it went.
On an ordinary Monday afternoon, a Canadian specialty e-commerce retailer's traffic went sideways: unique visitors climbing toward six times the normal baseline, pages slowing, no obvious reason why. By that evening the attack was understood, contained, and verified — not because anyone typed faster, but because we don't investigate alone. Our AI agents swept the server logs, edge analytics, and configuration in parallel while a senior engineer directed the investigation and made every decision. Over the following two days the engagement uncovered and fixed three separate root causes, and left behind an automated defense that has stood watch ever since.
10,630
Unique bot IPs in one hour at the swarm's peak — baseline ~900
Same evening
From detection to contained, verified, and documented
5 minutes
Detection-to-defense for the automation left standing watch
The attack: thousands of strangers, one fingerprint
The surge looked like a credential attack at first glance. The forensics said otherwise: it was a distributed catalog-scraping botnet — thousands of IP addresses spread across cloud providers and residential proxies, each making only a handful of requests, all funnelled through one signature URL pattern. At its peak the swarm reached 10,630 unique IPs in a single hour, against a normal baseline of about 900.
Two findings changed the shape of the engagement. First, the scraping wasn't new — log analysis showed it had been running for weeks, with daily request volumes more than doubling over the previous ten days. Nobody had noticed. Second, and worse: the origin server was publicly reachable. Anyone who found its address could bypass the CDN and every firewall rule entirely and hit the server directly — and the logs showed someone already was.
AI agents on the forensics, an engineer on the calls
This is where the AI-first approach earns its keep. Agents sampled more than ten thousand attack requests and fingerprinted the swarm: a rotation pool of 67 realistic browser identities, fake search-engine crawlers mixed in, and request patterns built to slip under simple rate limits. Other agents swept the edge configuration in parallel and found a firewall rule that had silently never fired — its match pattern was one character off from the real URL.
The remediation was decided by a human and deployed the same evening: challenge rules tuned to the swarm's exact fingerprint — passing real customers invisibly and sparing legitimate search crawlers — and an origin lockdown so no request reaches the server without passing through the edge. Every fix was verified with live tests before we called it contained: direct-to-origin requests denied, real traffic flowing, scheduled background jobs confirmed running.
Three days, three root causes
Real incidents are rarely one problem. On day two the site slowed to a crawl again — and this time it wasn't the bots. Agents traced it to a background sync engine embedded invisibly inside two commerce plugins, which had quietly resumed a massive job and exhausted the server's CPU budget. It was found, paced with a proper lock, and verified within the hour.
Day two also delivered the swarm's true peak and a nasty trap: a dashboard toggle that silently dropped every protection to 'off', flooding the origin within minutes. We restored the wall in under ten, then root-caused the toggle itself — a stored setting from before the attack — and corrected it permanently so it could never land on 'off' again.
Everything was decided on evidence, not habit. A caching layer that 'should' have helped was A/B tested, shown to make pages slower on this particular host, and rejected. A plugin suspected of causing the slowdown was tested and cleared. And the big calls — hosting, scope, what to deliberately leave alone — were made by the client, with complete information on the table.
The defense that stayed behind
The engagement didn't end with a report. It ended with an automated defense: a small edge worker that watches the store's traffic for the swarm's one unfakeable signature — a sudden crowd of strangers, measured against the site's own seven-day baseline — and raises maximum protection within five minutes of spotting one. When traffic stays calm, it stands down on its own. And it never overrides a wall a human raised.
The swarm spent thirty hours burning through proxy IPs for zero yield, then gave up. Every change from all three days — every firewall rule, server setting, and line of configuration — is recorded in a change ledger with a tested rollback path. The client owns the fix, understands it, and can undo any piece of it.
Project stories
What these projects look like
Day 1 — Contain
Traffic at six times baseline by mid-afternoon. Agents fingerprinted the botnet, found the origin server publicly exposed, and surfaced a firewall rule that had never actually fired. Fingerprint-tuned challenge rules and an origin lockdown were deployed and verified the same evening.
The outcomeThe swarm hit a wall: challenge bypasses collapsed to nearly zero, and real customers never noticed a thing.
Day 2 — Root-cause
The site slowed again — not from bots. A hidden sync engine buried inside two commerce plugins had exhausted the server's CPU. Found, paced, and verified within the hour — alongside evidence-based testing that cleared one suspect and rejected a 'fix' that made things measurably worse.
The outcomePage renders back from over a minute to about two seconds, and a booby-trapped settings default disarmed for good.
Day 3 — Automate
An edge worker now watches the store's traffic against its own seven-day baseline, raises maximum protection within five minutes of an anomaly, and stands down after sustained calm — never overriding a decision a human made.
The outcomeThe botnet burned thirty hours of proxy IPs for zero yield and moved on. The watchdog is still there.
FAQ
Common questions
- Was the AI making the decisions?
- No — and that's the point. The agents did the investigation: sweeping logs, sampling attack traffic, fingerprinting the botnet, auditing configuration — in parallel, at a speed no human team matches. Every remediation was designed, approved, and verified by a senior engineer. Even the automation left behind acts within strict limits: it only raises protection on clear anomalies, only lowers walls it raised itself, and never touches anything a human set.
- Would this work for our store or platform?
- The method is platform-agnostic. This engagement was a WooCommerce store behind a CDN, but AI-agent forensics, human-decided remediation, verified fixes, and right-sized automation apply equally to Shopify, WordPress, and fully custom platforms. The tooling changes; the approach doesn't.
- What does an engagement like this cost?
- Incident work is scoped tightly. This entire engagement — from first alert through three root causes to the automated defenses — ran three days, and the client got containment, a full written record of every change with rollback paths, and a defense that runs on its own. If something looks wrong on your site right now, reach out through the contact form and we'll treat it as urgent.
Have a project for us?
Let's build something that works — across the whole stack.
Tell us what you're building — we'll get back to you fast.