Skip to content

The history of the botnet: from EarthLink Spammer to Mirai and beyond

· 20 min read
Copyright: MIT
history botnet malware
The word BOTNET in mono type over black with an orange underline and a timeline from 1999 IRC to 2025 residential proxies

A botnet is a simple idea with a long tail. Take a program that phones home for orders, install it on a lot of machines their owners do not control, and you have a single operator with the combined bandwidth, address space, and compute of a small country. The idea has not changed since the late 1990s. Almost everything else has: what the machines are, how they take orders, what they are rented out to do, and how hard they are to find.

The arc bends in one consistent direction. Early botnets were loud, centralised, and easy to behead once you found the controller. Each generation that got taken down taught the next one to spread its command channel out, to encrypt it, to generate its rendezvous points algorithmically, and eventually to stop looking like malware at all. The endpoint of that thirty-year process is a botnet you cannot distinguish from a real customer, because it is running on a real person’s router and selling itself as a residential IP. This post walks the line from IRC channel bots and the EarthLink Spammer through Storm’s peer-to-peer mesh, Conficker’s domain-generation algorithm, the Zeus banking-trojan economy, Mirai’s webcam swarm, and the proxy networks that now launder credential stuffing, ad fraud, and AI scraping through millions of hijacked home connections.

What counts as a botnet, and why IRC got there first

The word fuses “robot” and “network,” and the network part came first by accident. Internet Relay Chat, the text-chat protocol of the 1990s, had a problem: channels needed someone present to keep operator status and enforce bans, and humans sleep. The answer was a daemon that sat in the channel and acted on commands. Eggdrop, written by Robey Pointer and first released in December 1993, is the one everybody cites. It was benign. It guarded a channel, kicked abusers, kept the channel alive overnight, and was scriptable in Tcl so its operators could teach it new tricks.

The architecture Eggdrop established is exactly the one attackers would copy: a remote program that joins a channel, listens for commands typed by whoever holds the keys, and acts on a fleet of machines at once. By 1999 the benign version had a malicious twin. Pretty Park, a worm, and Sub7, a trojan, both reached the wild that year and both used IRC as their control channel. A compromised machine would quietly connect out to a server, join a channel only the operator knew, and wait. Pretty Park could report the host’s configuration, harvest email addresses and stored passwords, update itself, move files, and run denial-of-service floods on command. GTbot followed in 2000, built on top of a real mIRC client and capable of some of the first command-driven DoS attacks. The template was set: infect, connect out to IRC, idle, obey.

IRC was a natural fit for reasons that outlived it. The connection is outbound, so it punches through home NAT without port forwarding. One operator can address thousands of clients with one line of text. And the protocol is so light that a control bot fits in a few kilobytes. The weakness was equally structural. Every bot connected to the same server and channel, so the channel was the single point of failure. Find it, and you could watch the whole botnet, enumerate it, or kill it by taking the server offline. That weakness defined the next fifteen years of botnet engineering, which is mostly a record of operators trying to get rid of the single point.

The IRC bots proved you could command many machines at once. The EarthLink Spammer case proved there was money in it. Around 2000, Khan C. Smith, an operator working out of Tennessee, ran an operation that sent roughly 1.25 billion emails through EarthLink’s network, harvesting credit-card numbers and credentials from the recipients. EarthLink sued in 2001 under federal racketeering and computer-fraud statutes. Smith, who represented himself and largely failed to appear, was ordered in a 2002 judgment to pay EarthLink 25 million dollars, at the time the largest spam judgment the internet had produced. EarthLink estimated Smith had cleared around 3 million dollars from the scheme.

Two things in that case point straight at the modern botnet. First, the volume. A billion-plus messages is not something you send from your own mail server; it requires fanning the work out across many sending machines, which is what compromised hosts are for. Second, the purpose. This was not vandalism or bragging rights. It was a revenue business with a victim, a profit margin, and a court-measured loss. From this point forward the interesting question about any botnet is not “what does it do” but “who pays for the output,” and the answer drives everything downstream: spam, then click fraud, then banking theft, then DDoS-for-hire, then proxy rental. The hosting in 2000 was crude. The economics were already mature.

Spam became the original killer app for botnets because it monetised scale directly and tolerated bad output. A spam run does not need every bot online or every message delivered; it needs enough volume that a tiny conversion rate still pays. That tolerance for loss is why spam botnets could grow huge and sloppy while still turning a profit, and why the anti-spam side eventually drove so much of the early measurement work on botnet size.

It also set the rhythm of the whole field. Spammers needed fresh sending IPs because mail providers blacklisted the dirty ones, so they wanted as many compromised machines as they could hold and did not much care if any individual one got cleaned. Defenders responded by sharing blocklists and reputation data, which pushed operators toward larger and more disposable pools of hosts. That feedback loop, abuse drives reputation scoring, reputation scoring drives demand for fresh hosts, is the same loop that runs today between residential-proxy abuse and IP-reputation systems. Only the unit of currency changed, from a sending IP good for one spam run to an exit IP good for a few fraudulent logins.

Storm and the move to peer-to-peer

By 2007 the IRC weakness had become a liability. Defenders had gotten good at finding control channels and sinkholing them, and a botnet with one server was a botnet with one neck. The Storm Worm answered by getting rid of the server.

Storm appeared in January 2007, riding a spam campaign with subject lines about a windstorm battering Europe, which is where it got its name. The payload was a trojan, but the interesting part was control. Instead of every bot dialing the same channel, each infected machine joined a peer-to-peer overlay and connected to a subset of other infected machines, on the order of thirty to thirty-five peers each. Commands propagated through the mesh. No single node held a list of the whole network; each one knew only its neighbours. The overlay borrowed from the Overnet/Kademlia distributed-hash-table designs that file-sharing networks used, so a bot looking for orders published and searched for keys in the DHT rather than connecting to a fixed address.

Centralised (IRC) Peer-to-peer (Storm) C2 one neck to cut no single list of members *The structural shift Storm forced. A star topology dies when the centre is sinkholed; a mesh keeps running and hides its own size, because no node can enumerate the whole network.*

The mesh made Storm hard to measure and harder to kill. Estimates of its size ranged wildly, from a million machines to tens of millions, precisely because no one could get a full count from inside. At its 2007 peak researchers attributed a large share of the world’s spam to it, and Microsoft reported it accounted for a meaningful fraction of malware seen on Windows machines that year. Defenders eventually fought back by polluting the DHT, injecting fake peers and poisoning lookups so bots could not find real commands, and the network declined through late 2007 into 2008. The lesson stuck. The single point of failure was gone, but a new one had appeared: the rendezvous mechanism itself. If you could pollute or predict how bots found each other, you could still break the botnet without finding a server. The next major worm attacked that problem directly.

Conficker and the domain-generation algorithm

Conficker is the worm that made domain-generation algorithms famous, and the timing of its first appearance is the reason this post carries the date it does. On October 23, 2008, Microsoft shipped an out-of-band patch, MS08-067, for a remote-code-execution bug in the Windows Server service. Within weeks a worm was exploiting that exact flaw on the machines that had not patched, and by January 2009 estimates of the infected population ran from roughly nine to fifteen million machines across more than 190 countries. Microsoft put a 250,000-dollar bounty on the authors in February 2009. They were never caught.

The technical story is the command channel. Conficker did not hardcode a server, and it did not build a peer overlay, at least not at first. It generated its rendezvous points. Every day each bot ran a domain-generation algorithm seeded from the current date and produced a list of pseudo-random domain names; it then tried to reach a controller at those domains. The A variant produced 250 domains a day across a handful of top-level domains. The operators only had to register one of that day’s domains to push an update, while defenders would have had to pre-register or block all of them to cut the channel. When researchers reverse-engineered the algorithm and the Conficker Working Group began registering the upcoming domains ahead of the bots, the operators responded in the C variant by widening the daily pool to 50,000 candidate domains across eight TLDs, of which each bot tried 500, making pre-registration economically hopeless. The C variant also added a peer-to-peer update path as a backup, so even blocking every domain did not guarantee silence.

date seed 2009-01-01 DGA PRNG + TLDs qwpzkf.org NXDOMAIN mbxlra.net NXDOMAIN vhzqtp.info REGISTERED jklmnq.biz NXDOMAIN ...247 more NXDOMAIN operator registers one; bot finds it *A DGA inverts the registration economics. The bot tries a fresh daily list; the operator registers a single domain to give an order, while a defender has to pre-empt the entire list.*

DGAs solved the rendezvous problem so well that they became standard equipment. The trade-off is that a DGA is also a fingerprint. A normal machine does not emit hundreds of NXDOMAIN responses a day for gibberish hostnames, so the very burst of failed lookups that keeps a botnet reachable also lights it up on a DNS monitor. Threat hunters learned to catch DGA traffic by its statistical signature, the high entropy and short lifetime of the names, which is the same trick that later fed into fast-flux detection and the broader use of DNS telemetry in JA3 and JA4 threat hunting. Conficker’s other legacy is institutional. The Conficker Working Group, a coalition of Microsoft, ICANN, registries, and security vendors, was an early model of the cross-industry takedown that later operations against Zeus and Mirai would formalise.

Zeus and the banking-trojan economy

If spam was the first business model and DDoS the second, the third was theft, and Zeus is its defining product. Zeus is not really one botnet. It is a toolkit that many operators used to build their own botnets, and that distinction is the whole point. It first surfaced in July 2007, used in a breach of the US Department of Transportation, and over the next several years it grew into the largest credential-stealing operation on the internet. Security firm Damballa estimated Zeus had infected around 3.6 million PCs in the US alone by 2009. In June of that year, researchers found a single Zeus campaign holding more than 74,000 stolen FTP credentials for sites including Bank of America, NASA, Amazon, Oracle, and Cisco.

The technical method was the man-in-the-browser. Zeus injected itself into the browser process and hooked the functions that handle form data, so it could read what you typed before it was encrypted by TLS and rewrite what you saw after the server’s response was decrypted. The customisation lived in a configuration file of web injects, snippets of HTML and JavaScript keyed to specific banking URLs. When the victim logged into a targeted bank, Zeus would silently splice the operator’s fields into the real page, asking for a card number or a one-time code that the genuine site never requested, and the request would carry the bank’s real certificate because it was the real page. None of the network-layer defenses applied. The theft happened inside the browser, after decryption, on a page the user trusted.

Two events turned Zeus from a product into an ecosystem. In May 2011 the full Zeus source code leaked to underground forums as a freely downloadable archive; a kit that had sold for thousands of dollars was now free, and it seeded hundreds of derivative banking trojans. And the lineage moved to peer-to-peer. GameOver Zeus, built on the leaked base, replaced the central configuration server with a P2P network and a DGA backup, applying Storm’s and Conficker’s resilience lessons to a theft platform. It was used to steal more than 100 million dollars and to distribute the CryptoLocker ransomware. Taking it down required Operation Tovar in June 2014, a joint effort of the FBI, the UK National Crime Agency, Europol, and private partners, which sinkholed the P2P network and seized the DGA domains in a single coordinated strike. The takedown worked, but the architecture was the point: only a multi-party operation hitting both the peer network and the domain backup at once could do it.

Browser process form fields TLS layer Zeus hook web injects Bank server real cert read before encrypt inject after decrypt *Why TLS did not help. Zeus sat inside the browser, reading form data before the TLS layer encrypted it and rewriting the page after the layer decrypted the bank's genuine, correctly-certified response.*

The banking-trojan era is where the botnet learned to be invisible at the application layer, and the techniques never went away. The web-inject model is the direct ancestor of Magecart-style web skimming, and the broader move toward stealing credentials in bulk feeds straight into the credential-stuffing mechanics that those stolen logins later fund.

Mirai and the internet of insecure things

Then the botnet changed substrate. For two decades the typical bot was a Windows PC. Mirai’s insight, in 2016, was that the cheapest and least-defended computers on the internet were no longer PCs. They were IP cameras, digital video recorders, and home routers, embedded Linux devices shipped with hardcoded telnet logins and never patched, sitting on fat residential uplinks, and counted in the tens of millions.

Mirai surfaced around August 2016, flagged early by the volunteer group MalwareMustDie. Its propagation was almost insultingly simple. Each bot scanned pseudo-random IPv4 addresses for an open telnet port, 23 or 2323, and on a hit it ran through a built-in dictionary of 62 username and password pairs, the factory defaults of the cheap-device market: root/xc3511, admin/admin, root/root, and so on. A successful login did not infect the device directly. The bot reported the working IP and credential to a report server, and a separate loader logged in afterward, identified the CPU architecture, and pushed the matching binary. Splitting scan from install kept each bot tiny enough to run on a camera with a few megabytes of RAM. The seven-month USENIX Security study of Mirai reconstructed this loop from the leaked source and tracked the botnet’s growth to a peak around 600,000 simultaneous infections, hitting nearly 65,000 devices in its first 20 hours.

The output was raw bandwidth. In September 2016 a Mirai botnet hit the security journalist Brian Krebs’s site with a flood measured at 623 Gbps, then one of the largest DDoS attacks ever publicly recorded, and shortly after, the French host OVH reported an attack approaching 1 Tbps. The defining event came on October 21, 2016, when Mirai targeted the authoritative DNS provider Dyn. Because Dyn served name resolution for a large slice of the consumer internet, the attack made Twitter, Reddit, Netflix, GitHub, Spotify, and others unreachable for users along the US East Coast, even though those companies’ own servers were fine. The thing that broke was the naming layer, which is the topic of our dedicated Mirai post and connects to the wider history of DDoS.

What makes Mirai a permanent fixture rather than a 2016 footnote is the source release. On October 1, 2016, a HackForums user calling himself Anna-senpai posted the full Mirai source code, claiming he usually pulled around 380,000 bots from telnet alone. The author, later identified as Paras Jha, did it partly to muddy attribution as researchers closed in. Jha, Josiah White, and Dalton Norman pleaded guilty in December 2017; their original motive, by their own accounts, was advantage in the Minecraft DDoS-protection market rather than any grand design. But the leaked code became a public toolkit. Every IoT botnet since has cribbed from it, and Mirai variants still appear in record-breaking attacks years later, which brings the story to the present.

The convergence: residential proxies, proxyware, and the laundering of traffic

The newest turn is the most consequential and the least dramatic to watch. A modern botnet’s most valuable output is often not a flood of packets or a stolen password. It is the IP address itself. An infected home router or phone is a residential IP, and a residential IP is laundered legitimacy: it belongs to a real ISP customer in a real city, it carries clean reputation, and traffic that exits through it looks like an ordinary person browsing. That is precisely what credential stuffing, ad fraud, sneaker scalping, and large-scale scraping all need in order to slip past defenses that key on datacenter ranges and ASN reputation.

So the botnet became a proxy network, and the line between malware and a commercial product blurred. The 911 S5 service is the clearest case. US authorities dismantled it in May 2024, arresting its administrator Yunhe Wang and describing a network of roughly 19 million compromised IP addresses across more than 190 countries, built by bundling a backdoor into free VPN apps like MaskVPN and DewVPN and into pirated software that installed the proxy client silently. Wang was alleged to have taken in about 99 million dollars selling access. The compromised machines were not used to attack anyone directly. They were rented out as exit nodes, and customers paid to route their own traffic, including fraud and worse, through someone else’s home connection.

The IoT swarms made the same pivot. Aisuru, an IoT botnet first identified in August 2024 and built on Mirai-descended techniques, grew to compromise at least 700,000 devices and produced some of the largest DDoS attacks ever recorded, including a flood near 30 Tbps and a 6.3 Tbps hit on Krebs that Google described as the largest it had mitigated at the time. Then its operators changed business. Rather than rent the swarm only for attacks, which draws law-enforcement attention and burns infrastructure, they overhauled it to sell the devices as residential proxies, a quieter and steadier income. Reporting tied that proxy capacity to large-scale data harvesting for AI projects, with scrapers routing through hijacked home IPs to dodge detection. The botnet that once existed to break the internet’s DNS now exists, in part, to make automated traffic look human.

1993 Eggdrop: benign IRC channel bot 2000 EarthLink Spammer: botnets earn money 2007 Storm: peer-to-peer control mesh 2008 Conficker: domain-generation algorithm 2011 Zeus source leaks: theft as a toolkit 2016 Mirai: IoT swarm, terabit DDoS 2024 911 S5 / Aisuru: rented residential proxies *Thirty years in one column. Each row is a response to the takedown of the row above it, ending where the botnet stops looking like malware and starts looking like a proxy customer.*

This convergence is why a post about botnet history sits in a blog about crawling and bot detection at all. The residential-proxy market that fraud operators and aggressive scrapers buy from is, at its supply end, frequently the same pool of compromised machines that started life as a DDoS or banking botnet. The detection problem on the defender’s side, distinguishing a hijacked-home-router exit from a real residential user, is the same whether the traffic above it is fraud, ad abuse, or content scraping. The botnet’s history and the history of web scraping have merged at the IP layer.

What thirty years of botnets actually taught

Read the arc end to end and one pattern dominates. Every defensive win taught the offense a structural lesson, and the lesson was always about the command channel. Sinkhole the IRC server and the operators build a peer-to-peer mesh. Poison the mesh and they generate domains. Pre-register the domains and they widen the pool past the point of pre-registration. Seize the infrastructure with a coordinated international takedown and they move the bots into a market where the bots are the product and the operator never needs persistent infrastructure at all. The botnet did not get smarter in some abstract sense. It got harder to find, one takedown at a time, and the people doing the finding wrote the curriculum.

The substrate shift matters as much as the control shift. The move from PCs to IoT devices was not a clever exploit; it was a demographic observation. The most numerous, least-defended, best-connected computers stopped being the ones people sat in front of. A security camera has no screen to show a warning, no user to install a patch, no antivirus, and a fat uplink, and there are billions of them. Mirai did not break new ground technically. It noticed where the soft targets had moved and pointed a 1990s technique, telnet and default passwords, at them.

The endpoint is the quiet part. The most valuable botnet in 2026 may launch no attack you can see. It sells the one thing a compromised home machine has that no datacenter can buy: the unremarkable legitimacy of a real residential IP, indistinguishable from the person whose router it runs on, right up until that traffic shows up in your logs looking exactly like a customer.

Sources & further reading

Further reading