Hunting for log4shell Compromises

### Overview In this talk, Jose Andrea, a senior incident handler at SIA, shares real-world experiences from compromise assessments conducted during December 2021 immediately following the disclosure of the Log4Shell vulnerability. The objective was to determine whether two critical operator client organizations had suffered compromises prior to or around the public disclosure on December 10, 2021.

### Key Topics - **Context & Operational Challenges:** Log4Shell surfaced right before the holidays with an initial CVSS score of 10.0, during the Omicron wave when teams were short-staffed. Three patches were required across less than two weeks, leaving defenses strained and threat detection teams overloaded. - **Compromise Assessment vs. Threat Hunting:** Andrea explains that while threat hunting proactively pursues TTPs with standard tools, a compromise assessment operates more like unplanned incident response. It deploys supplementary tools (such as provisioning analysis workstations), searches for unknown compromises, and delivers rapid (daily or twice-daily) findings back to local teams. - **Attack Lifecycle & Investigation Focus:** The attack generally follows three phases: an initial malicious request to the Java application (e.g., in user-agent headers), an outbound JNDI lookup (such as LDAP resolution) retrieving a malicious payload/class, and callback communications. The response team focused heavily on filtering for second-stage outbound connections to avoid having to run full digital forensics on every scanned system.

### Technical Details & Case Studies The hunting methodology relied on an iterative approach: identifying log sources, deploying baseline detection strings (e.g., `${jndi:ldap`), harvesting IoCs, refining regular expressions (leveraging Floran Roth’s public regex composer/rules), and re-evaluating.

- **Organization 1 (Healthcare Operator in Spain):** - *Architecture & Visibility:* A single-country footprint with simple, well-maintained network architecture and two years of centralized log backups. However, it had no EDR, no true SIEM, and no remote access, requiring the team to deploy on-site. - *Findings & Methods:* Web server logs served as the primary source, correlated manually against DMZ firewall logs for outgoing connections. Thousands of scan attempts were detected (almost all returning 3xx, 4xx, or 5xx codes, with only around 50 returning 200 OK), and no secondary Log4Shell exploitation activity was discovered.

- **Organization 2 (Multinational Energy Operator):** - *Architecture & Visibility:* Highly complex, distributed international network with shadow IT, partitioned business units, and complex chains of command. However, it boasted high cybersecurity maturity, dedicated SIEM, existing threat-hunting workflows, and widespread EDR deployment (CrowdStrike). - *Findings & Methods:* Dedicated workstations and Elasticsearch were provisioned to query logs. The team used EDR telemetry to hunt for suspicious commands and outbound connections originating from Java parent processes, while leveraging Palo Alto Panorama to trace egress traffic across multi-country firewalls. Although other malicious activity was uncovered, no successful Log4Shell second-stage compromise was found.

### Takeaways Andrea emphasizes that while perimeter-facing systems were patched quickly, Log4Shell will persist in legacy environments, unpatched internal software, and as a vector for lateral movement. Furthermore, the vulnerability highlights that untrusted JNDI lookups (a topic studied since 2016 by researchers Alvaro Muñoz and Alexander Mirosh) represent a broader vector across Java libraries beyond Log4j alone.