There is one other possible way to go about solving this problem, and that is to create no rootkit at all. I mean, what is a rootkit in essence? Something that allows you to maintain control over a machine once you have obtained access to it in some way(either by tricking the user, exploiting a vulnerability, or whatever). So, going on that, all we really need to do is inject a vulnerability into a permanently running and internet-accessible service. One way would be to patch the code in say, DCOM, to re-open one of the many now patched vulnerabilities that had been discovered a while back. Then, instead of having the command and control apparatus on each infected client, you maintain that apparatus on the controller's system, and it exists in the form of shellcode or shellcode that downloads, runs, and deletes some more complex application. Now, obviously simple code patching is very easy to detect, and it is just a simple PoC example of how this might be accomplished. But there are other things that can be manipulated at a very low level in the kernel, like say, manipulating some static NDIS buffers that are used in handling some extremely rare ICMP packet type to cause an overflow when they are accessed and used in the kernel.

Obviously the above methods have the limitation that when the machine is shut down, the 'rootkit' dies. But there are other possible, even more subtle reboot-resistant methods, such as changing configuration files, or maybe even editing the raw NTFS disk structure to, when requesting access to some specific file (like say on a web server), actually redirect the reads/writes to some important system file that can be used to take over the system. The possibilities here are really as expansive as is your imagination, and there are definitely some methods I have thought of that are resilient enough to work practically in a lot of real world challenges. If done correctly, it would be impossible to detect such a rootkit in a generic way. Obviously it will still be detectable if a rootkit detector specifically discovers and analyzes your specific system, but in this case, since the possibilities are so endless, and the primary coding work is done on the controller side, it is extremely easy to change the type of exploit that you use to maintain access, and this makes your rootkit much more potentially dynamic and versatile.