QNAPCrypt continues to spread via brute-force attacks.
A rare instance of ransomware targeting Linux-based file storage systems (network-attached storage servers, specifically) has been spotted, spreading via 15 separate but related campaigns. The adversaries behind the effort are continuing their depredations on an ongoing basis, according to researchers, so targets are expected to proliferate.
Researchers at Intezer Labs dubbed the malware “QNAPCrypt,” after QNAP, one of the larger NAS server vendors out there.
“NAS servers normally store large amounts of important data and files, which make them a valuable target for attackers and especially a viable target for ransomware campaigns,” Intezer researcher Ignacio Sanmillan said in an analysis of the malware, posted this week. However, he noted that “It is rare to see ransomware being used to target the Linux operating system.”
QNAPCrypt has a few attributes that differ from the standard ransomware bag of tricks, the researchers said. Like many ransomwares, it’s an ARM variant that encrypts all files, but the ransom note is delivered solely as a text file left on the machine, without any message on the screen. “Naturally, because it is a server and not an endpoint,” Sanmillan pointed out.
Also, every victim is provided with a different, unique Bitcoin wallet – an aspect that helps attackers avoid being traced via the money flows – being traced. Once a victim is compromised, the malware requests a wallet address and a public RSA key from the command and control server (CC2) before file encryption.
It’s this wallet function that has proved to be a bit of an Achilles Heel for the attackers. Researchers determined a couple of what the researcher said are “major design flaws” that allows them to temporarily block the threat actors’ operations.
First off, the list of bitcoin wallets was static and created in advance of the campaign.
“Therefore, it does not create a new wallet for each new victim in real time, but rather it pulls a wallet address from a fixed, predetermined list,” explained the researchers.
Secondly, the list, being static, is also finite. “Once all of the wallets are allocated (or sent), the ransomware would not be able to continue its malicious operation in the victim’s machine,” they said.
This opened the door to Intezer being able to mount what was essentially a denial-of-service (DoS) attack by simulating the infection of more than 1,091 victims, forcing the attackers to run through their list of unique Bitcoin wallets to supply to their victims.
“While researching the ARM instance of the malware, we observed that there was a request through their REST API in order to retrieve new victim configuration keys,” Sanmillan explained, adding that this is done via a connection to a SOCKS5 proxy. Herein lies a third design flaw That connection, to a SOCKS5 proxy, is completed without any authentication enforced, so anyone would have the capability to connect to it.
“This idea simply abuses the fact that no authentication is enforced to connect to the SOCKS5 proxy,” Sanmillan explained. “Since the authors behind this ransomware were delivering one Bitcoin wallet per victim from a static pool of already generated wallets, we could replicate the infection packets to retrieve all of the wallets until they had no further wallets under their control. Therefore, when a genuine infection would occur, the ransom client would not be able to retrieve configuration artifacts.”
The attackers took notice, and it wasn’t long before Intezer spotted updated QNAPCrypt variants.
“As a result…the authors behind this malware were forced to update their implants in order to circumvent this design flaw in their infrastructure to continue with their malicious operations,” Samillan said. “After several days of continuously DoS’ing QNAPCrypt clients, we encountered another QNAPCrypt sample—but this time targeting x86 systems.”
This newer implant reuses a large portion of code with old instances of x86 Linux.Rex, a malware that made headlines in 2016 as a self-replicating trojan that uses infected machines to create a peer-to-peer botnet, in order to conduct ransomware and DDoS operations.
“We interpret the discovery of these newer instances with hardcoded configuration to be a response from the threat actors behind this campaign to attempt to circumvent the DoS,” Sanmillan said. “This implied that they were forced to change their implants and to centralize their bitcoin wallets, making the tracking of their income via their ransomware campaigns more convenient.”
Intezer determined that the initial attack vector for the campaigns is SSH brute-force attacks, so administrators should take care to update their credentials with strong passwords in order to avoid an infection.
As for the decision to target NAS, Chris Morales, head of security analytics at Vectra, told Threatpost that it isn’t as common to deploy endpoint monitoring to a Linux dedicated network file server — thus, the QNAPCrypt malware represents the evolution and adaptation of an attack to bypass security controls.
“What often happens in a ransomware attack would be that a desktop machine, which is Windows or OS X, would be compromised through an existing vulnerability or phishing campaign,” he explained. “Once the host is infected, malware is designed to propagate across user systems and encrypt network file servers that are connected to those systems. By targeting the network file server directly, it is highly likely the attack is circumventing detection by endpoint security tools that are monitoring for the local encryption behaviors.”
Content retrieved from: https://threatpost.com/linux-ransomware-nas-servers/146441/.