CVE-2021-44228 – Log4J/Log4shell


Find out how to deal with the Log4Shell vulnerability right across your estate.
Yes, you need to patch, but that helps everyone else along with you!

📖 Read (

Regarding CVE-2021-44228 with a CVSS v3 score of 10 for the Apache Log4j product, numerous malicious activities were detected aimed at exploiting the product with reference to the distribution of malicious payloads.

The attack chain includes an initial scanning activity aimed at identifying vulnerable servers through URLs or DNS requests to callback domains.

In detail, it was found that several criminal actors started to actively exploit the vulnerability to distribute malicious code on the target systems such as the Kinsing backdoor, CobalStrike beacons or payloads related to the Mirai and Muhstik botnets or XMRig miners to extract Monero cryptocurrency. It is not excluded that the dissemination technique used could be used to convey ransomware attacks in the future.

In addition to using Log4Shell for malware dissemination, the observed activities could be aimed at identifying vulnerable target devices and systems in order to conduct subsequent large-scale denial-of-service attacks or to exfiltrate sensitive information such as credentials or configurations stored in files and environment variables, including host name, user running the Log4j service, operating system type and version.

Affected Products and Versions

The critical-level vulnerability, which is assigned the highest score (CVSSv3: 10) because it allows remote code execution (RCE) without authentication, is known as Log4Shell and affects Java-based applications that use the Log4j 2 product from version 2.0 through 2.14.1.

Attack scenario

The possible exploitation of the flaw allows the execution of arbitrary code to the detriment of the affected application. Attackers, who do not need prior access to the system, can send a malformed https request via a specially crafted string to generate a log on Log4j – which adopts JNDI (Java Naming and Directory Interface) – in order to record the malicious string in the application log. While processing the log, the vulnerable system will find itself in the condition of executing the code specially inserted by the malicious user. For example, this condition may lead the application to make a request to a malicious domain to execute a malicious payload. This allows the attacker to gain control of the affected application and full access to the system.

Possible affected products

Log4j 2 is a logging library widely used in the development of enterprise systems, it is included in various open-source software and often directly integrated into important software applications. For this reason, the scope of the impact is potentially extended to thousands of products and devices, including Apache products such as: Struts 2, Solr, Druid, Flink and Swift.

Since a Java library is involved, by nature multi-platform, the impact affects both Windows and Linux architecture and backend systems and microservices are also considered potentially vulnerable.

Non-exhaustive list of applications that use Log4j:

Elastic Search
Elastic LogStash
Minecraft (client and server)
Apache projects (Druid, Dubbo, Flink, Flume, Hadoop, Kafka, Solr, Spark, Struts, Tapestry, Wicket)
VMware products (Horizon, vCenter, vRealize, HCX, NSX-T, UAG, Tanzu)

Possible actions to detect exploitation attempts
You can use the YARA rule set available at the link:

You can search for compromise attempts in the logs via the commands:

sudo egrep -i -r '\${jndi:(ldap[s]?|rmi)://[^\n]+' /var/log sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\${jndi:(ldap[s]?|rmi)://[^\n]+'

Follow the directions released by Microsoft and given at the link: 

Active network exploitation

Detected scanning activity directed to search vulnerable servers

Mitigation action

If not already done, it is recommended to install Log4j in version 2.15.0 or and if not possible, reduce the attack surface:

  • set the following properties:
    log4j2.formatMsgNoLookups=true LOG4J_FORMAT_MSG_NO_LOOKUPS=true
  • remove the JndiLookup class from the class path
    zip-q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
  • Set the following properties in Java 8u121:

Because many Java-based applications can take advantage of Log4j 2, organizations should consider contacting application vendors or ensuring that their Java applications run the latest available version of the product. Developers using Log4j 2 should also make sure to adopt the latest version in their applications to ensure protection for users and organizations.