All blog posts

Optimizing your resilience against Log4Shell

Collection of actionable measures — across Prevention, Mitigation, Detection and assessment — for coping with the Log4Shell chaos

Collection of actionable measures — across Prevention, Mitigation, Detection and assessment — for coping with the Log4Shell chaos

As more information continues to unravel about the nature and characteristics of the Log4Shell vulnerability, it is clear that coping with this vulnerability is a complex task, and upgrading Log4j across your entire ecosystem is far from trivial. Defenders are therefore required to implement measures across multiple verticals — Prevention, Mitigation, Assessment and Detection — in order to optimize their posture in relation to the Log4Shell scenario.

Below is a list of actionable measures we’ve compiled — spanning across all 4 verticals— that can assist you in optimizing your resilience against this vulnerability:


Upgrade version of all log4j packages to 2.15.0 —


While the different mitigations may not provide a full-proof solution for the vulnerability, they are easier to implement and significantly reduce the attack surface, and therefore recommended as temporary measures until all relevant log4j packages are upgraded.

  1. Mitigations in Java configuration:
  • In Log4j releases >=2.10, the 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 >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
  • For releases >=2.0-beta9 and <=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
  • AWS have released a hotpatch that is to hotpatch a running JVM using any Log4j 2.0+.

2. Server hardening:

  • Restrict egress access (LDAP/HTTP/HTTPS/DNS) from all relevant servers to prevent the malicious user-controlled payload from being able to communicate with the attacker’s servers and download malicious code.

3. WAF:

  • General recommendation is to add a rule to your WAF searching and blocking “jndi:ldap://” for any input from the outside world.
  • Many of the WAF vendors have updated their rulesets with specific detections for Log4Shell. Make sure to follow and implement the WAF-specific recommendations.


Your attack surface consists of a combination of your organic assets and assets which exist in 3rd parties you’ve implemented inside your environment, therefore detection efforts should focus on both:

Organic assets — Search for usage of Log4j within your codebase (log4j-api and log4j-core) by looking at the following artifacts –

  • Pom.xml and other Java package manager files (ensure you inspect not only the root hierarchy — analysis should be done against the entire dependency tree)
  • Search in your codebase for imports of log4j code by looking for the following string: “org.apache.logging.log4j” (for example, in Github —

3rd parties — Assess the resilience of 3rd party products within your environment and follow vendor specific patching/mitigation recommendations. This resource contains many vendor specific bulletins around Log4Shell.


Several measures exist to assess and validate whether your environment is vulnerable and/or if the mitigations implemented are effective:

  1. IOCs / YARA signatures useful for detecting compromised assets –

2. Nuclei Payload to detect whether your assets are exploitable:

nuclei -c 200 -t log4j-detect.yaml -u $URL_YOU_WANT_TO_SCAN
Cider Security has been acquired by Palo Alto Networks