
Eine umfassende Simulation der Incident-Response eines Security Operations Centre (SOC), die die Erkennung, Priorisierung, Analyse und Eindämmung der Spring4Shell-Sicherheitslücke (CVE-2022-22965) demonstriert.

Eine praktische Simulation eines Security Operations Centre (SOC), bei der ich die Rolle eines Information Security Analyst übernommen habe und auf einen aktiven Spring4Shell-Exploit-Versuch reagiert habe. Dieses Repository dokumentiert den vollständigen Incident-Response-Lebenszyklus – von der ersten Erkennung über die Analyse bis zur Eindämmung.
Hinweis: Dieses Projekt wurde im Rahmen einer Cybersecurity-Jobsimulation auf Forage zu Bildungszwecken abgeschlossen. Die gesamte Analyse wurde in einer kontrollierten, simulierten Umgebung durchgeführt.
Spring4Shell ist eine kritische Schwachstelle zur Remote-Codeausführung im Spring Framework. Sie ermöglicht Angreifern, den Parameterbinding-Mechanismus auszunutzen, um unbefugten Zugriff auf Java-Class-Eigenschaften zu erhalten, was zu einer vollständigen Remote-Codeausführung führen kann.
Ziel: Firewall-Protokolle analysieren, um kompromittierte Infrastruktur zu identifizieren, den Schweregrad der Bedrohung zu bewerten und das entsprechende Team zu benachrichtigen.
Die Überprüfung der Firewall-Protokolle ergab ein Muster verdächtiger HTTP/1.1-POST-Anfragen, die auf /tomcatwar.jsp abzielten und alle class.module.classLoader-Parameterketten enthielten – das Signaturmerkmal einer Spring4Shell-Ausnutzung.

| Feld | Detail |
|---|---|
| Betroffene Infrastruktur | NBN-Kritische Dienste |
| Prioritätsstufe | P1 — Kritisch |
| Angriffsvektor | CVE-2022-22965 (Spring4Shell) |
| Aktueller Status | Dienst ausgefallen; Funktionalität beeinträchtigt |
| Erkennungszeitstempel | 2022-03-20T03:21:00Z |
Nach Bestätigung der Bedrohung habe ich eine Incident-Benachrichtigung an das NBN-Team verfasst und gesendet, mit einer präzisen Zusammenfassung der Situation, der betroffenen Systeme und der erforderlichen Sofortmaßnahmen.

Ziel: Eine tiefergehende Analyse der Angriffsmuster durchführen, die Ausnutzungsmechanismen verstehen und Firewall-Regeln entwickeln, um die Bedrohung einzudämmen.
Aus der Analyse der POST-Anfragenstruktur in den Firewall-Protokollen:
/tomcatwar.jspclass.module.classLoader.resources.context.parent.pipeline.first.patternEs wurde ein mehrschichtiger Ansatz verwendet, um den Angriff in jeder Phase zu blockieren:
| Regel | Aktion | Begründung |
|---|---|---|
Anfragen an *.jsp-Endpunkte blockieren | DROP | Verhindert Webshell-Zugriff |
POST-Anfragen mit class.module.classLoader.resources.context.parent.pipeline.first blockieren | DROP | Blockiert direkt den Ausnutzungsmechanismus |
Schreiboperationen auf webapps/ROOT/tomcatwar*.jsp blockieren | DENY | Stoppt die Webshell-Persistenz |
Nach der Definition der Eindämmungsstrategie habe ich die erforderlichen Firewall-Regeln mit vollständigem technischem Kontext des laufenden Angriffs an das Netzwerkteam kommuniziert.

class.module.classLoader-Parameterketten in HTTP-POST-Daten vorhanden/tomcatwar.jsp abzielenpipeline.first.pattern-Eigenschaften