January 24, 2014 at 15:49Attackers use Win32 / Boaxxe.BE to organize click fraud.
In this analysis, we want to talk about an interesting Win32 / Boaxxe.BE malware family that is used by cybercriminals to direct traffic to advertising sites using various click fraud techniques . In this way, attackers get material benefits from an advertiser who pays for clicks. The first part of the analysis covers the infrastructure of the affiliate network that is used to spread this malicious program; in the second part, we will focus on the technical aspects of the malicious code.
Distribution and profit
Win32 / Boaxxe.BE was distributed from the partnerka.me affiliate program website, which began its work in September 2013. Owners or clients of the affiliate program (partners) pay attackers for installing this malware on users' computers. The screenshot below shows the control panel of one of the partners (the so-called affiliate affiliate), which captures statistics related to the distribution of malicious code.
The "Promo" section indicates a malicious program that must be distributed through the branch.
The executable file with the malicious program itself is available either through direct download (Download) or through a special download URL (download link), which has the form “web5.asia/promos/download?token=TOKEN&sub_id=SUB-ID”. The TOKEN parameter is a value of 20 bytes in size, which identifies the affiliate (partner) branch. The SUB-ID parameter can also be used to identify the various executable files that are distributed by this branch.
The “Promo” section, on the part of the web page below the download buttons, shows the rating of detection of malware files by anti-virus products. We observed a change in the binary files of the malicious program every hour, which avoids detection by antivirus scanners. As it usually happens in such cases, the same malicious program is simply repacked in order to remove the detection.
Without going into technical details, we note that the executable files of the malicious program contain the identifier of the affiliate program, allowing the C&C server to correctly report the branch from which the malicious program was installed. The branch identifier is a double-byte value that increases by one for each new registered account in the affiliate program. Over the four months of our monitoring, the creation of forty new affiliate accounts was recorded.
The statistics page has the form.
The Installs column counts the number of successful malware installations. The purpose of the Blocked column is not entirely clear since we did not observe non-zero values for it. To understand the other columns, it should be noted that Win32 / Boaxxe.BE implements two different types of click fraud:
The website also provides a URL to a JSON object that contains the above statistics for processing directly by the partner. Interestingly, authentication is not used to access these statistics, so you just need to know the twenty-byte branch token to gain access to it. For example, we got statistics from one of the partners who used his account in the affiliate program from December 7th. In this case, the partner received more than three thousand installations (3.332) with a cash profit (PPC Profit) of $ 50 and $ 200 for automatic click fraud (CPV Profit). The statistics of this partner are shown below.
It is not surprising that attackers earned more for automatic clicks (CPV Actions) than for regular manual clicks. Automatic clicks are generated continuously by malicious code while the operating system is running. The CPV Actions / CPV Profit ratio gives us an approximate value of $ 0.0005 per click and Clicks / PPC Profit is equal to $ 0.015. It is obvious that redirecting a real user is more profitable for attackers.
The control panel web page contains a section for payment and support services through creating tickets for a partner.
The figure below illustrates the scheme used by attackers.
As we have already explained, malicious files to infect users are distributed by partnerska.me network partners. After infection, users will be forced to view advertising sites either automatically (covertly) or while clicking on links in a search engine. Infected machines use doorway search engines that return a list of advertising sites for a search query. Delivered URL links usually trigger a chain of redirects through sites that are linked by advertiser-publisher relationships (each website in the chain pays the previous one for received traffic).
In the end, advertised sites, among which may be legitimate, pay back the ad network for traffic. These networks charge a fee and pay part of the doorway service for the data received. Finally, partnerka.me receives the remaining part of the money, takes its share and pays the part to partners (branches).
We believe that the owners of the affiliate network are not related to the creation of Win32 / Boaxxe.BE, their service is only used to distribute this malicious program. Other versions of Boaxxe in-the-wild were noted that had additional functions in their composition: defense mechanisms or other implementation of existing modules, but at the same time they use redirects to the same ad networks.
The screenshot below shows the statistics of daily Win32 / Boaxxe.BE detections since the opening of partnerka.me in September 2013. The
interest of attackers in this malicious tool is quite high, which corresponds to an increase in the number of branches for its distribution. Peak activity indicators also correspond to the statistics of individual branches, for example, one of them launched a massive spam distribution campaign in late December.
Malicious browser extensions for click fraud
The installation process of the Win32 / Boaxxe.BE malicious code is shown in the figure below. This process involves three steps.
Win32 / Boaxxe.BE can initially be an installer (NSIS Installer), which contains an executable file and an auxiliary setup.dat file. The installer's task is to extract both files from itself and run the executable file, which, after checking the OS environment for emulators or debuggers, extracts the BMP image file from itself. An example image is presented below.
The data of this supposedly image is then decrypted into a new executable file, which is launched for execution. Such a technique is used to mislead analysts and automatic systems for analyzing malicious objects, which may decide that this file is not intended for execution. When converting the “image” file to executable, it is decrypted via RC4 and then unpacked using aPlib. Finally, CALL and JMP transition instructions are configured in the executable file using the special E8 / E9 method .
At the second stage, Win32 / Boaxxe.BE performs the installation of special extensions for browsers, through which later it will gain full access to the browser process and will click-fraud. The method of accessing the browser is different for different types of browsers, for example, as shown above, the browser extension mechanism is used to access Google Chrome and Mozilla Firefox, and in the case of Internet Explorer, special browser intercepts are used for the browser process. The following is an explanation of how malicious code uses its extensions to gain access to Chrome and Firefox.
Extensions for the Google Chrome browser are usually distributed through signed extensions. CRX files that can be installed simply by opening such a file in a browser. But for development purposes it is also possible to establish the so-called. "Unpacked" extension, this means that you can copy the extension files to the desired directory and modify the Chrome settings to download it. It is this method that is used in Win32 / Boaxxe.BE. The process begins with decryption using RC4 of various data contained in the body of the executable file.
One such data block is an extension manifest , which is a JSON object.
The name of the extension in the manifest will be selected based on the list of applications installed in the OS using characters from a value that depends on the hardware of the computer (hardware-specific). Thus, on each infected computer, the extension file will be with a new name. This manifest registers two JavaScript files. The first “background” will work in the context of the expansion process throughout its life. The second script will be embedded in each web page whose URL matches the matches parameter (in the example above, it will work for all web pages). The “permissions” parameter sets the required level of access to the specified web pages (for all) and the Chrome API for managing the browser.
The extension code itself is in three different files. The first is the background script, which consists of about 100 lines of obfuscated code and contains the basic logic of the extension.
The second script is a content-script with the following content.
It simply sends a message with the current URL and referrer to the receiving party and executes the response.
Another file is a JSON object called JSON_PAYLOAD, which consists of four fields.
Before saving the script files to disk, all parameters in the form of variables “@@ STRING @@” in the background script will be changed to the necessary values.
In the end, all three files are saved in the Chrome extension directory.
Installing an extension in Chrome is carried out through a modification of the extensions.settings JSON of the object contained in the settings file in the Chrome installation directory. This file contains information about all installed browser extensions. Win32 / Boaxxe.BE inserts the following lines to register its extension:
After all these operations, the JavaScript code necessary for attackers will be loaded into Chrome. It should be noted that Google announced a ban on installing this kind of browser extension since January 2014, if the browser itself is not used in developer mode.
Below are the files responsible for the extension for Firefox.
To install the extension in Firefox, the malicious code takes the following operations in the “Profile” directory of the browser: it registers the extension path in the “extensions.ini” file and checks for the presence of the extension with the same identifier in the SQLite database “extensions.sqlite”.
If such an identifier is present, the malicious code updates the table so that it points to a new extension. If there is no such identifier, then the extension is inserted into the table.
Payload
In the final step of the installation, Win32 / Boaxxe.BE retrieves its payload, which is stored on a remote server. To download it, use the message sent to the server, which is presented below.
The upper part of the message, highlighted in red, consists of four fields:
The blue part of the message contains the following supporting information.
The message is encrypted via RC4 using a 244-byte pseudo-random key. This key is additionally encrypted using the RSA public key, which is contained in the malicious code file. Further, this encrypted key and the encrypted message itself are subjected to additional encryption using base64.
The remote server responds with an html page that contains data encrypted using base64 in its body. After decryption, we get two executable files. The first DLL1 is a “springboard” library that will be registered through autorun to start in the context of the regsvr32.exe process. Its main purpose is to decrypt another DLL and to maintain its presence in the contexts of all system processes. The second DLL2 file is the actual Win32 / Boaxxe.BE payload and will be stored on the hard drive in encrypted form (RC4). The key for encryption through RC4 is generated through the values of the serial number of the disk and other hardware-dependent data. In other words, without information about the computer hardware, it will be difficult to decrypt the library (this type of cryptographic key is also known as an environmental key, “environmental key”).
After the request operation of the payload from the server, the column with the number of installations on the statistics of the partnerka.me network partner control panel will increase by one. But this will only happen if such a request arrives for the first time from this computer.
It should be noted that malicious code detects AV products running on the computer through the names of their processes and then sends this information to the server when receiving payload files (parameter v). This allows the remote server to use auxiliary mechanisms that will reduce the likelihood of detecting the payload. For example, if the ESET antivirus product is running on a computer, the resulting payload is protected through the Themida commercial protector .
DLL1 will always work on the system in the context of the regsvr32.exe process; it also registers a handler for the WH_CALLWNDPROC message. Thus, this library, in the future, will be loaded into all GUI processes that receive such a message. Each time loading into the address space of a new process, DLL1 will decrypt DLL2 and call its main function. This DLL2 is responsible for performing various functions, including its own DNS cache, user click fraud module, and automatic click fraud.
When DLL2 is loaded into the address space of the browser process (IE, Firefox, Chrome), it creates and maintains its own DNS cache, which stores the correspondence between domain names and IP addresses. The main purpose of such a cache is to avoid detection of malicious code activity by traffic analysis systems on the network. The cache itself relies on two data structures. The first is the DNS_CACHE cache itself, which consists of records of a fixed length of 0x60 bytes. An example of such a structure is shown below.
Each entry contains information related to one domain name, which can be both legitimate (i.e. does not apply to Boaxxe) and malicious. The entry consists of:
The following structure is a more concise version of the previous one.
This associative container (map) has a capacity of 256 elements, each of which is 24 bytes in size. The key is the checksum value (marked in blue) of the name of the domain stored in the cache, followed by the IP address associated with it, and finally two timestamp fields that describe the time interval when the domain was active. The entire structure is stored in a specific registry key and is regularly updated from the DNS cache in memory. Thus, malicious code can accumulate domain mapping information, store it for the time it needs, and use it as necessary.
When DLL2 is launched for the first time on a computer, in the context of the regsvr32.exe process, the DNS cache is empty. In this case, a set of about five hundred legitimate domains, in encrypted form, is stored in the DLL2 library. The program then selects a subset of the available domains based on the hardware-dependent value to populate the cache. Thus, different infected computers will have a different selection of a certain number of legitimate domains. When loading DLL2 into the address space of the browser process, for the first time, it adds several (usually four) malicious domains to the cache, in accordance with the value of the affiliate ID.
A malicious program pursues certain goals by choosing legitimate domains arbitrarily for a particular computer. This is to ensure that malicious code cannot be identified by the same series of DNS queries if traffic is monitored by analysis systems. Thus, it is difficult to build reliable Win32 / Boaxxe.BE discovery based on the DNS query pattern.
The malicious code will regularly check each entry in its cache and update it if 24 hours have passed since the last update. As expected, it uses a DNS query to update the record, but the received IP address will not match the one used by the malicious code in reality. In fact, the last three bytes of the received IP address will be encrypted using RC4 and the “ANKS” key to obtain the real IP address associated with the domain.
Consider an example: if you execute a DNS query for thegreerfive.biz domain (the malicious domain used by Win32 / Boaxxe.BE), you will get the IP address 31.240.6.70 as a response (1F F0 06 46 in hexadecimal). But the real server address that is associated with this domain is 31.193.0.178 (1F C1 00 B2), because applying RC4 with the “ANKS” key to bytes F0 06 46 gives us C1 00 B2.
As you already understood, the operators responsible for managing the Win32 / Boaxxe.BE infrastructure only control real IP addresses, that is, addresses obtained using the encryption algorithm that is applied to the address from a real DNS record. Thus, a simple analysis of the domains with which the malware contacts is completely useless without a key with which you can get real addresses.
Implementing a click fraud A
user-initiated click fraud is a process of redirecting users to web resources that an attacker needs when he performs a search query. This allows Win32 / Boaxxe.BE to drive traffic for advertising sites. Such engagement is performed meaningfully for a specific search query. The logic of this fraudulent scheme is presented in the figure below. Blue text indicates the actions of the user, and red indicates the actions of the malicious program.
At the first stage, the user performs a search query using the keyword K and receives as a response a list of sites matching this word. At the same time, Win32 / Boaxxe.BE sends the word K to its own search engine, which also returns a list of related sites. If there are no sites related to this keyword, redirection is not performed. At the second stage, the user clicks (clicks) on the selected site and receives the contents of the corresponding web page. If the user has Win32 / Boaxxe.BE installed, then he forcibly clicks on the corresponding link from the returned list. In practice, the user does not have time to see the web page that he clicked on; instead, he gets to the web page initiated by the malicious code.
As we indicated above, click fraud operations initiated by the user for Chrome and Firefox are implemented in browser extensions, and for Internet Explorer malicious code uses intercepts in the process memory.
The operations used in the extensions are similar for both browsers, so we describe this process only for Google Chrome. As we mentioned above, the extension for Chrome consists of two JavaScript files: a background script, an instance of which will always be active, and a content script, an instance of which will work for each web page.
When launched, the background script will decrypt JSON_PAYLOAD and calculate its field “c” (see above), which contains the logic of the extension. This code declares an array containing search engines supported by malicious code. All of them receive keywords from the user as parameters through a GET request, which is analyzed by malicious code. The list of search engines that was used by malicious code in December is given below.
Take the URL of the search query “www.google.com/search?q=cat” as an example, it is obvious that it will match the first row of the table and the keyword “cat” will be extracted by malicious code from the URL and then sent to the Win32 / Boaxxe.BE, which is searchpagex.com (searchpagex.org in the case of Firefox) in recent months.
In addition, the malicious code supports the so-called white list of sites: Wikipedia, Facebook, Twitter. If these sites are present in the GET request, the user will not be redirected to the Boaxxe domain. This possibility allows him to be more secretive, since in the case of redirects with these sites, the user can immediately suspect malicious activity in the browser.
Boaxxe registers event handlers using the Chrome API to process each URL the user visits. Using these handlers, which are contained in the content script, the malware implements the redirect logic. The response of the Win32 / Boaxxe.BE search engine is a JSON object that contains URLs in the form “searchpagex.com/c?t=BASE64ID”. When you visit one of these URLs, a redirect chain occurs with the ad network, which ends with a website that is directly related to the keyword. Simultaneously with this redirection process, the extension will check every hour the URL specified in the parameter “c” of the field of the JSON_PAYLOAD object to request its new version.
To implement custom click fraud in Internet Explorer, Win32 / Boaxxe.BE intercepts the following API functions: HttpAddRequestHeadersA , CreateWindowExW and DrawTextExW . The handlers of these functions are located in the body of the malicious program and subsequently provide URL addresses that the user must visit, which runs in a separate Boaxxe stream.
This thread implements a similar logic to the one we described in the case of the extension for Chrome. It compares incoming URLs with a list of search engines and retrieves keywords from the request. The difference is that it sends the extracted keywords not to its own search engine, but to a malicious IP address, which is stored in the DNS cache. The response from the server is encrypted using RC4 and has the following form.
The “u” parameter is used to identify the URL to which the user should be redirected, and the “r” parameter contains information about the referrer. This redirect source URL is indicated by the Win32 / Boaxxe.BE search engine. Using this referrer field allows malicious code operators to benefit from the ad network. In this way, a user transition is imitated using the doorway search engine.
Automatic click fraud is a covert visit to web resources with malicious code without user intervention. To perform this action, the Win32 / Boaxxe.BE code, running in the context of regsvr32.exe, launches Internet Explorer. This new process is invisible to the user due to the active “-Embedding” parameter with which the browser is running.
Boaxxe modifies various Internet Explorer options, for example, to turn off navigation sounds or to remove restrictions on file downloads. It also creates a thread that constantly monitors its execution time and the memory used by the process; if the amount of memory consumed or the execution time is large, then the process is forcibly terminated. Malicious code also intercepts the MessageBeep function, which can be used to play sound effects.
In addition, Win32 / Boaxxe.BE adds new entries associated with the partner identifier to its own DNS cache. Then he sends a request to one of them, using RC4 / base64 encryption, and receives as a response the information necessary to perform an automatic click fraud. An example response is given below:
A description of the important response parameters is given below.
Based on the message above, the browser process will visit the URL specified by the “u” parameter with the referrer, which is represented by the “r” parameter. The source URL for the visit begins a chain of redirects of four or five intermediate links (using HTTP status 302). Each of the pages visited in the chain is analyzed to extract links from it, which, in the future, will be redirected to. The recursion depth or the number of redirects is specified by the “n” parameter.
In the process of performing these operations, the flow periodically falls asleep for a certain amount of time, indicated by the parameter "t". This is probably done to simulate human behavior when visiting various sites. After visiting advertising pages, the malicious code performs an HTTP GET request to one of the legitimate well-known sites (Google, Facebook, Twitter, etc.). This allows malicious code to more effectively mask click frauds in the network traffic stream.
Conclusion
We tried to describe in detail the operation of the Win32 / Boaxxe.BE malicious code, the main purpose of which is to generate clicks (click fraud) with the subsequent extraction of material benefit from the advertiser by the attackers. The malware contains several mechanisms for hiding its traffic, including encrypting it, using requests to legitimate websites, and using its own DNS cache.
SHA-1 samples
Distribution and profit
Win32 / Boaxxe.BE was distributed from the partnerka.me affiliate program website, which began its work in September 2013. Owners or clients of the affiliate program (partners) pay attackers for installing this malware on users' computers. The screenshot below shows the control panel of one of the partners (the so-called affiliate affiliate), which captures statistics related to the distribution of malicious code.
The "Promo" section indicates a malicious program that must be distributed through the branch.
The executable file with the malicious program itself is available either through direct download (Download) or through a special download URL (download link), which has the form “web5.asia/promos/download?token=TOKEN&sub_id=SUB-ID”. The TOKEN parameter is a value of 20 bytes in size, which identifies the affiliate (partner) branch. The SUB-ID parameter can also be used to identify the various executable files that are distributed by this branch.
The “Promo” section, on the part of the web page below the download buttons, shows the rating of detection of malware files by anti-virus products. We observed a change in the binary files of the malicious program every hour, which avoids detection by antivirus scanners. As it usually happens in such cases, the same malicious program is simply repacked in order to remove the detection.
Without going into technical details, we note that the executable files of the malicious program contain the identifier of the affiliate program, allowing the C&C server to correctly report the branch from which the malicious program was installed. The branch identifier is a double-byte value that increases by one for each new registered account in the affiliate program. Over the four months of our monitoring, the creation of forty new affiliate accounts was recorded.
The statistics page has the form.
The Installs column counts the number of successful malware installations. The purpose of the Blocked column is not entirely clear since we did not observe non-zero values for it. To understand the other columns, it should be noted that Win32 / Boaxxe.BE implements two different types of click fraud:
- User-initiated click fraud: the user enters a search query in a browser and the malicious code substitutes advertising sites in relevant search results. This practice is implemented in various malware families, for example, Win32 / TrojanDownloader.Tracur and Win32 / Goblin (aka Win32 / Xpaj). Statistics for this type of click fraud are recorded in the following columns:
- Active : the number of computers infected with Win32 / Boaxxe.BE that were used to browse the web on that day.
- Searches : The number of keywords used in the search query.
- Clicks : the number of redirects made by the user (clicks completed).
- PPC Profit : the amount earned by this partner through click fraud.
- Automatic click fraud: Win32 / Boaxxe.BE incorporates the ability to secretly visit advertising sites without the user's knowledge.
- Live : number of infected computers that perform click fraud.
- CPV Actions : the number of automatic click fraud actions performed by the malware.
- CPV Profit : amount earned by a partner through click fraud.
The website also provides a URL to a JSON object that contains the above statistics for processing directly by the partner. Interestingly, authentication is not used to access these statistics, so you just need to know the twenty-byte branch token to gain access to it. For example, we got statistics from one of the partners who used his account in the affiliate program from December 7th. In this case, the partner received more than three thousand installations (3.332) with a cash profit (PPC Profit) of $ 50 and $ 200 for automatic click fraud (CPV Profit). The statistics of this partner are shown below.
It is not surprising that attackers earned more for automatic clicks (CPV Actions) than for regular manual clicks. Automatic clicks are generated continuously by malicious code while the operating system is running. The CPV Actions / CPV Profit ratio gives us an approximate value of $ 0.0005 per click and Clicks / PPC Profit is equal to $ 0.015. It is obvious that redirecting a real user is more profitable for attackers.
The control panel web page contains a section for payment and support services through creating tickets for a partner.
The figure below illustrates the scheme used by attackers.
As we have already explained, malicious files to infect users are distributed by partnerska.me network partners. After infection, users will be forced to view advertising sites either automatically (covertly) or while clicking on links in a search engine. Infected machines use doorway search engines that return a list of advertising sites for a search query. Delivered URL links usually trigger a chain of redirects through sites that are linked by advertiser-publisher relationships (each website in the chain pays the previous one for received traffic).
In the end, advertised sites, among which may be legitimate, pay back the ad network for traffic. These networks charge a fee and pay part of the doorway service for the data received. Finally, partnerka.me receives the remaining part of the money, takes its share and pays the part to partners (branches).
We believe that the owners of the affiliate network are not related to the creation of Win32 / Boaxxe.BE, their service is only used to distribute this malicious program. Other versions of Boaxxe in-the-wild were noted that had additional functions in their composition: defense mechanisms or other implementation of existing modules, but at the same time they use redirects to the same ad networks.
The screenshot below shows the statistics of daily Win32 / Boaxxe.BE detections since the opening of partnerka.me in September 2013. The
interest of attackers in this malicious tool is quite high, which corresponds to an increase in the number of branches for its distribution. Peak activity indicators also correspond to the statistics of individual branches, for example, one of them launched a massive spam distribution campaign in late December.
Malicious browser extensions for click fraud
The installation process of the Win32 / Boaxxe.BE malicious code is shown in the figure below. This process involves three steps.
Win32 / Boaxxe.BE can initially be an installer (NSIS Installer), which contains an executable file and an auxiliary setup.dat file. The installer's task is to extract both files from itself and run the executable file, which, after checking the OS environment for emulators or debuggers, extracts the BMP image file from itself. An example image is presented below.
The data of this supposedly image is then decrypted into a new executable file, which is launched for execution. Such a technique is used to mislead analysts and automatic systems for analyzing malicious objects, which may decide that this file is not intended for execution. When converting the “image” file to executable, it is decrypted via RC4 and then unpacked using aPlib. Finally, CALL and JMP transition instructions are configured in the executable file using the special E8 / E9 method .
At the second stage, Win32 / Boaxxe.BE performs the installation of special extensions for browsers, through which later it will gain full access to the browser process and will click-fraud. The method of accessing the browser is different for different types of browsers, for example, as shown above, the browser extension mechanism is used to access Google Chrome and Mozilla Firefox, and in the case of Internet Explorer, special browser intercepts are used for the browser process. The following is an explanation of how malicious code uses its extensions to gain access to Chrome and Firefox.
Extensions for the Google Chrome browser are usually distributed through signed extensions. CRX files that can be installed simply by opening such a file in a browser. But for development purposes it is also possible to establish the so-called. "Unpacked" extension, this means that you can copy the extension files to the desired directory and modify the Chrome settings to download it. It is this method that is used in Win32 / Boaxxe.BE. The process begins with decryption using RC4 of various data contained in the body of the executable file.
One such data block is an extension manifest , which is a JSON object.
The name of the extension in the manifest will be selected based on the list of applications installed in the OS using characters from a value that depends on the hardware of the computer (hardware-specific). Thus, on each infected computer, the extension file will be with a new name. This manifest registers two JavaScript files. The first “background” will work in the context of the expansion process throughout its life. The second script will be embedded in each web page whose URL matches the matches parameter (in the example above, it will work for all web pages). The “permissions” parameter sets the required level of access to the specified web pages (for all) and the Chrome API for managing the browser.
The extension code itself is in three different files. The first is the background script, which consists of about 100 lines of obfuscated code and contains the basic logic of the extension.
The second script is a content-script with the following content.
It simply sends a message with the current URL and referrer to the receiving party and executes the response.
Another file is a JSON object called JSON_PAYLOAD, which consists of four fields.
Before saving the script files to disk, all parameters in the form of variables “@@ STRING @@” in the background script will be changed to the necessary values.
- The “TOKEN” parameter is changed to a string encoded using base64 and RC4 (with the “tokencryptkey” key). The string can take the form "u: 14AB8569 w: 1234 p: 1 c: 5b b: 32 v: 0".
- The “LOGIC” parameter is changed to the JSON_PAYLOAD content encoded through base64 and RC4 using the previous “TOKEN” value as the key.
In the end, all three files are saved in the Chrome extension directory.
Installing an extension in Chrome is carried out through a modification of the extensions.settings JSON of the object contained in the settings file in the Chrome installation directory. This file contains information about all installed browser extensions. Win32 / Boaxxe.BE inserts the following lines to register its extension:
After all these operations, the JavaScript code necessary for attackers will be loaded into Chrome. It should be noted that Google announced a ban on installing this kind of browser extension since January 2014, if the browser itself is not used in developer mode.
Below are the files responsible for the extension for Firefox.
- install.rdf, is an extension manifest. The
fields "id", "name", "version" and "creator" will be filled with values that are hardware-dependent. For our example, these fields will take the values "id" as "{1234}" and "name" as "Microsoft Office". - The chrome.manifest file is decrypted and consists of the following data.
This file announces the JavaScript extension code in the first line (“component”), and then ensures that the extension is loaded and will be notified when the browser starts. When writing the contents of a script file to disk, variables of the type @@ STRING @@ are substituted with the corresponding values. Ultimately, three install.rdf, chrome.manifest and JavaScript files are saved to disk, in the directory with the browser.
To install the extension in Firefox, the malicious code takes the following operations in the “Profile” directory of the browser: it registers the extension path in the “extensions.ini” file and checks for the presence of the extension with the same identifier in the SQLite database “extensions.sqlite”.
If such an identifier is present, the malicious code updates the table so that it points to a new extension. If there is no such identifier, then the extension is inserted into the table.
Payload
In the final step of the installation, Win32 / Boaxxe.BE retrieves its payload, which is stored on a remote server. To download it, use the message sent to the server, which is presented below.
The upper part of the message, highlighted in red, consists of four fields:
- checksum field;
- payload size
- type of message;
- Partner ID
The blue part of the message contains the following supporting information.
The message is encrypted via RC4 using a 244-byte pseudo-random key. This key is additionally encrypted using the RSA public key, which is contained in the malicious code file. Further, this encrypted key and the encrypted message itself are subjected to additional encryption using base64.
The remote server responds with an html page that contains data encrypted using base64 in its body. After decryption, we get two executable files. The first DLL1 is a “springboard” library that will be registered through autorun to start in the context of the regsvr32.exe process. Its main purpose is to decrypt another DLL and to maintain its presence in the contexts of all system processes. The second DLL2 file is the actual Win32 / Boaxxe.BE payload and will be stored on the hard drive in encrypted form (RC4). The key for encryption through RC4 is generated through the values of the serial number of the disk and other hardware-dependent data. In other words, without information about the computer hardware, it will be difficult to decrypt the library (this type of cryptographic key is also known as an environmental key, “environmental key”).
After the request operation of the payload from the server, the column with the number of installations on the statistics of the partnerka.me network partner control panel will increase by one. But this will only happen if such a request arrives for the first time from this computer.
It should be noted that malicious code detects AV products running on the computer through the names of their processes and then sends this information to the server when receiving payload files (parameter v). This allows the remote server to use auxiliary mechanisms that will reduce the likelihood of detecting the payload. For example, if the ESET antivirus product is running on a computer, the resulting payload is protected through the Themida commercial protector .
DLL1 will always work on the system in the context of the regsvr32.exe process; it also registers a handler for the WH_CALLWNDPROC message. Thus, this library, in the future, will be loaded into all GUI processes that receive such a message. Each time loading into the address space of a new process, DLL1 will decrypt DLL2 and call its main function. This DLL2 is responsible for performing various functions, including its own DNS cache, user click fraud module, and automatic click fraud.
When DLL2 is loaded into the address space of the browser process (IE, Firefox, Chrome), it creates and maintains its own DNS cache, which stores the correspondence between domain names and IP addresses. The main purpose of such a cache is to avoid detection of malicious code activity by traffic analysis systems on the network. The cache itself relies on two data structures. The first is the DNS_CACHE cache itself, which consists of records of a fixed length of 0x60 bytes. An example of such a structure is shown below.
Each entry contains information related to one domain name, which can be both legitimate (i.e. does not apply to Boaxxe) and malicious. The entry consists of:
- The name of the domain preceded by its length in the first byte.
- The domain purpose field “domain purpose” (marked in red) is used to separate legitimate domains from malicious ones.
- IP address field (marked in blue). As we explain below, this address is actually not exactly the one that is directly associated with the domain.
- The field is “already resolved” (marked in green).
- The timestamp of the last successful domain resolution (marked in black) in Windows OLE x64 format.
The following structure is a more concise version of the previous one.
This associative container (map) has a capacity of 256 elements, each of which is 24 bytes in size. The key is the checksum value (marked in blue) of the name of the domain stored in the cache, followed by the IP address associated with it, and finally two timestamp fields that describe the time interval when the domain was active. The entire structure is stored in a specific registry key and is regularly updated from the DNS cache in memory. Thus, malicious code can accumulate domain mapping information, store it for the time it needs, and use it as necessary.
When DLL2 is launched for the first time on a computer, in the context of the regsvr32.exe process, the DNS cache is empty. In this case, a set of about five hundred legitimate domains, in encrypted form, is stored in the DLL2 library. The program then selects a subset of the available domains based on the hardware-dependent value to populate the cache. Thus, different infected computers will have a different selection of a certain number of legitimate domains. When loading DLL2 into the address space of the browser process, for the first time, it adds several (usually four) malicious domains to the cache, in accordance with the value of the affiliate ID.
A malicious program pursues certain goals by choosing legitimate domains arbitrarily for a particular computer. This is to ensure that malicious code cannot be identified by the same series of DNS queries if traffic is monitored by analysis systems. Thus, it is difficult to build reliable Win32 / Boaxxe.BE discovery based on the DNS query pattern.
The malicious code will regularly check each entry in its cache and update it if 24 hours have passed since the last update. As expected, it uses a DNS query to update the record, but the received IP address will not match the one used by the malicious code in reality. In fact, the last three bytes of the received IP address will be encrypted using RC4 and the “ANKS” key to obtain the real IP address associated with the domain.
Consider an example: if you execute a DNS query for thegreerfive.biz domain (the malicious domain used by Win32 / Boaxxe.BE), you will get the IP address 31.240.6.70 as a response (1F F0 06 46 in hexadecimal). But the real server address that is associated with this domain is 31.193.0.178 (1F C1 00 B2), because applying RC4 with the “ANKS” key to bytes F0 06 46 gives us C1 00 B2.
As you already understood, the operators responsible for managing the Win32 / Boaxxe.BE infrastructure only control real IP addresses, that is, addresses obtained using the encryption algorithm that is applied to the address from a real DNS record. Thus, a simple analysis of the domains with which the malware contacts is completely useless without a key with which you can get real addresses.
Implementing a click fraud A
user-initiated click fraud is a process of redirecting users to web resources that an attacker needs when he performs a search query. This allows Win32 / Boaxxe.BE to drive traffic for advertising sites. Such engagement is performed meaningfully for a specific search query. The logic of this fraudulent scheme is presented in the figure below. Blue text indicates the actions of the user, and red indicates the actions of the malicious program.
At the first stage, the user performs a search query using the keyword K and receives as a response a list of sites matching this word. At the same time, Win32 / Boaxxe.BE sends the word K to its own search engine, which also returns a list of related sites. If there are no sites related to this keyword, redirection is not performed. At the second stage, the user clicks (clicks) on the selected site and receives the contents of the corresponding web page. If the user has Win32 / Boaxxe.BE installed, then he forcibly clicks on the corresponding link from the returned list. In practice, the user does not have time to see the web page that he clicked on; instead, he gets to the web page initiated by the malicious code.
As we indicated above, click fraud operations initiated by the user for Chrome and Firefox are implemented in browser extensions, and for Internet Explorer malicious code uses intercepts in the process memory.
The operations used in the extensions are similar for both browsers, so we describe this process only for Google Chrome. As we mentioned above, the extension for Chrome consists of two JavaScript files: a background script, an instance of which will always be active, and a content script, an instance of which will work for each web page.
When launched, the background script will decrypt JSON_PAYLOAD and calculate its field “c” (see above), which contains the logic of the extension. This code declares an array containing search engines supported by malicious code. All of them receive keywords from the user as parameters through a GET request, which is analyzed by malicious code. The list of search engines that was used by malicious code in December is given below.
Take the URL of the search query “www.google.com/search?q=cat” as an example, it is obvious that it will match the first row of the table and the keyword “cat” will be extracted by malicious code from the URL and then sent to the Win32 / Boaxxe.BE, which is searchpagex.com (searchpagex.org in the case of Firefox) in recent months.
In addition, the malicious code supports the so-called white list of sites: Wikipedia, Facebook, Twitter. If these sites are present in the GET request, the user will not be redirected to the Boaxxe domain. This possibility allows him to be more secretive, since in the case of redirects with these sites, the user can immediately suspect malicious activity in the browser.
Boaxxe registers event handlers using the Chrome API to process each URL the user visits. Using these handlers, which are contained in the content script, the malware implements the redirect logic. The response of the Win32 / Boaxxe.BE search engine is a JSON object that contains URLs in the form “searchpagex.com/c?t=BASE64ID”. When you visit one of these URLs, a redirect chain occurs with the ad network, which ends with a website that is directly related to the keyword. Simultaneously with this redirection process, the extension will check every hour the URL specified in the parameter “c” of the field of the JSON_PAYLOAD object to request its new version.
To implement custom click fraud in Internet Explorer, Win32 / Boaxxe.BE intercepts the following API functions: HttpAddRequestHeadersA , CreateWindowExW and DrawTextExW . The handlers of these functions are located in the body of the malicious program and subsequently provide URL addresses that the user must visit, which runs in a separate Boaxxe stream.
This thread implements a similar logic to the one we described in the case of the extension for Chrome. It compares incoming URLs with a list of search engines and retrieves keywords from the request. The difference is that it sends the extracted keywords not to its own search engine, but to a malicious IP address, which is stored in the DNS cache. The response from the server is encrypted using RC4 and has the following form.
The “u” parameter is used to identify the URL to which the user should be redirected, and the “r” parameter contains information about the referrer. This redirect source URL is indicated by the Win32 / Boaxxe.BE search engine. Using this referrer field allows malicious code operators to benefit from the ad network. In this way, a user transition is imitated using the doorway search engine.
Automatic click fraud is a covert visit to web resources with malicious code without user intervention. To perform this action, the Win32 / Boaxxe.BE code, running in the context of regsvr32.exe, launches Internet Explorer. This new process is invisible to the user due to the active “-Embedding” parameter with which the browser is running.
Boaxxe modifies various Internet Explorer options, for example, to turn off navigation sounds or to remove restrictions on file downloads. It also creates a thread that constantly monitors its execution time and the memory used by the process; if the amount of memory consumed or the execution time is large, then the process is forcibly terminated. Malicious code also intercepts the MessageBeep function, which can be used to play sound effects.
In addition, Win32 / Boaxxe.BE adds new entries associated with the partner identifier to its own DNS cache. Then he sends a request to one of them, using RC4 / base64 encryption, and receives as a response the information necessary to perform an automatic click fraud. An example response is given below:
A description of the important response parameters is given below.
Based on the message above, the browser process will visit the URL specified by the “u” parameter with the referrer, which is represented by the “r” parameter. The source URL for the visit begins a chain of redirects of four or five intermediate links (using HTTP status 302). Each of the pages visited in the chain is analyzed to extract links from it, which, in the future, will be redirected to. The recursion depth or the number of redirects is specified by the “n” parameter.
In the process of performing these operations, the flow periodically falls asleep for a certain amount of time, indicated by the parameter "t". This is probably done to simulate human behavior when visiting various sites. After visiting advertising pages, the malicious code performs an HTTP GET request to one of the legitimate well-known sites (Google, Facebook, Twitter, etc.). This allows malicious code to more effectively mask click frauds in the network traffic stream.
Conclusion
We tried to describe in detail the operation of the Win32 / Boaxxe.BE malicious code, the main purpose of which is to generate clicks (click fraud) with the subsequent extraction of material benefit from the advertiser by the attackers. The malware contains several mechanisms for hiding its traffic, including encrypting it, using requests to legitimate websites, and using its own DNS cache.
SHA-1 samples