Inside Trojan.Clampi: Enhanced Logging

The latest malware threats from across the security forums

Moderators: Admin Team, Moderators

User avatar
Posts: 1856
Joined: Mon Jul 20, 2009 4:35 am
Area Of Expertise: General guidance and advice
experience: Not only can I turn PC on, I know most of its functions too
PC time: Alot more than I should
Location: Kent, UK

Inside Trojan.Clampi: Enhanced Logging

Postby Spudz » Tue Oct 20, 2009 2:05 pm

Inside Trojan.Clampi: Enhanced Logging
Nicolas Falliere
October 20th, 2009

This chapter in our Clampi saga brings us back to the malware’s logging facility. As we saw before, one of Clampi’s modules, codenamed LOGGER, is responsible for logging outgoing information going to a determined list of URLs – stored in a data file as CRCs.

One problem arises with banking sites that preprocess the user’s personal information before sending it over HTTPS—it’s done using client-side JavaScript. For instance, a hash of the input PIN number could be sent instead of the PIN number itself. This mechanism adds an extra layer of security, preventing malware from sniffing network traffic at one end of the SSL tunnel. But still, it’s only covering one end. It’s more secure than no encryption, but still not great. At least two methods exist to get around this:

* Setting up a keylogger using either software (driver/user-mode hooks) or hardware (wire-tapping). This is the generic approach.
* Grabbing the user information before it gets processed. This is non-generic, Web site-specific approach.

The Clampi gang decided to go with the second method and created another module named “LOGGEREXT” (which obviously stands for ‘Logger Extended’).

This module is replacing JavaScript stubs inside targeted Web pages. The replacement code is similar to Win32 hooks—they are called instead of other JavaScript functions, do some processing, and then call the original function.

The target pages, the original JavaScript stubs, and the replacement ones are stored in a separate data file, loaded by the LOGGEREXT module in its address space.

After reverse-engineering, guessing, and correlating elements with what we found out when analyzing the LOGGER module, we were able to figure out the data file’s file format. Here’s an entry:

offset=498, id=35, flags=83, count=1
type=3, len=17, crc=C1008A17
HTML entries:
blk00: '</BODY>'
blk01: '<script type="text/javascript">\r\n (…)</body>'
blk10: '</body>'
blk11: '<script type="text/javascript">\r\n (…)</body>'

Spam - Uninteresting garbage quickly deleted.
Spammer - A parasitic worm intent on creating internet misery.


Return to “Latest Malware Threats”

Who is online

Users browsing this forum: No registered users and 1 guest