Tag Archive for: Redis

Stealthy HeadCrab Malware Compromised Over 1,200 Redis Servers

/in


Feb 02, 2023Ravie LakshmananDatabase Security / Cryptocurrency

HeadCrab Malware

At least 1,200 Redis database servers worldwide have been corralled into a botnet using an “elusive and severe threat” dubbed HeadCrab since early September 2021.

“This advanced threat actor utilizes a state-of-the-art, custom-made malware that is undetectable by agentless and traditional anti-virus solutions to compromise a large number of Redis servers,” Aqua security researcher Asaf Eitani said in a Wednesday report.

A significant concentration of infections has been recorded in China, Malaysia, India, Germany, the U.K., and the U.S. to date. The origins of the threat actor are presently unknown.

The findings come two months after the cloud security firm shed light on a Go-based malware codenamed Redigo that has been found compromising Redis servers.

The attack is designed to target Redis servers that are exposed to the internet, followed by issuing a SLAVEOF command from another Redis server that’s already under the adversary’s control.

HeadCrab Malware

In doing so, the rogue “master” server initiates a synchronization of the newly hacked server to download the malicious payload, which contains the sophisticated HeadCrab malware.

“The attacker seems to mainly target Redis servers and has a deep understanding and expertise in Redis modules and APIs as demonstrated by the malware,” Eitani noted.

HeadCrab Malware

While the ultimate end goal of using the memory-resident malware is to hijack the system resources for cryptocurrency mining, it also boasts of numerous other options that allows the threat actor to execute shell commands, load fileless kernel modules, and exfiltrate data to a remote server.

What’s more, a follow-on analysis of the Redigo malware has revealed it to be weaponizing the same master-slave technique for proliferation, and not the Lua sandbox escape flaw (CVE-2022-0543) as previously disclosed.

Users are recommended to refrain from exposing Redis servers directly to the internet, disable the “SLAVEOF” feature in their environments if not in use, and configure the servers to only accept connections from trusted hosts.

Eitani said “HeadCrab will persist in using cutting-edge techniques to penetrate servers, either through…

Source…

Public Redis exploit used by malware gang to grow botnet

/in


Hacker

The Muhstik malware gang is now actively targeting and exploiting a Lua sandbox escape vulnerability in Redis after a proof-of-concept exploit was publicly released.

The vulnerability is tracked as CVE-2022-0543 and was discovered in February 2022, affecting both Debian and Ubuntu Linux distributions.

Soon after, on March 10th, a proof-of-concept (PoC) exploit was publicly released on GitHub, allowing malicious actors to run arbitrary Lua scripts remotely, achieving sandbox escape on the target host.

Although the vulnerability has been patched in Redis package version 5.6.0.16.-1, it is common for servers not to be updated immediately due to operational concerns or simply because the admin does not know of the new release.

According to a report by Juniper Threat Labs, just one day after the PoC was released, the Muhstik gang began actively exploiting the flaw to drop malware that supports its DDoS (denial of service) operations.

Executing commands on Redis session
Executing commands on Redis session (Juniper)

A long-running Chinese botnet

The Muhstik botnet is thought to be operated out of China, as researchers have previously linked its control infrastructure to a Chinese forensics firm.

It has been around since at least 2018 surviving by adaptation, regularly switching to exploiting new vulnerabilities consistently to target large numbers of vulnerable devices.

In the past, it targeted Oracle WebLogic Server bugs (CVE-2019-2725 and CVE-2017-10271) and a Drupal RCE flaw (CVE-2018-7600).

In September, Muhstik switched to attacking Confluence Servers through CVE-2021-26084, and in December, it focused on exploiting vulnerable Apache Log4j deployments.

The exploitation of CVE-2022-0543 started at the beginning of this month and is still ongoing.

Timeline of Muhstik activity
Timeline of Muhstik activity (Juniper)

A “Russian” payload

Muhstik named their payload “russia.sh”, which is downloaded from the C2 using wget or curl, saved as “/tmp.russ”, and eventually executed.

The script will fetch variants of the Muhstik bot from an IRC server, while the bot supports the reception and parsing of shell commands, flood commands, and SSH brute force.

Muhstik bot capabilities as seen in the code
Muhstik bot capabilities as seen in its strings (Juniper)

In the past, Muhstik also downloaded…

Source…

New Pro-Ocean malware worms through Apache, Oracle, Redis servers

/in


The financially-motivated Rocke hackers are using a new piece of cryptojacking malware called Pro-Ocean to target vulnerable instances of Apache ActiveMQ, Oracle WebLogic, and Redis.

The new malware is a step up from the previous threat used by the group in that it comes with self-spreading capabilities, blindly throwing exploits at discovered machines.

Hiding malicious activity

Rocke cryptojacking hackers have not changed their habit of attacking cloud applications and leverage known vulnerabilities to take control of unpatched Oracle WebLogic (CVE-2017-10271) and Apache ActiveMQ (CVE-2016-3088) servers. Unsecured Redis instances are also on the list.

Researchers at Palo Alto Networks analyzing the malware say it includes “new and improved rootkit and worm capabilities” that allow it to hide malicious activity and spread to unpatched software on the network.

To stay under the radar, Pro-Ocean uses LD_PRELOAD, a native Linux feature that forces binaries to prioritize the loading of specific libraries. The method is not new and is constantly seen in other malware.

The new part is that the developers took the rootkit capabilities further by implementing publicly available code that helps conceal malicious activity.

One example relates to the ‘open’ function of the ‘libc’ library, tasked with opening a file and returning its descriptor. The researchers discovered that the malicious code determines if a file needs to be hidden before calling ‘open.’

source: Palo Alto Networks

“If it determines that the file needs to be hidden, the malicious function will return a “No such file or directory” error, as if the file in question does not exist” – Palo Alto Networks

Crude self-spreading mechanism

The actors behind Pro-Ocean have also moved from manually exploiting victims to an unrefined automated process. A  Python script takes the infected machine’s public IP address using the ident.me service and then tries to infect all machines in the same 16-bit subnet.

There is no selection in the process and the attackers simply throw public exploits at the discovered hosts hoping that one of them sticks.

source: Palo Alto Networks

If there is successful exploitation,…

Source…