Well that's kind of hurtful...

It's pretty simple - the attackers install backdoor trojans which phone home to various command-and-control (C2) servers. In some cases when the USG identifies a high-value (i.e. involved in corporate and/or government espionage) C2 in the U.S. they get a warrant to monitor all network traffic to and from that host at the upstream. Once you have netflow or pcap data you can pretty easily tell who the compromised companies are when you see their corporate firewall IP hitting the C2 at regular intervals.

Private-sector researchers do this as well sometimes, but you need cooperation from the upstream. Or in some cases, the attackers are sloppy enough to leave behind publicly-accessible server logs ala Shady RAT.

Hardly any of the trojans used by Chinese APT actors are sophisticated at all. All these sophisticated features you listed are fine if you're only looking to launch a single-purpose attack, like a Stuxnet. The Chinese APT actors want to maintain a long-term presence even after they are discovered on the network.

As the sophistication of the malware rises, so does the cost/time involved, so it limits how many trojans you can deploy at once. Once your super-sophisticated trojan with rootkit, traffic tunneling, AV circumvention, strong encryption, disk and network stealth features gets discovered, your capability to maintain a long-term presence ends and you have to develop another one from scratch. There are only so many programmers working at this skill level, you don't find them every day.

The Chinese APT actors' answer to the problem is simply to throw a ton of different entry-level programmers at the problem. Each one basically uses the same feature requirements list and comes up with a completely different malware codebase, each one by default undetected by AV since it is brand new. Then each actor group goes after their targets using a set of those malware families. If one is discovered, that's OK, because nine more are probably still live on the victim network.

You have a chicken-and-the-egg problem. You said: "1.) Recovery Console bootup 2.) listsvc command to spot offending bogus MBR protecting driver (hello_tt.sys)" - in this case you have prior knowledge. You knew there was a rootkit in play, and you knew what it was named.

What if it has borrowed the name of another legit third-party driver? What if the rootkit code is just a stub inside another legit driver? This technique has been used by malware for years now. Now, how do you tell which is the malicious driver and which is not? How do you even tell if there is a rootkit in play at all? The answer is: other tools and techniques and most importantly, a lot of time spent.

You missed the point. Yes, TDL4 malware can be cleaned manually, no one is disputing that. The entire system could be forensically sanitized - manually - using the recovery console or a liveCD. It could take a long time depending on how many payloads had been downloaded and how well they hide. But this is not enough to kill the botnet unless you do this to 4.5 million PCs all at once. I never said your TDL-4 removal steps were incorrect, I just said they would not "kill the botnet", which is what Microsoft is suggesting they can do.

While nothing is impossible in theory, trying to destroy this botnet "one rig at a time" as you suggest would take decades even if you had an army tracking them down and cleaning them. The botnet would die on its own by then because the hard drives of those systems would fail first. Again though, I am reply to Microsoft's claims here, not yours.

The part you are wrong about is being able to use ProcessExplorer to fully sanitize the PC of the remaining malware. The only thing that truly separates malware from non-malware is intent. That's it. A P2P filesharing client and a P2P bot could share 99.999% of the same code, with only a single hidden malicious function. Tell me where in ProcessExplorer you would see the difference.

I'm not sure if you truly understand rootkits if you think they can't hide from ProcessExplorer. Even the simpler kernel-mode rootkits can do this, removing the hidden process from the kernel's linked list of objects - the same list that ProcessExplorer has to request from the OS to show you that tree of parent/child processes.

Making a determination on whether or not a program is malware is very hard to do programatically and even for a human often takes hours poring over the code in a debugger trying to understand the program's intent. If it were so easy, antivirus programs would still be adequate protection in this day and age.

No one said TDL4 can't be cleaned from a single PC. Cleaning it from all of them near-simultaneously is what you would have to do to destroy this botnet. The MSRT tool is not capable of performing the steps you described.

BTW your steps could still leave malware on the system unless you are a forensic/malware expert and can tell good processes from bad in ProcessExplorer. It's not so easy as you make it seem. Even if you are that experienced in process analysis, there could still be other kernel-level rootkits hiding malicious processes from ProcessExplorer. It could take days to truly disinfect a TDL-4-infected system that had been downloading payloads for a while. That's why reformat/reinstall has become the best-practice for dealing with malware, even though it is anathema to most Windows users/admins.

Another thing to note is that Microsoft hasn't destroyed the Rustock botnet, they are merely suppressing it. They will never be able to clean all the infected Rustock PCs, because countless thousands of them don't get Windows updates (either because they are pirated copies of Windows or updates have been disabled by other malware) and thus will never run the MSRT tool. If MS ceases their efforts before every last machine is sitting in a dump somewhere, the botnet could return, however unlikely that the author would bother to restore control.

Have a look at Cronto - it's an out-of-band authentication system, similar to ZTIC but doesn't use an electrical connection to the computer that could be impacted by a malware infection on the PC. Instead it transfers encrypted/signed transaction details via visual code to the Cronto device (or Cronto app running on a camera-enabled smartphone). There are a few other similar systems from other vendors, but Cronto is the only one I've seen with a mobile app so far.

Nope, I'm pretty sure it's a reference to guavas, considering the complete path was:

b:\myrtus\src\objfre_w2k_x86\i386\guava.pdb