log4shell.tools Scan logs

Log4Shell Scanner

Paste a log line, request header, or whole log file and instantly flag Log4Shell (CVE-2021-44228) exploitation attempts — including obfuscated JNDI payloads.

  1. Paste log lines, a header value, or a whole log file into the box.
  2. Click Scan — payloads are de-obfuscated and analysed locally.
  3. Review each finding: line, protocol, whether it was obfuscated, and why it's dangerous.

log4shell.tools scans text for Log4Shell exploitation attempts — the JNDI lookup payloads attackers fire at vulnerable Apache Log4j 2 instances (CVE-2021-44228). Paste a suspicious request header, a single log line, or a whole log file, and the scanner flags every ${jndi:...} attempt, names the protocol used, and explains the risk.

Crucially, it also catches the obfuscated payloads that bypass naïve grep — tricks like ${${lower:j}ndi:...} and ${${::-j}${::-n}${::-d}i:...} — by safely de-obfuscating Log4j lookups to reveal their intent. This is a detection-only tool: it never resolves a lookup, contacts a host, or executes anything.

What Log4Shell is

CVE-2021-44228 is a critical remote-code-execution flaw in Apache Log4j 2 (versions 2.0-beta9 through 2.14.1). Log4j supported a 'lookup' feature that would resolve ${jndi:ldap://…} strings even when they appeared in logged data — a username, a User-Agent, a chat message. An attacker simply gets the application to log a malicious string; the vulnerable Log4j then reaches out over JNDI/LDAP and loads a remote Java object, executing attacker code. It scored CVSS 10.0 and is one of the most widespread vulnerabilities ever.

Catching obfuscated payloads

Attackers quickly learned to hide the literal word jndi using Log4j's own lookup syntax. ${lower:J} resolves to j; ${::-j} emits the default value j; nesting them spells out jndi without it ever appearing in the raw text. A scanner that only greps for jndi: misses these. This tool resolves those lookup forms first, then matches — so the obfuscated and the plain attempts both light up, with the de-obfuscated form shown next to the original.

What to do if you find a hit

A hit in your logs means someone attempted exploitation — not necessarily that they succeeded. Check whether the affected service ran a vulnerable Log4j version (use the version checker), whether outbound LDAP/RMI was possible from that host, and whether the payload's callback domain was reached. Then patch to Log4j 2.17.1+ and review for post-exploitation activity. Treat confirmed-vulnerable, internet-exposed hits as incidents.

Guides about Log4Shell Scanner

Detecting exploitation How to Detect Log4Shell Exploitation in Your Logs A practical guide for defenders on detecting Log4Shell exploitation attempts in existing logs, covering which fields to search, the JNDI patterns to look for, and how to triage real findings. 6 min read Log4Shell explained How the Log4Shell JNDI Lookup RCE Worked, Conceptually A conceptual, defender-focused walkthrough of how the Log4Shell JNDI lookup led to remote code execution, explaining each link in the chain and where defenders can break it. 6 min read Remediation & patching How to Patch Log4j Against Log4Shell: A Step-by-Step Guide A step-by-step guide to patching Log4j against Log4Shell, covering which version to upgrade to, handling transitive dependencies, verifying the fix, and avoiding regressions. 6 min read Remediation & patching Log4Shell Mitigation Without Upgrading: Stopgaps That Help A defender's guide to mitigating Log4Shell when you cannot upgrade yet, covering removing JndiLookup.class, formatMsgNoLookups, WAF limits, and why these are stopgaps rather than fixes. 6 min read Obfuscated payloads Obfuscated JNDI Payloads Explained for Blue Teams A defender's breakdown of how Log4Shell JNDI payloads are obfuscated, from case-folding lookups to default-value tricks and encoding, so blue teams can recognise them in logs and traffic. 5 min read Detecting exploitation Triaging Log4Shell Across Your Estate With a Scanner A defender's playbook for triaging Log4Shell across a large estate, covering scanning and inventory, prioritising by exposure, confirming versions, hunting logs, and tracking remediation to closure. 6 min read

More log4shell tools

Log4j Version Checker Enter a Log4j version and find out whether it's vulnerable to Log4Shell — and exactly which fix you need.

Frequently asked questions

Does this scanner exploit or execute anything?
No. It is detection-only: it parses text, safely de-obfuscates Log4j lookup syntax, and pattern-matches. It never resolves a JNDI lookup or contacts any host.
Can it catch obfuscated payloads?
Yes — it resolves ${lower:}, ${upper:} and ${...:-default} lookup tricks to reveal hidden 'jndi' strings, so obfuscated and plain attempts both get flagged.
A payload showed up in my logs — was I hacked?
It means an attempt was logged, not that it succeeded. Success depends on whether a vulnerable Log4j version was running and outbound JNDI was possible. Check the version checker and investigate as an incident if exposed.
Is my pasted data sent anywhere?
Scanning happens server-side to analyse the text, and nothing is stored. The tool does not act on the payloads it finds.