Look for JNDI lookup patterns, obfuscated strings such as lower and upper transformations, and outbound traffic to known test or callback domains. Logging spikes in web, ALB, firewall, VPC, and cloud audit data can also reveal probing. Short-lived connections, unusual DNS queries, and payloads in headers or form fields are common indicators.
What the logs usually show before Log4j abuse becomes obvious
Exploitation attempts usually leave a pattern rather than a single signature. The most useful clues are suspicious lookup strings, encoded or fragmented payloads, and outbound requests that appear to test whether the target will resolve an attacker-controlled name. Correlate those application events with DNS, proxy, firewall, load balancer, and cloud audit records so you can separate noise from repeated probing.
One practical point is that the logging surface matters as much as the payload. Attackers often place the trigger in headers, form fields, user agents, or other fields that are logged automatically, so a clean application request can still become a malicious log event once it is written and processed.
For broader pattern validation, cross-check the behaviour against real-world exploitation patterns documented in 52 NHI Breaches Analysis, especially where initial access is followed by credential theft, lateral movement, or downstream abuse of exposed secrets.
Why these indicators matter operationally
Log4j exploitation attempts are valuable to defenders because they often create observable side effects even when the payload does not fully succeed. DNS lookups to strange domains, short-lived egress connections, and repeated test callbacks can show that an attacker is mapping exposure, measuring reachability, or trying alternate payloads until one lands. That makes the event stream useful for detection even before you see a confirmed compromise.
High-volume probes also tend to produce bursts in web and edge telemetry. A sudden spike in 4xx or 5xx responses, unusual request paths, or repeated hits across similar assets can indicate automated scanning rather than isolated user activity. When those signals line up with outbound lookup activity, the probability of exploitation attempts rises sharply.
For threat prioritisation, this kind of behaviour is most useful when paired with vulnerability context from the NIST National Vulnerability Database, active exploitation signals in the CISA Known Exploited Vulnerabilities Catalog, and likelihood scoring from FIRST EPSS.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Log4j probing is a public-facing exploit pattern against exposed services. |
| T1059 — Command and Scripting Interpreter | Successful Log4j exploitation often leads to command execution after initial access. | |
| T1046 — Network Service Discovery | Repeated testing and callback validation can indicate discovery of reachable targets. | |
| Recommendation — Map repeated probing to T1190 and prioritise exposed application paths for containment. Hunt for post-exploitation command execution after suspicious lookup-triggered events. Correlate callback-like traffic with discovery activity to identify active scanning. | ||
| CIS Controls v8 | 8 — Audit Log Management | Detecting Log4j attempts depends on collecting and correlating web, DNS, and egress logs. |
| 13 — Network Monitoring and Defense | Outbound callbacks and unusual DNS activity are network defence signals for exploitation attempts. | |
| 17 — Incident Response Management | Confirmed exploitation attempts require coordinated triage, containment, and evidence preservation. | |
| Recommendation — Centralize and correlate logs across application, network, and cloud telemetry sources. Alert on anomalous DNS and egress connections tied to suspicious application requests. Use incident response playbooks to preserve evidence and isolate affected hosts quickly. | ||
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | The answer relies on continuous observation of application, DNS, and network telemetry. |
| DE.AE — Anomalies and Events | Suspicious lookup strings, obfuscation, and callback traffic are anomalous events. | |
| RS.AN — Analysis | Investigators must analyse correlated logs to confirm whether activity is malicious. | |
| Recommendation — Continuously monitor application and network telemetry for exploitation indicators. Triage anomalous request patterns and outbound callbacks as potential exploitation. Analyze correlated logs to distinguish probing from confirmed compromise. | ||
Practitioner Guidance
What to verify: Confirm whether the suspected events are isolated scans or repeated attempts across multiple hosts, then check whether the same source IPs, domains, or payload variants recur in logs, DNS, and egress telemetry. If you see the same pattern across web, WAF, proxy, and cloud audit data, treat it as coordinated probing rather than benign chatter.
What to prioritise: Focus first on assets that both log untrusted input and can reach the internet from the runtime environment. Those are the systems most likely to generate useful detection signals and the systems most likely to be used for callback validation if an exploit attempt succeeds.
Common mistake: Looking only for the textbook lookup string and missing the obfuscation layer. In practice, attackers vary encoding, split tokens across fields, or hide the trigger inside headers, so detections need to match the behaviour pattern, not just one literal string.
Practitioner takeaway: The strongest signal is correlation, not a single log line, so treat repeated payload variants plus outbound resolution or callback traffic as the threshold for active investigation.
Related resources from NHI Mgmt Group
- What are the early signs that AWS IAM role exploitation is already happening?
- What are the signs that CVE-style gateway exploitation is happening in practice?
- What are the signs that an OpenSSH server may be exposed to active exploitation attempts?
- What are the signs that regreSSHion exploitation attempts may be underway?
