Many of these key queries are interesting because the Trojan seemed to be looking to see if it has already been installed in such a way as to bypass various Windows security mechanisms, including SafeBoot and Software Restriction Policies. The Trojan didn’t manipulate the keys, however, so I didn't really know why it was checking -- yet.
The Trojan eventually created and wrote the following registry key: HKLM\System\CurrentControlSet\Control\SessionManager\PendingFileRenameOperations.
Using this key, it told Windows to delete the host file from which it was executed upon the next reboot.
Next, the Trojan wrote itself to a file called Csrss.exe and stored itself in the \Windows folder. This is an interesting trick. The legitimate Csrss.exe file is stored in \Windows\System32, which the Trojan could not modify, overwrite, or delete (because of Windows File Protection). So, it wrote itself into another directory that most casual users would not think twice about checking.
After that, the Trojan searched the Temporary Internet Files folder of Internet Explorer, looking for evidence of files and cookies from more than 100 different banking Web sites. It then used this information to create localized copies of the logon pages of various bank Web sites.
This is the amazing part: When the user visits one of these Web sites, the Trojan intercepts the legitimate banking Web logon request and replaces the bank’s logon screen with a localized copy. That's why it was mysteriously manipulating the files and querying the keys. By watching the browser carefully, I was able to see the local version load, but I think most end-users would miss the switcheroo.
Thanks to the sneaky swap, the users' browsers appear to have an SSL connection to their bank’s Web site (and shows an SSL icon in their browser), but the SSL connection is really to the Trojan’s local Web page. As the user logs in, the Trojan captures the logon credentials, writes them to a file called Temp.dlb, and then passes them along to the bank’s Web site. This technique has been referred to as “SSL mixing,” “SSL-proxy,” and “SSL man-in-the-middle.” (The latter is the more traditional name.) The Trojan uploads the Temp.dlb file to a Russian-addressed Web site, and goes back into hiding.
Seeing the worm in action was startling. Although I’ve known about and demonstrated many SSL man-in-the-middle attacks, I had never seen one so automated and so criminal. After doing some more research, I found out that SSL mixing Trojans aren’t new -- just new to me. They have been documented since about six months ago.
Thankfully, many banks are using more sophisticated logon screens than just an SSL-protected page asking for a name and PIN. A great example of this is Barclays’ UK Web site. After asking for a surname and account number (some of which is provided), the user is prompted for their passcode and two randomly chosen letters of their “memorable word.” Although an appropriately coded Trojan might eventually collect all the letters of the memorable word and possibly put them together in the right order, it’s complicated enough right now to defeat the current SSL and other keylogging Trojans. It's also something that more banks and other online entities should adopt.