Log4shell Deep Scan

What the Log4Shell deep scanner does

This Automox Worklet™ performs an exhaustive search of Linux filesystems for Java applications containing Log4j vulnerabilities (CVE-2021-44228 and CVE-2021-45046). The scanner, adapted from Arctic Wolf's open-source tool, recursively examines JAR, WAR, and EAR files to find JndiLookup.class, the source of the Log4Shell vulnerability.

The scan goes beyond surface-level file detection. It unpacks nested archives and checks for the presence of patches by looking for the log4j2.enableJndi string in JndiManager.class. Applications patched to Log4j 2.16+ or 2.12.2+ are correctly identified as safe.

Why perform a deep Log4Shell scan

The Log4Shell vulnerability (CVE-2021-44228) enables remote code execution on any system running vulnerable Log4j versions. Attackers exploited this vulnerability within hours of public disclosure, scanning the internet for exposed systems and delivering payloads that install ransomware, cryptominers, and persistent backdoors. Organizations that did not immediately identify and patch vulnerable Log4j instances suffered compromises that persisted for months.

Log4j libraries exist deep within Java application dependencies, embedded in third-party software, hidden in vendor products, and bundled inside complex application stacks. Traditional vulnerability scanners that only check package manifests miss Log4j JAR files embedded in application WARs, nested in ZIP archives, or copied to non-standard directories. You need comprehensive filesystem scanning to find every Log4j instance.

Software vendors took weeks or months to release patches for products that embedded vulnerable Log4j versions. Some vendors never patched legacy products, leaving you with unpatched vulnerabilities in business-critical applications. Before you can remediate, you must identify every system that contains Log4j to prioritize patching, apply workarounds, or isolate vulnerable systems.

Compliance auditors and cyber insurance providers require evidence that you scanned your environment for Log4Shell, documented vulnerable systems, and took appropriate remediation action. Organizations that cannot demonstrate due diligence face audit findings, insurance claims denials, and questions about their security program maturity.

How Log4Shell deep scanning works

1. Evaluation phase: Always triggers remediation (exit 1) to run the scan. The actual scanning logic is in the remediation script.

2. Remediation phase: Uses find to locate all JAR, WAR, and EAR files starting from /. For each archive, uses unzip to check for JndiLookup.class and JndiManager.class. Recursively extracts nested archives to temporary files for inspection. Generates /tmp/log4shell_deep_scan.output.*.json with results and a corresponding .log file for debugging.

Log4Shell scanner requirements

• Linux endpoints with unzip and mktemp commands available

• Root privileges for the Automox agent to access all filesystems

• Sufficient disk space in /tmp/ for temporary extraction of nested archives

• Scan may take several minutes on endpoints with many Java applications

• Compatible with workstations and servers

Expected scan output

The Worklet generates a comprehensive report listing every Log4j JAR file found on the endpoint. The report includes full file paths, SHA-256 hashes, file sizes, and discovery timestamps for each detected Log4j instance. This data feeds into your vulnerability management workflow and risk assessment processes.

The scan results appear in the Automox console output for this Worklet execution. You can export the results, aggregate data across multiple endpoints, and identify which systems require immediate remediation. The scan covers common installation directories, application folders, temporary directories, and user home directories.

You now have evidence showing whether each endpoint contains vulnerable Log4j versions. Systems with no detections are documented as clean. Systems with detections are flagged for remediation through vendor patches, workaround application, or isolation from the network depending on remediation options available for each application.

The scan data provides the detailed information security teams need to prioritize remediation work. Java applications with Log4j 2.15.0 or earlier require immediate attention. Applications with Log4j 2.16.0 or later are less critical but should still be updated. The report includes enough detail to distinguish between vulnerable and patched versions.

How to validate log4shell deep scan changes

1. Run this Worklet on a pilot Linux endpoint and review evaluation output for log4shell deep scan.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as exit.

4. Validate remediation effects from script operations such as else, log, printf, then rerun evaluation for compliance.