Log4Shell / Log4J Detection

What the Log4Shell deep scan does

This Automox Worklet™ walks every fixed drive on a Windows endpoint, opens every JAR, WAR, and EAR archive it finds, and looks inside for the JndiLookup.class component that powers the Log4Shell remote code execution chain. The detection logic is derived from the Arctic Wolf deep-scan tool and matches the patterns Java applications use to bundle Log4j as a transitive dependency.

When the scan finds JndiLookup.class inside an archive, it also inspects JndiManager.class for the log4j2.enableJndi mitigation string that Log4j 2.16.0 and 2.12.2 introduced. Archives that carry JndiLookup without the patched JndiManager are reported as vulnerable. Nested archives are unpacked recursively, so a Spring Boot fat JAR or a WAR with a bundled vendor JAR cannot hide the exposure.

Results land in the Automox console activity log in three states. A PASS line means no vulnerable archives were found. A FAIL block lists every vulnerable path with CVE-2021-44228 and CVE-2021-45046 references attached, and any unreadable archives are appended under a WARNING line. An UNKNOWN result fires when no vulnerable archives were found but at least one archive could not be opened. Common culprits are locked database JARs, files held by another process, and archives sitting in $Recycle.Bin – which the script skips by design when an open fails.

Why hunt Log4Shell across the fleet

CVE-2021-44228 is a CVSS 10.0 unauthenticated remote code execution flaw in Log4j 2.0-beta9 through 2.14.1. Two follow-on advisories kept the patch line moving for weeks: CVE-2021-45046 added an RCE path in 2.15.0 under non-default configuration, and CVE-2021-45105 added a denial of service in 2.16.0. The fixed builds are Log4j 2.17.1+ on Java 8, 2.12.4+ on Java 7, and 2.3.2+ on Java 6. CISA still lists Log4Shell on the Known Exploited Vulnerabilities catalog as an active exploitation entry.

Software bills of materials rarely cover the third-party JARs that ship inside vendor installers, build agents, and legacy WAR files, and SBOM tools that rely on package metadata routinely miss Log4j when it lives inside nested archives or shaded jars. That is where unpatched Log4j tends to survive. PCI-DSS 11.3.1 internal vulnerability scanning, HIPAA Security Rule 164.308(a)(1), and NIST 800-53 RA-5 all expect documented vulnerability discovery on every endpoint that processes regulated data. Pair this detection Worklet with a remediation Worklet to roll out a patched archive in a follow-up policy run.

How Log4Shell deep scanning works

1. Evaluation phase: The evaluation script is a single line, Exit 1, which forces the deep scan to execute on every policy cycle. This is by design – Log4j exposure changes whenever a new application is installed, a vendor pushes an update, or a developer drops a JAR onto a server. Running remediation each cycle keeps the inventory current rather than caching a stale PASS.

2. Remediation phase: The remediation script enumerates fixed drives with [System.IO.DriveInfo]::GetDrives() filtered to DriveType Fixed, recursively walks each root with Get-ChildItem -Force -Recurse -ErrorAction SilentlyContinue, and filters to files whose extension is .jar, .war, or .ear. Each archive is opened as a System.IO.FileStream and passed to a System.IO.Compression.ZipArchive reader. The script flags an archive as vulnerable when it contains JndiLookup.class and the matching JndiManager.class does not contain the log4j2.enableJndi string introduced in the patched releases. Nested .jar, .war, and .ear entries are recursed in place. Findings, unreadable paths, and the final PASS, FAIL, or UNKNOWN verdict are written to the Automox activity log. The Worklet is detection-only and does not delete, quarantine, or replace any archive.

Log4Shell deep scan requirements

• Windows 8.1, Windows 10, Windows 11, Windows Server 2012, Windows Server 2016, Windows Server 2019, or Windows Server 2022

• PowerShell 3.0 or later, with the .NET System.IO.Compression assembly available (the script loads it through Add-Type)

• SYSTEM-level read access to every fixed drive, including hidden directories under Program Files, ProgramData, application data folders, and developer build trees

• A maintenance window sized for the endpoint: a clean workstation typically completes in 5–15 minutes; a build server or file server with thousands of nested archives can run 30+ minutes

• Read access to archive contents – databases that hold .jar files open exclusively (Elasticsearch, some Atlassian products) will appear in the UNKNOWN list and need a service stop or follow-up snapshot scan

Expected Log4Shell scan results

Open the Automox activity log for the policy run and look for the Result line. Result: PASS means no archive on any fixed drive carries an unpatched JndiLookup.class. Result: FAIL is followed by a list of full file paths prefixed with `--` – for example, ` -- C:\Program Files\Vendor\lib\application.jar` – each of which contains JndiLookup.class without the patched JndiManager marker, plus a WARNING block listing any archives that could not be read. Result: UNKNOWN appears when no vulnerable archives were found but at least one archive could not be opened, and the unreadable paths are listed underneath.

Treat every FAIL path as a Log4Shell remediation ticket. For each vulnerable archive, identify the parent product and check the vendor advisory for a patched build (Log4j 2.17.1+ on Java 8 is the modern baseline). Then upgrade the vendor application, drop in a replacement Log4j JAR, or remove JndiLookup.class from the archive as a stopgap. After remediation, rerun the same Worklet against the affected endpoint. A PASS line in the activity log is your audit evidence that JndiLookup no longer ships on disk. For audit retention, export the activity log entries that contain Result: PASS, Result: FAIL, or Result: UNKNOWN. Store them alongside the policy run identifier so vulnerability scanners and assessors can reconcile against an endpoint-side record of truth.