Security teams detect Log4j injection by searching for suspicious lookup patterns, unexpected outbound callbacks, and exploit attempts in application and proxy logs. Prioritise internet-facing systems, identify where vulnerable Log4j versions are in use, and correlate application errors with anomalous requests. Also review egress filtering, because outbound reachability can reveal successful probing.
What Log4Shell detection should look for
Effective detection starts with the exploit shape, not just the vulnerable library. Log4Shell attempts often leave a trail in application, reverse proxy, and WAF logs, including lookup syntax, unusual header values, and requests that trigger unexpected class loading or name resolution. Search broadly across web tiers, middleware, and any service that parses user-controlled text.
The highest-signal detections usually combine pattern matching with behaviour. A single lookup string can be noisy, but a request followed by an outbound DNS, LDAP, or HTTP callback from the same host is much stronger evidence of probing or successful execution. That is why defenders should correlate request logs with egress telemetry and DNS activity, not treat them as separate problems.
For application-focused detection patterns, the Web Application Attacks Guide is a useful reference because Log4Shell sits in the broader class of web injection and payload smuggling techniques that defenders often find first in edge logs and request traces.
Where teams should concentrate their search
Prioritise systems that are internet-facing, process untrusted input, or sit in front of many downstream applications. Public endpoints, authentication services, upload handlers, API gateways, and logging-heavy services tend to surface the earliest exploitation attempts because they are easy to discover and often receive attacker spray at scale.
It also helps to inventory where Log4j is actually deployed, because detection effort should follow exposure. If teams do not know which applications bundle the library, they may miss the systems most likely to produce valid indicators, especially older services, vendor appliances, or long-lived internal apps that are rarely rebuilt.
From a software supply-chain perspective, the Open Source Security Guide supports this search by helping teams trace vulnerable open-source components, identify dependency exposure, and connect alerting to the actual software inventory.
How to confirm suspected exploitation without overcalling noise
Use a layered approach. First, look for known exploit strings or lookup variations in HTTP parameters, headers, and body content. Then confirm whether the target host made an outbound lookup or connection that it normally would not make. Finally, correlate the timing with application errors, unexpected JVM behaviour, or process anomalies on the same system.
False positives are common when defenders only match a string. Attackers often vary encodings, nested lookups, and delivery paths, while some scanners generate benign-looking callbacks that never reach code execution. The more reliable question is whether the request pattern, server behaviour, and outbound reachability line up in the same event window.
For baseline app-layer control context, the OWASP Top 10 is a practical external reference for understanding why injection-style issues frequently surface through untrusted input handling and weak validation boundaries.
Risk and Threat Considerations
Log4Shell is dangerous because detection can lag behind exposure. Attackers often probe at internet scale, and a successful callback may indicate more than an attempted exploit, it can also reveal that the target can reach external services, which expands the chance of follow-on payload delivery or post-exploitation activity.
Failure mechanism: The exploit often succeeds through ordinary logging or request parsing paths, so defenders can miss it if they only monitor obvious application errors and do not watch for unusual outbound resolution, child process behaviour, or follow-on requests from the same host.
Impact: A missed event can leave a foothold uninvestigated, especially when the exploit is used for reconnaissance first and payload delivery later. Systems with broad egress access and weak log retention are hardest to validate after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Log4Shell is detected through exploit attempts against exposed apps and their logs. |
| T1041 — Exfiltration Over C2 Channel | Outbound callbacks and unusual external connections can indicate post-exploit activity. | |
| Recommendation — Correlate public-facing exploit traffic with host and network telemetry to spot active exploitation. Monitor unexpected outbound connections for callback behaviour following suspicious requests. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on searching application, proxy, DNS, and egress logs for exploit evidence. |
| Recommendation — Centralise and retain logs needed to search for exploit strings and correlated callback activity. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | The answer relies on network and egress monitoring to identify exploit callbacks. |
| Recommendation — Monitor network and egress activity for unusual resolution or outbound connections from targeted hosts. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | Log4Shell detection depends on log coverage and error correlation across the app path. |
| Recommendation — Instrument application logging so suspicious input and errors can be correlated during incident review. | ||
Practitioner Guidance
What to verify: Confirm that detection content covers multiple lookup variants, not just one canonical pattern, and that it is deployed across WAF, proxy, application, DNS, and egress logs. A detector that only watches one log source will miss many real attempts.
Decision rule: If you see a suspicious lookup plus an outbound callback from the same host, treat it as a high-priority investigation even before you know whether code execution occurred. If you only see the lookup string with no supporting behaviour, treat it as a probe and continue hunting across adjacent systems.
What practitioners underestimate: Egress filtering is not only a containment control, it is also a detection signal. If a server should never make arbitrary outbound requests, a sudden callback can be the fastest clue that the exploit path was exercised.
Practitioner takeaway: The best Log4Shell detection programs combine string hunting with behavioural correlation, because exploit text alone is weak evidence while request plus callback patterns are much stronger indicators of real exposure.