Video Screencast Help
Scheduled Maintenance: Symantec Connect is scheduled to be down Saturday, April 19 from 10am to 2pm Pacific Standard Time (GMT: 5pm to 9pm) for server migration and upgrades.
Please accept our apologies in advance for any inconvenience this might cause.

Inside Trojan.Clampi: The Logger Module

Created: 12 Oct 2009 17:01:37 GMT • Updated: 23 Jan 2014 18:32:18 GMT
Nicolas Falliere's picture
+1 1 Vote
Login to vote

As mentioned in our previous blog entry, most of the Trojan.Clampi features reside in separate modules that are sent by a remote server in response to clients’ queries. In this part of this blog series, we’ll have a look at one of the modules used by the malware to steal login credentials mostly from banking Web sites.
 
This module is codenamed LOGGER by the threat. After decryption, the beginning of the module’s raw data looks like this (compressed):

blog-2-image-1.jpg

To avoid downloading the module each time Clampi runs, it is stored in the registry (in an encrypted form) in a value named “Mxx”, where “xx” is a zero-based number representing the current module count (e.g. “M02”).

Note that Clampi’s modules are standard DLLs, and like Clampi itself, are protected by a complex commercial software protector that uses executable code virtualization.

The LOGGER module injects a code stub into Internet Explorer and hooks several APIs imported by the standard Windows DLL, urlmon.dll, which is used by Internet Explorer to open Web pages. These hooks will redirect code execution to the Clampi-injected code. The hooked routines include:

  • InternetConnectA
  • InternetOpenA
  • InternetSetStatusCallbackA
  • InternetReadFileExA
  • InternetOpenUrlA
  • InternetCrackUrlA
  • InternetReadFile
  • InternetWriteFile
  • HttpOpenRequestA
  • InternetSendRequestA
  • HttpSendRequestExA
  • InternetQueryOptionA
  • InternetQueryDataAvailable
  • InternetCloseHandle

Here’s a screenshot of the code injected into an Internet Explorer instance:

blog-2-image-4.jpg 

Each time the user visits a Web page, the injected code will calculate the CRC for portions of the URL and compare the CRC to a list found in a data file, which is also being sent by the server. If a match is found, the data sent to the (usually) financially related Web site will also be sent to Clampi’s gateway servers, allowing Clampi to steal large amounts of login credentials and other confidential data being sent to multiple Web sites.

The following is an example of data being sent by Clampi when visiting a bank from Cyprus. I logged on with the fake ID “abcdef” and PIN “123456”, which appear clearly in the stolen data:

 blog-2-image-3.jpg

The use of CRCs rather than plain-text URLs is very smart for multiple reasons:

  • The URLs are not stored in plain text, which avoids raising instant suspicion.
  • Pattern matching a large list of URLs is faster using CRCs.
  • Storing CRCs takes less space than full URLs.
  • CRCs are essentially one-way functions, so reversing the CRCs to URLs is not a trivial task. This means that given a specific site, someone can determine if it is being monitored easily, but establishing a comprehensive list of monitored sites is not.

By correlating this module’s code with the data file, we were able to figure out the file’s structure and what each field is used for. Let’s take a practical example by describing a CRC entry of the data file. Have a look at the highlighted part of this picture:

blog-2-image-2.jpg

The highlighted fields are translated as follows:

  • Index: 0x359—This is the 857th entry of the file.
  • Flags: 0x4B
  • CRC count: 1
    - CRC type: 2—Like 99% of the CRCs in the file.
    - URL length: 0xA (10, decimal)
    - URL CRC: 0x45DCA3D3

This CRC entry is for a popular online payment Web site. Now you may wonder about the field CRC type (being 2 in this case). This field is used by the injected code to determine what part of the URL should be used in the calculation of the CRC.
 
For type 2, the domain of URL is hashed. For example, let’s assume the URL being visited is http://www.online.mybank.com/index.html. The injected code will calculate the CRC on:

While the vast majority of CRCs match against the domain of the URL (type 2), others also match additional parts of the URL. There are over 4600 CRCs in the current LOGGER data file and it can be updated dynamically.

We were able to reverse most of the URLs, determining which sites are being targeted. The list includes major banks and other financial institutions, online payment sites, but also high-traffic social Web sites, webmail, and security vendor portals.

The domains are from all around the world including more than 120 top-level domains. The majority (45%) are .com domains based in the United States. Ignoring non-country specific top-level domains such as .com, .net, and .org, Australia (.au) and Italy (.it) are the most represented domains followed by the United Kingdom (.uk).

The following graph shows the percentage of different country-specific top-level domains (TLDs):

ClampiPieChart1.jpg

Since the CRCing algorithm results in a considerable number of collisions, we first generated over 10,000 possible matches for over 4600 CRCs and then pruned the list to the actual targeted sites by verifying the domains existed.

Even so, collisions remained and the list of targeted Web sites is actually greater than the number of CRCs. This means that by Web site content, Clampi may have wanted to target a particular site, it would also indirectly return login credentials from other sites as well.

For example, when trying to target a particular financial institution l****capital.com, Clampi will also hit a jewelry-merchant Web site ****jewelers.com, since their length and CRCs match.

In addition, the list also has domains that no longer exist. For example, the domain for a financial institution *****alcu.com.au still turns up in search results, but the site actually no longer exists.

While most sites are financial institutations, a variety of other types of Web sites are targetted. Spot checking these sites shows that all have a login form on their home page. It’s likely the authors automatically spidered the Web for sites that met certain popularity or industry-type criteria and had some type of login form or other strings such as ‘Your account’ on their home page.

Below we’ve provided a flash applet that will check Type 2 domain CRCs. To use it, type in a URL or domain name, including possible subdomains. E.g., if your bank is www.mybank.com, you may want to try other valid combinations your bank uses such as login.mybank.com or secure.mybank.com. While Type 2 domain CRCs are not the only match patterns Clampi uses, they do represent 99% of the URLs matched. Thus, if the domain you test does not match, there is still a chance the domain is being monitored. Finally, the applet only checks the CRCs at the time of posting.

The complexity and sheer number of domains being monitored by Clampi demonstrate this is a professional operation. In addition, reports from compromised individuals have confirmed that the gang beyond Clampi are actively using the stolen credentials to transfer money to unknown bank accounts.

Clampi has many more features to discuss, so watch for more Clampi blog entries yet to come.

Next: Inside Trojan.Clampi: Stealing Your Information
Previous: Inside Trojan.Clampi: Network Communication