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.

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>