Unfortunately, the centralized AV was not fully deployed - and was sometimes out of date. The problem was magnified by the fact that the company is multi-site and fairly wide open, subnet wise.
Apparently, Qakbot spreads through CIFS shares. It likes to push itself through the administrative shares and place executables to be run into the All Users directory. It then creates registry entries to start itself upon login. It does annoying things like changing permissions on the AV program directories such that updates won't work. It then uses the credentials of the user to attack the administrative shares and (likely) remote registry service of other machines. This can be bad if you happen to be a domain admin, Anyway, the virus doesn't seem to work correctly on Windows 7 or 2008 for some reason.
The biggest problem removing it was that we were not able to isolate segments of the network, and by logging on, you'd simply activate it, if the executables had already been placed.
I figured out a simple way to clean up a machine remotely (do this at your own risk, of course. You may damage your system if you are not careful.):
\\c$\documents and settings\all users\application data\microsoft
The Qakbot worm creates a randomly named directory. Let's pretend our folder name was "gvcajscwxoq." I can't tell you exactly what it'll be called, but the name will be rather random and should have only one exe, two dlls, and maybe some .tmp or .dmp files. So, we'd have a folder called:
\\c$\documents and settings\all users\application data\microsoft\gvcajscwxoq
There will be an executable and two DLLs witht the same name as the folder "gvcajscwxoq." There may be a few other tmp files. What you need to do is delete or rename the files to a different extension - like .vir.
That works well enough if the virus isn't active on the machine. If it is, you'll need to kill the process remotely before logging in. I found a useful freeware commercial tool called Desktop Central:
(note, I'm in no way associated with that company. I just found the tool to be useful.)
Provided it can connect to the infected machine, you should find the rogue process running as the same random name of the folder you attempted to rename above. End that process (make sure it's the same random name!) Wait about 20-30 seconds and then try to rename the remaining files in the application data\microsoft folder. You should be able to. You probably can't rename the bad folder, yet.
I'd also recommend that all domain admins check out the administrative shares of boxes before logging into them. Remember from above:
For Windows 2000-2003, XP, look in
\\servername\c$\documents and settings\all users\application data\microsoft
For Windows 2008, Vista, and Windows 7, try looking in c:\programdata\microsoft
If you see a randomly named folder with an exe and two dlls in it, you'll need to cleanup the server before logging in.