I've spent a good deal of time researching this particular threat since we were hit with it a few days back. Here are some high level details, if you want more send me a pm and we can talk in detail. Keep in mind this is for the variant that started spreading around the globe on Feb 26th, 2009
On a few occasions the file 2.exe was found in a handful of users IE temp folders. This is an indication that our initial victims got hit by browsing the web.
Once it is inside the environment is uses the PSEXESVC (PSEXEC) to spread to other machines across your network. It is interesting because it actually downloads its own version of psexec in this case it is called 1.exe. The file 1.exe is not picked up as a threat by Symantec since it really is just a renamed version of psexec. A side effect of all of this psexec usage is a large number of user profiles under documents and settings.
2.exe uses 1.exe (psexec) to connect to other machines uses the credentials of the currently logged in user. If this user has administrator rights to the next target then 2.exe is executed on that remote box. If this process fails to connect, then 2.exe will try to connect as administrator/blank password, guest/blank password, or NoGuest/blank password. The presence of NoGuest on the machine is interesting in its own right but that is more in depth than I care to get here. Even though NoGuest is a renamed guest a count it appears that this account has modified security descriptors and its rights have been modified.
How do you fix this?
1. You need to tighten up the local administrator account across all servers and workstations. Users should not be logging in with privileged accounts. They should have two accounts, one for the interactive login and another they can use with the RUNAS command while doing their administrative tasks.
2. If the machine has been infected you will see that there is now a psexec services installed on the machine and it should be set to manually start. You should change this to be disabled. If you have a valid need you can secure it properly after you get your outbreak under control.
3. Ensure that all accounts have strong passwords and that any Guest or NoGuest accounts are disabled.
Now that we talked about the propagation method on the internal network lets go deeper.
2.exe is in the system32 folder, it executes and performs a buffer overflow against Iexplore.exe. IE then launches in a hidden window and starts to download additional files from servers in India and China.
Uninstall exe takes over and starts doing an inventory of the infected machine. At this point 2.exe will delete itself by calling cmd.exe /c >>null && del 2.exe.
Registry and process traces show that uninstall.exe will read various registry keys gathering info, such as registered organization, terminal service settings etc. This information must be sent back to the command control servers but I can never seen it get transferred as all of the HTTP traffic is encrypted or encoded. If you do a netstat on the infected machines chances are you will not see the sessions listed, they appear to hidden.
Keep in mind that if you allow these machines to continue to communicate with command and control you run the risk of them autoupdating, as well as stealing info, proxying traffic etc.
block the http traffic to the c&c servers
stop psexec from working
disable restore points
run a full scan and you should be ok.
Hopefully, this quick post can help some poor soul who is infected. Like I said if you want more details or need additional assistance pm and we can dig into the details.