The Botnet With One Member

In 2013 I built a botnet with a single member, and within a day it was taking connections from Tokyo, Helsinki, Moscow, and a hosting company in Amsterdam. The single member was a virtual machine on the desk in front of me. I knew every machine in the botnet, because there was only one and it was mine, which is what made the traffic from Finland hard to account for.

I was a systems engineer at FireEye then, writing a series meant to show how little skill it now took to run commodity malware. The brand is gone now, its products business merged with McAfee Enterprise and rebranded Trellix, but the point of the series has aged better than the company did. To show how weak the detection was, I built a research botnet from an off-the-shelf kit and submitted the payload to a public scanning service, so I could count how many antivirus engines caught it. Then the callbacks started arriving from around the world, to a command-and-control server that should have had exactly one caller.

My first reaction was the ordinary one. Something has gone wrong, I have been found, take it down. So I took it down, stood a fresh server up on another continent, rebuilt the payload, and this time pointed it at a file that said, in plain text, “This is not a botnet. This is for research. Please move along.” The connections came back. So I did the boring, honest thing, and logged where they were coming from.

They were not attackers. They were defenders, or rather the defenders’ machines. Antivirus labs were pulling my sample from the public scanning service, reading the command-and-control address baked into it, and connecting to see what was there. They were building their signatures and their blocklists by mining the same public well that everyone uploads suspicious files into. Sensible work. It also meant their pipeline had an intake they did not control, and anything with an intake it does not control can be fed.

There was a second thing in the logs, quieter than the first. I had built two research botnets, one from the well-known ZeuS family and one from a rarer family. The ZeuS server drew callbacks from all over. The other drew almost none. The automated defence was concentrated where the volume was, on the family everyone already knew, and comparatively blind to the one that was uncommon. If you wanted to be seen, ZeuS was the way. If you wanted not to be, the answer was sitting in my logs.

Here is the part you already know, so I will be quick about it. Offensive capability has become cheap. In 2013 I built a working botnet in about fifteen minutes from a pirated kit, with no real skill involved. In 2026 an agent will do the equivalent from a few vague prompts, researching the target, writing the exploit, and tidying up after itself, and there is a growing stack of incident reports to prove it. This is close to the most repeated sentence in security right now, and it is true, and it is not the interesting part. The industry has been saying it loudly enough that I have nothing to add to the volume.

What the loud version misses is the other half of the same curve. Everyone is counting how cheap offence has become. Almost nobody is saying that defence has become cheap in exactly the same way, and that the automated part of defence is the part you can feed. My accident in 2013 was a small, early version of this. A defensive pipeline was making decisions by taking in an open channel, and the channel could be filled with whatever I chose to put in it. In 2026 the same shape is everywhere and it has a far larger appetite. Reputation systems that score a file or a domain, telemetry pipelines that classify behaviour, models trained on public samples and public chatter: each one learns from an intake it does not fully control, and each one can be taught. The 2013 version cost me an afternoon of confusion. The 2026 version is a design property nobody selling the product wants to say out loud, because the automated defender that learns from the open web is also the automated defender the open web can lie to.

Which points at the thing worth taking from all of this. When the capability is cheap and roughly equal on both sides, the capability stops being the advantage. I had no offensive edge in 2013. Anyone could have run that kit. My edge, such as it was, came from understanding the channel: that the defenders’ machines ate public uploads, and that a public upload was therefore a way to talk to them. The advantage lived in the coupling between the two automated systems, not in either system by itself. Carry that forward. When the attacker and the defender are both running the same cheap models, the horsepower is symmetric and dull. The asymmetry is in who understands how the other side’s automation takes in signal, what it trusts, and where its intake sits open. The edge is the channel.

A security veteran will object that none of this is new, that understanding the defender’s logic is as old as the trade, and about 2013 they are right. What has changed is that the defender now learns, continuously, from a channel that stays open. The one-time reconnaissance of the old red team becomes a conversation you can hold with the machine, correcting it, nudging it, feeding it a diet, for as long as it keeps taking things in. Cheap symmetric capability did not invent the channel. It industrialised it, on both sides, and pointed it at systems that rewrite themselves from what they are fed.

The cheap attack was never the risk worth losing sleep over. We built the automated defence on the same curve as the automated attack, and a system that learns from an open channel can be taught by anyone who takes the trouble to understand the channel. The botnet with one member was never a story about how easy attacks had become, though that is how I told it in 2013. It was the first time I watched the defenders’ machine believe something I had told it, and go looking, from Helsinki and Tokyo and Amsterdam, for a threat that was a virtual machine on my desk with a note on it asking them to move along.