In early April, we detected a significant increase in attacks that use banking Trojans of the QBot family (aka QakBot, QuackBot, and Pinkslipbot). The malware would be delivered through e-mail letters written in different languages — variations of them were coming in English, German, Italian, and French. The messages were based on real business letters the attackers had gotten access to, which afforded them the opportunity to join the correspondence thread with messages of their own. As a general rule, such letters would be urging the addressee — under a plausible pretext — to open an enclosed PDF file. As an example, they could be asking to provide all the documentation pertaining to the attached application or to calculate the contract value based on the attached cost estimate.

Example of a forwarded letter containing a malicious attachment

Such simulated business correspondence can obstruct spam tracking while increasing the probability of the victim falling for the trick. For authenticity, the attackers put the sender’s name from the previous letters in the ‘From’ field; however, the sender’s fraudulent e-mail address will be different from that of the real correspondent.

A short look at QBot

The banking Trojan QBot was detected for the first time in 2007. Since then, it has gone through multiple modifications and improvements to become one of the most actively spread malware in 2020. In 2021, we published a detailed QBot technical analysis. Currently the banker keeps getting new functions and module updates for increased effectiveness and profit.

QBot distribution methods have also evolved. Early on it was distributed through infected websites and pirated software. Now the banker is delivered to potential victims through malware already residing on their computers, social engineering, and spam mailings.

QBot infection chain

New QBot infection chain

The QBot malware delivery scheme begins with an e-mail letter with a PDF file in the attachment being sent. The document’s content imitates a Microsoft Office 365 or Microsoft Azure alert advising the user to click Open to view the attached files. If the user complies, an archive will be downloaded from a remote server (compromised site), protected with a password given in the original PDF file.

Examples of PDF attachments

In the downloaded archive there is a .wsf (Windows Script File) file containing an obfuscated script written in JScript.

Obfuscated JScript

After the WSF file is deobfuscated its true payload gets revealed: a PowerShell script encoded into a Base64 line.

Encoded PowerShell script

So, as soon as the user opens the WSF file from the archive, the PowerShell script will be discretely run on the computer and use wget to download a DLL file from a remote server. The library’s name is an automatically generated alphabetic sequence varying from one victim to another.

Decoded PowerShell script

The PowerShell script will try in succession to download the file from each one of the URLs listed in the code. To figure whether the download attempt was successful, the script will check the file size using the Get-Item command to get the information. If the file size is 100,000 bytes or more, the script will run the DLL with the help of rundll32. Otherwise, it will wait for four seconds before attempting to download the library using the next link down the list. The downloaded library is the Trojan known as QBot (detected as Trojan-Banker.Win32.Qbot.aiex).

Technical description of malicious DLL

We have analyzed the Qbot samples from the current e-mail campaign. The bot’s configuration block features company name “obama249” and time stamp “1680763529” (corresponding to April 6, 2023 6:45:29), as well as over a hundred IP addresses the bot will be using to connect to command servers. Most of these addresses belong to those users, whose infected systems provide an entry point into the chain which is used to redirect the botnet traffic to real command servers.

Qbot’s functionality hardly changed in the past couple of years. As before, the bot is capable of extracting passwords and cookies from browsers, stealing letters from your mailbox, intercepting traffic, and giving operators remote access to the infected system. Depending on the value of the victim, additional malware can be downloaded locally, such as CobaltStrike (to spread the infection through the corporate network) or various ransomware. Or else the victim’s computer can be turned into a proxy server to facilitate redirection of traffic, including spam traffic.

Statistics

We have analyzed the QBot attack statistics collected using Kaspersky Security Network (KSN). According to our data, the first letters with malicious PDF attachments began to arrive in the evening of April 4. The mass e-mail campaign began at 12:00 p.m. on the following day and continued until 9:00 p.m. During that time we detected an approximate total of 1,000 letters. The second upsurge began on April 6, again at noon, with over 1,500 letters dispatched to our customers this time. For the next few days new messages kept coming, and soon, on the evening of April 12 we discovered another upsurge with 2,000 more letters sent to our customers. After that cybercriminal activity went down, but users still receive fraudulent messages.

Geography of Qbot family attacks, April 1–11, 2023 (download)

In addition, we checked which countries were targeted by Qbot the most by relating the number of users attacked in a given country against the total number of users attacked worldwide. It turned out, the bank Trojan QBot was a more common issue for the residents of Germany (28.01%), Argentina (9.78%), and Italy (9.58%).

QBot is a well-known malware. Kaspersky solutions for consumers and for business use multi-layered approach, including Behavior Detection to detect and block this threat including the variant described in this article. All components of the attack are detected as HEUR:Trojan.PDF.QBot.gen, HEUR:Trojan.Script.Generic, Trojan-Banker.Win32.Qbot, and HEUR:Trojan-Dropper.Script.Qbot.gen, PDM:Trojan.Win32.Generic. Kaspersky solutions also detect and block most of the spam emails used in this attack.

Qbot indicators of compromise

MD5

PDF files
253E43124F66F4FAF23F9671BBBA3D98
39FD8E69EB4CA6DA43B3BE015C2D8B7D

ZIP archives
299FC65A2EECF5B9EF06F167575CC9E2
A6120562EB673552A61F7EEB577C05F8

WSF files
1FBFE5C1CD26C536FC87C46B46DB754D
FD57B3C5D73A4ECD03DF67BA2E48F661

DLL
28C25753F1ECD5C47D316394C7FCEDE2

Malicious links

ZIP archive
cica.com[.]co/stai/stai.php
abhishekmeena[.]in/ducs/ducs.php

DLL
rosewoodlaminates[.]com/hea/yWY9SJ4VOH
agtendelperu[.]com/FPu0Fa/EpN5Xvh
capitalperurrhh[.]com/vQ1iQg/u6oL8xlJ
centerkick[.]com/IC5EQ8/2v6u6vKQwk8
chimpcity[.]com/h7e/p5FuepRZjx
graficalevi.com[.]br/0p6P/R94icuyQ
kmphi[.]com/FWovmB/8oZ0BOV5HqEX
propertynear.co[.]uk/QyYWyp/XRgRWEdFv
theshirtsummit[.]com/MwBGSm/lGP5mGh

In recent months, we observed an increase in the number of malicious campaigns that use Google Advertising as a means of distributing and delivering malware. At least two different stealers, Rhadamanthys and RedLine, were abusing the search engine promotion plan in order to deliver malicious payloads to victims’ machines. They seem to use the same technique of mimicking a website associated with well-known software like Notepad++ and Blender 3D.

The treat actors create copies of legit software websites while employing typosquatting (exploiting incorrectly spelled popular brands and company names as URLs) or combosquatting (using popular brands and company names combined with arbitrary words as URLs) to make the sites look like the real thing to the end user—the domain names allude to the original software or vendor. The design and the content of the fake web pages look the same as those of the original ones. Threat actors then pay to promote the website in the search engine in order to push it to the top search results. The technique is called “malvertising”.

Our observations

In the following snapshots, we can see Google ads promoting fake pages for AMD drivers and the Blender 3D software. If we take a closer look at the URLs, we will see that the domain names incorporate the software name but are in fact unrelated to the real AMD or Blender 3D vendors. In most cases, the top-level domains are different from those of the official sites as well. The use of less common TLDs enables the threat actors to register second-level domains that are similar to the real ones. These domains lure victims to click on the link and access the fake website more often than random domains registered in a more common domain zone, such as COM, because they may look more like a legitimate website.

Fake AMD and Blender 3D websites in search results

We visited some of the promoted sites and obtained the malicious payloads they were distributing. In this article, we will focus mainly on the “Blender 3D” fake websites.

Fake Blender 3D web pages

The size of the downloaded file (ZIP archive) is 269 MB, which is close to the original Blender installer size. The size of 257 MB stated on the fake web page matches that of the original Blender 3D installer, but it does not match the size of the fake download.

When the user clicks the “Download” button, the archive blender-3.4.1-windows-x64.zip (E0BDF36E4A7CF1B332DC42FD8914BA8B) is downloaded.

The size of the file (BBA8AA93FCDDA5AC7663E90C0EEFA2E7) extracted from the archive is 657 MB. When launched, it drops two files into the temp directory:

• The original Blender 3D MSI installer (marked green on the screenshot below), whose size is also 657 MB;
• A PE file that acts as a next-stage loader for a malicious PE file (marked red), which also has the same size as the original installer: 657 MB.

Dropped files: the original Blender 3D MSI installer and the malicious loader

The size of the dropped malicious loader is this big because it is inflated with junk bytes when the PE file is created. The deflated malicious loader size is about 330 KB, and the rest is junk.

Junk bytes inflating the loader

After the initial installer (extracted from the archive) drops these two files, it runs the malicious PE file using the CMD method (cmd.exe /c [Filename] command) to hide it from the user. Additionally, the initial installer also runs the original Blender 3D MSI to make the victim believe that the desired software is running.

Thus, the threat actors disguise their malicious payload through the installation of another software product by creating a “pre-installer” for the legitimate software, which will put both the malware and the desired genuine software on the victim’s machine.

Blender 3D installer launched by the “pre-installer”

The screenshot above shows the actual software installer running, but if we take a closer look at the processes, we will notice a short-lived sub-process (cmd.exe /c -> “SetupFileProgram”) run by the “pre-installer”. This short-lived process is the loader for the malware.

The loader

The loader is a .NET file protected by an unregistered version of .NET Reactor. It seems to use an anti-debugging technique in order to prevent a debugger from executing and dynamically analyzing the binary. In a nutshell, the loader runs a new powershell.exe process and manipulates it to execute numerous PowerShell commands, which instruct it to access a third-party URL in order to get the payload. The payload is a base64-encoded, AES-encrypted fileless binary. Further commands are related to decoding and decrypting that binary, then running it in memory, within a newly created aspnet_compiler.exe process, a legitimate Windows .NET framework compilation tool.

In this case, we observed two detection evasion tricks during the runtime:

• The fileless technique, which involves getting a payload from an online source and loading it directly into the memory of a process;
• LOLBAS (living-off-the-land binaries and scripts), which, in this case, is the use of a .NET compilation tool to run the malicious binary.

Below, we provide a more detailed analysis of the loader execution chain. After passing the loader anti-debugger, we can see that it starts a PowerShell process, so we will put a breakpoint at the CreateProcessW WinAPI call to observe the behavior.

Call of CreateProcessW to spawn a PowerShell process

Since we did not see any command passed to the PowerShell process when initializing it via the CreateProcessW call, we can conclude that it will be passed at some point later, so we can observe the passing of the PowerShell command(s) by putting a breakpoint at WinAPI WriteFile in order to see the command lines for the powershell.exe process.

So, after letting it run and reach the breakpoint, we will check the result in the return of the function call, and we can see in the stack that the first command pushed to the powershell.exe process was #Start-Sleep -seconds 30;.

Observing the pushed command(s)

We can try checking the memory section where the command is stored and searching for other commands that are being kept in the memory for later use by the loader.

Memory address of the pushed PowerShell commands

After taking all the data from this memory section, we will see all the commands passed to the powershell.exe process via the WriteFile WinAPI call.

PowerShell commands

If we read the commands, we will see exactly what the powershell.exe process is about to do. The commands instruct it to perform the following actions:

1. Download string data, which is part of the following URL, namely the name of the file: http[:]//45.93.201[.]114/docs/[RandomChars].txt. The downloaded data is a Base64-encoded string that is decoded into encrypted data.
2. Prepare the decryption method, AES-CBC, as can be seen in the screenshot above. We can also easily see and decode the Base64-encoded key and IV (initialization vector) used for decryption in the PowerShell command.
3. Decrypt the data into a Gzip-compressed binary.
4. Decompress the binary.
5. Invoke the binary to run it.

Decrypted binary

The extracted binary (RedLine stealer)

The binary that we obtained is the dropper of known malware, the RedLine stealer. The version of the stealer at hand uses an interesting technique to hide its malicious payload: it is encoded in the least significant bit of images stored in the resource section of the dropper, as well as the key and the IV bytes for its AES decryption.

Embedded images with a malicious payload

Payload decryption routine

After decrypting the payload, the dropper starts a legitimate process named “aspnet_compiler.exe”, which is part of the Microsoft .NET framework, and injects the payload into it.

Injecting a payload routine

Infrastructure

To deploy decoy pages, the malefactors register deceptive domain names, such as blender3d-software[.]net or blender3d-software[.]org. We have found more than fifty similar domains hosted at the same IP address: 91.229.23[.]200. These domain names mimic other software distribution sites as well, for example, afterburner-software[.]org, tradingviews-software[.]org, and unity-download[.]com.

The malicious payload could be stored on the same site (for example, hxxps[://]blahder3dsoft[.]store/Blender[.]rar) as the landing page or on a public service that can be used as the file hosting service (MediaFire or GitHub).

Conclusion

We are seeing an increase in the spread of malware families through Google Ads campaigns, specifically through search ads. Threat actors use fake websites to mimic legitimate software vendor websites to lure victims, and pay for ads to promote these. They use typosquatting and combosquatting for their malicious website domains, which have become common techniques in recent months. In some cases, such as the one described in this article, the threat actors also make sure to install the desired software alongside their malicious payload.

In recent campaigns, we observed mainly stealer-type malware, such as RedLine or the notorious Rhadamanthys, which is also known to use malvertising techniques to reach victims and steal data from their compromised machines.

This kind of distribution suggests that the threat actors are targeting victims, both individual and corporate, all around the world.

Indicators of Compromise

Web skimming is a common class of attacks generally aimed at online shoppers. The principle is quite simple: malicious code is injected into the compromised site, which collects and sends user-entered data to a cybercriminal resource. If the attack is successful, the cybercriminals gain access to shoppers’ payment information.

To make the data flow to a third-party resource less visible, fraudsters often register domains resembling the names of popular web services, and in particular, Google Analytics (google-anatytics[.]com, google-analytcsapi[.]com, google-analytc[.]com, google-anaiytlcs[.]com, google-analytics[.]top, google-analytics[.]cm, google-analytics[.]to, google-analytics-js[.]com, googlc-analytics[.]com, etc.). But attack of this kind were also found to sometimes use the authentic service.

To harvest data about visitors using Google Analytics, the site owner must configure the tracking parameters in their account on analytics.google.com, get the tracking ID (trackingId, a string like this: UA-XXXX-Y), and insert it into the web pages together with the tracking code (a special snippet of code). Several tracking codes can rub shoulders on one site, sending data about visitors to different Analytics accounts.

Recently, we identified several cases where this service was misused: attackers injected malicious code into sites, which collected all the data entered by users, and then sent it via Analytics. As a result, the attackers could access the stolen data in their Google Analytics account. We found about two dozen infected sites worldwide. The victims included stores in Europe and North and South America selling digital equipment, cosmetics, food products, spare parts etc.

The screenshot below shows how the infection looks — malicious code with the attacker’s tracking code and tracking ID:

Screenshot 1

The attacker tries to hide their malicious activity using a classic anti-debugging technique. Screenshot 2 shows code for checking whether Developer mode is enabled in the visitor’s browser. The code in the screenshot above is executed only if the result is negative.

Screenshot 2

Curiously, the attackers left themselves a loophole — the option to monitor the script in Debug mode. If the browser’s local storage (localStorage) contains the value ‘debug_mode’==’11’, the malicious code will spring into life even with the developer tools open, and will go as far as to write comments to the console in clumsy English with errors. In screenshot 3, the line with the ‘debug_mode’ check follows the implementation of the RC4 encryption algorithm (used to encrypt the harvested data before sending it).

Screenshot 3

If the anti-debugging is passed, the script collects everything anyone inputs on the site (as well as information about the user who entered the data: IP address, UserAgent, time zone). The collected data is encrypted and sent using the Google Analytics Measurement Protocol. The collection and sending process is shown in screenshot 4.

Screenshot 4

The stolen data is sent by invoking the send event method in the ‘eventAction’ field.

The function signature in this case is:

ga('send', 'event', {
  'eventCategory': 'Category',  //Protocol Parameter: ec; Value type: text; Max Lenght: 150 Bytes
  'eventAction': 'Action',    //Protocol Parameter: ea; Value type: text; Max Lenght: 500 Bytes
  'eventLabel': 'Label'     //Protocol Parameter: el; Value type: text; Max Lenght: 500 Bytes
});

This leads to an HTTP request being sent to the URL
https[:]//www.google-analytics.com/collect?<parameters>&ea=packed_stolen_data&<parameters>

In the above-described case, malicious code is inserted into a script on the infected site in “readable” form. In other cases, however, the injection can be obfuscated. Malicious code also can be downloaded from a third-party resource. Screenshot 5 shows an example obfuscation option. In this variant, a call to a malicious script from firebasestorage.googleapis[.]com is inserted into the infected site.

Screenshot 5

After deobfuscation, we obtain a similar script with the same distinctive comments. Part of its code is presented in screenshot 6 (a different tracking ID is used).

Screenshot 6

What’s the danger

Google Analytics is an extremely popular service (used on more than 29 million sites, according to BuiltWith) and is blindly trusted by users: administrators write *.google-analytics.com into the Content-Security-Policy header (used for listing resources from which third-party code can be downloaded), allowing the service to collect data. What’s more, the attack can be implemented without downloading code from external sources.

How to avoid the issues

Users:

• Install security software. Kaspersky solutions detect malicious scripts used in such attacks as HEUR:Trojan-PSW.Script.Generic.

Webmasters:

• Do not install web applications and CMS components from untrusted sources. Keep all software up to date. Follow news about vulnerabilities and take recommended actions to patch them.
• Create strong passwords for all administration accounts.
• Limit user rights to the minimum necessary. Keep track of the number of users who have access to service interfaces.
• Filter user-entered data and query parameters to prevent third-party code injection.
• For e-commerce sites, it is recommended to use PCI DSS-compliant payment gateways.

IOCs

firebasestorage.googleapis[.]com/v0/b/bragvintage-f929b.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/canature-5fab3.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/ericeirasurfskate-559bf.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/gluten-8e34e.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/laser-43e6f.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/movile-720cd.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/plumb-99e97.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/redfox-64c35.appspot.com/o/*
firebasestorage.googleapis[.]com/v0/b/tictoc-9677e.appspot.com/o/*

Last year, we discovered malware that installs a malicious browser extension on its victim’s computer or infects an already installed extension. To do so, it disables the integrity check for installed extensions and automatic updates for the targeted browser. Kaspersky Lab products detect the malicious program as Trojan.Win32.Razy.gen – an executable file that spreads via advertising blocks on websites and is distributed from free file-hosting services under the guise of legitimate software.

Razy serves several purposes, mostly related to the theft of cryptocurrency. Its main tool is the script main.js that is capable of:

• Searching for addresses of cryptocurrency wallets on websites and replacing them with the threat actor’s wallet addresses
• Spoofing images of QR codes pointing to wallets
• Modifying the web pages of cryptocurrency exchanges
• Spoofing Google and Yandex search results

Infection

The Trojan Razy ‘works’ with Google Chrome, Mozilla Firefox and Yandex Browser, though it has different infection scenarios for each browser type.

Mozilla Firefox

For Firefox, the Trojan installs an extension called ‘Firefox Protection’ with the ID {ab10d63e-3096-4492-ab0e-5edcf4baf988} (folder path: “%APPDATA%\Mozilla\Firefox\Profiles\.default\Extensions\{ab10d63e-3096-4492-ab0e-5edcf4baf988}”).

For the malicious extension to start working, Razy edits the following files:

• “%APPDATA%\Mozilla\Firefox\Profiles\.default\prefs.js”,
• “%APPDATA%\Mozilla\Firefox\Profiles\.default\extensions.json”,
• “%PROGRAMFILES%\Mozilla Firefox\omni.js”.

Yandex Browser

The Trojan edits the file ‘%APPDATA%\Yandex\YandexBrowser\Application\\browser.dll’ to disable extension integrity check. It renames the original file ‘browser.dll_’ and leaves it in the same folder.

To disable browser updates, it creates the registry key ‘HKEY_LOCAL_MACHINE\SOFTWARE\Policies\YandexBrowser\UpdateAllowed” = 0 (REG_DWORD).

Then the extension Yandex Protect is installed to folder ‘%APPDATA%\Yandex\YandexBrowser\User Data\Default\Extensions\acgimceffoceigocablmjdpebeodphgc\6.1.6_0’. The ID acgimceffoceigocablmjdpebeodphgc corresponds to a legitimate extension for Chrome called Cloudy Calculator, version 6.1.6_0. If this extension has already been installed on the user’s device in Yandex Browser, it is replaced with the malicious Yandex Protect.

Google Chrome

Razy edits the file ‘%PROGRAMFILES%\Google\Chrome\Application\\chrome.dll’ to disable the extension integrity check. It renames the original chrome.dll file chrome.dll_ and leaves it in the same folder.

It creates the following registry keys to disable browser updates:

• “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\AutoUpdateCheckPeriodMinutes” = 0 (REG_DWORD)
• “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\DisableAutoUpdateChecksCheckboxValue” = 1 (REG_DWORD)
• “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\InstallDefault” = 0 (REG_DWORD)
• “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\UpdateDefault” = 0 (REG_DWORD)

We have encountered cases where different Chrome extensions were infected. One extension in particular is worth mentioning: Chrome Media Router is a component of the service with the same name in browsers based on Chromium. It is present on all devices where the Chrome browser is installed, although it is not shown in the list of installed extensions. During the infection, Razy modified the contents of the folder where the Chrome Media Router extension was located: ‘%userprofile%\AppData\Local\Google\Chrome\User Data\Default\Extensions\pkedcjkdefgpdelpbcmbmeomcjbeemfm’.

Scripts used

Irrespective of the targeted browser type, Razy added the following scripts it brought along to the folder containing the malicious script: bgs.js, extab.js, firebase-app.js, firebase-messaging.js and firebase-messaging-sw.js. The file manifest.json was created in the same folder or was overwritten to ensure these scripts get called.

Left: list of files of the original Chrome Media Router extension.
Right: list of files of the modified Chrome Media Router extension.

The scripts firebase-app.js, firebase-messaging.js and firebase-messaging-sw.js are legitimate. They belong to the Firebase platform and are used to send statistics to the malicious actor’s Firebase account.

The scripts bgs.js and extab.js are malicious and are obfuscated with the help of the tool obfuscator.io. The former sends statistics to the Firebase account; the latter (extab.js) inserts a call to the script i.js with parameters tag=&did=&v_tag=&k_tag= into each page visited by the user.

In the above example, the script i.js is distributed from the web resource gigafilesnote[.]com (gigafilesnote[.]com/i.js?tag=&did=&v_tag=&k_tag=). In other cases, similar scripts were detected in the domains apiscr[.]com, happybizpromo[.]com and archivepoisk-zone[.]info.

The script i.js modifies the HTML page, inserts advertising banners and video clips, and adds adverts into Google search results.

YouTube page with banners added by the script i.js

The culmination of the infection is main.js – a call to the script is added to each page visited by the user.

Fragment of the script i.js code that inserts the script main.js to web pages.

The script main.js is distributed from the addresses:

• Nolkbacteria[.]info/js/main.js?_=
• 2searea0[.]info/js/main.js?_=
• touristsila1[.]info/js/main.js?_=
• solkoptions[.]host/js/main.js?_=

The script main.js is not obfuscated and its capabilities can be seen from the function names.

The screenshot above shows the function findAndReplaceWalletAddresses that searches for Bitcoin and Ethereum wallets and replaces them with the addresses of the threat actor’s wallets. Notably, this function works on almost all pages except those located on Google and Yandex domains, as well as on popular domains like instagram.com and ok.ru.

Images of QR codes that point to wallets also get substituted. The substitution occurs when the user visits the web resources gdax.com, pro.coinbase.com, exmo.*, binance.* or when an element with src=’/res/exchangebox/qrcode/’ is detected on the webpage.

As well as the functionality described above, main.js modifies the webpages of the cryptocurrency exchanges EXMO and YoBit. The following script calls are added to the pages’ codes:

• /js/exmo-futures.js?_= – when exmo.*/ru/* pages are visited
• /js/yobit-futures.js?_= – when yobit.*/ru/* pages are visited

where is one of the domains nolkbacteria[.]info, 2searea0[.]info, touristsila1[.]info, or archivepoisk-zone[.]info.

These scripts display fake messages to the user about “new features” in the corresponding exchanges and offers to sell cryptocurrency at above market rates. In other words, users are persuaded to transfer their money to the cybercriminal’s wallet under the pretext of a good deal.

Example of a scam message on the EXMO website

• /(?:^|\s)(gram|телеграм|токен|ton|ico|telegram|btc|биткойн|bitcoin|coinbase|крипта|криптовалюта|,bnrjqy|биржа|бираж)(?:\s|$)/g;
• /(скачать.*музык|музык.*скачать)/g;
• /тор?рент/g;

This is how an infected user is enticed to visit infected websites or legitimate cryptocurrency-themed sites where they will see the message described above.

Google search results that were modified by the infected extension

When the user visits Wikipedia, main.js adds a banner containing a request for donations to support the online encyclopedia. The cybercriminals’ wallet addresses are used in place of bank details. The original Wikipedia banner asking for donations (if present) is deleted.

Fake banner on Wikipedia asking for donations

When the user visits the webpage telegram.org, they will see an offer to buy Telegram tokens at an incredibly low price.

The infected extension loads content on the telegram.org site from the phishing web resource ton-ico[.]network

Fake banner shown at telegram.org. The link leads to the phishing website ton-ico[.]network

When users visit the pages of Russian social network Vkontakte (VK), the Trojan adds an advertising banner to it. If a user clicks on the banner, they are redirected to phishing resources (located on the domain ooo-ooo[.]info), where they are prompted to pay a small sum of money now to make a load of money later on.

Fraudulent banner on the vk.com website

Indicators of compromise

Kaspersky Lab’s products detect scripts associated with Razy as HEUR:Trojan.Script.Generic.

Below are all the wallet addresses detected in the analyzed scripts:

• Bitcoin: ‘1BcJZis6Hu2a7mkcrKxRYxXmz6fMpsAN3L’, ‘1CZVki6tqgu2t4ACk84voVpnGpQZMAVzWq’, ‘3KgyGrCiMRpXTihZWY1yZiXnL46KUBzMEY’, ‘1DgjRqs9SwhyuKe8KSMkE1Jjrs59VZhNyj’, ’35muZpFLAQcxjDFDsMrSVPc8WbTxw3TTMC’, ’34pzTteax2EGvrjw3wNMxaPi6misyaWLeJ’.
• Ethereum: ’33a7305aE6B77f3810364e89821E9B22e6a22d43′, ‘2571B96E2d75b7EC617Fdd83b9e85370E833b3b1′, ’78f7cb5D4750557656f5220A86Bc4FD2C85Ed9a3’.

At the time of writing, total incoming transactions on all these wallets amounted to approximately 0.14 BTC plus 25 ETH.

MD5

Trojan.Win32.Razy.gen
707CA7A72056E397CA9627948125567A
2C274560900BA355EE9B5D35ABC30EF6
BAC320AC63BD289D601441792108A90C
90A83F3B63007D664E6231AA3BC6BD72
66DA07F84661FCB5E659E746B2D7FCCD
Main.js
2C95C42C455C3F6F3BD4DC0853D4CC00
2C22FED85DDA6907EE8A39DD12A230CF
i.js
387CADA4171E705674B9D9B5BF0A859C
67D6CB79955488B709D277DD0B76E6D3
Extab.js
60CB973675C57BDD6B5C5D46EF372475
Bgs.js
F9EF0D18B04DC9E2F9BA07495AE1189C

Malicious domains

gigafilesnote[.]com
apiscr[.]com,
happybizpromo[.]com,
archivepoisk-zone[.]info,
archivepoisk[.]info,
nolkbacteria[.]info,
2searea0[.]info,
touristsila1[.]info,
touristsworl[.]xyz,
solkoptions[.]host.
solkoptions[.]site
mirnorea11[.]xyz,
miroreal[.]xyz,
anhubnew[.]info,
kidpassave[.]xyz

Phishing domains

ton-ico[.]network,
ooo-ooo[.]info.

Dreams of a Threat Actor

There are two crucial features of the Android OS protection system:

1. it is impossible to download a file without user’s knowledge on a clean device;
2. it is impossible to initialize installation of a third-party app without user’s knowledge on a clean device.

These approaches greatly complicate malware writers’ lives: to infect a mobile device, they have to resort to ruses of social engineering. The victim is literally tricked into force-installing a Trojan. This is definitely not always possible, as users become more aware, and it is not that easy to trick them.

Invisible installation of a malware app onto a mobile device without a user’s knowledge is definitely a daydream of many a malware writer. To do that, it is necessary to find and exploit an Android system vulnerability. These vulnerabilities have been found: we are talking about CVE-2012-6636, CVE-2013-4710, and CVE-2014-1939.

These vulnerabilities allow to execute any code on a device by means of a custom-made HTML page with a JavaScript code. The vulnerabilities have been closed, starting with Android 4.1.2.

It would be great to say that everything is fine now, but, alas, that is not so. We should not forget about the third feature of the Android OS: a device manufacturer is responsible for creating and deploying updates for its specific device model.

Updating the Android operating system is decentralized: each company uses its own custom version of Android, compiled with its own compilers and supplied with its own optimization and drivers. Regardless of who has found a vulnerability and whether that person has informed the OS developer about it, releasing updates is a prerogative of each manufacturer. Only manufacturers are capable of helping the users.

Nevertheless, updates are released somewhat periodically but mostly for the leading models: not all of the manufacturers actively support all of their models.

A publically available detailed description of vulnerabilities for the Android OS provides malware writers with all of the required knowledge. Incidentally, a potential victim of the vulnerability exploits can remain such for a long period of time: let us call it “an endless 0-day”. The problem can be solved only by buying a new device.

This, in particular, coupled with publically available descriptions of the vulnerabilities and examples of the vulnerabilities being exploited, incited malware writers into developing an exploit and performing drive-by attacks onto mobile devices.

Web Site Infection

Drive-by attacks on computers of unsuspecting users give a large audience to threat actors (if they manage to post a malicious code on popular web sites) as well as invisibility (inasmuch as users do not suspect being infected). Owners of compromised web sites may not suspect being infected for a long time as well.

The method of code placement and other attack features allow one to distinguish web sites infected with the same “infection”. For quite long, we observed a typical infection within a group of minimum several dozens of Russian web sites of different types and attendances, including quite well-known and popular resources (for example, web sites with a daily turn-out of 25,000 and 115,000 users). Web-site infection from this group is characterized by the usage of the same intermediate domains, the similarity of the malicious code placed onto them, the method of code placement (in most cases, it is placed on the same domain as an individual JavaScript file), as well as speed and synchronicity of changes in the code on all of the infected web sites after the malicious code has been detected.

The attack method has been standard (even though it has gone through some changes), and it has been used at least since 2014. It has been standard also owing to its targeting Windows OS users. However, some time ago, after threat actors performed a regular modification of the code on infected web sites, we discovered a new script instead of a “common” one that uploads flash exploits. It checked for the “Android 4” setting in User-Agent and operated with tools uncommon for Windows. This anomaly urged us to study the functionality of the script meticulously and watch the infection more closely.

Thus, on the 22nd of January 2016, we discovered a JavaScript code that exploited an Android vulnerability. Only within 3 days, on the 25th of January 2016, we found a new modification of this script with more threatening features.

Scripts

We managed to detect two main script modifications.

Script 1: Sending SMS

The only goal of the first script is to send an SMS message to a phone number of threat actors with the word “test”. For that, the malware writers took advantage of the Android Debug Bridge (ADB) client that exists on all of the devices. The script executes a command to check for the ADB version on a device using the Android Debug Bridge Daemon (ADBD). The result of the command execution is sent to the server of the threat actors.

The code for sending an SMS is commented. In fact, it cannot be executed. However, if it is uncommented, then devices with the Android version below 4.2.2 could execute the commands given by malware writers. For newer versions of Android, the ADBD local connection (in the Loopback mode) is forbidden on the device.

Sending an SMS to a regular number does not promise big losses for the victim, but nothing prevents the malware writers from replacing the test number with a premium-rate number.

The first malicious script modification should not cause any big problems for users, even if the threat actors would be able to send an SMS to a short code. Most mobile carriers have the Advice-of-Charge feature, which does not apply any charges for the first SMS to a premium-rate number: one more message with a specific text must be sent. This is impossible to do from within a JavaScript code for the specific case. This is why, most likely, a second modification of the script has appeared.

Script 2: SD-Card File

The second script, in effect, is a dropper. It drops a malicious file from itself onto an SD card.

By resorting to unsophisticated instructions, part of the script body is decrypted. First of all, separators are removed from the string:

Then, the string is recorded onto an SD card into the MNAS.APK file:

The string must be executed. As a result, the created app should be installed onto the system:

However, this code is yet still commented.

Let us review the script in more detail. The script has a check for a specific Android version (it has to be 4).

Obviously, the malware writers know which versions are vulnerable, and they are not trying to run the script on Android 5 or 6.

Just like with the first script, the second has an ADB check at the control center side:

In this case, the check will not affect anything; however, the ADB version is really essential, since not all of the versions support a local connection with ADBD.

We analyzed several modifications of the second script, which allowed us to track the flow of thought of the malware writers. Apparently, their main goal was to deliver the APK file to the victim.

Thus, some earlier script modifications send data about each executed command to the control center:

In this case, the SD card is checked for the MNAS.lock file. If it is not there, then the script tries to create the MNAS.APK file with a zero size by using a touch utility.

In later script modifications, the task of the APK file delivery to the victim was solved by using the ECHO command, which allows to create any file with any content on a device:

As a result of the ECHO command execution, a malicious APK file is created on the SD card.

Trojan

The second script, in the state as we have discovered it, created and wrote a malicious file, which also needed to be executed, onto an SD card. Inasmuch as the dropper script does not contain a Trojan execution mechanism, the task has to be fulfilled by the user.

The APK file dropped from the script can be detected by Kaspersky Lab as Trojan-Spy.AndroidOS.SmsThief.ay. Since the beginning of 2016, we have managed to find four modifications of the Trojan.

Malware writers use the “example.training” name inside the Trojan code:

At the same time, the malicious file has enough privileges to carry out fully fledged attacks onto the wallet of the victim by sending SMS messages:

The first action that the malicious code does after its execution is requesting administrator rights for the device. After obtaining the rights, it will conceal itself on the application list, thus making it difficult to detect and remove it:

The Trojan will wait for incoming SMS messages. If they fall under given rules, for example, if the come from a number of one of the biggest Russian banks, then these messages will be forwarded at once to the malware writers as an SMS:

Also, the intercepted messages will be forwarded to the server of the threat actors:

Aside from the controlling server, the threat actors use a control number to communicate with the Trojan: the data exchange occurs within SMS messages.

The control number initially exists in the malicious code:

The Trojan awaits specific commands from the control center and in SMS messages from the control number.

A command to change the control number can come from the server of threat actors:

The following commands can come from a control number:

• SEND: send an SMS to an indicated number with indicated text;
• STOP: stop forwarding SMS messages;
• START: start forwarding SMS messages.

For the moment, the functionality of the Trojan is limited to intercepting and sending SMS messages.

Conclusion

The task of carrying out a mass attack on mobile users is solved by infecting a popular resource that harbors a malicious code that is capable of executing any threat actors’ command on an infected mobile device. In case of the attacks described in the article, the emphasis has been placed on devices of Russian users: these devices are old and not up-to-date (notably, Russian domains have been infected).

It is unlikely that the interest of the malware writers towards drive-by attacks on mobile devices will decrease, and they will keep finding methods of carrying out these attacks.

It can be inferred that it is obvious that the attention of malware writers towards publications of research laboratories regarding the topic of Remote Code Execution vulnerabilities will increase, and the attempts to implement attacks by using mobile exploits will persist.

It is also obvious that no matter how enticing publishing is for a 0-day vulnerability, it is worth to refrain from showing detailed exploit examples (Proof of concept). Publishing the mentioned examples most likely will lead to someone creating a fully functional version of a malicious code.

There is a good news for the owners of old devices: our Kaspersky Internet Security solution is capable of protecting your device by tracking changes on the SD card in real time and removing a malicious code as soon as it is written to the SD card. Therefore, our users are protected from the threats known to Kaspersky Lab, which are delivered by the drive-by download method.