PHP2Shell im Active Directory: Mit dem ISW PHP Security Scanner jede PHP-Installation finden

Seit PHP2Shell stellen viele Admins dieselbe Frage: Auf welchen unserer Windows-Server läuft eigentlich PHP? Meistens kennt man zwei oder drei Systeme. Die anderen – das Monitoring-Frontend, das Ticketsystem, die alte XAMPP-Testinstallation – fallen erst auf, wenn es zu spät ist. Der ISW PHP Security Scanner findet sie alle, bewertet jede Installation und jede PHP-Webanwendung und liefert die Behebung gleich mit. Hier stelle ich das Werkzeug vollständig vor.

Das Problem: PHP steckt dort, wo niemand hinschaut

Mit PHP2Shell (CVE-2026-109618 und CVE-2026-109619) sind im Oktober 2026 zwei Lücken im PHP-Kern bekannt geworden. Im ungünstigsten Fall lässt sich darüber ohne Anmeldung Schadcode ausführen – noch bevor der Code der eigentlichen Anwendung startet. Betroffen ist jede Betriebsart, die Webanfragen bedient: IIS mit FastCGI ebenso wie Apache mit mod_php oder php-cgi. Korrigiert sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35; für PHP 8.1 und älter gibt es keine Korrektur mehr.

Das Update selbst ist schnell erledigt. Schwierig ist die Frage davor: Wo liegt überhaupt überall PHP? In Windows-Umgebungen kommt PHP selten über einen Installer. Es wird von Fachanwendungen mitgebracht, liegt entpackt unter C:\PHP, steckt in einem XAMPP-Ordner von vor fünf Jahren oder hängt an einer IIS-Site, die niemand mehr verwaltet. Eine Softwareinventur findet das nicht – PHP taucht in keiner Liste installierter Programme auf.

Der Funktionsumfang im Überblick

1. Server auswählen und vorprüfen

„Aus AD laden …“ öffnet einen AD-Explorer mit dem OU-Baum der Domäne; Unter-OUs werden beim Aufklappen nachgeladen. Rechts stehen die Windows-Computer der gewählten OU mit Betriebssystem, Rolle und letzter Anmeldung. Filter blenden Clients, Domänencontroller, deaktivierte und lange nicht angemeldete Konten aus. Die Markierung bleibt beim Wechsel der OU erhalten – so sammeln Sie Server aus mehreren OUs. Systeme außerhalb der Domäne tragen Sie von Hand ein, Server, die nie gescannt werden sollen, schließen Sie dauerhaft aus.

Die Vorprüfung klärt danach in wenigen Sekunden je Server, ob der Scan dort funktioniert: Namensauflösung, WinRM-Port, Anmeldung, lokale Administratorrechte, PowerShell-Version, IIS und die Voraussetzungen der Spurensuche. Das Ergebnis erscheint als Ampel – „Bereit“, „Bereit (Spurensuche eingeschränkt)“, „Eingeschränkt“ oder „Nicht bereit“ mit der Ursache im Tooltip.

2. PHP finden – auf allen Wegen

Der Scan läuft per WinRM, mehrere Server parallel; der eigene Rechner wird lokal geprüft. Er ist rein lesend und installiert nichts. Gesucht wird über:

• IIS: FastCGI-Anwendungen und Handler aus der applicationHost.config und den web.config-Dateien, mit den Sites, die PHP nutzen
• Apache: httpd.conf mit mod_php, CGI und mod_fcgid, DocumentRoot und Alias
• Dienste und Prozesse: php.exe und php-cgi.exe als Dienst oder laufender Prozess
• Registry und bekannte Ordner: IniFilePath, C:\PHP, Programme\PHP, XAMPP, WAMP, Laragon
• Dateisuche: alle lokalen Laufwerke bis Ebene 3, mit Tiefensuche ohne Begrenzung, dazu eigene Suchordner

Für jede Installation bestimmt der Scanner die wirksame php.ini so, wie PHP es unter Windows selbst tut: PHPRC aus der FastCGI-Einstellung, PHPIniDir aus Apache, IniFilePath in der Registry, Programmordner, Windows-Ordner. Zusatzdateien aus PHP_INI_SCAN_DIR – systemweit oder je FastCGI-Anwendung – werden danach geladen und überschreiben Werte. Im Detailbereich sehen Sie für jede Direktive Ist, Soll und die Datei, aus der der Wert stammt.

Die Einbindung bestimmt die Bewertung: „IIS FastCGI“, „Apache mod_php“, „Windows-Dienst“, „Prozess läuft“ oder „Nur Dateien“. Eine verwundbare Version am Webserver ist CRITICAL, ein vergessener Ordner ohne Einbindung wird bei Konfigurationsbefunden eine Stufe niedriger eingestuft – bleibt aber sichtbar. Zusätzlich meldet der Scanner Prozesse, die nach einem Update noch mit dem alten Programmstand laufen.

3. Schwachstellen und Online-Daten

PHP2Shell, CVE-2024-4577 und das Supportende der PHP-Zweige sind eingebaut und funktionieren auch ohne Internet. Ist der Online-Abgleich aktiv, fragt der Scanner nach dem Scan für jede gefundene PHP-Version und jede Webanwendung die NVD ab. Lücken aus dem CISA-Katalog „Known Exploited Vulnerabilities“ – also aktiv ausgenutzte – macht er automatisch zu CRITICAL. Supportende und aktuelle Version kommen von endoflife.date, Composer-Pakete werden gegen die Sicherheitshinweise von Packagist geprüft.

Übertragen werden dabei nur Produktnamen und Versionen, keine Server- oder Firmennamen. Die Ergebnisse werden zwischengespeichert (Standard 24 Stunden). Ohne NVD-API-Schlüssel erlaubt die NVD fünf Abfragen in 30 Sekunden; mit einem kostenlosen Schlüssel geht es etwa zehnmal schneller.

4. Webanwendungen und riskante Dateien

PHP-Lücken stecken nicht nur im PHP-Kern. Der Scanner durchsucht deshalb alle Webverzeichnisse der IIS-Sites (inklusive Anwendungen und virtueller Verzeichnisse) und die DocumentRoot- und Alias-Ordner von Apache. Er erkennt WordPress, Nextcloud, Moodle, phpMyAdmin, Joomla, Drupal, GLPI, das Zabbix-Frontend und Roundcube samt Version und prüft jede Anwendung auf CVEs und Supportende. Composer-Projekte werden mit allen Paketversionen aus der composer.lock erfasst.

Dazu kommen Dateien, die im Webverzeichnis nichts zu suchen haben: phpinfo()-Seiten, Adminer, Sicherungskopien wie *.php.bak, .env-Dateien, SQL-Sicherungen und .git-Ordner. Unter Apache sind sie meist direkt abrufbar (HIGH), IIS liefert unbekannte Dateitypen standardmäßig nicht aus (LOW). In .user.ini und .htaccess meldet der Scanner auto_prepend_file, ein wieder eingeschaltetes Upload-Progress, display_errors und Handler, die Bild- oder Textdateien als PHP ausführen.

5. Spurensuche mit ehrlicher Aussagekraft

War eine Lücke länger offen, stellt sich die Frage, ob sie schon ausgenutzt wurde. Ab einem einstellbaren Datum prüft der Scanner:

• Prozessstarts: Ereignis 4688 und Sysmon-Ereignis 1 – Prozesse, die php.exe oder php-cgi.exe gestartet haben, sowie Shells und Werkzeuge wie cmd, powershell, certutil oder whoami unter w3wp.exe oder httpd.exe
• Webshell-Merkmale: neue oder geänderte PHP-Dateien und alle PHP-Dateien in Upload-Ordnern, etwa eval mit Entschlüsselung oder system/exec mit Anfrageparametern
• Webprotokolle: IIS- und Apache-Zugriffsprotokolle mit Größenlimit, durchsucht nach CVE-2024-4577, php://input, PHPUnit eval-stdin.php, Verzeichniswechseln, Code-Aufrufen und Aufrufen der verdächtigen Dateien

„Keine Treffer“ ist nur dann eine Aussage, wenn Prozessstarts protokolliert werden und das Sicherheitsprotokoll weit genug zurückreicht. Der Scanner bewertet deshalb je Server Überwachungsrichtlinie, Befehlszeile, Sysmon und Reichweite des Protokolls und meldet offen „Spurensuche nicht aussagekräftig“, wenn etwas fehlt. Eine eigene Signatur für PHP2Shell in den Webprotokollen gibt es bewusst nicht – der Angriff steckt im Anfrageinhalt, der dort nicht steht. Eine erfundene Signatur würde nur falsche Sicherheit erzeugen.

6. Oberfläche, Befunde und Verlauf

Das Dashboard zeigt Gesamtstatus, geprüfte Server, PHP-Installationen, PHP2Shell-verwundbare Installationen, Supportende, weitere CVEs mit der Zahl aktiv ausgenutzter Lücken, Webanwendungen mit Handlungsbedarf, neue Befunde seit dem letzten Scan und einen Score. Dazu kommen die PHP-Zweige im Einsatz und die häufigsten Befunde. Während des Scans zeigt eine Zeile am unteren Rand Fortschritt und Laufzeit, aufgeklappt den aktuellen Schritt je Server – das Fenster bleibt bedienbar.

Ein Doppelklick auf einen Server öffnet alle Details: AD-Angaben, Ergebnis, Installationen, Befunde, Webanwendungen und die Spurensuche mit Prozessstarts, Webshell-Merkmalen, Webprotokollen und geänderten Dateien. „In Zwischenablage“ kopiert alles als Text für ein Ticket.

Jeder Befund trägt das Datum seines ersten Auftretens. Verschwindet er auf einem geprüften Server, gilt er als behoben; nicht erreichte Server lassen Befunde bewusst offen. Daraus entstehen die Kennzahlen, die Auditoren verlangen: mittlere Behebungsdauer, mittlere Offen-Dauer und das Alter des ältesten offenen CRITICAL. Bewusst getragene Risiken lassen sich akzeptieren – mit Begründung, Verantwortlichem und Ablaufdatum von höchstens 365 Tagen. Akzeptierte Befunde bleiben sichtbar und stehen im Bericht unter „Akzeptierte Risiken“, zählen aber bis zum Ablauf nicht für den Status.

7. Behebungshilfe

Zu jeder Installation erzeugt der Scanner einen php.ini-Block mit den empfohlenen Werten, den Link auf die passende korrigierte Version (NTS oder TS, Compiler, Architektur) und für IIS ein PowerShell-Skript, das FastCGI-Anwendung, Handler und PHPRC auf den neuen Ordner umstellt – mit vorheriger Sicherung der IIS-Konfiguration. Alles lässt sich kopieren oder als Behebungsplan für alle Server in eine Datei schreiben. Bis zum Update empfiehlt das PHP-Team diese Sofortmaßnahmen:

session.upload_progress.enabled = 0
post_max_size = 32M
expose_php = Off
display_errors = Off

8. Berichte und E-Mail

Exportiert wird als PDF im ISW-Layout, als HTML, als JSON und als CSV – je eine Datei für Server, Installationen, Befunde, Webanwendungen, CVEs und Konfiguration – sowie als Behebungsplan. Der Bericht enthält Kennzahlen, die Veränderung seit dem letzten Scan, Installationen mit CVEs, Webanwendungen, offene Befunde mit „offen seit“, die Spurensuche mit Aussagekraft je Server, akzeptierte Risiken und nicht erreichte Server. Per SMTP geht eine Kurzfassung raus, auf Wunsch mit PDF im Anhang.

9. Automatisch überwachen

Der geplante Scan wird direkt in den Einstellungen eingerichtet – täglich oder wöchentlich, als SYSTEM oder als gMSA, ohne gespeichertes Administratorkennwort. Nach jedem Lauf vergleicht der Scanner mit dem vorherigen Ergebnis und legt die Berichte ab. Die E-Mail geht „Immer“, „Nie“ oder nur bei „Neue HIGH/CRITICAL“ – dann, wenn neue schwere Befunde, verdächtige Prozessstarts oder Webshell-Merkmale aufgetaucht sind. Jede Aktion landet im eigenen Windows-Ereignisprotokoll „ISW PHP Security Scanner“, neue HIGH/CRITICAL-Befunde mit eigener Ereignis-ID – bereit für SIEM und Monitoring.

Für RMM-Werkzeuge und eigene Skripte gibt es den Silent-Modus:

"PHP Security Scanner.exe" /scan /report pdf,html,csv,json /mail /out D:\Berichte
REM nur bestimmte Server:  /targets web01;web02.firma.local
REM 0 = ohne HIGH/CRITICAL · 1 = HIGH · 2 = CRITICAL · 3 = Fehler · 4 = Lizenz · 5 = keine Adminrechte

10. Sicherheit des Werkzeugs selbst

Ein Scanner, der mit Administratorrechten auf alle Server zugreift, muss selbst sauber sein. Kennwörter für WinRM und SMTP sowie der NVD-Schlüssel liegen AES-256-verschlüsselt in einem Benutzertresor und – für den geplanten Scan – in einem Maschinentresor, auf den nur SYSTEM und Administratoren zugreifen. An PowerShell gehen Kennwörter nur über die Standardeingabe, nie über die Befehlszeile. Der Datenordner unter %ProgramData% wird bei jedem Start abgesichert: Dateien, die nicht von Administratoren stammen, landen in Quarantäne statt verwendet zu werden. So kann niemand Befunde durch eigene Versionsdaten unterdrücken. Jede Aktion steht mit Zeit, Konto und Ergebnis im Protokoll.

Fallstrick Spurensuche: erst protokollieren, dann suchen

Ohne die Überwachung „Prozesserstellung“ und ohne Befehlszeile im Ereignis 4688 ist jede Spurensuche blind. Den aktuellen Stand prüfen Sie so:

auditpol /get /subcategory:"{0CCE922B-69AE-11D9-BED3-505054503030}"

Aktivieren lässt sich das per GPO unter Computerkonfiguration › Richtlinien › Windows-Einstellungen › Sicherheitseinstellungen › Erweiterte Überwachungsrichtlinienkonfiguration › Detaillierte Nachverfolgung › „Prozesserstellung überwachen“ (Erfolg) und unter Administrative Vorlagen › System › Überwachung der Prozesserstellung › „Befehlszeile in Prozesserstellungsereignisse einschließen“. Vergrößern Sie zusätzlich das Sicherheitsprotokoll – sonst reicht es oft nur wenige Tage zurück.

Compliance-Bezug

Jeder Befund nennt Empfehlung und Referenz. Im BSI IT-Grundschutz sind das vor allem APP.3.2 (Webserver), APP.3.1 (Webanwendungen und Webservices), OPS.1.1.3 (Patch- und Änderungsmanagement), OPS.1.1.5 (Protokollierung) und DER.2.1 (Behandlung von Sicherheitsvorfällen). Für NIS2 deckt der Scanner das Schwachstellenmanagement nach Art. 21 und die Vorbereitung auf Meldungen nach Art. 23 ab, in den CIS Controls die Controls 2, 4, 7, 8 und 16. Verlauf, Behebungsdauer und befristete Risikoakzeptanz liefern die Nachweise, die ISO-27001- und NIS2-Audits verlangen.

Systemvoraussetzungen

Fazit

PHP2Shell ist kein reines Update-Thema, sondern ein Inventarthema. Wer nicht weiß, wo PHP läuft, kann es nicht patchen und auch nicht beurteilen, ob schon ein Angriff stattgefunden hat. Der ISW PHP Security Scanner beantwortet beides für alle Server im Active Directory in einem Durchgang – vom AD-Explorer über Schwachstellen, Konfiguration und Webanwendungen bis zur Spurensuche, mit fertiger Behebungshilfe, Verlauf für den Auditor und automatischer Überwachung. Das Werkzeug kostet einmalig 399,00 € inkl. MwSt. als Standortlizenz ohne Benutzerbegrenzung, ohne Abonnement und mit kostenlosen Updates innerhalb der Hauptversion.