Zero-Day-Response: Log4Shell bei einem regulierten Unternehmen

Die Ausgangslage

Mit der Veröffentlichung von Log4Shell im Dezember 2021 war innerhalb von Stunden weltweit massenhafte Ausnutzung zu beobachten. Für den Kunden — ein reguliertes Unternehmen — bestand die zentrale Frage nicht darin, ob die Schwachstelle relevant ist, sondern wo genau die betroffene Log4j-Komponente in einer gewachsenen Applikations- und Dienstleisterlandschaft im Einsatz ist.

Die Herausforderung

Log4j steckt tief in Java-Applikationen, Appliances und Drittanbieter-Produkten — oft ohne Eintrag in einer Software-Stückliste. Klassische Scans lieferten kein vollständiges Bild, während parallel bereits Exploit-Versuche gegen exponierte Systeme liefen. Es musste gleichzeitig inventarisiert, detektiert und eingedämmt werden.

Das Vorgehen

Sofortiger Incident-Response-Einsatz. Das CyStrat-Team übernahm die technische Einsatzleitung und arbeitete direkt mit den Applikations- und Infrastrukturteams des Kunden zusammen.

Auswertung der eingesetzten Produkte. Wir haben systematisch ermittelt, welche Produkte und Komponenten betroffene Log4j-Versionen enthalten und wo diese produktiv im Einsatz sind — sowohl über SIEM-Auswertungen (Prozess-, Applikations- und Netzwerktelemetrie) als auch über eigens entwickelte Ad-hoc-Analyse-Skripte auf den Systemen.

Notfall-Use-Cases im SIEM. Innerhalb kurzer Zeit wurden dedizierte Detektions-Use-Cases für Log4Shell-Ausnutzungsmuster (JNDI-Callbacks, verdächtige Outbound-Verbindungen, Child-Prozesse von Java-Diensten) ausgerollt. Über diese Use Cases wurden verschiedene betroffene Systeme identifiziert.

Containment in unter fünf Minuten. Bei Alarmierung wurde die Exploit-Kette in weniger als fünf Minuten unterbunden — durch Isolation der betroffenen Systeme, Blockieren der Callback-Ziele und Abschalten der ausnutzbaren Pfade, bis Patches oder Mitigationen greifen konnten. Automatisierung lieferte die Vorarbeit; die Entscheidung über jede Containment-Maßnahme traf ein Analyst gemeinsam mit dem Kunden.

Ad-hoc-Blocking über eigene Threat Intelligence. Aus den beobachteten Angriffsversuchen gewonnene Indikatoren (Callback-Hosts, Payload-Server, Scanner-Infrastruktur) flossen unmittelbar in unsere eigene Threat Intelligence und von dort in Blocklisten und Detektionsregeln — inklusive Anreicherung aus weiteren Quellen.

Kontinuierliche Überwachung in den Folgewochen. Log4Shell war kein Ereignis eines Tages: In den folgenden Wochen liefen fortlaufendes Monitoring, Nachscans und weitere vergleichbare Ad-hoc-Response-Maßnahmen bei neu veröffentlichten Folge-CVEs und neu entdeckten betroffenen Komponenten.

Das Ergebnis

• Alle beobachteten Angriffsversuche wurden erfolgreich abgewehrt bzw. die Angriffskette bereits auf den „Patient 0"-Systemen unterbrochen.
• Kein Weitertragen in die Umgebung — es gab in keinem Fall einen „Patient 2".
• Kein Abfluss von Daten; die regulatorische Nachweisführung war durch dokumentierte Timeline und Evidenzen abgedeckt.
• Vollständiges Bild über die betroffenen Produkte und Systeme als Basis für die anschließende geordnete Patch-Welle.

Genau dieses Muster ist heute Teil unseres Managed Vulnerability Management: Exposure-Bewertung innerhalb von Stunden, betroffene Assets über den gesamten Bestand identifizieren, Übergangs-Mitigationen setzen und die Behebung verifizieren.

Hinweis: Die Referenz ist zum Schutz des Kunden anonymisiert dargestellt.