Video Screencast Help
Symantec Appoints Michael A. Brown CEO. Learn more.
Security Response

Anatomy of Bamital: A Prevalent Click-fraud Trojan

Created: 14 Sep 2011 05:24:59 GMT • Updated: 23 Jan 2014 18:19:05 GMT • Translations available: 日本語
Nicolas Falliere's picture
+1 1 Vote
Login to vote

(Note: This blog was written on September 2. We decided to postpone publishing it due to an ongoing joint effort to shut down servers and block domain names. The variant studied is not the latest but accurately reflects the functionalities of the threat.)

Trojan.Bamital appeared in the summer of 2010. The threat really became prevalent at the beginning of 2011, shortly after the discovery of the B variant. Bamital hooks into various browsers in order to modify search results and redirect the user to advertisement links. In this blog, we’re going to dissect a recent variant of Bamital to understand how the click-fraud scheme is implemented.

Installation

Bamital comes as a UPX-packed executable. When executed, it drops two components to the %CommonFiles% folder:

  • %CommonProgramFiles%\nt.dll is a small DLL file used to load the main component of Bamital.
  • %CommonProgramFiles%\dll is the main component of Bamital. Contrary to what it’s name suggests, it is not a DLL but a pure binary file meant to be injected into existing processes.

The Trojan checks if the user runs with administrative privileges. If Windows Vista or 7 is detected, it will also require an elevated process to proceed. Bamital will then trigger the execution of the nt.dll loader by registering a new print processor. On top of that, in order to evade security software, ntdll!ZwConnectPort is hooked to return a substitute spooler device string when the processor is being added.

If the process is not privileged or elevated, Bamital will try to escalate its privileges by using the Task Scheduler vulnerability, which was initially introduced to the world by Stuxnet. Bamital exits if it cannot run as a privileged process on Windows Vista or 7. On Windows XP, Bamital will run but the infection of explorer.exe (as described below) will not take place.

The print processor technique combined with the ZwConnectPort hook, as well as the last-resort usage of the Task Scheduler vulnerability is a clear copy-and-paste from the latest versions of Tidserv (TDL4.)

System infection

Ideally, the first execution of the loader is meant to happen within the spoolsv.exe process. The loader’s unique role is to map and execute the content of the main component (dll).

Copies of both components are dropped to the %System% folder.

The explorer.exe system file (default window manager on Windows) is infected. The infection is a straightforward entry-point-overwrite meant to execute the loader component. If Windows XP is being infected, the winlogon.exe file as well as both cached copies of explorer.exe and winlogon.exe, which reside in the %System%\dllcache folder, are also infected. On other versions of Windows, such as Vista or 7, wininit.exe is infected but the cached copies are left untouched. Windows’ SystemRestore functionality is also tampered with.

File infection of these critical system processes means the system will automatically execute Bamital at startup time.

Process injection

Bamital monitors Web browser processes and injects them. Currently, four browsers are “supported” and two different injection techniques are used.
The first technique takes care of injection at process creation time:

  • Within the explorer.exe process, the undocumented ntdll!CreateProcessInternalW API is hooked in order to monitor process creation.
  • If a targeted browser is detected, the process is created in suspended mode.
  • A memory section containing a copy of the main component is created in that target process.
  • An APC is queued to execute the memory section.
  • The primary thread is resumed, triggering the execution of the main component.

The second technique involves standard process enumeration. If a target browser is detected, Bamital performs the following:

  • Suspends the target process.
  • Creates a memory map and copies the main component to it.
  • Creates a memory copy of kernel32.dll and infects the WaitForSingleObject API so that executing it also triggers the execution of the main component.
  • Maps the infected kernel32 image in lieu of the clean kernel32 image.
  • Resumes the target process.

Since the kernel32!WaitForSingleObject API is frequently used, it will not take long before the main component gets executed. Once the main component runs inside a browser, the click-fraud subcomponent is run. I’ll describe how it works.

Click-fraud implementation

The idea behind click-fraud is to generate revenue by having advertisement links clicked, either in an automated, manual, or distributed manner. Bamital’s click-fraud scheme is very similar to the one implemented in Xpaj.B. I strongly recommend reading the white paper detailing Xpaj.B if you want to know more about this threat.

Contact with the Command and Control server

First, Bamital contacts its Command and Control (C&C) server. The server location changes daily, using a time-based domain generator algorithm. The time of day is retrieved by issuing a GET query to a search engine. Up to 26 domains are tried, which are of the form MD5(<C><time-of-day>).co.cc:

  • <C> is a character in the [A - Z] range.
  • <time-of-day> is the timestamp string returned by the HTTP server. For example, on September 2, one candidate was MD5(A02 Sep 2011).co.cc that translates into 5fe6c34bbc48b7832393da580e19de23.co.cc.

Bamital issues the following query to the C&C server:
http://<cnc>/message.php?subid=<subid>&br=<brtype>...

The meaning of the fields is as follows:

  • subid: Unique threat ID, embedded in the high word of the original Bamital executable. This ID could be an Affiliate ID, which means the threat could be distributed by third party via standard PPI schemes.
  • brtype: The injected browser type, e.g. “IE_x”=Internet Explorer.
  • osver: The OS version information, in the form xy, where:
    o x is the major version type (1 = XP, 2 = Vista, 3 = Seven, 4 = Other)
    o y is the major Service Pack number
  • machineid: A 32-character long hexadecimal string that is the MD5 hash of various machine characteristics. It uniquely identifies a compromised computer.
  • version: The trojan version number. Currently, it seems the latest version is 21.

The C&C replies with an encoded blob of data formatted as a markup language. The major information contains:

  • The location of the server used to provide the redirected links to ads.
  • Optional: A link to an updated version of the Trojan.
  • Optional: An updated domain for the C&C. This domain has priority over the DGA-based domains (unless it turns out to be non-responsive).
  • Potentially more non-critical data.

The most important piece of data is the ad server URL. Currently, this URL is of the form:
http://click[removed].info/x.php?subid=<subid>&key=<querystring>

The subid field is replaced by the threat’s own value. This fact strengthens the idea that this value is likely an Affiliate ID.

Monitoring user searches

Search queries made to prominent search engines, such as Microsoft Bing, are monitored. To achieve this goal, Bamital hooks the following socket APIs within the browser:

  • recv and send
  • WSARecv and WSASend
  • closesocket
  • getaddrinfo
  • DnsQuery_W and WSAAsyncSelect
  • gethostbyname
  • getaddrinfo and WSAGetOverlappedResult

When a user issues a search query to one of the search engines, the search result list is intercepted. If the user clicks any of the result links, Bamital takes control and performs the following actions:

  • First, it issues a query to Bamital’s ad server (currently click[REMOVED].info, resolving to 173.244.[REMOVED] in the United States).
    o If the search query string was “buy xx”, the URL queried would be: http://click[REMOVED].info/x.php?subid=<subid>&key=buy+xx
  • The ad server returns a small response in the form of <i>AdUrl</i><r>Referrer</r>, for instance <i>http://xx.230.138.178/c.php?s=[...]</i><r>http://pheromone-oil.com/search/?q=buy+xx</r>.
    o The AdUrl links to an online ad service company. Several of such websites are used by Bamital, some of them legitimate.
    o The Referrer link will be “set” as the “Referer” HTTP field to fool the ad provider.
  • Bamital then redirects the user to the Referrer link by generating a fake 302 response. (Note that the Referrer link hostname is forcefully resolved by Bamital to the search engine site. This technical oddity was used as an easy way to have WinInet set the HTTP Referer field to the proper value in the following HTTP query.)
  • Bamital injects the response with a small JavaScript stub that redirects the user to the AdUrl.
  • The AdUrl redirects the user to the ad page.

The authors will thus receive money from the ad provider. The ad provider itself will receive money from the advertized website, which is the direct victim of click-fraud operations.

The referrer trick is used to fool potential provenance checks implemented by ad providers. The referrer points to fake search engines or simply fake URLs that look like search queries, in our example, http://.../search/?q=buy+xx.

The following diagram summarizes the click-fraud operation:

Conclusion

Bamital is a serious nuisance. Unfortunately, and unlike Xpaj.B, we do not have data that would allow us to present infection statistics, such as earnings, click counts, and number of ads served. We advise our customers to keep their virus definitions up-to-date.