An SSL trojan unmasked

As mentioned in last week’s column, I was recently sent an SSL Trojan from a security consultant assisting a bank with a large online presence. This particular SSL Trojan had installed itself on more than 100 of the bank customers' computers. The most interesting part was that the Trojan could insert itself in the SSL connection between the customer’s browser and the bank’s SSL Web site. I made a weak attempt to disassemble the Trojan, followed by executing it on my specially configured analysis virtual machine computer.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

I fired up the excellent IDA Pro Disassembler and opened the Trojan. I immediately learned it was packed (compressed to minimize size and complicate malware analysis) using ASPACK. IDA Pro still showed me a few API calls: I now knew the Trojan manipulated the Windows registry, and used basic Windows APIs (Ntdll.dll) and some C libraries (Msvcr71.dll).

The latter file reveals that the Trojan was probably written in Microsoft Visual C++. But I could not see any immediately interesting ASCII text strings. I’d have to wait on my better-skilled, professional friends for a more detailed disassembly.

I then executed the Trojan on my analysis virtual machine host, which was running two images: Windows XP Pro SP1 and SP2. I use both images because SP2 often prevents malware from running. The images have multiple monitoring utilities, including Ethereal and Sysinternals' Regmon, Filemon, Autorun, and Process Explorer.

I froze Trojan execution in several different phases and examined my monitoring logs. Here’s what I learned.

When the Trojan launches, it immediately looks for the Microsoft C Runtime library (Msvcr71.dll). I discovered that the library file wasn’t on my XP SP1 image, but was on my SP2 image and any XP images with .Net Framework installed. The Trojan also called Ntdll.dll and Gdi32.dll, which contain some of the most-used Windows APIs.

The Trojan next wrote 60K-80K (depending on VM image) of content to \System32\Config\System.log. When I checked, the System.log file was its normal 1K size and not full of Trojan code. At this point, I didn’t know what the Trojan was doing here, but I planned to find out in the future.

Next, the Trojan queried the following keys and various subkeys:

*           HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Image\FileExecutionOption

*           HKLM\System\CurrentControlSet\Control\SafeBoot\Option

*           HKLM\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\TransparentEnabled

*           HKCU\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\TransparentEnabled

*           HKLM\System\CurrentControlSet\Control\TerminalServer\TSAppCompat

*           HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Compatibility32\<hostname>

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.