Written by:

Updated 15.12.2021


There is a critical vulnerability in Apache Log4j versions 2.0 to 2.14.1, a widely used software library for Java applications. The vulnerability, CVE-2021-44228, also named #Log4Shell allows for unauthenticated remote code execution and is trivial to exploit. Proof-of-concept code has been published, and we currently observe internet-wide exploit attempts and scanning for vulnerable servers. Several botnets are already exploiting this vulnerability, and it is being observed used by both crime-oriented and state-sponsored threat actors.

A vendor fix is available and highly recommended to apply as soon as possible. A workaround mitigation is described and recommended for systems that cannot be upgraded.


Apache Log4j is a widely used logging library for Java applications. On November 24, Alibaba Cloud's security team reported a a zero-day vulnerability in Log4j versions 2.0 to 2.14.1 to Apache.

The vulnerability is trivial to exploit, is present in default configurations of a large number of popular enterprise software, and proof-of-concept exploit code was published on the 9th of December. If an attacker is able to get a vulnerable application to log an attacker-supplied input, remote code execution is possible.

JNDI (Java Naming and Directory Interface) is a Java programming language API that that allows software clients to discover and look up data and resources. The vulnerability allows an attacker to craft and send a malicious payload containing a JNDI lookup that gets parsed and executed by Log4j. The supplied user input can for example come from a web application that logs user names, referrers or user-agent strings. The vulnerable Log4j code may reside on a system in backend infrastructure that is not directly accessible via the internet. We have observed many cases where the malicious payload contains code with message lookups causing outbound connections through various protocols, effectively creating a backdoor access for remote code execution.

A new version of Log4j 2.16.0 is now available, which fixes the vulnerability by removing support for message lookups and disabling JNDI by default.

Threat Intelligence assessment

mnemonic is observing both active reconnaissance and exploitation attempts for this vulnerablity.

Due to the ease of exploitation and availability of exploit code, we expect evolving techniques and increased number of attempts to exploit this vulnerability. This vulnerability is currently being exploited by both crime-oriented and state-sponsored threat actors.

The consequences of a successful exploitation could be both in the form of remote code execution and data leaks.

The mass scanning activity observed so far has involved attempts at installing several cryptocurrency miners and the Tsunami backdoor. The Mirai botnet was very quick to adopt the exploit as part of its functionality. Mass scanning and concurrent exploit attempts are targeting both Windows and Linux systems. Data leaks attempts without dropping a payload is also part of the mass scanning activity. The vulnerability is also being leveraged by initial access brokers that operate a business model where they sell their access to vulnerable targets to ransomware-as-a-service operators.

Affected systems

Software applications utilising Apache Log4j 2 versions 2.0 to 2.14.1 are vulnerable.

Log4j versions 1.x are not affected by this vulnerability, however these reached end of life in 2015 and are affected by several other security vulnerabilities.

Apache released an initial fix, 2.15.0rc1 which security researchers were able to bypass. Following this, Apache released 2.15.0rc2, which fixed these issues. However, on 14. December a new vulnerability CVE-2021-45046 was discovered for certain non-default configurations of the 2.15.0 fixes that enable an attacker to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service attack. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath.


mnemonic recommends that you perform the following actions:

  • Get an overview of all your affected systems
    • Vulnerable systems are not necessarily directly exposed to the internet, take this into account when enumerating
  • Upgrade Apache Log4j 2 to log4j-2.15.0-rc2 or later
  • If you cannot immediately upgrade Log4j, apply one of the following mitigations (applies to versions >=2.10):
    • Start your Java Virtual Machine with log4j2.formatMsgNoLookups set to true.
    • Remove the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class)
  • If you cannot immediately upgrade or apply any of the workaround mitigations consider shutting down or taking affected applications offline
  • Check that your firewall, WAF and/or IPS receives automatic ruleset updates
  • Adjust firewall rules to prevent unexpected outbound traffic and to monitor for denied outbound connections
  • Initiate threat hunting activities
  • Search all of your logs for the following patterns:
    • jndi:ldaps
    • jndi:ldap
    • jndi:rmi
    • jndi:dns

Please note that there are several obfuscation techniques in use by attackers that might make searching for exploit patterns difficult. Mass scanning has been observed since the 9th of December, but some exploitation attempts have been reported as early as 1st of December. Threat hunting activities is therefore recommended on historical log data.

mnemonic strongly recommends to assume compromise and to initiate incident response activities if any anomalies are discovered on a device running vulnerable versions of Log4j.

Detection coverage for Argus customers and Argus Continuous Vulnerability Monitoring (CVM) coverage

  • Detection has been developed for Argus Log Analyser which detects usage of jndi: in common HTTP fields
  • Detection has been developed for Argus Network Analyser and other network sensors managed by mnemonic which detects usage of jndi: in common HTTP fields
  • Detection has been developed for Argus Network Analyser based on ip/domain reputation derived from reported and observed scanning and exploitation activity
  • Detection has been added for Argus CVM (both remote/direct and local/authenticated) This includes detection via callback/detection via Path Enumeration/Message Lookup Substitution

We are continuously monitoring the situation and will develop and implement detection as soon as new patterns and indicators are identified for any given Argus service.

Mitigation coverage for security products provided by mnemonic


  • F5 has released several new signatures for ASM/AWAF/Nginx AppProtect to accompany their existing general signatures
  • An iRule for load balanced services with SSL-profiles is also available for customers not using WAF

Check Point

  • Check Point IPS has proven to be effective against general reconnaissance and external scanning against vulnerable services

Palo Alto

  • Palo Alto Threat Prevention has proven to be effective against general reconnaissance and external scanning against vulnerable services
  • For additional mitigation, Palo Alto can block exposed file types such as Java Class files, and can identify and block traffic using LDAP and RMI

If you need any assistance in how to apply any of these measures, please open an Argus ticket or reach out to your Sales contact in mnemonic.