Skip to main content
Blog

Critical Log4j vulnerability exposing enterprise systems to ransomware & RAT infection

By 15 December 2021No Comments

Log4J, an open source Apache logging framework that logs activity in applications, has been found featuring a serious vulnerability that allows malicious actors to plant a remote access trojan and also ransomware in enterprise servers.

Log4j is a widely-used open source library written in Java script that logs activities in applications. It is used by frameworks such as Elasticsearch, Kafka and Flink and is a crucial component used for running a significant proportion of websites and online services.  Recently, security researchers at Bitdefender discovered a critical RCE (remote code execution) vulnerability in Log4j which, if exploited widely, could have a very significant ripple effect on the software supply chain.

Bitdefender said that the RCE vulnerability, assigned CVE-2021-44228, affects all versions of Log4j from 2.0-beta9 (released in September 2013) to 2.14.1 (March 2021). The security firm has already observed hackers using various botnets to exploit the flaw and says the primary motive for them is to use compromised machines for cryptojacking (malicious crypto mining without the knowledge and consent from the owner).

On 11th December, Bitdefender also observed hackers trying to exploit the vulnerability to target systems using the Windows operating system. Previously, all the observed attacks seemed to target Linux servers. Hackers targeting systems using Windows OS are now attempting to download an additional payload, namely the Khonsari ransomware family which uses AES 128 CBC to encrypt system files.

On December 13, Bitdefender discovered that malicious actors are also trying to exploit the RCE vulnerability in Log4j to download a payload that appears to be the Orcus Remote Access Trojan (RAT). Bitdefender says that the only way for organizations to protect their applications and systems from hackers intent on exploiting the RCE vulnerability is to immediately upgrade their Log4j deployments in their enterprise systems to Log4j version 2.15.0, which is not vulnerable.

Andy Norton, European cyber risk officer at Armis, says that an exploitation of the zero-day vulnerability can allow hackers to take full control over targeted systems. Security teams should, therefore, take a defense-in-depth approach to address the critical vulnerability and follow specific steps to remediate and protect their systems.

“Armis researchers analysed the vulnerability over the weekend and suggest that security teams scan their entire environment to identify all applications on the network that are vulnerable to this flaw. Enterprises should then apply the Log4j.2.15.0 update to remediate. In order to protect against any potential exploitation in the cloud environment, it’s vital to apply the updated rules to their WAF, to remove any opportunity for exploitation of assets while the patching is being finalised,” he said.

Reuven Harrison, CTO at Tufin, says that the exploit,  like many others, relies on a call-home step to a command-and-control (C2) server. “To prevent these kinds of attacks, organizations should restrict egress (outbound) connectivity. Each subnet, server and workload should be allowed to connect only to the endpoints that are required by business. All other destinations should be blocked.

“Blocking egress connections is easy with standard security controls such as firewalls, but defining the policy, which egress connections are allowed, is tough. Doing this properly requires continuous learning of legitimate application connectivity patterns, and enforcement in production environments.” 

Source

All rights reserved Teiss Recruitment Ltd.