An anonymized incident from our operations log. Details are generalized; the timeline and techniques are real.
One afternoon, monitoring flagged a client website burning far more CPU and memory than normal. Forty minutes of log analysis later, the picture was clear: 9,672 unique IP addresses had hit the site in a 40-minute window — a botnet, and it wasn’t trying to break in. It was doing something sneakier.
The attack: search-spam poisoning
The bots were firing thousands of junk queries at the site’s built-in search — 2,269 requests in the sample we analyzed, 2,264 of them unique. Each junk query produced a crawlable search-results page. Left alone, search engines would index thousands of garbage pages under the client’s domain, diluting its rankings and reputation.
What we did, in order
- Contained first. Rate-limited the abusive patterns and blocked the keyword signatures behind the junk queries, returning clean
404responses — so search engines drop the spam URLs from their index instead of crawling them. - Protected the index. Verified no legitimate search URLs were affected; legitimate visitors never saw a difference.
- Stabilized the server. Isolated the cause of the CPU/memory spike within a two-hour window and restored normal headroom.
- Reported. Delivered a written incident report: timeline, traffic analysis, actions taken, and preventive recommendations — written for management, not just engineers.
What we changed permanently
- Keyword-based request filtering now blocks known spam patterns before they reach the application.
- Tighter monitoring thresholds, so the next anomaly is caught in minutes.
- Staged (staging → production) update routines, so security patches land quickly without risking the live site.
The lesson
Most website attacks aren’t dramatic break-ins. They’re slow, automated abuse that quietly eats performance and search rankings. The difference between a bad afternoon and a bad quarter is whether someone is watching — and knows what to do. That’s what a care plan is for.