Five years ago, researchers made a grim discovery—a legitimate Android app in the Google Play market that was surreptitiously made malicious by a library the developers used to earn advertising revenue. With that, the app was infected with code that caused 100 million infected devices to connect to attacker-controlled servers and download secret payloads.
Now, history is repeating itself. Researchers from the same Moscow, Russia-based security firm reported Monday that they found two new apps, downloaded from Play 11 million times, that were infected with the same malware family. The researchers, from Kaspersky, believe a malicious software developer kit for integrating advertising capabilities is once again responsible.
Clever tradecraft
Software developer kits, better known as SDKs, are apps that provide developers with frameworks that can greatly speed up the app-creation process by streamlining repetitive tasks. An unverified SDK module incorporated into the apps ostensibly supported the display of ads. Behind the scenes, it provided a host of advanced methods for stealthy communication with malicious servers, where the apps would upload user data and download malicious code that could be executed and updated at any time.
The stealthy malware family in both campaigns is known as Necro. This time, some variants use techniques such as steganography, an obfuscation method rarely seen in mobile malware. Some variants also deploy clever tradecraft to deliver malicious code that can run with heightened system rights. Once devices are infected with this variant, they contact an attacker-controlled command-and-control server and send web requests containing encrypted JSON data that reports information about each compromised device and application hosting the module.
The server, in turn, returns a JSON response that contains a link to a PNG image and associated metadata that includes the image hash. If the malicious module installed on the infected device confirms the hash is correct, it downloads the image.
The SDK module “uses a very simple steganographic algorithm,” Kaspersky researchers explained in a separate post. “If the MD5 check is successful, it extracts the contents of the PNG file—the pixel values in the ARGB channels—using standard Android tools. Then the getPixel method returns a value whose least significant byte contains the blue channel of the image, and processing begins in the code.”
The researchers continued:
If we consider the blue channel of the image as a byte array of dimension 1, then the first four bytes of the image are the size of the encoded payload in Little Endian format (from the least significant byte to the most significant). Next, the payload of the specified size is recorded: this is a JAR file encoded with Base64, which is loaded after decoding via DexClassLoader. Coral SDK loads the sdk.fkgh.mvp.SdkEntry class in a JAR file using the native library libcoral.so. This library has been obfuscated using the OLLVM tool. The starting point, or entry point, for execution within the loaded class is the run method.
Follow-on payloads that get installed download malicious plugins that can be mixed and matched for each infected device to perform a variety of different actions. One of the plugins allows code to run with elevated system rights. By default, Android bars privileged processes from using WebView, an extension in the OS for displaying webpages in apps. To bypass this safety restriction, Necro uses a hacking technique known as a reflection attack to create a separate instance of the WebView factory.
This plugin can also download and run other executable files that will replace links rendered through WebView. When running with the elevated system rights, these executables have the ability to modify URLs to add confirmation codes for paid subscriptions and download and execute code loaded at links controlled by the attacker. The researchers listed five separate payloads they encountered in their analysis of Necro.
The modular design of Necro opens myriad ways for the malware to behave. Kaspersky provided the following image that provides an overview.
The researchers found Necro in two Google Play apps. One was Wuta Camera, an app with 10 million downloads to date. Wuta Camera versions 6.3.2.148 through 6.3.6.148 contained the malicious SDK that infects apps. The app has since been updated to remove the malicious component. A separate app with roughly 1 million downloads—known as Max Browser—was also infected. That app is no longer available in Google Play.
The researchers also found Necro infecting a variety of Android apps available in alternative marketplaces. Those apps typically billed themselves as modified versions of legitimate apps such as Spotify, Minecraft, WhatsApp, Stumble Guys, Car Parking Multiplayer, and Melon Sandbox.
People who are concerned they may be infected by Necro should check their devices for the presence of indicators of compromise listed at the end of this writeup.
For the past year, previously unknown self-replicating malware has been compromising Linux devices around the world and installing cryptomining malware that takes unusual steps to conceal its inner workings, researchers said.
The worm is a customized version of Mirai, the botnet malware that infects Linux-based servers, routers, web cameras, and other so-called Internet of Things devices. Mirai came to light in 2016 when it was used to deliver record-setting distributed denial-of-service attacks that paralyzed key parts of the Internet that year. The creators soon released the underlying source code, a move that allowed a wide array of crime groups from around the world to incorporate Mirai into their own attack campaigns. Once taking hold of a Linux device, Mirai uses it as a platform to infect other vulnerable devices, a design that makes it a worm, meaning it self-replicates.
Dime-a-dozen malware with a twist
Traditionally, Mirai and its many variants have spread when one infected device scans the Internet looking for other devices that accept Telnet connections. The infected devices then attempt to crack the telnet password by guessing default and commonly used credential pairs. When successful, the newly infected devices target additional devices using the same technique. Mirai has primarily been used to wage DDoSes. Given the large amounts of bandwidth available to many such devices, the floods of junk traffic are often huge, giving the botnet as a whole tremendous power.
On Wednesday, researchers from network security and reliability firm Akamai revealed that a previously unknown Mirai-based network they dubbed NoaBot has been targeting Linux devices since at least last January. Instead of targeting weak telnet passwords, the NoaBot targets weak passwords connecting SSH connections. Another twist: Rather than performing DDoSes, the new botnet installs cryptocurrency mining software, which allows the attackers to generate digital coins using victims’ computing resources, electricity, and bandwidth. The cryptominer is a modified version of XMRig, another piece of open source malware. More recently, NoaBot has been used to also deliver P2PInfect, a separate worm researchers from Palo Alto Networks revealed last July.
Akamai has been monitoring NoaBot for the past 12 months in a honeypot that mimics real Linux devices to track various attacks circulating in the wild. To date, attacks have originated from 849 distinct IP addresses, almost all of which are likely hosting a device that’s already infected. The following figure tracks the number of attacks delivered to the honeypot over the past year.
“On the surface, NoaBot isn’t a very sophisticated campaign—it’s ‘just’ a Mirai variant and an XMRig cryptominer, and they’re a dime a dozen nowadays,” Akamai Senior Security Researcher Stiv Kupchik wrote in a report Wednesday. “However, the obfuscations added to the malware and the additions to the original source code paint a vastly different picture of the threat actors’ capabilities.”
The most advanced capability is how NoaBot installs the XMRig variant. Typically, when crypto miners are installed, the wallets’ funds are distributed to are specified in configuration settings delivered in a command line issued to the infected device. This approach has long posed a risk to threat actors because it allows researchers to track where the wallets are hosted and how much money has flowed into them.
NoaBot uses a novel technique to prevent such detection. Instead of delivering the configuration settings through a command line, the botnet stores the settings in encrypted or obfuscated form and decrypts them only after XMRig is loaded into memory. The botnet then replaces the internal variable that normally would hold the command line configuration settings and passes control to the XMRig source code.
Kupchik offered a more technical and detailed description:
In the XMRig open source code, miners can accept configurations in one of two ways — either via the command line or via environment variables. In our case, the threat actors chose not to modify the XMRig original code and instead added parts before the main function. To circumvent the need for command line arguments (which can be an indicator of compromise IOC and alert defenders), the threat actors had the miner replace its own command line (in technical terms, replacing argv) with more “meaningful” arguments before passing control to the XMRig code. The botnet runs the miner with (at most) one argument that tells it to print its logs. Before replacing its command line, however, the miner has to build its configuration. First, it copies basic arguments that are stored plaintext— the rig-id flag, which identifies the miner with three random letters, the threads flags, and a placeholder for the pool’s IP address (Figure 7).
Curiously, because the configurations are loaded via the xmm registers, IDA actually misses the first two loaded arguments, which are the binary name and the pool IP placeholder.
Enlarge/ NoaBot code that copies miner configurations
Akamai
Next, the miner decrypts the pool’s domain name. The domain name is stored, encrypted, in a few data blocks that are decrypted via XOR operations. Although XMRig can work with a domain name, the attackers decided to go the extra step, and implemented their own DNS resolution function. They communicate directly with Google’s DNS server (8.8.8.8) and parse its response to resolve the domain name to an IP address.
The last part of the configuration is also encrypted in a similar way, and it is the passkey for the miner to connect to the pool. All in all, the total configuration of the miner looks something like this:
-o --rig-id --threads –pass espana*tea
Notice anything missing? Yep, no wallet address.
We believe that the threat actors chose to run their own private pool instead of a public one, thereby eliminating the need to specify a wallet (their pool, their rules!). However, in our samples, we observed that miner’s domains were not resolving with Google’s DNS, so we can’t really prove our theory or gather more data from the pool, since the domains we have are no longer resolvable. We haven’t seen any recent incident that drops the miner, so it could also be that the threat actors decided to depart for greener pastures
