Zero-day response: Log4Shell at a regulated company

The situation

When Log4Shell was published in December 2021, mass exploitation was visible worldwide within hours. For this regulated client the question was never whether the vulnerability mattered, but exactly where the affected Log4j component was in use across a grown application and third-party landscape.

The challenge

Log4j sits deep inside Java applications, appliances and vendor products — frequently without any entry in a software bill of materials. Conventional scans did not give the full picture, while exploit attempts were already hitting internet-facing systems. Inventory, detection and containment had to happen at the same time.

The approach

Immediate incident response engagement. The CyStrat team took technical command and worked directly with the client's application and infrastructure teams.

Analysis of the products in use. We systematically determined which products and components shipped affected Log4j versions and where they were running in production — both through SIEM analytics (process, application and network telemetry) and purpose-built ad-hoc analysis scripts executed on the systems.

Emergency use cases in the SIEM. Dedicated detection use cases for Log4Shell exploitation patterns (JNDI callbacks, suspicious outbound connections, child processes spawned by Java services) were deployed within a short time. Those use cases surfaced several affected systems.

Containment in under five minutes. On alert, the exploit chain was broken in less than five minutes — isolating affected systems, blocking callback destinations and shutting down exploitable paths until patches or mitigations were available. Automation did the groundwork; an analyst decided on every containment action together with the client.

Ad-hoc blocking from our own threat intelligence. Indicators harvested from observed attack attempts (callback hosts, payload servers, scanner infrastructure) fed straight into our own threat intelligence and from there into blocklists and detection rules, enriched with additional sources.

Continuous monitoring in the following weeks. Log4Shell was not a one-day event: the weeks after brought continuous monitoring, re-scanning and further comparable ad-hoc response actions for follow-up CVEs and newly discovered affected components.

The outcome

• Every observed attack attempt was defended, with the kill chain broken on the "patient 0" systems themselves.
• No lateral spread into the environment — there was never a "patient 2".
• No data exfiltration; regulatory evidence was covered by a documented timeline and artefacts.
• A complete picture of affected products and systems as the basis for the orderly patch wave that followed.

That exact pattern is now part of our managed vulnerability management: exposure assessment within hours, identification of affected assets across the estate, interim mitigations and verified remediation.

Note: this reference is presented anonymised to protect the client.