Log4shell Deep Scan

What the Log4Shell deep scanner does

This Automox Worklet™ scans the Linux filesystem for Java applications carrying Log4j versions vulnerable to Log4Shell (CVE-2021-44228) and the follow-on JNDI bypass (CVE-2021-45046). The Worklet is adapted from Arctic Wolf's open-source log4shell-tools scanner and walks every JAR, WAR, and EAR file beneath / on the local mount. For each archive, it lists the contents with unzip -l and uses unzip -p to stream JndiManager.class without writing the class file to disk.

Detection runs in two checks. The first confirms that JndiLookup.class is present, which marks the archive as a Log4j-bearing artifact. The second reads JndiManager.class and searches for the log4j2.enableJndi string introduced in 2.16.0 and backported to 2.12.2. Archives that contain JndiLookup.class but not the enableJndi marker are reported as vulnerable Log4j 2.0 through 2.15. Archives that contain the marker, or that contain neither class, are treated as not exposed.

Nested archives are handled recursively. WAR files that bundle JARs, JARs shaded inside fat-JAR Spring Boot builds, and EAR archives copied into vendor application directories are extracted into a per-run temporary file under a local tmp/ directory, re-scanned, and removed. Each vulnerable finding is recorded with the absolute path of the top-level archive. Results stream to /tmp/log4shell_deep_scan.output.<hostname>.<epoch>.json with a parallel .log file capturing unreadable paths, permission failures, and archives that could not be opened.

Why hunt for Log4Shell in nested archives

Log4Shell is the canonical example of a vulnerability that lives where standard vulnerability scanners cannot see. Package manifest scanners (rpm -qa, dpkg -l, even SBOM-aware tooling) only catch Log4j when it is installed as a managed system package. The real exposure sits inside the application stack. A vendor product bundles log4j-core-2.14.1.jar inside a WAR. That WAR is bundled inside an EAR, and the EAR ships in a tarball that an operator extracted into /opt/vendor/lib in 2019. Attackers exploited this gap within hours of CVE-2021-44228 disclosure, and follow-on payloads landed on systems whose owners had already declared themselves patched.

CVE-2021-44228 Log4Shell remains one of CISA's most-cited exploited vulnerabilities, and Java applications routinely ship Log4j inside nested archives that surface-level SBOM tools miss. This Worklet recursively scans JAR, WAR, and EAR archives across Linux servers, container hosts, build agents, and developer workstations, identifies the JndiLookup.class signature inside log4j-core, and returns a per-endpoint evidence trail via Automox. Once exposed paths are known, pair this detection with a Log4j remediation Worklet to neutralize JNDI exposure inside the same scheduled cycle.

How the Log4j filesystem scan works

1. Evaluation phase: The evaluation script always exits 1 to schedule remediation. Log4Shell hunting is a recurring detective control rather than a one-time check, so every policy run produces a fresh scan artifact. The remediation script then verifies that unzip and mktemp are present on the endpoint and stops with a clear UNKNOWN result in the activity log if either is missing.

2. Remediation phase: The remediation script runs find / -mount -type f -regex '.*\.[ejw]ar$' and streams each match through unzip -l to enumerate contents. When JndiLookup.class is detected, the script opens JndiManager.class with unzip -p and pipes it to grep -q 'log4j2.enableJndi' to classify version. Nested archives are extracted into a per-run temporary file under a local tmp/ directory via mktemp "tmp/tmp-XXXXXX", scanned, and removed. Output is written to /tmp/log4shell_deep_scan.output.<hostname>.<epoch>.json as a JSON array of records, and a sibling .log file records files that could not be read because of permissions or corruption.

Log4Shell scanner requirements

• Linux endpoint with unzip and mktemp available on PATH (find, grep, awk, and sed are also used; all are standard on RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, and SUSE)

• Root privileges for the Automox agent so the scan can read application directories under /opt, /var/lib, container image stores, and user home directories

• Free space in /tmp/ for the JSON output file plus transient extraction of nested archives (size scales with the largest WAR or EAR on the endpoint)

• The scan uses find -mount and stays on the root filesystem; run a separate policy targeting other mount points if Java applications live on a dedicated /opt or /data volume that is not part of /

• Expect runtime of 30 seconds to several minutes; endpoints with large Java application stacks (Jira, Confluence, Solr, Elasticsearch, Tomcat farms) take longer because every archive is opened

• Safe on workstations and production servers; the scan is read-only against application archives and writes only to /tmp/ and a transient tmp/ working directory in the Worklet's working path

• Vulnerable Log4j range the scanner reports as exposed: 2.0-beta9 through 2.15.0. Patched ranges reported as safe: 2.16.0+ and 2.12.2+ (both carry the log4j2.enableJndi marker)

Expected scan output and triage workflow

Each policy run produces a JSON file at /tmp/log4shell_deep_scan.output.<hostname>.<epoch>.json containing a JSON array of records. Every record includes the hostname, the scan timestamp (scan_ts), the scanner version (scan_v), the search_root, and a result field of PASS, FAIL, or UNKNOWN. FAIL records carry a vulnerable_jar field with the absolute path of the top-level archive that contained the vulnerable nested Log4j. UNKNOWN records carry an unscanned_jar field for archives the script could not open. The matching .log file records find errors, permission denials, and corrupted archives – inspect the .log file when a known Log4j-bearing application is missing from the FAIL records.

Aggregate the output across the fleet by exporting the JSON files (or copying them via a follow-up Worklet) into a central store, then group findings by vulnerable_jar path. A single vendor product redistributed to 200 endpoints will show up across 200 host files with the same archive path, which collapses neatly to one remediation ticket. Records flagged FAIL require immediate action: a vendor patch, a Log4j 2.17+ in-place upgrade, or removal of the JndiLookup.class from the JAR with zip -q -d <jar> org/apache/logging/log4j/core/lookup/JndiLookup.class as a workaround when no vendor fix exists.

Compliance auditors, cyber insurance underwriters, and incident response retainers commonly ask for evidence that Log4Shell was actively hunted across the fleet, not just patched at the package layer. The per-endpoint JSON output plus a record of the policy schedule supports CIS Critical Security Control 7 (continuous vulnerability management) and NIST 800-53 RA-5 (vulnerability monitoring and scanning). Keep the output files for the retention window your audit program requires. The Worklet itself accumulates artifacts on each run: the hostname plus scan timestamp embedded in the output filename means rerunning produces a new pair of files without overwriting prior runs, so the artifact trail persists as long as /tmp/ is not purged on reboot.