The payload *will be* a “whole separate baddy”, and won’t need to exploit anything to do whatever it is it needs to do. It’ll already be running with system privileges on however-many hosts just like conficker.c is now. No zero-day required.

While the true end-goal/purpose is currently unknown, it’s only because it hasn’t been made available. If you check out the papers linked from the presentation slides (especially the SRI paper), you can see that malware analysts have a very good handle on what Conficker.C’s code does. The same would also apply to any payload that’s deployed, soon after a sample is obtained. If it were to start exploiting other systems with zero-day at that point, it’d be pretty obvious in a sniffer pretty quickly.

Seems like a waste of good zero-day, when zero-day isn’t cheap and you already have millions of compromised systems.

It’s not going to melt the internet. It’s impact likely won’t be the armageddon.

But at the same time, it’s out there for a reason, and it’s not just going to be forgotten about by those that control the botnet. It’ll do something, sometime… be ready….

I don’t know the dirty details of what is known about it, and I’m not by any means a professional in computer security, but I often wonder if the patches that are out are truly fixing the problem. What if the coders were really whitty and what we know as Conficker.C, is actually just a cover for something more serious exploiting a zero-day exploit very subtly in the background. Conficker.C is good at spreading, but are we 100% sure that something else wasn’t piggy backed along with it? What if one of the infected domains sends conficker it’s payload, but it also passes along something else that’s a whole separate baddy.

I could just be a paranoid, conspiracy nut on this, but I always have doubt. There’s never any way to know with 100% certainty that we have fixed a problem entirely.

Lets all put our foil hats on and see what happens (probably not any time too soon IMO).