Posted on

Bamital Bites the Dust

Today we are pleased to announce the successful takedown of the Bamital botnet. Symantec has been tracking this botnet since late 2009 and recently partnered with Microsoft to identify and shut down all known components vital to the botnet's operation.

Bamital is a malware family whose primary purpose is to hijack search engine results, redirecting clicks on these results to an attacker controlled command-and-control (C&C) server. The C&C server redirects these search results to websites of the attackers' choosing. Bamital also has the ability to click on advertisements without user interaction. This results in poor user experience when using search engines along with an increased risk of further malware infections.

Bamital’s origin can be tracked back to late 2009 and has evolved through multiple variations over the past couple of years. Bamital has primarily propagated through drive-by-downloads and maliciously modified files in peer-to-peer (P2P) networks. From analysis of a single Bamital C&C server over a six-week period in 2011 we were able to identify over 1.8 million unique IP addresses communicating with the server, and an average of three million clicks being hijacked on a daily basis. Recent information from the botnet shows the number of requests reaching the C&C server to be well over one million per day.

Clickfraud, the name used for the type of fraud committed by Bamital, is the process of a human or automated script emulating online user behavior and clicking on online advertisements for monetary gain. Bamital redirected end users to ads and content which they did not intend to visit. It also generated non-human initiated traffic on ads and websites with the intention of getting paid by ad networks. Bamital was also responsible for redirecting users to websites peddling malware under the guise of legitimate software. The following video illustrates how Bamital exploits the online advertising model:

Default Chromeless Player

Bamital is just one of many botnets that utilize clickfraud for monetary gain and to foster other cybercrime activities. Many of the attackers behind these schemes feel they are low risk as many users are unaware that their computers are being used for these activities. This takedown sends a message to those attackers that these clickfraud operations are being monitored and can be taken offline.

For further details on Bamital's activities you can download a copy of our whitepaper.

Details on recovering from a Bamital infection are available here: http://www.norton.com/bamital. Users of Symantec security products with current definitions are already protected against Bamital and its variants.

Symantec Security Response would like to acknowledge Spain's Civil Guardia, Catalunyan CERT (CESICAT), and Microsoft for assisting us in understanding and ultimately bringing this botnet to its demise.

Posted on

Anatomy of Bamital: A Prevalent Click-fraud Trojan

(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.

Posted on

12 Million Exploit Attacks Originating from the CO.CC Domain

Symantec’s telemetry has shown over 12 million Intrusion Prevention Signature (IPS) hits on sub domains of the ‘CO.CC’ domain in the last six months. Anyone somewhat familiar with the top-level domain-naming hierarchy might be lead to believe that CO.CC is actually an official second-level domain similar to CO.UK; this, however, is not the case. .CC is the Internet country code top-level domain (ccTLD) for Cocos (Keeling) Islands, an Australian territory. "CO.CC" is not an official hierarchy; it is a domain owned by a company that offers free sub domains and other services such as URL forwarding. The terms and conditions for use of the ‘CO.CC’ Web site can be found here.

The CO.CC domain itself is legitimate and has registered over eight million legitimate website URLs on its sub domains. However, wherever a free service exists, it is susceptible to being abused by malware distributors.  A malware distributor can register several free sub domains and use the URL forwarding service to point them all to one domain hosting a crimeware exploit pack. This way an attacker can stage their attack through redirection and try to mask the final URL destination hosting the exploit pack. This in turn makes it more difficult for the black listing of malicious URLs. In our analysis, we have seen numerous exploit packs such as Black hole, Fragus, Phoenix, Crimepack, K0de, and Eleonore being associated to CO.CC sub domains.  

 

This may not sound very innovative to some readers, as in the past we have seen other free services, such as free dynamic DNS sites, being abused by malware distributors. Attacks such as Hydraq (Aurora) highlighted the use of dynamic DNS by attackers and has lead to numerous companies blocking the use of dynamic DNS sites on their network. The use of free services on sites, such as the one highlighted in this blog, has given attackers another avenue for performing their attacks.

In our research, we have also identified variants of the following threats to be communicating with CO.CC sub domains.

Threats seen using CO.CC sub domains

As always, Symantec recommends that you keep your definitions up to date to ensure protection against threats mentioned in this blog.