Log4Shell Investigation Playbook — Evidence-Based Triage

Answer first

Triage Log4Shell in five steps: Confirm the CVE → Find affected systems → Collect indicators → Validate exploitation → Plan fix.

1. What Log4Shell is and why it matters

CVE-2021-44228 is a remote code execution vulnerability in Apache Log4j 2’s JNDI message-lookup feature. An attacker who can control any string logged by an affected version can trigger an outbound JNDI lookup and, when conditions allow, remote code execution. Because Log4j is embedded in thousands of products, the blast radius is broad — this is why the vulnerability has its own CISA advisory and exploitation wave.

2. Affected systems and versions

Start from your asset inventory and map it to known-affected versions:

• Log4j 2.0-beta9 through 2.14.1 (and several 2.15.x builds) are affected by CVE-2021-44228.
• CVE-2021-45046 affects Log4j 2.x prior to 2.16.0 and is scored separately.
• Products embedding Log4j (application servers, security appliances, SDKs) are affected even when you did not install Log4j directly.

Use the CVE Lookup for the severity, CVSS vector, affected products and CISA KEV status of each CVE before prioritising.

3. Indicators to collect

When hunting for exploitation, collect — do not delete — these signals:

• Log lines containing ${jndi:ldap://, ${jndi:rmi://, ${jndi:dns:// or base64-encoded JNDI patterns.
• Outbound connections from application hosts to unknown LDAP/RMI/HTTP hosts on unusual ports.
• HTTP headers or parameters that echo user input into logs (User-Agent, Referer, X-Forwarded-For, form fields).
• Command fragments observed in exec() traces or process command lines on the host.
• IOCs published by vendors and the CISA/NCSC advisories: attacker IPs, domains looked up via JNDI, and payload hashes.

Normalise and defang every indicator with IOC Lookup and check the normalised value in OpenTrojan intelligence. Record the raw value before defanging.

4. Investigation workflow

1. Confirm the record: read the CVE details and the vendor advisory for your exact product and version.
2. Scope: list every host and service running an affected Log4j, including embedded copies.
3. Collect: pull logs and packet captures from the task window you are investigating (do not modify files first).
4. Validate: distinguish a benign scan / honeypot interaction from real exploitation by correlating the JNDI lookup with a subsequent outbound request or process execution.
5. Contain: isolate confirmed hosts, then apply the vendor patch or the official mitigation before wider remediation.

Start a new investigation to track scope, evidence and remediation per host — record every collector finding with its source and timestamp.

5. What to collect (evidence discipline)

For every finding, record: host, service, Log4j version, exact log line (defanged), observed timestamp, source of the record, and the analyst who confirmed it. Keep the raw logs immutable for later validation.

6. How to validate

A confirmed signal means an inbound JNDI lookup from attacker-controlled input and a matching outbound interaction, or a command execution marker. A single log template match is suspected, not confirmed — attackers and scanners both trigger lookups. Never treat a tool hit as a verdict by itself.

7. Detection and mitigation

• Detection: search the indicators above, plus web-access logs for JNDI strings, plus egress connections to unusual LDAP/HTTP destinations.
• Mitigation: upgrade to the vendor-fixed Log4j version, enable the official mitigations for versions you cannot upgrade, block egress to untrusted LDAP/RMI, and apply the CISA required action if the CVE is on KEV.

8. Tools that help

• CVE Lookup — severity, CVSS, affected products and KEV status.
• IOC Lookup — normalise, defang and check indicators against OpenTrojan intelligence.
• Investigation Workspace — track scope and remediation.

9. References

• NVD — CVE-2021-44228
• CISA — Understanding and mitigating Log4Shell
• Apache Log4j security page