The Hive ransomware gang is more active and aggressive than its leak site shows, with affiliates attacking an average of three companies every day since the operation became known in late June.
Security researchers gleaning information straight from Hive’s administrator panel found that affiliates had breached more than 350 organizations over four months.
The gang’s data leak site currently lists only 55 companies that did not pay the ransom, suggesting that a large number of Hive ransomware victims paid the ransom.
A conservative estimation places Hive ransomware gang’s profits into millions of U.S. Dollars between October and November alone.
Recruiting partners
Hive ransomware emerged in late June targeting companies in various sectors. While most of the non-paying victims on their leak site are small to medium-sized businesses, the gang also published files from larger companies with revenues assessed to be in the hundreds of millions.
A source has told BleepingComputer that Hive ransomware is also behind the recent attack on Virginia’s Division of Legislative Automated Systems (DLAS). However, we could not independently verify the information.
Analysts at cybersecurity company Group-IB investigating the Hive ransomware-as-a-service (RaaS) operation discovered that the group is “one of the most aggressive ones,” its affiliates hitting at least 355 companies by October 16.
The first publicly known attack from this gang was on June 23, against Canadian IT company Altus Group. At that time, it was unclear if Hive was a RaaS operation open to other cybercriminals.
Things became clear in early September when the group, through a user known as “kkk,” replied in a thread on “reputable” ransomware programs that they were looking for partners that already had access to company networks.
source: Group-IB
The message also included details about splitting the ransom money: 80% for affiliates, 20% for the developers.
The same user also provided technical information about the file-encrypting malware in a self-destructing note captured by Group-IB researchers.
Although “kkk” did not name the RaaS they were representing, the researchers say that the technical details provided made it clear that the actor was referring to Hive ransomware.
source: Group-IB
Behind the Hive ransomware curtains
Group-IB obtained access to the Hive ransomware admin panel and started to collect information about the operation and how it worked.
It appears that the developers set everything up to make ransomware deployment and negotiations with the victims as easy and transparent as possible.
Affiliates can generate a malware version in up to 15 minutes and negotiations run via Hive ransomware admins, who pass the message to the victim in a chat window also visible to affiliates.
source: Group-IB
Although the decryption software is provided after paying the ransom, some companies complained that the tool was not working properly and corrupted the Master Boot Record of virtual machines, making them non-bootable.
source: Group-IB
In a report shared with BleepingComputer, Group-IB notes that the Hive ransomware administration panel shows affiliates how much money they made, the companies that paid and those that had their data leaked, and lets them store profiles for targeted businesses.
source: Group-IB
The researchers found that all affiliates have access to the company IDs in the Hive ransomware database, which is rather unusual.
Furthermore, the admin panels and the leak site are running through an API (Application Programming Interface), which Group-IB says has been seen with only two other ransomware groups: Grief and DoppelPaymer.
Looking closer at the API, the researchers found an error that allowed them to glean information about all Hive ransomware attacks, which also let them gauge how many companies paid these attackers.
According to their assessment, the threat actor hit 355 organizations by October 16; 104 victims negotiated with the attackers.
“Based on the analysis of company data obtained through API, the number of victims grew by 72% in less than one month. On September 16, the total number of records related to victim companies was 181. Just one month later, on October 16, the number increased to 312. Notably, 43 companies listed as victims in September disappeared from API in October, most likely after paying the ransom” – Group-IB
As for the money extorted from victims, Group-IB told BleepingComputer that they estimate the gang made at least $6.5 million from October to November.
Group-IB’s research into the ransomware business, recently published in the company’s recent report called “Corporansom: threat number one,” shows that about 30% of the victims choose to pay the threat actor.
Despite being more active than initially believed, Hive ransomware relies on common initial compromise methods, which include the following:
vulnerable RDP servers
compromised VPN credentials
phishing emails with malicious attachments
The attackers also deploy the encryption stage of the attack during non-working hours or over the weekend, which is typical for most ransomware attacks.
eCommerce servers are being targeted with remote access malware that hides on Nginx servers in a way that makes it virtually invisible to security solutions.
The threat received the name NginRAT, a combination of the application it targets and the remote access capabilities it provides and is being used in server-side attacks to steal payment card data from online stores.
NginRAT was found on eCommerce servers in North America and Europe that had been infected with CronRAT, a remote access trojan (RAT) that hides payloads in tasks scheduled to execute on an invalid day of the calendar.
NginRAT has infected servers in the U.S., Germany, and France where it injects into Nginx processes that are indistinguishable from legitimate ones, allowing it to remain undetected.
RATs enable server-side code modification
Researchers at security company Sansec explain that the new malware is delivered CronRAT, although both of them fulfill the same function: providing remote access to the compromised system.
Willem de Groot, director of threat research at Sansec, told BleepingComputer that while using very different techniques to maintain their stealth, the two RATs appear to have the same role, acting as a backup for preserving remote access.
Whoever is behind these strains of malware, is using them to modify server-side code that allowed them to record data submitted by users (POST requests).
Sansec was able to study NginRAT after creating a custom CronRAT and observing the exchanges with the command and control server (C2) located in China.
The researchers tricked the C2 into sending and executing a rogue shared library payload, as part of the normal malicious interaction, disguising the NginRAT “more advanced piece of malware.”
“NginRAT essentially hijacks a host Nginx application to stay undetected. To do that, NginRAT modifies core functionality of the Linux host system. When the legitimate Nginx web server uses such functionality (eg dlopen), NginRAT intercepts it to inject itself” – Sansec
At the end of the process, the Nginx process embeds the remote access malware in a way that makes it virtually impossible to tell apart from a legitimate process.
In a technical report today, Sansec explains that NginRAT lands on a compromised system with the help of CronRAT via the custom “dwn” command that downloads the malicious Linux system library to the “/dev/shm/php-shared” location.
The library is then launched using the LD_PRELOAD debugging feature in Linux that is typically used to test system libraries.
Likely to mask the execution, the threat actor also added the “help” option multiple times at the end. Executing the command injects the NginRAT into the host Nginx app.
Because NginRAT hides as a normal Nginx process and the code exists only in the server’s memory, detecting it may be a challenge.
However, the malware is launched using two variables, LD_PRELOAD and LD_L1BRARY_PATH. Administrators can use the latter, which contains the “typo,” to reveal the active malicious processes by running the following command:
Sansec notes that if NginRAT is found on the server, administrators should also check the cron tasks because it is very likely that malware is hiding there, too, added by CronRAT.
Security researchers have discovered a new remote access trojan (RAT) for Linux that keeps an almost invisible profile by hiding in tasks scheduled for execution on a non-existent day, February 31st.
Dubbed CronRAT, the malware is currently targeting web stores and enables attackers to steal credit card data by deploying online payment skimmers on Linux servers.
Characterized by both ingenuity and sophistication, as far as malware for online stores is concerned, CronRAT is undetected by many antivirus engines.
Clever hideout for payloads
CronRAT abuses the Linux task scheduling system, cron, which allows scheduling tasks to run on non-existent days of the calendar, such as February 31st.
The Linux cron system accepts date specifications as long as they have a valid format, even if the day does not exist in the calendar – which means that the scheduled task won’t execute.
This is what CronRAT relies on to achieve its stealth. A report today from Dutch cyber-security company Sansec explains that it hides a “sophisticated Bash program” in the names of the scheduled tasks.
“The CronRAT adds a number of tasks to crontab with a curious date specification: 52 23 31 2 3. These lines are syntactically valid, but would generate a run time error when executed. However, this will never happen as they are scheduled to run on February 31st,” Sansec Researchers explain.
The payloads are obfuscated via multiple layers of compression and Base64 encoding. Cleaned up, the code includes commands for self-destruction, timing modulation, and a custom protocol that allows communication with a remote server.
The researchers note that the malware contacts a command and control (C2) server (47.115.46.167) using an “exotic feature of the Linux kernel that enables TCP communication via a file.”
Furthermore, the connection is done over TCP via port 443 using a fake banner for the Dropbear SSH service, which also helps the malware stay under the radar.
After contacting the C2 server, the disguise falls, sends and receives several commands, and gets a malicious dynamic library. At the end of these exchanges, the attackers behind CronRAT can run any command on the compromised system.
CronRAT has been found on multiple stores across the world, where it was used to inject on the server scripts that steal payment card data – the so-called Magecart attacks.
Sansec describes the new malware as “a serious threat to Linux eCommerce servers,” due to its capabilities:
Fileless execution
Timing modulation
Anti-tampering checksums
Controlled via binary, obfuscated protocol
Launches tandem RAT in separate Linux subsystem
Control server disguised as “Dropbear SSH” service
Payload hidden in legitimate CRON scheduled task names
All these features make CronRAT virtually undetectable. On VirusTotal scanning service, 12 antivirus engines were unable to process the malicious file and 58 of them did not detect it as a threat.
Sansec notes that CronRAT’s novel execution technique also bypassed its detection algorithm, eComscan, and the researchers had to rewrite it in order to catch the new threat.
Security researchers have discovered a new remote access trojan (RAT) for Linux that keeps an almost invisible profile by hiding in tasks scheduled for execution on a non-existent day, February 31st.
Dubbed CronRAT, the malware is currently targeting web stores and enables attackers to steal credit card data by deploying online payment skimmers on Linux servers.
Characterized by both ingenuity and sophistication, as far as malware for online stores is concerned, CronRAT is undetected by many antivirus engines.
Clever hideout for payloads
CronRAT abuses the Linux task scheduling system, cron, which allows scheduling tasks to run on non-existent days of the calendar, such as February 31st.
The Linux cron system accepts date specifications as long as they have a valid format, even if the day does not exist in the calendar – which means that the scheduled task won’t execute.
This is what CronRAT relies on to achieve its stealth. A report today from Dutch cyber-security company Sansec explains that it hides a “sophisticated Bash program” in the names of the scheduled tasks.
“The CronRAT adds a number of tasks to crontab with a curious date specification: 52 23 31 2 3. These lines are syntactically valid, but would generate a run time error when executed. However, this will never happen as they are scheduled to run on February 31st,” Sansec Researchers explain.
The payloads are obfuscated via multiple layers of compression and Base64 encoding. Cleaned up, the code includes commands for self-destruction, timing modulation, and a custom protocol that allows communication with a remote server.
The researchers note that the malware contacts a command and control (C2) server (47.115.46.167) using an “exotic feature of the Linux kernel that enables TCP communication via a file.”
Furthermore, the connection is done over TCP via port 443 using a fake banner for the Dropbear SSH service, which also helps the malware stay under the radar.
After contacting the C2 server, the disguise falls, sends and receives several commands, and gets a malicious dynamic library. At the end of these exchanges, the attackers behind CronRAT can run any command on the compromised system.
CronRAT has been found on multiple stores across the world, where it was used to inject on the server scripts that steal payment card data – the so-called Magecart attacks.
Sansec describes the new malware as “a serious threat to Linux eCommerce servers,” due to its capabilities:
Fileless execution
Timing modulation
Anti-tampering checksums
Controlled via binary, obfuscated protocol
Launches tandem RAT in separate Linux subsystem
Control server disguised as “Dropbear SSH” service
Payload hidden in legitimate CRON scheduled task names
All these features make CronRAT virtually undetectable. On VirusTotal scanning service, 12 antivirus engines were unable to process the malicious file and 58 of them did not detect it as a threat.
Sansec notes that CronRAT’s novel execution technique also bypassed its detection algorithm, eComscan, and the researchers had to rewrite it in order to catch the new threat.
The Emotet botnet is back by popular demand, resurrected by its former operator, who was convinced by members of the Conti ransomware gang.
Security researchers at intelligence company Advanced Intelligence (AdvIntel) believe that restarting the project was driven by the void Emotet itself left behind on the high-quality initial access market after law enforcement took it down ten months ago.
The revival of the botnet follows a long period of malware loader shortage and the decline of decentralized ransomware operations that allowed organized crime syndicates to rise again.
Conti ransomware may rise to dominance
Considered the most widely distributed malware, Emotet acted as a malware loader that provided other malware operators initial access to infected systems that were assessed as valuable.
Qbot and TrickBot, in particular, were Emotet’s main customers and used their access to deploy ransomware (e.g. Ryuk, Conti, ProLock, Egregor, DoppelPaymer, and others).
“Emotet’s strategic, operational, and tactical agility was executed through a modular system enabling them to tailor payload functionality and specialization for the needs of specific customers” – AdvIntel
The botnet operators provided initial access at an industrial scale, so many malware operations depended on Emotet for their attacks, especially those in the so-called Emotet-TrickBot-Ryuk triad.
Ryuk is the predecessor of Conti ransomware. The switch occurred last year when Conti activity started to increase and Ryuk detections dwindled down. The operators of both ransomware strains have a long history of attacks hitting organizations in the healthcare and education sector.
AdvIntel researchers say that once Emotet disappeared from the scene, top-tier cybercriminal groups, like Conti (loaded by TrickBot and BazarLoader) and DoppelPaymer (loaded by Dridex) were left without a viable option for high-quality initial access.
“This discrepancy between supply and demand makes Emotet’s resurgence important. As this botnet returns, it can majorly impact the entire security environment by matching the ransomware groups’ fundamental gap” – AdvIntel
The researchers believe that one reason that contributed to multiple ransomware-as-a-service (RaaS) operations shutting down this year (Babuk, DarkSide, BlackMatter, REvil, Avaddon) was that affiliates used low-level access sellers and brokers (RDP, vulnerable VPN, poor quality spam).
With competitors leaving the ransomware business, the “traditional groups” such as Conti (previously Ryuk) and EvilCorp climbed up the ladder once again, attracting “the talented malware specialists who are massively leaving disbanded RaaSes.”
The Conti group, with at least one Ryuk former member on board and in partnership with Emotet’s biggest client, TrickBot, was in the best position to ask Emotet operators for a comeback.
AdvIntel researchers are confident that the Conti group will deliver their payload to high-value targets via Emotet once the botnet grows, and will become a dominant player on the ransomware scene.
Since partnerships yield the best results, as shown by the Emotet-TrickBot-Ryuk alliance in 2019 and 2020, a new triad may soon rise above other operations, with Conti ransomware as the final payload.
