Featured image of post Log4j RCE exploitation detection

Log4j RCE exploitation detection

Find any actions, related to the Log4j 2.x RCE vulnerabilities CVE-2021-44228 and CVE-2021-45046

Both, CVE-2021-44228 and CVE-2021-45046 should be well known and are very well documented on many other sites already. Therefore a will not go into any further details about the two CVE’s and skip right to the real thing.

Here is a pattern search for logs within /var/log (works well on Debian 10/11):

sudo egrep -I -i -r '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+' /var/log

For compresses (GZ) files within /var/log, use this (also works well on Debian 10/11):

sudo -i
find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+'

Find Log4j related JAR Files and get the used version of the JAR (based on the manifest)

sudo -i
find / | grep log4j | grep .jar | xargs -I {} sh -c 'echo {} && unzip -p {} META-INF/MANIFEST.MF | grep Implementation-Version:'

You can also use PowerShell to scan a Windows based Client or Server:

$AllFixedDisks = (Get-Volume -ErrorAction SilentlyContinue | Where-Object -FilterScript {
      (($_.DriveType -eq 'Fixed') -and ($_.DriveLetter -ne $null))
foreach ($FixedDisk in $AllFixedDisks)
   Get-ChildItem -Path ('{0}:\' -f $FixedDisk.DriveLetter) -Recurse -Force -Include *.jar -ErrorAction SilentlyContinue | ForEach-Object -Process {
      Select-String -Pattern 'JndiLookup.class' -Path $_
   } | Select-Object -ExpandProperty Path

Pattern for usage within a SIEM:


If you want to check your own System (without doing a scan), the simplest way to detect if a remote endpoint is vulnerable is to trigger a DNS query. The exploit will cause the vulnerable server to try to fetch remote code. By using the address of the free online DNS logging tool in the exploit string, you can detect when the vulnerability is triggered.

Go to and create a free Log4Shell Token, you can select how the trigger is fired: Mail or a Webhook. Mail is fine, but a Webhook makes it very flexible! If you have end endpoint for it.

curl -H 'X-Api-Version: ${jndi:ldap://x${hostName}.L4J.<TOKEN>}'

Replace the <TOKEN> above with the token you generated at!

You might have to replace the Port (in this case 8080) with the port your server is listening to. And you can also execute this test remotely (Replace with the IP, hostname, FQDN of you host).

I recommend to read the Log4Shell: RCE 0-day exploit found in Log4j 2.x, a popular Java logging package at LunaSec.

I also recommend to mitigate the issue by using the JVM option log4j2.formatMsgNoLookups=true. Even if you have upgraded to the latest version of Log4J (like Log4j 2.12.2 and Log4j 2.16.0), one that is not effected by CVE-2021-44228 and/or CVE-2021-45046.

Always use an UpToDate version of a JVM!

If you can not (why ever) upgrade, the mitigation above is something i would consider as the minimum required mitigation! In this case, i would consider to remove the JndiLookup class from the Java classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

If you have any kind of Web Application Firewall (WAF) or reverse proxy in use, check if the vendor provides updated rules to mitigate any Log4Shell actions.

I know, Log4J 1.2 is not impacted by the CVE’s above! But as you hopefully already know: It’s end of life since years and you should avoid using software after the end of life is reached for years now!