Log4Shell / Log4J Detection

What the Log4Shell detection Worklet does

This Automox Worklet™ scans all fixed drives on Windows endpoints to detect Log4Shell and Log4j vulnerabilities in Java applications. The Worklet searches for JAR, WAR, and EAR files containing the vulnerable JndiLookup.class component that enables remote code execution attacks.

The Worklet reports all findings to the Automox console activity log with detailed file paths and vulnerability status. Results indicate whether Java applications contain unpatched Log4j versions (2.0-beta9 through 2.14.1) or have been updated to patched versions (2.16.0+ or 2.12.2+).

Why detect Log4Shell vulnerabilities on your endpoints

Organizations without Log4j visibility face critical exposure to CVE-2021-44228, a CVSS 10.0 vulnerability that allows unauthenticated remote code execution. Attackers can exploit unpatched Log4j libraries to gain complete control of affected endpoints without user interaction.

The Log4Shell zero-day, initially reported November 24, 2021, put hundreds of millions of endpoints at immediate risk. Java applications commonly bundle Log4j as a logging dependency, making it difficult to track which systems contain vulnerable code without systematic scanning.

Scanning fixed drives identifies hidden Log4j instances that may exist in third-party applications, custom software, or legacy systems. You gain accurate risk assessment data to prioritize patching efforts and meet compliance requirements for CVE-2021-44228, CVE-2021-45046, and related vulnerabilities.

How Log4Shell vulnerability detection works

1. Evaluation phase: The Worklet scans all fixed drives for Java archive files (JAR, WAR, EAR) and searches for the JndiLookup.class component within Log4j libraries. It checks version numbers to determine patch status and identifies files that match vulnerable Log4j versions 2.0-beta9 through 2.14.1.

2. Remediation phase: This is a detection-only Worklet with no remediation actions. The evaluation script reports all findings to the Automox activity log with detailed file paths and vulnerability status (PASS/FAIL) for manual remediation planning.

Log4Shell detection requirements

• Windows operating system (all supported versions)

• PowerShell execution permissions on target endpoints

• Read access to all fixed drives and Java application directories

• Sufficient scan time for environments with large numbers of Java applications or archive files

Expected vulnerability assessment results

After the Worklet completes, you will see detailed scan results in the Automox console activity log for each endpoint. Results show PASS status when no vulnerable Log4j instances are detected, or FAIL status with complete file paths listing all Java applications that contain unpatched JndiLookup classes.

FAIL results indicate applications that remain vulnerable to CVE-2021-44228 and CVE-2021-45046 exploitation. You can use these detailed file paths to prioritize patching efforts, update vulnerable applications to Log4j 2.16.0+ or 2.12.2+, or remove applications that cannot be patched from production endpoints.

How to validate log4shell / log4j detection changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for log4shell / log4j detection.

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 the evaluation and remediation scripts.

4. Validate remediation effects from script operations such as Add-Type, Where-Object, Select-Object, then rerun evaluation for compliance.

For technical validation, compare endpoint state to the Worklet evaluation logic and remediation flow for log4shell / log4j detection. This supports repeatable security workflows, faster change control review, and auditable compliance evidence.

Useful script references for this Worklet include evaluation operations such as the evaluation and remediation scripts and remediation operations such as Add-Type, Where-Object, Select-Object. Use these indicators to verify that endpoint changes match intended policy outcomes.