Critical Vulnerability on Apache Log4J 2 Library


National Cyber Coordination and Command Centre (NC4) would like to alert everyone about a critical vulnerability concerning the use of Log4J 2 library and a working exploit affecting all applications using the library. The exploits can cause information leak and remote code execution and has been proven that it can be used to gain remote access into the vulnerable server and can potentially be used to attack other resources or hold the server for ransom.


Complete system takeover, Information leakage, malware host/infection and service disruption.

Brief Description

NC4 is alerted of a high severity vulnerability (CVE-2021-44228) involving Apache Log4j 2, with CVSSv3 score of 10.0. Multiple versions of the Apache Log4j 2 utility in particular Apache Log4j 2 versions 2.0 to 2.14.1 were impacted by this severity which was disclosed publicly on 9 December 2021. Apache Log4j 2.14.1 (and below) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. This vulnerability allows for unauthenticated remote code execution and due to how ubiquitous this library is and how easy it is to exploit, the impact of the exploit can lead to total server takeover. However, for log4j 2.15.0, this behavior has been disabled by default.

Log4j 2 is an open-source Java logging library developed by the Apache Foundation. Log4j 2 is widely used in many applications and is present, as a dependency, in many services including enterprise applications as well as numerous cloud services.

Therefore, organisations are urged to take the necessary actions to prevent your organisations from becoming victims of this attack that may interrupt your daily operation.

Affected Product

All web servers and online services that use Log4J library in Log4j 2.0-beta9 up to v2.14.1.


For CVE-2021-44228, NC4 recommends following vendor best practice advice in the mitigation of vulnerabilities. Organisations are advised to identify all the systems that use Log4j 2 directly or indirectly(via software bundle/package) and apply the latest patch released by Apache or respective software as soon as possible. More information is available at:


Method to Identify Log4j Version

The specific files to search for should match the following pattern:


Depending on the installation method, the location of the matching JAR file may also give indications as to which application is potentially vulnerable. For example, on Windows, if the file is located in C:\Program Files\ApplicationName\log4j-core-version.jar it indicates ApplicationName should be investigated. On Linux, the lsof utility can show which processes currently have the JAR file in use and can be run via the following syntax:

lsof /path/to/log4j-core-version.jar

Monitoring Log4j Exploit and Attack

From the web and server logs data in the request, the exploit will contain the malicious payload string: “${jndi:ldap://}” (where is an attacker controlled server).

While this method can bypass security appliances by using code obfuscation technique, it is still advisable that organisations block any request using this default payload string to reduce the risk.

Permanent Mitigation

  1. Upgrade to Log4j 2.15.0.
  2. For those who cannot upgrade to 2.15.0:
    • For version 2.10 and above, this vulnerability can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
    • For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

If patching is not possible, it is highly advised organisations apply the temporary mitigation below and monitor impacted applications closely for anomalous behavior.

Temporary Mitigation

To mitigate the vulnerability in place of updating Log4j 2, the following parameter should be set to true when starting the Java Virtual Machine:


Organisations are also advised to be vigilant and to take the following actions:

  1. Enumerate any external facing devices that have log4j 2 installed;
  2. Monitor your infrastructure to detect any associated threat activity;
  3. Make sure that your security operations center is actioning every single alert on the devices that fall into the category above;
  4. Upgrade your current Log4J 2 version to Log4j version 2.15 or apply your appropriate vendor recommended mitigations immediately;
  5. Install a web application firewall (WAF) with rules that automatically update so that your SOC is able to concentrate on fewer alerts;
  6. Review your firewall logs and other security devices for anomalies from time to time;
  7. Review your firewall and other security appliance configurations from time to time;
  8. Block or restrict access to every port such as 81, 2628, 3306, 6669, 3389 (RDP), 5900 (VNC) and 22 (SSH) and services except for those that should be publicly available;
  9. Make sure your system password is strong and secured. Change the password if needed;
  10. Perform regular backups of all critical information to limit the impact of data or system loss and to help expedite the recovery process. Ideally, the backup must be done daily, on a separate media and stored offline at an alternate site;
  11. If you suspected that your servers have been compromised, isolate your server, reset all usernames and passwords and initiate incident handling;
  12. Perform hardening on all your Internet facing applications; and
  13. Report any anomalies happening within your network and enterprise environment to NC4.






National Security Council
Prime Minister's Department
Level LG & G, West Wing,
Perdana Putra Building,
Federal Government Administrative Center,
62502 Putrajaya, Malaysia.


Number of Visitors Last Updated
715,989 15 April 2024