A UK retailer’s monitoring goes amber at 09:12 on a Tuesday: origin CPU is fine, cache hit ratio has fallen from the high nineties to about sixty per cent, and the search endpoint is queuing. No single source IP address stands out. Nothing has tripped a rate limit. Twenty minutes later the site is timing out and the phone lines are busy. Most explanations of a botnet DDoS attack explained the attacker’s side of this and stopped there: infected devices, command and control, a big flood. That is the easy half. The half that decides whether you stay online is what that traffic looks like when it lands on your network edge, your application and your authoritative domain name system (DNS) servers, and why the same botnet produces three completely different sets of symptoms.
What a botnet is, and how a pile of infected devices becomes an attack
A botnet is a collection of compromised internet-connected machines under the control of one operator. Three parts make it work. Infection, usually through default credentials, unpatched firmware or a commodity malware loader. Command and control (C2), the channel the operator uses to issue instructions, which may be an internet relay chat channel, an HTTPS endpoint or a peer-to-peer mesh. And the herder, the person or crew who owns the panel and decides where the traffic goes.
Scale here is not theoretical. Botnets have historically been measured in the hundreds of thousands of compromised hosts, with some estimates reaching a million zombies, and the population turns over constantly as devices are cleaned, rebooted or replaced.
Most attacks are rented, not built
Very few of the attacks that hit UK organisations come from someone who wrote the malware. They come from booter and stresser services, where the buyer picks a target, a vector and a duration from a dropdown. That changes the shape of the incident. Rented attacks tend to run in bursts of minutes to an hour rather than days, because the buyer is paying by time. Target selection is often opportunistic, or driven by a grudge, a competitor or an extortion campaign rather than by any strategic value in your estate. And the person on the other end is frequently not technically sophisticated, which matters when a ransom note arrives.
Botnet floods versus reflection and amplification
The two get conflated constantly. A botnet flood is traffic generated by compromised machines and sent directly at you. A reflection attack sends spoofed requests to third-party services (open DNS resolvers, network time protocol servers, memcached instances, connectionless lightweight directory access protocol endpoints) with your address in the source field, so the responses land on you. Amplification is the multiplier: a small query producing a much larger answer.
Reflection needs almost no bots at all. A handful of hosts on networks that permit source address spoofing can generate hundreds of gigabits per second by borrowing other people’s bandwidth. That is why the distinction is operationally useful: reflection traffic comes from a limited set of identifiable service ports and can often be dropped upstream on protocol and port alone, while genuine botnet traffic arrives from real addresses, over real TCP sessions, and increasingly with a valid transport layer security (TLS) handshake attached.
Node count is the wrong headline number
Vendors and journalists quote node counts because they are dramatic. What actually determines whether you fall over is aggregate request rate, the protocol chosen, and the cost of the thing being requested. Ten thousand cloud instances doing full TLS handshakes against a login page will hurt far more than half a million home routers sending malformed UDP packets that your upstream drops for free.
The device mix has changed, and the old blocking reflexes broke with it
The 2016 generation of botnets was overwhelmingly consumer hardware. US-CERT’s alert TA16-288A, published in October 2016, described Mirai as scanning for internet-of-things devices still running factory default credentials, principally digital video recorders, IP cameras and routers. Huge node counts, low output per node, spread across almost every country with broadband.
Compromised cloud and hosting instances are a different animal. Fewer nodes, but each with a gigabit or more of egress, modern CPUs capable of thousands of TLS handshakes per second, and an IP address that belongs to a reputable provider rather than a residential range. Reputation lists do not help you. Blocking the autonomous system means blocking a major cloud, which is where a good deal of your legitimate API traffic also lives.
Then there are residential proxy networks. Some are outright criminal, some are commercial services whose users consented in a software development kit buried in a free app. Either way, the attacker rents exit nodes on real consumer broadband lines, in the country of your choosing, driving real browser engines. IP reputation scoring, country blocking and simple JavaScript challenges all degrade badly against them.
Which brings us to the reflex every incident call reaches for at minute fifteen: block the bad countries. Against a 2016 IoT botnet it bought you something. Against a device mix that includes UK residential exits and instances in Ireland and Frankfurt, geo-blocking removes customers and leaves the attack broadly intact. Worse, it feels like action, so people stop looking for the real signature.
What one botnet looks like on each of your three surfaces
Network and transport
SYN floods that exhaust connection state, UDP floods that fill the pipe, ACK floods designed to look like established sessions to a stateful firewall. The variant that catches people out is carpet bombing: instead of hammering one host, the traffic is spread thinly across every address in your /24 or across several prefixes. No single destination crosses the per-IP threshold that triggers detection, but the aggregate saturates the upstream link or the edge router’s packet-per-second ceiling. Flow data shows it clearly. Per-host alarms do not.
Application layer
Here is the arithmetic that ought to be on a slide in every procurement meeting. Thirty thousand nodes, ten requests per minute each, is 300,000 requests per minute, or roughly 5,000 requests per second. Point that at an uncached search endpoint that costs the database 200 milliseconds per query and the connection pool is gone in seconds. Now look at any individual source: ten requests a minute, one every six seconds, from a residential address with a plausible user agent. That is slower than a real shopper browsing a category page.
Attackers pick the expensive endpoints deliberately: internal search, faceted filters, login and password reset, add-to-basket, anything with a query string that defeats the cache. Bandwidth at the edge may look unremarkable throughout.
Authoritative DNS
The surface almost nobody has budgeted for. On 21 October 2016 a Mirai-based botnet attacked the managed DNS provider Dyn; the widely reported consequence was that users could not reach services including Twitter, Reddit and Spotify, none of which were themselves under attack. Their web tiers were fine. Name resolution was not.
Two vectors dominate. Straight query floods, and the random subdomain or “water torture”attack, where the botnet requests a8f3k2.yourdomain.co.uk, then another random label, then another. Recursive resolvers cannot serve those from cache, so every query is forwarded to your authoritative servers, and your own customers’ resolvers become the delivery mechanism. Your web server sees nothing. Your site is still down.
The pattern in the field is consistent: an organisation buys a reverse proxy for the website, leaves DNS with the domain registrar on whatever plan came free with the renewal, and discovers during the incident that DNS DDoS attack protection was never part of the contract. If your DNS sits on two non-anycast nameservers at a registrar, that is the weakest link in your estate, and it is usually the cheapest one to fix.
One botnet can be pointed at all three surfaces in sequence during a single incident. Fifteen minutes of SYN flood, a pause while someone reads the effect, then an HTTP flood, then DNS when the HTTP flood stops working. Treat the incident as one campaign, not three unrelated events.
Reading the evidence: botnet flood, flash crowd or badly behaved crawler
Three things produce a traffic spike, and only one of them is an attack. The separators are behavioural, not volumetric.
- Source diversity and depth. A flash crowd (a newsletter send, a broadcast mention, a viral post) has concentrated referrers and normal session depth: landing page, then two or three more pages. Botnet traffic has extreme source diversity and session depth of one, repeated.
- User agent and header spread. Real populations produce a long, messy tail of browser versions. Botnets produce either an unnaturally narrow set or an unnaturally uniform distribution, and often header ordering that does not match the browser being claimed.
- Cache hit ratio. Genuine traffic raises hits. Attack traffic aimed at query strings and search collapses the ratio while requests climb. That divergence is one of the earliest reliable signals.
- Conversion behaviour. Sessions up, transactions flat is an attack or a scraper. Sessions up, transactions up is a good day.
- Robots and rate. A misconfigured crawler identifies itself, comes from a narrow set of prefixes, and usually respects a 429 response. A botnet does none of that.
Look in this order: edge or content delivery network logs for endpoint and cache behaviour; NetFlow or sFlow from the border routers for packet rates and destination spread; authoritative DNS query logs for NXDOMAIN volume; and origin connection counts. Then the trap. Per-IP rate limiting is close to useless against a wide botnet, because every source is under any threshold you could set without harming real users. Detection has to run on aggregate behaviour and endpoint cost, not per-source counters.
One diagnostic worth committing to memory: if the origin’s 5xx rate is climbing while edge traffic looks normal, the attack is bypassing the proxy. Someone has your real origin address.
Which defences actually stop botnet traffic
Match the tool to the layer, because none of them covers everything.
- Reverse proxy or CDN for HTTP and HTTPS floods. It terminates TLS, applies challenges and behavioural rules, and absorbs application-layer volume. It does nothing for traffic sent directly to your IP addresses.
- BGP-based cloud DDoS scrubbing for network and transport layer floods and carpet bombing. Your prefixes are announced to the scrubbing network, dirty traffic is filtered, clean traffic returns over GRE tunnels or a direct connection. Note the entry requirement: for IPv4 you generally need to control a /24 you can announce, which rules the model out for most organisations sitting on provider address space.
- Hosting-level filtering is a partial measure. It helps with obvious volumetric noise and costs nothing extra. It rarely includes application-layer inspection, and the provider’s ultimate defence is often a remotely triggered blackhole of your address, which completes the attacker’s objective for them.
Always-on versus on-demand deserves a firm position rather than a balanced shrug. On-demand diversion costs you detection time plus BGP convergence plus tunnel establishment, and a rented botnet reaches full rate in under a minute. Carpet bombing makes it worse, because the per-host thresholds that trigger diversion may never be crossed. If your risk profile includes network-layer attacks on your own prefixes, always-on is the honest choice; the trade-off between always-on and on-demand protection is mostly a question of how many minutes of downtime you can absorb, and what a time-to-mitigate SLA actually commits the provider to.
Origin IP leakage beats raw volume
More proxies are bypassed by leaked origin addresses than by attack size. The leaks are boringly consistent: an old A record still in passive DNS history; a mail server on the same address as the web application, advertised in SPF and MX records; a certificate transparency log entry (public by design under RFC 6962) exposing staging.yourdomain.co.uk; a development host, a status page, or a direct-to-origin API subdomain that was never proxied.
The fix takes an afternoon and almost nobody does it at onboarding: change the origin IP addresses after moving behind the proxy, then lock the origin firewall so ports 80 and 443 accept traffic only from the provider’s published ranges. Everything else gets dropped. If your provider does not publish those ranges, that is worth asking about before signing.
What to ask a provider, and what to do when the note arrives
Ask whose network you are actually buying. Resale chains are common, and the capacity figure in the deck, the SLA and the escalation path may each belong to a different company. Ask how many layers sit between your contract and the engineer who can change a mitigation policy.
Pin down what “managed”includes: onboarding and rule tuning, traffic baselining, named contacts, who raises the ticket, and specifically who is authorised to act at 03:00 without waking your CTO for sign-off. If nobody on their side can change policy without your approval, you have bought monitoring, not management. The detail of what a managed DDoS contract should specify in the UK is worth reading before the first renewal, not after the first incident.
Then judge their attack reports, which is the cheapest evidence available to a buyer. A useful report shows source distribution by network and geography, a vector breakdown, peak packet and request rates, and the exact mitigation applied with timestamps. A bandwidth graph with a red line on it is marketing. Ask for a redacted sample during procurement, alongside any vendor claims you intend to test against real attack behaviour.
Ransom demands
The pattern is familiar: a demonstration burst lasting a few minutes, then an email demanding cryptocurrency and naming a return date. That demonstration is evidence. Capture the flow data and the edge logs from those minutes, because they tell you the vector mix, the approximate node count and whether the operator has application-layer capability or only volumetric noise. That is a better basis for deciding what to buy than any threat in the email.
In the UK, denial of service offences are prosecuted under the Computer Misuse Act 1990, section 3 having been amended by the Police and Justice Act 2006 to cover unauthorised acts intended to impair the operation of a computer. Report to Action Fraud (Police Scotland if you are in Scotland) and follow NCSC guidance on denial of service attacks. Paying is not recommended by UK authorities, and the practical argument is stronger than the moral one: payment confirms the target pays, and the operator selling you peace has no mechanism to stop a second crew, or himself, coming back next quarter. Spend the money on capacity instead, and rehearse the first sixty minutes of an incident before you need it.
Frequently Asked Questions
How is a botnet DDoS attack different from a reflection or amplification attack?
A botnet flood is generated directly by compromised machines, so the source addresses are real and the sessions can be genuine TCP or TLS connections. Reflection abuses third-party servers by spoofing your address as the source, so the responses land on you, and amplification is the multiplier when a small request produces a large answer. Reflection needs very few attacker-controlled hosts and is usually easier to filter upstream by protocol and port.
How can I tell a botnet attack from a sudden spike in genuine traffic?
Compare behaviour, not volume. Genuine spikes carry concentrated referrers, normal session depth, a rising cache hit ratio and some conversion; botnet traffic shows enormous source diversity, single-request sessions, a collapsing cache hit ratio and flat transactions. Authoritative DNS query logs and NetFlow will usually confirm the picture within a few minutes.
Does blocking countries or IP ranges stop a botnet DDoS attack?
Rarely, and it often costs you customers. Modern device mixes include compromised cloud instances in mainstream hosting regions and residential proxy exits inside the UK, so country blocking removes legitimate buyers while leaving much of the attack in place. Filtering has to work on request behaviour and endpoint cost instead.
Why does my DDoS protection stop working even though the proxy is switched on?
Almost always because the attacker has your origin IP address, from an old DNS record, a mail server sharing the host, a certificate transparency entry or an unproxied staging subdomain. Traffic then goes straight past the edge, which is why origin 5xx errors climb while edge graphs look calm. Rotate the origin address and restrict the firewall to your provider’s published ranges.
Should I pay a ransom demand attached to a botnet DDoS attack?
UK guidance from the NCSC and Action Fraud does not recommend paying, and payment marks you as a target that pays. Preserve the logs from the demonstration burst, report the incident, and put the money towards scrubbing capacity and DNS protection instead.
“`