Threat Hunting Exercise: Analyzing IDS Log4j JNDI Exploitation Signature Dataset

This hunt uses a simulated network intrusion detection dataset (ids_log4j_signature_2022-10-26T101500.json) capturing T1190: Exploit Public-Facing Application, correlating a network-layer IDS signature hit for Log4j JNDI exploitation attempts against a broader, internet-wide reconnaissance/scanning campaign versus a targeted, successful exploitation attempt against the organization's infrastructure.

Step 1: Hypothesis Formation

Hypothesis: An IDS signature for ET EXPLOIT Log4j RCE Attempt or equivalent fires against an internal application, and the response traffic or subsequent internal-host behavior determines whether this represents a successful compromise (application vulnerable, callback occurred) versus benign/failed mass-internet scanning noise (extremely common post-CVE-2021-44228 disclosure). Indicators:

• IDS alert for JNDI/LDAP lookup pattern in inbound HTTP traffic, correlated with whether the destination application uses a vulnerable Log4j version.
• Absence or presence of outbound LDAP/RMI traffic from the targeted internal host within seconds of the alert (the definitive success/failure differentiator).
• Alert source IP behavior: single opportunistic probe (mass scanner) versus sustained, targeted, multi-technique activity against the same destination.
• Whether the targeted application/host appears in vulnerability-scan results as running an unpatched Log4j version.

Null Hypothesis: The signature fired against a patched application (Log4j upgraded or mitigation applied) or is a false positive from unrelated traffic containing benign ${ characters, and no exploitation occurred. Invalidate by confirming no outbound JNDI callback occurred and the application's patch status.

Rationale: Given the massive scale of internet-wide Log4j scanning that followed public disclosure, alert-fatigue is a real risk; efficiently triaging IDS hits by correlating with actual outbound callback behavior - rather than manually reviewing every hit - is essential to focus analyst time on genuine compromises.

Step 2: Data Sources and Scope

• Sources: IDS/IPS alert logs (Suricata/Snort ET ruleset); internal application vulnerability-scan results; outbound firewall/network flow logs for the targeted host.
• Scope: ~2022-10-26T10:15:00-11:00:00 UTC; IDS alerts against three internal application hosts; correlated with outbound flow logs.
• SIEM Queries (Splunk/ELK):
• index=ids signature="ET EXPLOIT Log4j*" | stats count by dest_ip, src_ip
• Callback correlation: index=netflow src_ip IN (alerted_dest_ips) dest_port IN (389,1389,1099,88) earliest=alert_time latest=alert_time+30s
• Patch status: index=vuln_scan host IN (alerted_dest_ips) cve="CVE-2021-44228"

Step 3: Key Findings

Parsed events (5 shown) confirm the IDS logged 214 Log4j JNDI signature hits across three hosts over 45 minutes, but only one - srv-legacy-crm (confirmed still running the vulnerable Log4j version) - showed a corresponding outbound LDAP callback, confirming a single successful exploitation among widespread scanning noise.

Validation:

• Timeline: mass scanning noise across three hosts, with only the unpatched host (srv-legacy-crm) producing an outbound callback and subsequent class-fetch - clearly distinguishing the single genuine compromise from 213 failed/benign hits.
• False Positives: srv-api-19 and srv-web-portal show no callback traffic and are confirmed patched in the vulnerability scan, correctly ruling out compromise despite the IDS alert firing.
• Correlation: patch status, alert-to-callback timing correlation, and second-stage payload retrieval jointly confirm exactly one successful exploitation requiring incident response, while efficiently triaging out 213 benign alerts.

Step 4: Recommendations & Next Steps

• Immediate Response: Isolate srv-legacy-crm immediately, treat as a confirmed compromise (full incident response, not just patching), patch/upgrade Log4j across all three hosts regardless of individual exploitation status, and block 194.61.55.71 at the perimeter.
• Detection: Sigma-style rule: title: Log4j IDS Alert with Confirmed Outbound Callback → selection1: signature="ET EXPLOIT Log4j*" selection2: dest_port IN (389,1389,1099) src_ip=selection1.dest_ip within 30s → condition: selection1 and selection2 (this correlated rule, not the raw IDS signature alone, should drive P1 incident creation).
• Pro Tip: Build an automated correlation pipeline that suppresses standalone Log4j IDS alerts to informational/low priority, but auto-escalates to P1 the moment a corresponding outbound LDAP/RMI/DNS callback is observed from the same host within a short window - this single correlation transforms an unmanageable flood of scanning-noise alerts into a small number of high-confidence, actionable incidents.

Hypothesis confirmed - of 214 Log4j exploitation signature hits across three internet-facing applications, only the one unpatched legacy CRM server produced a genuine outbound JNDI callback and second-stage payload fetch, confirming a single successful remote code execution amid widespread internet scanning noise!