Einleitung

Kritische Schwachstellen in PHP stellen Security Operations Center (SOC) vor besondere Herausforderungen. Insbesondere dann, wenn betroffene Webanwendungen außerhalb der eigenen Infrastruktur betrieben werden und keine direkte Überwachung der Webserver möglich ist.

Mit den unter der Bezeichnung PHP2Shell diskutierten Schwachstellen CVE-2026-109618 und CVE-2026-109619 rückt diese Problematik erneut in den Fokus. Beide Schwachstellen werden mit einer möglichen unauthentifizierten Remote Code Execution (RCE) in Verbindung gebracht und im vorliegenden Fall mit einem CVSS-Wert von 9,2 beschrieben.

Als korrigierte PHP-Versionen werden folgende Releases genannt:

PHP-Zweig	Genannte korrigierte Version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Die Angaben zu CVEs, Ausnutzung und Patchständen stammen aus der zugrunde liegenden technischen Diskussion und sollten vor einer produktiven Veröffentlichung anhand der offiziellen PHP-Sicherheitsmeldungen überprüft werden.

Für Wazuh-Administratoren ergeben sich daraus mehrere Fragen: Wie lassen sich mögliche Exploit-Versuche erkennen? Welche Logquellen sind tatsächlich geeignet? Und was kann ein SOC leisten, wenn es ausschließlich Syslog-Daten von Firewalls und Endpoint-Security-Produkten erhält?

Dieser Artikel zeigt, wie sich PHP2Shell-bezogene Erkennungsmechanismen mit Wazuh aufbauen lassen, welche Rolle Apache- und PHP-Logs spielen und wie externe Hosting-Umgebungen sinnvoll in das Schwachstellen- und Detection-Management integriert werden können.

Ausgangslage / Problemstellung

Betrachten wir eine typische Managed-SOC-Umgebung mit Wazuh 4.14.9.

Das SOC überwacht die IT-Infrastruktur eines Kunden, verfügt jedoch über keine Wazuh-Agenten auf den überwachten Systemen.

Stattdessen werden Sicherheitsereignisse ausschließlich über Syslog oder entsprechende Logweiterleitungen an Wazuh übertragen.

Die vorhandenen Datenquellen umfassen:

• Microsoft 365 für Cloud- und Identitätsereignisse
• Palo Alto Networks Firewalls für Netzwerk- und Bedrohungsereignisse
• SentinelOne für Endpoint-Detection-and-Response-Ereignisse

Die öffentlich erreichbare Unternehmenswebsite wird bei einem externen Hosting-Anbieter betrieben.

Das SOC hat weder administrativen Zugriff auf den Webserver noch erhält es Apache-, PHP-, WAF- oder Betriebssystemlogs des Hosters.

Vereinfachte Überwachungsarchitektur

Microsoft 365Cloud-Events

Palo AltoFirewall-Logs

SentinelOneEDR-Alerts

Wazuh Manager 4.14.9Syslog-Ingestion, Decoder, Rules, Alerts

Externer PHP-Webserver

Apache / PHP / Hosting-Provider

Keine Webserver- oder PHP-Logs verfügbar

Die vorhandenen Sicherheitsdatenquellen liefern keine automatische Sichtbarkeit auf Systeme außerhalb ihrer jeweiligen Überwachungsbereiche.

Das zentrale Problem: Fehlende Telemetrie

Ein SIEM kann nur Ereignisse auswerten, die tatsächlich erfasst und übertragen werden.

Auch umfangreiche Detection Rules können fehlende Datenquellen nicht ersetzen.

Bei einer PHP-Schwachstelle ist das besonders relevant, da viele aussagekräftige Indikatoren direkt auf dem Webserver entstehen:

• Ungewöhnliche HTTP-Anfragen
• Fehler während der PHP-Initialisierung
• Auffällige PHP-Prozessaktivitäten
• Neue Shell-Prozesse mit einem Webserverprozess als Parent
• Veränderungen an Webdateien
• Verdächtige ausgehende Netzwerkverbindungen

Ohne entsprechende Telemetrie kann Wazuh weder die Ausnutzung zuverlässig erkennen noch ausschließen.

Technische Analyse

1. PHP2Shell und die Bedeutung der PHP-Fehlermeldungen

Die diskutierten Schwachstellen betreffen die PHP-Laufzeitumgebung selbst.

Für die Angriffserkennung ist daher wichtig, nicht ausschließlich nach verdächtigen PHP-Skripten oder Webshell-Dateien zu suchen.

Ein relevanter Hinweis aus der technischen Analyse ist folgende Fehlermeldung:

PHP Fatal error: Allowed memory size of ... bytes
exhausted (tried to allocate ... bytes)
in Unknown on line 0

Diese Meldung zeigt zunächst lediglich, dass PHP während der Verarbeitung eine Speichergrenze erreicht hat.

Der Bestandteil

in Unknown on line 0

ist besonders interessant, da er auf einen Fehler außerhalb eines konkret zugeordneten PHP-Skriptkontexts hinweisen kann.

Im Zusammenhang mit CVE-2026-109618 wurde dieses Muster als möglicher Erkennungsindikator diskutiert.

Wichtig: Die Meldung ist kein eindeutiger Nachweis für PHP2Shell.

Sie kann auch bei anderen PHP-Speicherproblemen auftreten. Ebenso muss nicht jeder Exploit-Versuch eine solche Fehlermeldung erzeugen.

Insbesondere für CVE-2026-109619 ist nicht davon auszugehen, dass dieses Logmuster zuverlässig auftritt.

Eine Erkennungsregel sollte deshalb als Indikator für eine Untersuchung und nicht als bestätigter Exploit-Treffer behandelt werden.

2. Warum bestehende Wazuh-Regeln möglicherweise nicht ausreichen

Wazuh bringt bereits Decoder und Regeln für verschiedene Webserver-Logformate mit.

Diese erkennen beispielsweise HTTP-Fehler, verdächtige Zugriffsmuster oder bekannte Angriffstechniken.

Eine PHP-spezifische Schwachstelle wird dadurch jedoch nicht automatisch abgedeckt.

Für die betrachtete Wazuh-Version 4.14.9 wurde berichtet, dass die vorhandenen Standardregeln bei den untersuchten Apache-2.4-Logs keine spezifischen PHP2Shell-Alerts erzeugten.

Daraus ergeben sich zwei Anforderungen:

1. Die relevanten Logdaten müssen Wazuh überhaupt erreichen.
2. Die Logdaten müssen durch geeignete Decoder und Regeln ausgewertet werden.

Ein vorhandener Apache-Decoder garantiert noch keine Schwachstellenerkennung.

3. Welche vorhandenen Sicherheitsprodukte helfen tatsächlich?

Datenquelle	Möglicher Beitrag	Einschränkung
Microsoft 365	Identitäts- und Cloud-Folgeaktivitäten	Keine direkte Sicht auf PHP-Exploits
Palo Alto Firewall	Signaturtreffer, HTTP-Anomalien, verdächtige Verbindungen	Nur für tatsächlich durchlaufenden Netzwerkverkehr
SentinelOne	Prozessstarts, Shell-Ausführung, verdächtiges Verhalten	Agent beziehungsweise entsprechende Telemetrie auf dem betroffenen Host erforderlich
Apache Access Logs	Auffällige Requests, HTTP-Statuscodes, wiederholte Fehlversuche	Müssen vom Hoster bereitgestellt werden
PHP Error Logs	PHP-Laufzeitfehler und mögliche Exploit-Indikatoren	Nicht jeder Angriff erzeugt erkennbare Fehler
WAF-Logs	Blockierte Requests und Angriffsmuster	Abhängig von WAF-Abdeckung und Signaturen

Besonders relevant ist die Unterscheidung zwischen einer vorhandenen Sicherheitslösung und ihrer tatsächlichen Sichtbarkeit.

Eine Palo Alto Firewall kann beispielsweise keine eingehenden Angriffe auf einen extern gehosteten Webserver erkennen, wenn dieser Verkehr die Firewall des Kunden nicht passiert.

Gleiches gilt für SentinelOne: Ohne Sensor auf dem betroffenen System gibt es keine entsprechende Prozessüberwachung.

Lösung / Best Practices

Schritt 1: PHP-Version und Patchstatus überprüfen

Vor dem Aufbau zusätzlicher Detection Rules sollte geklärt werden, ob der externe Webserver überhaupt betroffen ist.

Dazu sollte der Hosting-Anbieter mindestens folgende Informationen bereitstellen:

• Installierte PHP-Version und verwendeter PHP-Zweig
• Eingesetzte PHP-Builds und gegebenenfalls Backports
• Zeitpunkt der Installation relevanter Sicherheitsupdates
• Verwendete Webserver- und PHP-Betriebsart
• Vorhandene WAF- oder andere Schutzmechanismen
• Möglichkeiten zur Bereitstellung von Webserver- und PHP-Logs

Die Versionsnummer allein reicht nicht immer aus. Distributionen und Hosting-Anbieter können Sicherheitskorrekturen in eigene Paketversionen zurückportieren.

Entscheidend ist daher die Bestätigung, dass die relevanten Sicherheitskorrekturen tatsächlich enthalten sind.

Priorität hat die Behebung der Schwachstelle. Detection Rules sind eine ergänzende Maßnahme und kein Ersatz für ein Sicherheitsupdate.

Schritt 2: Apache- und PHP-Logs an Wazuh übertragen

Falls der Hosting-Anbieter eine Logweiterleitung ermöglicht, sollten mindestens folgende Quellen angebunden werden:

Apache Access Log
Apache Error Log
PHP Error Log
WAF Security Log (falls vorhanden)

Dabei sollten Webserver- und PHP-Fehlerlogs nicht ungeprüft als klassische Apache-Access-Logs behandelt werden.

Die Formate unterscheiden sich deutlich.

Ein Apache-Access-Log enthält typischerweise:

192.0.2.10 - - [21/Oct/2026:10:42:00 +0000]
"GET /index.php HTTP/1.1" 500 612

Ein PHP-Fehlerlog kann dagegen folgendermaßen aussehen:

[21-Oct-2026 10:42:01 UTC]
PHP Fatal error: Allowed memory size of
134217728 bytes exhausted
(tried to allocate 67108864 bytes)
in Unknown on line 0

Für eine zuverlässige Verarbeitung muss die Logweiterleitung die Ereignisgrenzen erhalten. Mehrzeilige PHP-Fehler sollten nach Möglichkeit als zusammengehörige Ereignisse übertragen werden.

Beispiel: Syslog-Empfang in Wazuh

Ein möglicher Ausschnitt aus der Konfiguration des Wazuh Managers:

<remote>
  <connection>syslog</connection>
  <port>514</port>
  <protocol>tcp</protocol>
  <allowed-ips>192.0.2.50</allowed-ips>
  <local_ip>0.0.0.0</local_ip>
</remote>

Die Adresse 192.0.2.50 ist ein Beispiel und muss durch die tatsächliche Quelladresse des autorisierten Logsenders ersetzt werden.

Für die Kommunikation über nicht vertrauenswürdige Netze sollte die Übertragung zusätzlich durch TLS, einen VPN-Tunnel oder einen entsprechend abgesicherten Log-Relay geschützt werden.

Wazuhs einfacher Syslog-Empfang über TCP bietet nicht automatisch eine Ende-zu-Ende-TLS-Absicherung.

Nach einer Änderung der Manager-Konfiguration muss der Wazuh Manager neu gestartet werden.

Schritt 3: Custom Rule für auffällige PHP-Speicherfehler erstellen

Ein erster Erkennungsansatz ist eine Regel für das charakteristische PHP-Fehlermuster.

Hierfür eignet sich eine eigene Regeldatei:

/var/ossec/etc/rules/local_rules.xml

Beispiel:

<group name="php,php2shell,web_attack,">

  <rule id="100210" level="10">
    <match type="pcre2">PHP Fatal error:.*Allowed memory size of.*exhausted.*tried to allocate.*in Unknown on line 0</match>
    <description>
      PHP: Suspicious memory exhaustion
      during unknown execution context.
      Possible PHP2Shell indicator.
    </description>
    <group>php_error,attack_attempt,</group>
  </rule>

</group>

Diese Regel durchsucht den empfangenen Logeintrag nach einer Kombination aus:

• PHP Fatal Error
• Memory-Limit-Überschreitung
• Fehlgeschlagener Speicherallokation
• in Unknown on line 0

Die Regel-ID 100210 liegt im üblichen Bereich für benutzerdefinierte Regeln und muss innerhalb der jeweiligen Wazuh-Installation eindeutig sein.

Das Alert-Level 10 dient hier als Beispiel für eine priorisierte Untersuchung. Es bedeutet nicht, dass eine erfolgreiche Kompromittierung nachgewiesen wurde.

Die Regel ist außerdem bewusst als erster Detection-Baustein zu verstehen. Sie funktioniert nur dann vollständig, wenn die relevanten Bestandteile in einem gemeinsamen, auswertbaren Logereignis vorliegen.

Bei mehrzeiligen Meldungen oder ungewöhnlichen Syslog-Formaten muss die Logaufbereitung entsprechend angepasst werden.

Schritt 4: Eigene Decoder für strukturierte PHP-Logs einsetzen

Falls der Hosting-Anbieter strukturierte Lognachrichten übermittelt, kann ein eigener Decoder sinnvoll sein.

Ein vereinfachtes Eingabeformat könnte beispielsweise so aussehen:

php_error: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 67108864 bytes) in Unknown on line 0

Für dieses Format lässt sich ein Decoder unter folgendem Pfad definieren:

/var/ossec/etc/decoders/local_decoder.xml

Beispiel:

<decoder name="custom-php-error">
  <prematch>^php_error:</prematch>
</decoder>

<decoder name="custom-php-error-fields">
  <parent>custom-php-error</parent>
  <regex type="pcre2">^php_error:\s+(.*)$</regex>
  <order>php_message</order>
</decoder>

Damit kann Wazuh die eigentliche PHP-Fehlermeldung in das Feld php_message übernehmen.

Eine darauf aufbauende Regel könnte folgendermaßen aussehen:

<group name="php,php2shell,">

  <rule id="100211" level="10">
    <decoded_as>custom-php-error-fields</decoded_as>
    <field name="php_message"
           type="pcre2">Allowed memory size of.*exhausted.*in Unknown on line 0</field>
    <description>
      PHP2Shell investigation:
      suspicious PHP memory exhaustion.
    </description>
    <group>php_error,attack_attempt,</group>
  </rule>

</group>

Dieser Decoder ist ausschließlich für das dargestellte, normalisierte Logformat vorgesehen. Reale Syslog-Nachrichten enthalten häufig zusätzliche Header, Zeitstempel und Hostnamen.

Bei solchen Nachrichten müssen Decoder und gegebenenfalls die vorgelagerte Lognormalisierung an das tatsächlich empfangene Format angepasst werden.

Schritt 5: Regeln mit wazuh-logtest validieren

Bevor die Regeln produktiv aktiviert werden, sollten sie mit realistischen Beispielereignissen getestet werden.

Dafür steht folgendes Werkzeug zur Verfügung:

/var/ossec/bin/wazuh-logtest

Ein geeigneter Testeintrag:

php_error: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 67108864 bytes) in Unknown on line 0

Im Test sollte geprüft werden, ob:

1. Der gewünschte Decoder erkannt wird.
2. Das Feld php_message korrekt extrahiert wird.
3. Die entsprechende Custom Rule ausgelöst wird.
4. Die Regel-ID und das Alert-Level stimmen.

Zusätzlich sollten Negativtests durchgeführt werden.

Beispielsweise darf eine gewöhnliche PHP-Warnung nicht automatisch als PHP2Shell-Verdacht klassifiziert werden:

php_error: PHP Warning: Undefined array key "id" in /var/www/html/index.php on line 15

Auch normale Memory-Limit-Fehler mit konkretem Dateinamen sollten getrennt bewertet werden.

Nach erfolgreicher Validierung können die Konfigurationsdateien produktiv übernommen und der Wazuh Manager neu gestartet werden.

Schritt 6: Apache-Access-Logs zur Korrelation nutzen

Ein PHP-Fehler allein liefert häufig zu wenig Kontext.

Deshalb sollte das SOC nach Möglichkeit die zugehörigen HTTP-Anfragen untersuchen.

Interessante Merkmale sind unter anderem:

• Wiederholte HTTP-500-Antworten
• Auffällige Request-Methoden
• Ungewöhnlich große Requests
• Verdächtige Parameter und Header
• Hohe Request-Frequenzen
• Mehrere Fehler unmittelbar nach Requests derselben Quelladresse

Ein möglicher Ablauf:

1

Auffälliger HTTP-Request

Apache Access Log oder WAF-Ereignis

2

PHP-Laufzeitfehler

Memory Exhaustion oder anderes ungewöhnliches Verhalten

3

Zeitliche Korrelation

Abgleich von Host, Zeitstempel und Request-Kontext

4

Security Alert

SOC-Triage und Prüfung möglicher Exploit-Indikatoren

Die Korrelation sollte nicht allein über eine identische Sekunde erfolgen. Je nach Hosting-Umgebung können Logging-Verzögerungen, unterschiedliche Zeitzonen und asynchrone Verarbeitung auftreten.

Falls verfügbar, sind eindeutige Request-IDs besonders hilfreich.

Schritt 7: Hostbasierte Erkennung ergänzen

Falls der Hosting-Anbieter Wazuh-Agenten oder ein EDR-System unterstützt, können zusätzliche Erkennungsmechanismen implementiert werden.

Besonders relevant sind ungewöhnliche Kindprozesse eines Webserverprozesses.

Beispiele für verdächtige Prozessketten:

apache2
  └── sh
       └── curl

php-fpm
  └── bash
       └── wget

Solche Prozessketten können auf die Ausführung von Betriebssystembefehlen durch eine Webanwendung hindeuten.

Allerdings können bestimmte legitime Anwendungen ebenfalls externe Programme starten.

Eine produktive Regel sollte daher Kontext berücksichtigen, beispielsweise:

• Parent-Prozess
• Ausgeführter Befehl
• Benutzerkontext
• Zieladresse
• Zugehörige Anwendung
• Häufigkeit und Zeitpunkt

Ein weiterer Vorteil einer hostbasierten Überwachung ist die Möglichkeit, File Integrity Monitoring und Systemkonfigurationsprüfungen einzusetzen.

Schritt 8: Security Configuration Assessment für PHP-Hardening

Neben Detection Rules kann Wazuh Security Configuration Assessment (SCA) zur Überprüfung der PHP-Konfiguration eingesetzt werden.

Ein mögliches SCA-Konzept umfasst vier Prüfbereiche:

Prüfung	Sicherheitsziel
PHP-Version und Patchstand	Verwundbare Builds identifizieren
expose_php	Unnötige Versionsinformationen reduzieren
display_errors	Interne Fehlermeldungen nicht öffentlich ausgeben
allow_url_include	Unsichere Remote-Include-Konfigurationen vermeiden

Diese Prüfungen sind allgemeine Hardening-Maßnahmen und keine spezifischen Nachweise dafür, dass PHP2Shell nicht ausnutzbar ist.

Ein SCA-Policy-Ausschnitt könnte beispielsweise so aussehen:

policy:
  id: "php-hardening"
  file: "php-hardening.yml"
  name: "PHP Security Configuration"
  description: "Basic PHP hardening checks"

checks:
  - id: 10001
    title: "PHP version must be reviewed"
    description: "Verify the installed PHP version and vendor security patches."
    rationale: "Outdated PHP builds may contain critical vulnerabilities."
    remediation: "Install a vendor-supported patched PHP build."
    compliance:
      - pci_dss: ["6.3.3"]
    condition: all
    rules:
      - 'c:php -v -> r:PHP'

Die dargestellte Prüfung bestätigt lediglich, dass ein PHP-Binary aufgerufen werden kann und eine Versionsausgabe liefert. Sie ist kein vollständiger Versions- oder Patchstandcheck.

Für eine produktive Richtlinie müsste die Ausgabe gegen die jeweils gültigen Sicherheitsversionen beziehungsweise die Paketinformationen des Betriebssystems geprüft werden.

Außerdem setzt die native Wazuh-SCA-Auswertung einen Wazuh-Agenten auf dem geprüften System voraus.

In einer vollständig agentenlosen Umgebung müsste der Hosting-Anbieter entsprechende Prüfergebnisse separat bereitstellen.

Lessons Learned / Best Practices

1. Fehlende Sichtbarkeit muss dokumentiert werden

Eine zentrale Erkenntnis aus diesem Szenario ist, dass ein SOC nicht jedes Kundenasset automatisch überwachen kann.

Externe Hosting-Systeme, SaaS-Dienste und ausgelagerte Infrastruktur können erhebliche Sichtbarkeitslücken verursachen.

Solche Systeme sollten deshalb im Asset- und Risk-Management eindeutig gekennzeichnet werden.

Beispielsweise:

Asset	Sicherheitsüberwachung	Risiko
Interne Endpoints	SentinelOne	Host-Telemetrie vorhanden
Interne Netzwerke	Palo Alto	Netzwerk-Telemetrie vorhanden
Microsoft 365	Cloud-Events	Cloud-Telemetrie vorhanden
Externer PHP-Webserver	Keine direkten Logs	Unzureichende Angriffssichtbarkeit

Das Fehlen eines Alerts ist in diesem Fall keine Bestätigung, dass kein Angriff stattgefunden hat.

2. Detection Coverage gehört zum Serviceumfang

Ein SOC sollte gegenüber Kunden klar kommunizieren, welche Sicherheitsereignisse erkannt werden können und welche nicht.

Dazu gehören insbesondere:

• Überwachte Assets
• Verfügbare Logquellen
• Abgedeckte Angriffstechniken
• Bekannte Erkennungslücken
• Verantwortlichkeiten externer Dienstleister
• Eskalationswege bei kritischen Schwachstellen

Gerade bei Managed-SOC-Dienstleistungen verhindert eine solche Dokumentation falsche Erwartungen.

3. Hosting-Anbieter in das Incident-Response-Konzept einbinden

Für extern betriebene Webanwendungen sollten vor einem Sicherheitsvorfall klare Vereinbarungen bestehen.

Wichtige Fragen sind:

Wer stellt bei einer kritischen Schwachstelle den Patchstatus bereit?

Wie schnell kann der Hosting-Anbieter Webserver- und WAF-Logs liefern?

Welche Aufbewahrungsfristen gelten?

Wer untersucht verdächtige Prozesse oder Dateien auf dem Webserver?

Und wer ist für die Incident Response verantwortlich?

Diese Fragen sollten nicht erst nach Bekanntwerden einer kritischen RCE geklärt werden.

4. Community-Regeln sind ein Ausgangspunkt, keine fertige Detection-Strategie

Für PHP2Shell wurde ein Community-Labor auf Basis folgender Komponenten beschrieben:

6

Wazuh-Regeln

3

Decoder

4

SCA-Checks

Beschriebene Laborumgebung

Wazuh 4.14.8, Ubuntu 24.04.5 LTS, Apache 2.4.58, mod_php 8.3.6 sowie eine angepasste Apache-LogFormat-Konfiguration.

Die konkreten Regel- und Decoder-Dateien lagen im bereitgestellten Material nicht vor. Eine Veröffentlichung oder technische Validierung des vollständigen Community-Labors lässt sich daraus daher nicht bestätigen.

Insbesondere ist zu beachten, dass eine Laborumgebung mit PHP 8.3.6 nicht mit einem aktuellen, gepatchten Produktivsystem gleichgesetzt werden darf.

Für die Übernahme solcher Detection-Inhalte empfiehlt sich ein kontrollierter Prozess:

1. Regeln in einer isolierten Testumgebung validieren.
2. Decoder mit den tatsächlichen Produktivlogs testen.
3. False Positives und False Negatives untersuchen.
4. Regel-IDs und bestehende Konfigurationen auf Konflikte prüfen.
5. Detection-Inhalte versionieren und dokumentieren.
6. Neue Regeln zunächst überwachen, bevor automatische Reaktionen aktiviert werden.

5. Keine automatischen Gegenmaßnahmen auf Basis eines einzelnen PHP-Fehlers

Ein einzelner PHP-Memory-Error ist kein ausreichender Beleg für eine erfolgreiche Remote Code Execution.

Automatisches Blockieren von IP-Adressen, Stoppen von Diensten oder Sperren von Benutzerkonten kann auf Basis eines solchen Ereignisses zu unnötigen Betriebsunterbrechungen führen.

Für die initiale Implementierung ist daher eine alarmbasierte Erkennung mit anschließender Analystenprüfung vorzuziehen.

Erst wenn eine Regel durch zusätzliche Indikatoren zuverlässig validiert wurde, sollten weitergehende Reaktionsmaßnahmen erwogen werden.

Fazit

PHP2Shell verdeutlicht ein grundlegendes Problem moderner SOC-Architekturen: Die Qualität der Angriffserkennung hängt nicht nur von den SIEM-Regeln, sondern vor allem von der verfügbaren Telemetrie ab.

Wazuh kann verdächtige PHP-Fehlermeldungen analysieren, HTTP-Ereignisse korrelieren und mit geeigneter Host-Telemetrie mögliche Folgeaktivitäten einer Remote Code Execution erkennen.

Für eine belastbare Erkennung sind jedoch passende Datenquellen erforderlich.

In einer agentenlosen Umgebung mit ausschließlich Microsoft-365-, Palo-Alto- und SentinelOne-Ereignissen ist die direkte Erkennung eines Angriffs auf einen extern gehosteten PHP-Webserver nicht zuverlässig möglich, sofern diese Systeme keinen relevanten Verkehr oder keine Hostereignisse des Webservers erfassen.

Die sinnvollste Vorgehensweise besteht deshalb aus drei Maßnahmen:

Zuerst den Patchstatus verifizieren, anschließend relevante Webserver- und PHP-Logs integrieren und schließlich gezielte Wazuh-Decoder und Custom Rules implementieren.

Solange keine ausreichende Sichtbarkeit besteht, sollte das betroffene Asset ausdrücklich als Monitoring-Blindspot dokumentiert werden.

Denn eine funktionierende SIEM-Plattform kann fehlende Telemetrie nicht kompensieren. Eine professionelle SOC-Leistung umfasst deshalb nicht nur die Erkennung von Angriffen, sondern auch die transparente Kommunikation darüber, wo eine solche Erkennung technisch nicht möglich ist.

Mehr zu Wazuh …

Mehr zum Wazuh Ambassador Program …

https://wazuh.slack.com/archives/C0A933R8E/p1792688310146889