Attackers use Win32 / Boaxxe.BE to organize clickfroot
In this analysis, we want to tell about an interesting family of Win32 / Boaxxe.BE malware , which is used by attackers to direct traffic to advertising sites using various click-fraud techniques. Thus, the attackers receive a material benefit from the advertiser who pays for clicks. The first part of the analysis covers the infrastructure of the partner network that is used to distribute 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 partner program site, which began its work in September 2013. The owners or clients of the affiliate program (partners) pay attackers for installing this malicious program 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 malware that must be distributed through the branch.
The executable file with malware 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 20-byte value that identifies the affiliate affiliate (partner). The SUB-ID parameter can also be used to identify various executable files that are distributed by this branch.
In the "Promo" section, on the part of the web page that is located below the download buttons, shows the detection rate of malicious program files by antivirus products. We observed a change in the binary files of the malware every hour, thus avoiding detection by antivirus scanners. As is usually the case in such cases, the same malicious program is simply repackaged 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 partner program, allowing the C & C server to correctly report the branch from which the malicious program was installed. The branch identifier is a two-byte value, which is incremented by one for each new registered account in the affiliate program. For four months of our monitoring, the creation of forty new partner accounts has been recorded.
A page with statistics looks like.
The Installs column counts the number of successful installations of the malware. The purpose of the Blocked column is not entirely clear since we did not observe nonzero values ​​for it. To understand the other columns, it should be noted that Win32 / Boaxxe.BE implements two different types of clickfruits:
The website also provides a URL to the JSON object, which contains the above statistics for its processing directly by the partner. Interestingly, authentication is not used to access these statistics, so you just need to know the branch’s twenty-second mark to access it. For example, we received statistics from one of the partners who used their 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 an automatic clickfrod (CPV Profit). Below is the statistics of this partner.
It is not surprising that attackers automatically earned more than regular clicks manually generated by the user for automatic clicks (CPV Actions). 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 $ 0.015. Obviously, real user redirection is more profitable for intruders.
The web page of the control panel contains a section for payment and support services through the creation of tickets for a partner.
The figure below illustrates the scheme used by the attackers.
As we have already explained, malicious files for infecting users are spread by partners of the partnerka.me network. After infection, users will be forced to browse advertising sites either automatically (covertly), or while clicking on links in a search engine. Infected cars use doorway search engines that return a list of advertising sites for a search query. Linked URLs usually launch a chain of redirections through sites that are linked to an advertiser-publisher relationship (each website in the chain pays back to the traffic received).
In the end, advertised sites, among which may be legitimate, pay back to the advertising network for traffic. These networks charge a fee and pay part of the doorway service for the data. Finally, partnerka.me receives the rest of the money, takes its share and pays a part to the partners (affiliates).
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 malware. Other versions of Boaxxe in-the-wild were also noted, which had additional functions in their composition: defense mechanisms or another implementation of existing modules, but they also use redirections to the same advertising networks.
The screenshot below shows the statistics for daily Win32 / Boaxxe.BE detections since partnerka.me was opened in September 2013.
The interest of intruders in this malicious tool is quite high, which corresponds to an increase in the number of branches in its distribution. Peak activity indicators are also consistent with the statistics of individual branches, for example, one of them started a massive spam campaign for distribution in late December.
Malicious browser extensions to execute clickfrod
The installation process of the Win32 / Boaxxe.BE malicious code is shown below. This process involves three steps.
Win32 / Boaxxe.BE may initially be an installer (NSIS Installer), which contains an executable file and an auxiliary file setup.dat. The task of the installer 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 shown below.
The data of this alleged image is then decrypted already in a new executable file, which is launched for execution. This technique is used to mislead analysts and automatic systems for analyzing malicious objects that may decide that this file is not intended for execution. When converting an “image” file into an executable file, it is decrypted via RC4, and then decompressed using aPlib. Finally, the CALL and JMP transition instructions are configured in the executable file using the special method E8 / E9 .
At the second stage, Win32 / Boaxxe.BE installs special extensions for browsers through which later it will get full access to the browser process and will click the folder. The method of accessing the browser is different for different types of browsers, for example, as shown above, the browser extensions mechanism is used to access Google Chrome and Mozilla Firefox, and in the case of Internet Explorer, special hooks in memory are used for the browser process. Below 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 via subscribed ones. CRX files that can be installed simply by opening such a file in the 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 correct directory and modify the Chrome settings to load it. This method is used in Win32 / Boaxxe.BE. The process begins with the decryption using RC4 of various data contained in the body of the executable file.
One of these data blocks 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 computer hardware (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 work. The second script will be embedded in each web page, the URL of which corresponds to the parameter “matches” (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 to control 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 main 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 the “@@ STRING @@” variables in the background script will be changed to the required values.
In the end, all three files are stored in the Chrome extension directory.
The extension is installed in Chrome by modifying the extensions.settings JSON object, which is contained in the settings file, in the Chrome installation directory. This file contains information about all installed browser extensions. Win32 / Boaxxe.BE to register its extension inserts the following lines there:
After all these operations, the JavaScript code required by the attackers will be uploaded to Chrome. It should be noted that Google announced a ban on the installation of this kind of browser extensions from January 2014, if the browser itself is not used in developer mode.
Below are the files responsible for the extension for Firefox.
To install an extension in Firefox, the malicious code undertakes the following operations in the browser’s Profile directory: registers the path to the extension in the extensions.ini file and checks for the presence of an extension with the same identifier in the SQL extensions.sqlite database.
In the presence of such an identifier, the malicious code updates the table so that it points to a new extension. If there is no such identifier, the extension is inserted into the table.
Payload
In the final stage of the installation, Win32 / Boaxxe.BE performs the extraction of 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 message portion highlighted in blue contains the following supporting information.
The message is encrypted via RC4 using a 244-byte pseudo-arbitrary 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 in its body the data encrypted using base64. After decryption, we get two executable files. The first DLL1 is the "springboard" library, which will be registered through autorun for start in the context of the regsvr32.exe process. Its main purpose is to decipher another DLL and to maintain its presence in the contexts of all processes of the system. The second DLL2 file is the actual Win32 / Boaxxe.BE payload and will be stored on the hard disk in encrypted form (RC4). The key for encryption via RC4 is formed through the values ​​of the disk serial number and other hardware-dependent data. In other words, without having information about the hardware of the computer, it will be difficult to decrypt the library (this type of cryptographic key is also known as the environmental key, "environmental key").
After the operation of requesting a payload from the server, the column with the number of installations on the statistics of the partnerka partner’s control panel will increase by one. But this will happen only if such a request is received for the first time from this computer.
It should be noted that malicious code detects AV products running on a 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 apply auxiliary mechanisms that will reduce the likelihood of payload detection. For example, in the case of an ESET antivirus product 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, a custom click-frame module and an 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 detecting the activity of malicious code from 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 fixed-length entries of 0x60 bytes. An example of such a structure is shown below.
Each entry contains information related to one domain name, which can be either legitimate (that is, not related to Boaxxe) or malicious. The record 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 domain name 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, the malicious code can accumulate information on the domain mapping, save it for the time it needs and use it as necessary.
When DLL2 is run for the first time on a computer, in the context of the regsvr32.exe process, the DNS cache is empty. At the same time, a set of about five hundred legitimate domains, in encrypted form, is stored in DLL2. The program then selects a subset of the existing domains based on a hardware-dependent value to fill the cache. Thus, a different sample of a certain number of legitimate domains will be made on different infected computers. In the process of loading DLL2 into the address space of the browser process, for the first time, it adds several (usually four) malicious domains to the cache, according to the value of the partner identifier (affiliate ID).
The malware pursues certain goals by choosing legitimate domains arbitrarily for a specific computer. This is done so that the malicious code cannot be identified by the same series of DNS queries in case of traffic tracking by the analysis systems. Thus, it is difficult to build reliable Win32 / Boaxxe.BE detection based on the DNS query pattern.
The malicious code will regularly check every 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 resulting IP address will not be the same as the one used by the malicious code in reality. In fact, the last three bytes of the resulting IP address will be encrypted using RC4 and the "ANKS" key to get the real IP address associated with the domain.
Consider an example: if you perform a DNS query for the thegreerfive.biz domain (the malicious domain used by Win32 / Boaxxe.BE), then you will receive the IP address 31.240.6.70 as the answer (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 the F0 06 46 bytes gives us C1 00 B2.
As you already understood, the operators responsible for managing the Win32 / Boaxxe.BE infrastructure control only real IP addresses, i.e. addresses obtained using the encryption algorithm that is applied to the address from the real DNS record. Thus, a simple analysis of the domains contacted by the malware is completely useless without a key, with which you can get real addresses.
Implementation of clickfrod
The user-initiated click-fraud is the process of redirecting users to the web resources that attackers need when they execute a search query. This allows Win32 / Boaxxe.BE to drive traffic for advertising sites. Such an attraction is performed meaningfully for a specific search query. The logic of this fraudulent scheme is shown below. Blue text indicates user actions, and red indicates actions of a 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 corresponding to this word. At the same time, Win32 / Boaxxe.BE sends the word K to its own search engine, which also returns a list of relevant sites. In the absence of sites related to this keyword, the redirection is not performed. At the second stage, the user performs a click (transition) on the selected site and receives the contents of the corresponding web page.If the user has Win32 / Boaxxe.BE installed, he will forcefully click on the corresponding link from the returned list. In practice, the user does not have time to see the web page to which he has accessed; instead, he goes to a web page initiated by malicious code.
As we mentioned above, user-initiated click-for operations for Chrome and Firefox are implemented in browser extensions, and for Internet Explorer, the malicious code uses traps in the process’s 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 Chrome extension consists of two JavaScript files: a background script (background script), an instance of which will always be active, and a content script (script), an instance of which will work for each web page.
When launched, the background script will decrypt JSON_PAYLOAD and calculate its "c" field (see above), which contains the logic of the extension. This code declares an array containing the search engines supported by the 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 used by the malicious code in December is shown below.
Take for example the URL of the search query “www.google.com/search?q=cat”, it is obvious that it will correspond to the first row of the table and the keyword “cat” will be extracted by malicious code from the URL, and then sent to the search engine Win32 / Boaxxe.BE, which is searchpagex.com (searchpagex.org in the case of Firefox) over the past 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 feature allows it to be more secretive, because in the case of redirections with these sites, the user can immediately suspect malicious activity in the browser.
Boaxxe registers event handlers using the Chrome API to handle each URL a user visits. Using these handlers, which are contained in the content script, the malware implements the logic of redirections. 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 chain of referrals takes place involving the ad network, which ends with a website directly related to the keyword. Simultaneously with this redirection process, the extension will check the URL specified in the “c” parameter of the JSON_PAYLOAD object field every hour to request its new version.
In order to implement a custom clickfred in Internet Explorer, Win32 / Boaxxe.BE performs interception of the following API functions: HttpAddRequestHeadersA , CreateWindowExW and DrawTextExW . The handlers of these functions are located in the body of the malicious program and then provide the URLs that the user must visit, which is executed in a separate Boaxxe stream.
This thread implements a similar logic to the one we described in the case of the Chrome extension. It matches the incoming URLs with the list of search engines and retrieves keywords from the query. The difference is that it sends the extracted keywords not to its own search engine, but to a malicious IP address that 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 source of the redirect (referrer). This redirect source URL is specified by the Win32 / Boaxxe.BE search engine. Using this referrer field allows malicious code operators to benefit from the ad network. Thus, the user’s transition is simulated using the doorway search engine.
Automatic clickfrod is a secretive visit of 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 for execution. This new process is invisible to the user due to the active “-Embedding” parameter with which the browser is running.
Boaxxe changes various Internet Explorer settings, for example, to disable navigation sounds or remove restrictions on file downloads. It also creates a thread that constantly monitors the time of its execution and the memory used by the process; if the amount of memory consumed or 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 to its own DNS cache associated with the partner identifier. Then he sends a request to one of them, using RC4 / base64 encryption and receives as a reply the information necessary to execute an automatic clickfrod. An example of the answer 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 indicated by the “u” parameter with the referrer source, which is represented by the “r” parameter. The source URL to visit starts 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, to which, in the future, redirection will be carried out. The recursion depth or the number of redirections is set by the parameter "n".
In the process of performing these operations, the stream 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 the 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 clickfreds in the stream of network traffic.
Conclusion
We have tried to describe in detail the work of the Win32 / Boaxxe.BE malicious code, the main purpose of which is to generate clicks (clickfrod) with the subsequent extraction of material benefits from the advertiser by the attackers. The malware contains several mechanisms for hiding its traffic, including its encryption, the use of requests to legitimate websites and the use of its DNS cache.
SHA-1 samples
Distribution and profit
')
Win32 / Boaxxe.BE was distributed from the partnerka.me partner program site, which began its work in September 2013. The owners or clients of the affiliate program (partners) pay attackers for installing this malicious program 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 malware that must be distributed through the branch.
The executable file with malware 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 20-byte value that identifies the affiliate affiliate (partner). The SUB-ID parameter can also be used to identify various executable files that are distributed by this branch.
In the "Promo" section, on the part of the web page that is located below the download buttons, shows the detection rate of malicious program files by antivirus products. We observed a change in the binary files of the malware every hour, thus avoiding detection by antivirus scanners. As is usually the case in such cases, the same malicious program is simply repackaged 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 partner program, allowing the C & C server to correctly report the branch from which the malicious program was installed. The branch identifier is a two-byte value, which is incremented by one for each new registered account in the affiliate program. For four months of our monitoring, the creation of forty new partner accounts has been recorded.
A page with statistics looks like.
The Installs column counts the number of successful installations of the malware. The purpose of the Blocked column is not entirely clear since we did not observe nonzero values ​​for it. To understand the other columns, it should be noted that Win32 / Boaxxe.BE implements two different types of clickfruits:
- User-initiated clickfrod: the user enters a search query in the browser and the malicious code inserts advertising sites into the relevant search results. This practice has been implemented in various malware families, for example, Win32 / TrojanDownloader.Tracur and Win32 / Goblin (aka Win32 / Xpaj). Statistics on this type of clickfrod 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 that were used in the search query.
- Clicks : the number of completed user redirects (clicks made by him).
- PPC Profit : the amount earned by this partner through the clickfrod.
- Automatic klykfrod: Win32 / Boaxxe.BE incorporates the ability to covertly visit advertising sites without the user's knowledge.
- Live : the number of infected computers that are running a clickfrod.
- CPV Actions : the number of automatic click actions taken by the malware.
- CPV Profit : the amount earned by the partner through a clickfrod.
The website also provides a URL to the JSON object, which contains the above statistics for its processing directly by the partner. Interestingly, authentication is not used to access these statistics, so you just need to know the branch’s twenty-second mark to access it. For example, we received statistics from one of the partners who used their 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 an automatic clickfrod (CPV Profit). Below is the statistics of this partner.
It is not surprising that attackers automatically earned more than regular clicks manually generated by the user for automatic clicks (CPV Actions). 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 $ 0.015. Obviously, real user redirection is more profitable for intruders.
The web page of the control panel contains a section for payment and support services through the creation of tickets for a partner.
The figure below illustrates the scheme used by the attackers.
As we have already explained, malicious files for infecting users are spread by partners of the partnerka.me network. After infection, users will be forced to browse advertising sites either automatically (covertly), or while clicking on links in a search engine. Infected cars use doorway search engines that return a list of advertising sites for a search query. Linked URLs usually launch a chain of redirections through sites that are linked to an advertiser-publisher relationship (each website in the chain pays back to the traffic received).
In the end, advertised sites, among which may be legitimate, pay back to the advertising network for traffic. These networks charge a fee and pay part of the doorway service for the data. Finally, partnerka.me receives the rest of the money, takes its share and pays a part to the partners (affiliates).
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 malware. Other versions of Boaxxe in-the-wild were also noted, which had additional functions in their composition: defense mechanisms or another implementation of existing modules, but they also use redirections to the same advertising networks.
The screenshot below shows the statistics for daily Win32 / Boaxxe.BE detections since partnerka.me was opened in September 2013.
The interest of intruders in this malicious tool is quite high, which corresponds to an increase in the number of branches in its distribution. Peak activity indicators are also consistent with the statistics of individual branches, for example, one of them started a massive spam campaign for distribution in late December.
Malicious browser extensions to execute clickfrod
The installation process of the Win32 / Boaxxe.BE malicious code is shown below. This process involves three steps.
Win32 / Boaxxe.BE may initially be an installer (NSIS Installer), which contains an executable file and an auxiliary file setup.dat. The task of the installer 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 shown below.
The data of this alleged image is then decrypted already in a new executable file, which is launched for execution. This technique is used to mislead analysts and automatic systems for analyzing malicious objects that may decide that this file is not intended for execution. When converting an “image” file into an executable file, it is decrypted via RC4, and then decompressed using aPlib. Finally, the CALL and JMP transition instructions are configured in the executable file using the special method E8 / E9 .
At the second stage, Win32 / Boaxxe.BE installs special extensions for browsers through which later it will get full access to the browser process and will click the folder. The method of accessing the browser is different for different types of browsers, for example, as shown above, the browser extensions mechanism is used to access Google Chrome and Mozilla Firefox, and in the case of Internet Explorer, special hooks in memory are used for the browser process. Below 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 via subscribed ones. CRX files that can be installed simply by opening such a file in the 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 correct directory and modify the Chrome settings to load it. This method is used in Win32 / Boaxxe.BE. The process begins with the decryption using RC4 of various data contained in the body of the executable file.
One of these data blocks 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 computer hardware (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 work. The second script will be embedded in each web page, the URL of which corresponds to the parameter “matches” (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 to control 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 main 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 the “@@ STRING @@” variables in the background script will be changed to the required values.
- The parameter “TOKEN” changes to a string encoded with base64 and RC4 (with the key “tokencryptkey”). The string can take the form "u: 14AB8569 w: 1234 p: 1 c: 5b b: 32 v: 0".
- The “LOGIC” parameter is changed to JSON_PAYLOAD encoded via base64 and RC4 using the previous value “TOKEN” as the key.
In the end, all three files are stored in the Chrome extension directory.
The extension is installed in Chrome by modifying the extensions.settings JSON object, which is contained in the settings file, in the Chrome installation directory. This file contains information about all installed browser extensions. Win32 / Boaxxe.BE to register its extension inserts the following lines there:
After all these operations, the JavaScript code required by the attackers will be uploaded to Chrome. It should be noted that Google announced a ban on the installation of this kind of browser extensions from 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 “id”, “name”, “version” and “creator” fields 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 declares the JavaScript extension code in the first line ("component"), and then ensures that the extension is loaded and notified when the browser starts. When writing the contents of a script file to disk, variables of type @@ STRING @@ are substituted with the corresponding values. Finally, three install.rdf, chrome.manifest files and a JavaScript file are saved to the disk in the directory with the browser.
To install an extension in Firefox, the malicious code undertakes the following operations in the browser’s Profile directory: registers the path to the extension in the extensions.ini file and checks for the presence of an extension with the same identifier in the SQL extensions.sqlite database.
In the presence of such an identifier, the malicious code updates the table so that it points to a new extension. If there is no such identifier, the extension is inserted into the table.
Payload
In the final stage of the installation, Win32 / Boaxxe.BE performs the extraction of 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;
- message type;
- Partner ID.
The message portion highlighted in blue contains the following supporting information.
The message is encrypted via RC4 using a 244-byte pseudo-arbitrary 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 in its body the data encrypted using base64. After decryption, we get two executable files. The first DLL1 is the "springboard" library, which will be registered through autorun for start in the context of the regsvr32.exe process. Its main purpose is to decipher another DLL and to maintain its presence in the contexts of all processes of the system. The second DLL2 file is the actual Win32 / Boaxxe.BE payload and will be stored on the hard disk in encrypted form (RC4). The key for encryption via RC4 is formed through the values ​​of the disk serial number and other hardware-dependent data. In other words, without having information about the hardware of the computer, it will be difficult to decrypt the library (this type of cryptographic key is also known as the environmental key, "environmental key").
After the operation of requesting a payload from the server, the column with the number of installations on the statistics of the partnerka partner’s control panel will increase by one. But this will happen only if such a request is received for the first time from this computer.
It should be noted that malicious code detects AV products running on a 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 apply auxiliary mechanisms that will reduce the likelihood of payload detection. For example, in the case of an ESET antivirus product 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, a custom click-frame module and an 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 detecting the activity of malicious code from 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 fixed-length entries of 0x60 bytes. An example of such a structure is shown below.
Each entry contains information related to one domain name, which can be either legitimate (that is, not related to Boaxxe) or malicious. The record 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.
- The IP address field (marked in blue). As we will explain below, this address is actually not exactly the one that is associated with the domain directly.
- The "already otrezolven" field (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 domain name 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, the malicious code can accumulate information on the domain mapping, save it for the time it needs and use it as necessary.
When DLL2 is run for the first time on a computer, in the context of the regsvr32.exe process, the DNS cache is empty. At the same time, a set of about five hundred legitimate domains, in encrypted form, is stored in DLL2. The program then selects a subset of the existing domains based on a hardware-dependent value to fill the cache. Thus, a different sample of a certain number of legitimate domains will be made on different infected computers. In the process of loading DLL2 into the address space of the browser process, for the first time, it adds several (usually four) malicious domains to the cache, according to the value of the partner identifier (affiliate ID).
The malware pursues certain goals by choosing legitimate domains arbitrarily for a specific computer. This is done so that the malicious code cannot be identified by the same series of DNS queries in case of traffic tracking by the analysis systems. Thus, it is difficult to build reliable Win32 / Boaxxe.BE detection based on the DNS query pattern.
The malicious code will regularly check every 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 resulting IP address will not be the same as the one used by the malicious code in reality. In fact, the last three bytes of the resulting IP address will be encrypted using RC4 and the "ANKS" key to get the real IP address associated with the domain.
Consider an example: if you perform a DNS query for the thegreerfive.biz domain (the malicious domain used by Win32 / Boaxxe.BE), then you will receive the IP address 31.240.6.70 as the answer (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 the F0 06 46 bytes gives us C1 00 B2.
As you already understood, the operators responsible for managing the Win32 / Boaxxe.BE infrastructure control only real IP addresses, i.e. addresses obtained using the encryption algorithm that is applied to the address from the real DNS record. Thus, a simple analysis of the domains contacted by the malware is completely useless without a key, with which you can get real addresses.
Implementation of clickfrod
The user-initiated click-fraud is the process of redirecting users to the web resources that attackers need when they execute a search query. This allows Win32 / Boaxxe.BE to drive traffic for advertising sites. Such an attraction is performed meaningfully for a specific search query. The logic of this fraudulent scheme is shown below. Blue text indicates user actions, and red indicates actions of a 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 corresponding to this word. At the same time, Win32 / Boaxxe.BE sends the word K to its own search engine, which also returns a list of relevant sites. In the absence of sites related to this keyword, the redirection is not performed. At the second stage, the user performs a click (transition) on the selected site and receives the contents of the corresponding web page.If the user has Win32 / Boaxxe.BE installed, he will forcefully click on the corresponding link from the returned list. In practice, the user does not have time to see the web page to which he has accessed; instead, he goes to a web page initiated by malicious code.
As we mentioned above, user-initiated click-for operations for Chrome and Firefox are implemented in browser extensions, and for Internet Explorer, the malicious code uses traps in the process’s 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 Chrome extension consists of two JavaScript files: a background script (background script), an instance of which will always be active, and a content script (script), an instance of which will work for each web page.
When launched, the background script will decrypt JSON_PAYLOAD and calculate its "c" field (see above), which contains the logic of the extension. This code declares an array containing the search engines supported by the 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 used by the malicious code in December is shown below.
Take for example the URL of the search query “www.google.com/search?q=cat”, it is obvious that it will correspond to the first row of the table and the keyword “cat” will be extracted by malicious code from the URL, and then sent to the search engine Win32 / Boaxxe.BE, which is searchpagex.com (searchpagex.org in the case of Firefox) over the past 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 feature allows it to be more secretive, because in the case of redirections with these sites, the user can immediately suspect malicious activity in the browser.
Boaxxe registers event handlers using the Chrome API to handle each URL a user visits. Using these handlers, which are contained in the content script, the malware implements the logic of redirections. 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 chain of referrals takes place involving the ad network, which ends with a website directly related to the keyword. Simultaneously with this redirection process, the extension will check the URL specified in the “c” parameter of the JSON_PAYLOAD object field every hour to request its new version.
In order to implement a custom clickfred in Internet Explorer, Win32 / Boaxxe.BE performs interception of the following API functions: HttpAddRequestHeadersA , CreateWindowExW and DrawTextExW . The handlers of these functions are located in the body of the malicious program and then provide the URLs that the user must visit, which is executed in a separate Boaxxe stream.
This thread implements a similar logic to the one we described in the case of the Chrome extension. It matches the incoming URLs with the list of search engines and retrieves keywords from the query. The difference is that it sends the extracted keywords not to its own search engine, but to a malicious IP address that 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 source of the redirect (referrer). This redirect source URL is specified by the Win32 / Boaxxe.BE search engine. Using this referrer field allows malicious code operators to benefit from the ad network. Thus, the user’s transition is simulated using the doorway search engine.
Automatic clickfrod is a secretive visit of 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 for execution. This new process is invisible to the user due to the active “-Embedding” parameter with which the browser is running.
Boaxxe changes various Internet Explorer settings, for example, to disable navigation sounds or remove restrictions on file downloads. It also creates a thread that constantly monitors the time of its execution and the memory used by the process; if the amount of memory consumed or 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 to its own DNS cache associated with the partner identifier. Then he sends a request to one of them, using RC4 / base64 encryption and receives as a reply the information necessary to execute an automatic clickfrod. An example of the answer 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 indicated by the “u” parameter with the referrer source, which is represented by the “r” parameter. The source URL to visit starts 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, to which, in the future, redirection will be carried out. The recursion depth or the number of redirections is set by the parameter "n".
In the process of performing these operations, the stream 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 the 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 clickfreds in the stream of network traffic.
Conclusion
We have tried to describe in detail the work of the Win32 / Boaxxe.BE malicious code, the main purpose of which is to generate clicks (clickfrod) with the subsequent extraction of material benefits from the advertiser by the attackers. The malware contains several mechanisms for hiding its traffic, including its encryption, the use of requests to legitimate websites and the use of its DNS cache.
SHA-1 samples
Source: https://habr.com/ru/post/210192/
All Articles