Search for requests that contain JNDI lookup patterns or obfuscated variants, especially in headers, URI paths, parameters and JSON bodies. Look for follow-on behaviour such as unusual outbound connections, unexpected LDAP or RMI lookups and application errors after the request. Treat repeated probes from the same source as active exploitation attempts.
What to look for in requests and payloads
Detection starts with matching the exploit string itself and the ways it is commonly obscured. Inspect headers, URI paths, query parameters, form fields and JSON bodies for JNDI lookup patterns, encoded delimiters and mixed-case or nested variants that still resolve to the same lookup behaviour. In practice, the signal is strongest when the pattern appears in places the application would normally treat as untrusted input, not just in one obvious field.
For web logs, that means preserving enough request context to search across all parsed fields rather than only the raw URL. Many successful detections come from correlating the suspicious token with request method, content type, user agent and the target endpoint, because exploit attempts often stand out as malformed or unexpected for the route being hit. Logging that flattens or truncates request detail will hide the exact lookup attempt you are trying to catch.
When you need a broader reference for tracking actively exploited issues, the CISA Known Exploited Vulnerabilities Catalog is the right place to confirm whether a flaw is being actively abused, while the NIST National Vulnerability Database helps anchor the CVE record and affected-product context.
How to separate probing from exploitation
A single suspicious request is often only a probe. The stronger indicator is follow-on behaviour that should not happen during normal request handling: outbound LDAP or RMI lookups, unexpected DNS resolution, strange HTTP callbacks, or application errors that occur immediately after the malformed input is processed. Those secondary events help distinguish a log line containing an exploit string from a request that actually reached a vulnerable code path.
Sequence matters. If the same source repeats the payload, varies the obfuscation, or fans out across many endpoints, the activity is more consistent with active exploitation than casual scanning. If several hosts show similar JNDI-shaped requests in a short time window, treat it as a campaign pattern and check whether the application tier, reverse proxy and egress logs all agree on timing. That cross-log correlation is often the difference between a useful alert and an ignored one.
If you are validating exposure at scale, NHIMG’s Vulnerability Management Guide is useful for turning suspicious detections into a prioritised response workflow, and the FIRST EPSS score can help decide how aggressively to hunt when a vulnerable component is present.
How to hunt for exploitation in the rest of the environment
Log review should not stop at the web tier. Once you have a suspicious request, check application logs, egress telemetry, DNS, proxy logs and endpoint or container events for evidence that the payload triggered an outbound lookup or secondary process creation. The most useful hunt question is not only “was the string present?” but “did the application attempt to resolve or fetch something it should never have contacted?”
Also look for operational side effects that appear shortly after the request, such as unusual error bursts, class-loading failures, service restarts or unexpected changes in outbound traffic shape. Those effects are not proof by themselves, but they strengthen the case that the input was processed rather than merely logged. The practical goal is to reconstruct the chain from inbound request to attempted lookup to any observable post-request behaviour.
For context on open-source component exposure and exploit-driven response, NHIMG’s Open Source Security Guide helps frame dependency risk, while the CISA Known Exploited Vulnerabilities Catalog remains the most authoritative place to confirm whether a JNDI-related issue is under active exploitation.
Risk and Threat Considerations
Log4Shell-style attempts matter because the observable request is often only the first stage of a much larger exploitation chain. A successful probe can be followed by remote code execution, outbound beaconing, credential theft or additional payload staging, so the real risk is not the string in the log but the possibility that the application interpreted it and initiated attacker-controlled network activity.
Failure mechanism: The attacker places a JNDI lookup or an obfuscated equivalent into a field that the application processes, and the vulnerable code path performs a remote lookup or related follow-on action that should never occur from untrusted input.
Impact: You may see only a brief request in web logs, while the real compromise signal appears in outbound connections, application faults, or later host activity. If the same source retries the payload or varies the encoding, assume the actor is testing defenses and treat the event as an active exploitation attempt until disproven.
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 SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Web-log detection depends on preserving and reviewing request evidence for exploit patterns. |
| Recommendation — Centralise and retain request logs so JNDI probes and follow-on behaviour are searchable. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | The answer relies on analysing logs and correlating suspicious request activity with follow-on events. |
| SI-4 — System Monitoring | Detection requires monitoring for malicious payloads and unexpected outbound behaviour after requests. | |
| Recommendation — Review audit records for suspicious request content and downstream lookup activity. Monitor web and egress telemetry for exploit strings, callbacks and anomalous resolution attempts. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | The question is about detecting exploit attempts in logs and using errors as supporting evidence. |
| Recommendation — Log security-relevant request data and errors needed to spot exploit attempts. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | JNDI exploitation attempts in web logs are indicative of public-facing application exploitation. |
| T1105 — Ingress Tool Transfer | Unexpected outbound connections after the request can indicate payload staging or retrieval. | |
| Recommendation — Map inbound probes and post-request effects to public-facing application exploitation hunting. Hunt for outbound retrieval and staging activity after suspicious web requests. | ||
Practitioner Guidance
What to verify: Make sure your search covers every request field that can carry user-controlled data, including headers and structured bodies, and that your logging preserves enough context to tie the input to the downstream response. If your web logs only show the URL, you will miss many attempts that arrive through headers or JSON payloads.
Decision rule: If you see the JNDI pattern plus any outbound lookup, callback, or immediate application error, escalate from detection to compromise assessment rather than treating it as a simple malformed request. If the pattern repeats from the same source, prioritise containment and hunting over further signature tuning.
Practitioner takeaway: The best detection is correlation, not string matching alone, because the decisive evidence is the transition from suspicious input to unexpected resolution or outbound behaviour.
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- How do you detect path traversal exploitation attempts in web server logs?
- How do you detect cross-site scripting attempts in web server logs?
- How do you detect server-side template injection attempts in web logs?
- How should security teams detect Log4Shell exploitation across web, endpoint, and network data sources?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org