On a whim, I investigated the current state of botnet design.

Here are two listings of botnet source code.

Here is a user's guide to one.

Here is a pretty good white paper (and supplement). Here is a book on them.

It appears that the current state of the art is something like this:
* all bots are deployed as a trojan or remote code execution payload
* some have a compression loader (e.g. UPX) to help prevent AV detection
* all bots have a compiled-in reference to a couple IRC servers w/ channel names and passwords
* some bots have a modular payload design
* some bots allow for self-updates
* some bots have basic built-in payloads and self-propogation ability
* some botherders have a stripped-down or otherwise modified version of IRCd used to allow a large number of bots to connect (e.g. 80k) and to detect spying
* authentication is via cleartext login & password in the compiled-in channel, meaning that if an attacker can spy on the channel (by running strings on a captured bot) and possibly gain ops, they can send an update command to the bots and thus take them over with their own bot code

To me, this seems pretty atrocious as a design. I presume that there are at least some better botnets not available in open source.


As a purely academic exercise, here is my opinion of how to design a better system.
* use completely modular design
* have completely decentralized c&c, such that each node - including the command origination node - connects only to a small number of other nodes (<10) and does not know who they are
* use public key encryption for message passing, such that each bot generates its own key, and each bot knows the keys of its predecessors and also of the master, allowing for completely crypted, authenticated traffic and deniable master node
* bots have multiple modules for communication, preferably using both sync (for online commands) and async (for announcement) methods - e.g. XMPP, Gnutella, tor, commentspam, etc)
* bots post their contact info, crypted to their predecessors + the master, and including their own public key, in multiple methods
* preferably use cross-platform-compatible code (maybe even... *shudder*... Java. Or less horrendously, jRuby - it'd be metasploit-compatible). If that's not feasible, C++ would probably be best.
* stub out as much as possible to good external projects (like Metasploit, tor, et al)
* have some kind of Core Impact like variant on Metasploit that allows each bot to automatically scan, detect, and exploit vulnerable hosts (if possible, taking advantage of the extra data available to it)
* have some kind of mutex to prevent multiple infection of the same host but still prevent easy identification of infection (a hard problem - most likely a matter of steganography)
* have self-controls to prevent the bot ever using enough system resources to adversely impact users' performance
* patch the holes it exploits, or otherwise do things that both benefit the user (resulting in better performance & lower chance of detection) and cover up its own tracks / holes (again lowering detection chance as well as preventing other exploits from doing bad things [that get one detected], competing for resources, or attempting to hijack the bot)


P.S. Dear NSA/FBI/SS/employers: please read this as advice for how to think about (& thus prepare for) next-generation botnets, rather than evidence of any kind of criminal intent on my part. I'm a whitehat; DDoS is something I help to prevent. Someone *will* make and deploy this maliciously; I'm hardly the only smart guy out there, and unlike some people, I have no connections to organized crime that would allow me to get away with the real stuff. (Money laundering is hard.)

You're better off thinking about it before that happens.