The ‘Advertising’ Botnet

Bots belonging to the Artro botnet are detected by Kaspersky Lab products as Trojan-Downloader.Win32.CodecPack, which has been around since early 2008. However, a full description of its functionality is still not available, so to rectify this, we decided to publish the results of a study we undertook.

The downloader

The Artro botnet was created using a Trojan downloader that is detected by Kaspersky Lab as Trojan-Downloader.Win32.CodecPack. The Trojan is protected by a packer with heavily obfuscated code. As a rule, packers are used to prevent the detection of a packed malicious program rather than to protect its code from analysis, and this piece of malware is no exception: unpacking it is a relatively easy task. When unpacked, the WinMain function of different Trojans usually looks more or less the same. In this case, however, the malware authors tried to obfuscate their code by inserting large numbers of superfluous instructions in order to make the code harder to analyze.

The WinMain function of Trojan-Downloader.Win32.CodecPack after unpacking

The superfluous code is polymorphic and consists of code blocks that perform various operations on global variables which are not used by the main code. It also includes API functions, which when executed, in no way affect the running of the program itself.

Superfluous instructions in a fragment of the Trojan’s disassembled code

Obfuscation produces code that is remarkably jumbled up for a simple downloader.

Notable features of Trojan-Downloader.Win32.CodecPack include checking that the Trojan is not running on a virtual machine or under a debugger. However, unlike most malicious programs which terminate upon detecting a debugger or virtual machine in order to hinder dynamic analysis, CodecPack simply sends the results of the check to the C&C server.

Each string of the Trojan is encrypted using the RC4 algorithm and decrypted every time it needs to be used. The first one or two bytes in each string contain the decryption key. The length of the string is calculated by adding a constant to the key value -the constant being embedded in the Trojan’s code and unique for each sample.

The first thing Trojan-Downloader.Win32.CodecPack does upon launching is check for an Internet connection by sending DNS requests to several popular websites, such as, and, which are likely to be available at any time of the day or night. If there is no Internet connection, CodecPack terminates its process. If the infected computer is online, the downloader collects information about it, including the volume serial number of the drive containing the Windows folder, operating system version, whether the current user has administrator privileges and whether the Trojan is running on a virtual machine or under a debugger. Next, a request to the C&C center containing the collected data is created. It is worth noting that the domains to which the downloader sends requests are not real C&C centers. The servers associated with these domains are simply reverse proxies which are only needed to conceal the botnet’s real command-and-control center.

A POST request from the downloader to the C&C center and the reply received

Importantly, all the requests sent to command servers by the Trojan are encrypted. The data is first encrypted using the RC4 algorithm and then encoded using Base64. Replies from the C&C center are also encrypted. The procedure for decrypting replies is the reverse of that used to encrypt requests: firstly, a reply is decoded using the Base64 algorithm and then it is decrypted using RC4. The key used to encrypt and decrypt data is the same for all samples and is embedded in the Trojan’s body.

A request to the C&C center is a POST request with an ini parameter that contains a string:


…which produces the following string when decrypted:

35a169ddfc4eef&a2=00001920&cd=Fri 04 2011,22:16:41

The string includes the Trojan’s unique identifier (parameter a1), an identifier of the partner through which CodecPack was downloaded to the machine (parameter a2), and a time stamp that is included in the file as a string (parameter cd). The data parameter contains a string:


…which looked like this before encryption:

Windows XP Professional Service Pack 2 (build 2600)

This string provides the following information to the C&C center:

  • whether the user account under which the Trojan is running has administrator privileges (the value of the admin parameter can be “yes” or “no”)
  • whether the Trojan is running under a debugger or on a virtual machine (the debug parameter can take the following values: “none”, “vmware”, “vmware2”, “vmware3”, “msvpc”, “msvpc2”, “cvpc”, “debugger1”, “debugger2”, “debugger3”, “debugger4”, “debugger5”, “softice”, “vm”, “vm2”)
  • the version of the operating system (the OS parameter)

The purpose of the request is to receive a configuration file from the command server. The file is sent by the server as a meaningless set of characters:


…which is decrypted to form an XML configuration file:

<url crypt='gif'
_upp.gif<url crypt='gif'

<url crypt='gif'
><url crypt='gif'

<url crypt='gif'
werce.gif<url crypt='gif'

<url crypt='gif'
.gif<url crypt='gif'

The configuration file has a fairly simple structure. The root element includes a number of start elements. Each start element corresponds to a file that is to be downloaded and executed. Each start element also includes URL elements that specify download addresses. A start element can include several URL elements. Thus if the malware fails to download a file using the link provided in the first URL element, it will try to download it using the next link.

Files are downloaded to users’ machines in encrypted form. The encryption method is defined by the crypt attribute of a URL element. The attribute can take two values, GIF or RC4. It is easy to guess that the latter method consists of encrypting files using the RC4 algorithm. The GIF value means that a .gif image will be downloaded, such as the following:

Naturally, it will not be just an image: in addition to graphical data, it will contain an executable file encrypted using the RC4 algorithm.

Decrypted files are saved to the hard drive and launched, after which the downloader deletes its file from the hard drive and terminates its process. Thus, the downloader’s mission is limited to downloading malicious files from links specified in the configuration file and launching them on the machine.

While conducting research into the botnet’s operation, we discovered that the downloader’s configuration file cannot be downloaded by users from some countries. For example, users in Russia, Belarus and Kazakhstan have so far not been able to download the file: they see a ‘404 Not Found’ error message every time.

Downloads: adware/clickers

As a rule, the downloader’s configuration file contains links to 3 or 4 programs. The links may lead to malicious files that are downloaded following orders received by the botnet’s owners from their cybercriminal ‘colleagues’. Such files may vary depending on the country and may not be present in the download instructions for some countries. But there are programs that the downloader always downloads: these are bot programs displaying advertising (i.e., adware) and which click on links, advertising banners and popup windows. Unlike files downloaded to infected computers to-order, these programs are developed by the same malware authors who created the downloader. This conclusion is supported by the following two facts:

Firstly, links to these files are always present in the downloader’s configuration file. In other words, they are the basic set of downloaded malicious programs and provide the botnet’s owners with their principal source of income.

Secondly, the code in these malicious programs is very similar to that of the downloader: it uses the same obfuscation methods, the same algorithm for encrypting each string (although the keys that are used differ), the same packer and a protocol for communicating with the server that is identical to that used by the downloader.

Communication between the HitBot and the server

Each bot regularly requests an encrypted configuration file with parameters specific to that bot from the command server.

The domains used for the command servers with which the bots communicate are different from those used for the downloader and change relatively infrequently.

Five main programs downloaded to infected computers by the Trojan downloader are known at this time.

BannerBot. The configuration file provides this bot with direct links to advertising service banners, which it clicks on, resulting in redirection to a website. Alternatively, it provides links to websites where it uses the div tag to find specific banners to click on. The bot shows some of the banners to the user. Parameters in the configuration file include the referer field, which contains a link to the request source (i.e., from where the advertising site redirected the ‘user’).

An example of a decrypted BannerBot configuration file

New_bb. This bot’s functionality is similar to that of BannerBot, but it sends some additional statistics about its operation to the server and can communicate with the server without receiving a configuration file. In this instance, the server to which the bot sends a POST request redirects the request to a second server using response code 302. The bot extracts the relevant parameters, such as the referer field for requested banner links and the number of clicks to be performed on banners before connecting to the first server again, from the Set-Cookie HTTP field.

Extracting parameters for New_bb from the Set-Cookie field and redirecting the bot’s request to a second server

In its turn, the second server returns JavaScript with a link to a banner which is executed in the browser.

Receiving JavaScript from the second server for New_bb

PopupBot. The configuration file provides this bot with links to scripts that open pop-up windows, on which the bot clicks, resulting in redirection to a website. The bot displays some of the pop-up windows to the user. The screenshot below shows a sample set of instructions for this bot providing the referer field for the links to scripts among its parameters.

Decrypted instructions from the server for the PopupBot

HitBot is a clicker that receives instructions from the server to request network resources at regular intervals with the referer field and the time interval specified in the configuration file.

Decrypted instructions for the HitBot received from the server

If the ref parameter in the configuration file is empty, the HitBot simply generates fake traffic statistics for the website specified in the URL parameter.

Oms. This is the only bot implemented as a dynamic-link library and installed as a service. The bot supports regular expressions and intercepts browser requests to the Google, Bing and Yahoo search engines, extracting queries entered by the user.

Regular expressions used in parsing user queries

After extracting a query, the Oms bot encrypts its parameters and sends them to the server. Parameters sent include the user’s search query and the search engine’s website address.

Decrypted parameters sent by the Oms bot to the server

The server’s reply will be in the form of a configuration file that includes, depending on the user’s query, a link to which the user will be redirected upon clicking on any of the search engine results, as well as a referer field for that link.

Decrypted instructions for the Oms bot from the server

For example, a link received in the configuration file may redirect users to a web page imitating an explorer.exe window with what appears to be the results of a malware scan, along with an offer to download fake antivirus software.

A web page imitating an antivirus solution scan

Websites opened by the Oms bot and other CodecPack bots have a variety of content, such as that shown in the screenshot below.

An example of a website opened by the adware program

The money

As we mentioned above, the botnet’s owners make money from downloads of third-party malware, as well as click fraud, fake traffic and showing web pages with a variety of content to users. We have no way of assessing how much money the cybercriminals may be making from downloads, but we can provide a tentative estimate of their income from click fraud and fake traffic.

So how do the owners of the ‘advertising botnet’ make money?

Strategy for deceiving advertisers

Many website owners who want to increase user traffic to their resources employ the services of advertising networks. To increase traffic to the web resource being advertised, links to that site are displayed on websites belonging to participants of the advertising network, the so-called publishers. The advertiser pays the network’s owners for each user they attract. Publishers are paid for each user redirected from their website to the advertiser’s website.

Many advertising services use affiliate programs in order to increase the number of sites upon which advertising links can be displayed.

Some publishers use the services provided by botnet owners in order to increase their income by redirecting visitors to advertisers’ resources. Bots emulate redirection of users who click on advertising links to the resources being advertised. For this purpose, the bot enters the address of the botnet client’s website into the referer field of an HTTP request to the advertising service or sends the ID of an advertising network partner in the request’s parameters. In turn, the advertising service redirects to the target resoursce

This fraudulent scheme provides income to botnet owners, unscrupulous partners and publishers. The advertising networks receive their share of the income as well. Only the advertisers suffer: their investment in advertising fails to provide their websites with visitors.

We believe that many of the website owners and advertising network partners are unaware of the fact that some of their revenue comes from a botnet.

While monitoring the botnet’s activity, we identified numerous systems for buying and selling traffic with which different CodecPack bots interact. Below is a sample list of such services, the information for which was taken from configuration files:


This list includes well known and widely used advertising services, as well as more dubious ones. Links to these domains were received by bots with numerous different referer values or partner identifiers. Below are listed some of the websites for which fake traffic services were ordered from botnet owners and which were specified in the referer field of configuration files in February 2011:


For example, the address is provided in the referer field for the Oms bot. Here is an assessment of the site by a service that offers information on website revenue and net worth:

Evaluation of the net worth and revenue of by

In the course of our research, we discovered the average number of clicks-per-day that each module performs on the links received in the configuration file. This figure, as well as such parameters as the average payment received by an advertising service per click, the minimum number of bots on a zombie network and the probable share of the income that botnet owners receive from selling traffic, enables us to evaluate the probable income received by the cybercriminals. Our estimate is US $1,000 to $2,000 per day.

It should be noted that this calculation does not include the Oms bot, the clicks from which are wholly dependent on what users do with their search queries. It is also worth noting that the cybercriminals use flexible settings for the frequency of clicks performed by bots. This allows them to imitate the behavior of real-life users: clicks are performed in succession over predetermined periods of time, with long intervals interspersed by periods of increased activity, rather than at a constant frequency.

Luckily, some advertising services are already using technologies that detect fake traffic attempts. As for advertisers, they should take the choice of services they use to attract traffic to their websites very seriously.


CodecPack uses a variety of methods to find its way onto users’ machines. This indicates that the owners of the Artro botnet use malware distribution services provided by their colleagues. The CodecPack downloader is distributed by botnets; this means that it is installed on computers that are already infected with a Trojan downloader. It can also be distributed using exploit packs: once a user visits an infected website, an exploit hosted on the site will automatically download and install CodecPack on the visitor’s computer. One shining example of distributing the downloader using exploits was a spam mailing detected by Kaspersky Lab in March 2011, following the latest major earthquake in Japan. Spam messages included a link to a malicious website that used exploits to install Trojan-Downloader.Win32.CodecPack on users’ machines.

However, the main method of infecting users’ machines with CodecPack is actually quite unsophisticated: users download and launch the malicious executable themselves. Naturally, few users will launch an unknown file ‘just for the sake of it’ these days. Cybercriminals bear this in mind and disguise the Trojan as a codec, a legitimate program, a key generator or a ‘crack’ for a useful program distributed via so-called ‘Warez’ sites. CodecPack is also distributed via fake video hosting sites, pornography sites created for the specific purpose of infecting users’ computers and fake blogs. Based on the nature of these sites, it can be surmised that the cybercriminals’ victims are mostly those who like freebies and adult content, as well as unwary users.

How does this happen? Suppose that a user visits a fake video hosting site in order to watch a video:

A fake video hosting site

Text located next to the player window warns the user that a codec may need to be downloaded. As a result, when a standard dialog window opens in response to the user’s attempt to view a video and offers to save or run an executable with a plausible name (e.g., DivXcodec.exe), the user launches the file without thinking twice, believing that this is the codec required to watch the video. However, the program launched is in fact Trojan-Downloader.Win32.CodecPack, which incidentally, was named after this method of installing the malware on users’ machines. Users who try to view pornography on fake porn sites or read posts in fake blogs are infected in a similar way.

A fake blog site

An attempt to view a video published in a blog brings up a web page with an image of a video player.

A web page with an image of a video player

In reality, this is not a video player but an image linking to a malicious file. The link has the following format:

As described above, the user clicks on the image of a video player, bringing up an offer to download a ‘codec’. Needless to say that downloading and launching the file will not allow the user to view a video but will result in the computer becoming infected.

If a user attempts to download software, a key generator or a crack from a ‘Warez’ website, things appear even more convincing as the user’s principal reason for visiting the site is to download a program. Naturally, the software downloaded will contain nothing but a Trojan.

A website distributing Trojan-Downloader.Win32.CodecPack disguised as cracked,
legitimate software

How do users reach websites hosting links to malicious files? They are attracted to such websites using black hat search-engine optimization (Black SEO) methods. For example, the fake blog mentioned above came up on the second page of search results in response to certain search terms. In addition, links to sites that link to malicious files are published in comments to posts on popular blogs and news portals.

Malicious links on many different websites may lead to the same domain. Domains used in links are commonly changed several times a day.

The number of domains hosting CodecPack per-day during January, 2011

Scale of the problem

Kaspersky Lab detected the first CodecPack sample in the summer of 2008. The Artro botnet has grown to an enormous size in the last two and a half years: in January 2011, CodecPack was detected at least once on the machines of approximately 140,000 of our users.

The number of users upon whose computers Trojan-Downloader.Win32.CodecPack has been detected

It is worth comparing this figure with the data obtained from the cybercriminals’ servers, which is possible as we were able to access one of the botnet’s back-end servers and examine its log files. The log files contained such data as IP addresses of computers from which requests to C&C centers had come, request dates and times, plus countries where infected computers were located. The diagram below shows the number of unique IP addresses from which requests were sent to the botnet’s C&C center during the period 24 April to 07 August (by day).

The number of unique IP addresses in C&C log files per day

The diagram shows that on some days, the number of unique IP addresses reached 150 thousand. Importantly, these log files were obtained from one back-end server only, while the botnet has at least three such servers. It is unclear whether log files are stored centrally on one of the servers or whether each server generates its own log files. In the latter case, the actual figures could be significantly higher than those shown above.

According to the log files, computers in 235 countries across the globe have been infected with Trojan-Downloader.Win32.CodecPack. The table below shows the top 20 countries most affected by the malware.

Country %
United States 14.46%
Brazil 6.45%
India 5.65%
Germany 5.87%
Mexico 4.08%
France 2.45%
Italy 2.28%
United Kingdom 2.26%
Spain 2.14%
Colombia 2.01%
Vietnam 1.78%
Turkey 1.53%
Ukraine 1.47%
Canada 1.43%
Iran 1.43%
Pakistan 1.38%
Indonesia 1.35%
Thailand 1.31%
Peru 1.27%
Argentina 1.25%
Others 27.51%

The geographical distribution of computers infected with
(based on data from log files)

This list correlates closely with similar data obtained from the Kaspersky Security Network (KSN): the countries in the top 20 are largely the same, only their positions in the ranking have changed.

Country %
India 10.64%
United States 9.16%
Germany 5.48%
Russian Federation 4.61%
Italy 4.15%
Vietnam 3.64%
United Kingdom 3.63%
Saudi Arabia 2.92%
France 2.77%
Malaysia 2.55%
Brazil 2.45%
Spain 2.34%
Indonesia 2.299%
Canada 2.294%
Thailand 2.2%
Turkey 1.99%
Mexico 1.61%
Poland 1.55%
United Arab Emirates 1.50%
Iran 1.44%
Others 30.78%

The geographical distribution of Trojan-Downloader.Win32.CodecPack detection
(based on statistics from KSN)


One of the factors which favor the botnet’s growth is that the malware authors use a packer to protect the CodecPack downloader from detection. As mentioned above, the adware files downloaded by Trojan-Downloader.Win32.CodecPack are packed with the same packer as the downloader. The packer is polymorphic and uses anti-emulation techniques.

The downloader and the files downloaded by it are repacked relatively often, at least once a day, making detection of the malware a difficult task.

The number of repacked variants of Trojan-Downloader.Win32.CodecPack (per day)

As an experiment, Trojan-Downloader.Win32.CodecPack, which had been distributed by the cybercriminals two days earlier, was uploaded to the Virustotal antivirus scanning service. The result was encouraging: 40 antivirus products out of 43 detected the file as malicious.

Scanning results for a two-day-old file

Another sample, which had been distributed by the cybercriminals on the day of the experiment, was also uploaded to the service. The scanning results were disappointing to say the least: only 11 out of 43 antivirus products detected the file as malicious:

Disappointing scanning results for a ‘fresh’ sample

It appears that the cybercriminals are actively monitoring the detection of repacked programs by antivirus products. A Kaspersky Lab product with Kaspersky Security Network support enabled on it was installed on one of the computers. For some time, we received notifications that a Perl application on the computer was trying to download files detected by Kaspersky Lab as CodecPack from certain links. The links used gave us valuable information: they provided the names the bots were given by the malware authors and showed the folder structure used on the server, thereby disclosing the server’s purpose.

KSN notifications regarding Web Anti-Virus module responses triggered
by attempts to download files detected by Kaspersky Lab

This has enabled us to identify a server used by the malware authors to check the ability of different antivirus products to detect newly-repacked bots and CodecPack downloaders.

In conclusion

The Artro botnet has been in existence for over two years and has grown to an impressive size. The key element in building the botnet is Trojan-Downloader.Win32.CodecPack. This is protected with a polymorphic packer, by which it is repacked several times a day.

The botnet’s owners mainly specialize in generating fake website traffic. A large number of infected computers and a well organized business model allow the cybercriminals to deceive advertisers and make large amounts of money in the process. In addition to this line of business, the cybercriminals also make money from downloading third-party malware to infected computers. The number of infected machines, combined with a downloader that is not easy to detect, means that the CodecPack/Artro botnet is a very dangerous tool in the hands of the cybercriminals.

We will continue to closely monitor the Artro botnet’s activities.

The ‘Advertising’ Botnet

Your email address will not be published. Required fields are marked *



The leap of a Cycldek-related threat actor

The investigation described in this article started with one such file which caught our attention due to the various improvements it brought to this well-known infection vector.

Lazarus targets defense industry with ThreatNeedle

In mid-2020, we realized that Lazarus was launching attacks on the defense industry using the ThreatNeedle cluster, an advanced malware cluster of Manuscrypt (a.k.a. NukeSped). While investigating this activity, we were able to observe the complete life cycle of an attack, uncovering more technical details and links to the group’s other campaigns.

Sunburst backdoor – code overlaps with Kazuar

While looking at the Sunburst backdoor, we discovered several features that overlap with a previously identified backdoor known as Kazuar. Our observations shows that Kazuar was used together with Turla tools during multiple breaches in past years.

Subscribe to our weekly e-mails

The hottest research right in your inbox