6 requêtes KQL pour enquêter avec Microsoft Defender XDR.
Deux vulnérabilités critiques dans PHP, un risque d’exécution de code à distance et des correctifs à appliquer rapidement.
Lorsqu’une faille touche PHP, nous pensons immédiatement aux serveurs web.
Mais les postes de travail peuvent aussi héberger des environnements PHP potentiellement vulnérables.
Identifier les installations PHP, rechercher les CVE, observer les processus et examiner l’exposition réseau, sans confondre vulnérabilité et compromission.
📑 Au programme
- PHP2Shell : comprendre les vulnérabilités
- Pourquoi les postes Windows sont concernés
- Les prérequis Defender XDR
- KQL 1 — Inventorier PHP
- KQL 2 — Rechercher les CVE
- KQL 3 — Identifier les exécutions
- KQL 4 — Examiner les ports d’écoute
- KQL 5 — Analyser les communications
- KQL 6 — Rechercher les comportements suspects
- Comment corriger les postes concernés
- Bilan et limites de l’investigation
1. PHP2Shell : que s’est-il passé ?
Le 21 octobre 2026, l’équipe PHP a publié des correctifs de sécurité concernant deux vulnérabilités critiques.
Une corruption mémoire liée à la gestion d’une situation de mémoire
insuffisante.
Une utilisation d’un état interne
devenu invalide entre plusieurs
requêtes PHP.
Dans certaines configurations, ces vulnérabilités peuvent permettre l’exécution de code à distance, sans authentification.
Le CERT-FR a également signalé des tentatives d’exploitation visant des déploiements PHP spécifiques.
PHP considère particulièrement à risque les installations traitant des requêtes web, notamment avec Apache mod_php.
Une installation utilisée uniquement en ligne de commande ne doit pas être automatiquement assimilée à un service web accessible à distance.
Quelles versions sont corrigées ?
| Branche PHP | Version corrigée |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 et antérieures | Migration ou correctif fournisseur adapté |
Le 26 octobre, PHP a republié certains binaires Windows avec le suffixe -1, notamment 8.3.36-1.
Ces paquets embarquent une correction de dépendance Brotli supplémentaire
(CVE-2026-111497). Il s’agit d’un sujet distinct des deux vulnérabilités PHP2Shell.
2. Pourquoi vérifier les postes de travail ?
Lorsqu’une faille concerne PHP, les premières investigations portent généralement sur les serveurs web.
Pourtant, les postes Windows peuvent aussi disposer de PHP : développement logiciel, tests locaux, outils portables ou environnements installés par les utilisateurs.
Scripts et outils de développement.
Le risque RCE web n’est pas
automatiquement applicable.
Environnements locaux pouvant
embarquer un moteur PHP
et un serveur web.
Nginx ou Apache peut servir
des applications depuis un poste.
L’accessibilité doit être vérifiée.
PHP peut se trouver dans un conteneur
ou une distribution Linux et ne pas
apparaître dans l’inventaire classique.
Nous allons rechercher successivement les installations PHP, leurs vulnérabilités, leur activité et les éléments techniques permettant de qualifier l’exposition.
3. Préparer l’investigation dans Defender XDR
Pour reproduire les recherches, vous devez disposer de Microsoft Defender
for Endpoint, d’un accès adapté à Advanced Hunting et des données nécessaires de Defender Vulnerability Management.
→ Hunting / Repérage
→ Advanced Hunting
| Table KQL | Objectif |
|---|---|
| DeviceTvmSoftwareInventory | Inventaire logiciel |
| DeviceTvmSoftwareVulnerabilities | CVE détectées sur les appareils |
| DeviceProcessEvents | Démarrages de processus |
| DeviceNetworkEvents | Activité réseau enregistrée |
⚠️ Une requête vide n’est pas une garantie de sécurité
La visibilité dépend notamment de l’onboarding des appareils, des fonctionnalités disponibles, de la fraîcheur de l’inventaire, de la rétention des événements et de la couverture des logiciels.
4. Identifier les postes qui possèdent PHP
Commençons par le plus simple : quelles machines possèdent PHP ou un environnement de développement associé ?
Pour cela, nous allons interroger l’inventaire logiciel de Defender.
Cette requête identifie notamment les logiciels dont le nom contient PHP, XAMPP, WAMP ou Laragon.
Une version PHP identifiée indique une installation inventoriée, pas nécessairement un service actif.
De même, un outil tel que PhpStorm peut apparaître dans les résultats sans prouver qu’un moteur PHP vulnérable est installé avec cet outil.
Simulation pédagogique — données entièrement fictives.
Nous savons comment identifier les installations connues de Defender.
Il faut maintenant vérifier les vulnérabilités associées.
5. Rechercher les deux CVE PHP2Shell
PHP est installé, mais quelles machines sont réellement associées aux vulnérabilités dans Defender ?
Nous allons utiliser DeviceTvmSoftwareVulnerabilities.
Cette recherche retourne les correspondances connues de Defender entre les logiciels installés et les deux CVE.
Un résultat confirme que Defender associe une vulnérabilité à un logiciel présent sur l’appareil.
Cela ne signifie pas qu’un attaquant a exploité le poste.
Simulation pédagogique — données entièrement fictives.
⚠️ Ne confondez pas les tables KQL
DeviceTvmSoftwareVulnerabilitiesKB décrit la base de connaissances des vulnérabilités évaluées par Microsoft.
Elle ne représente pas directement le nombre de postes vulnérables dans votre organisation.
6. PHP est-il réellement exécuté sur les postes ?
Une application vulnérable peut rester installée sans être exécutée.
Nous allons donc examiner les événements de création de processus enregistrés par Defender sur les 14 derniers jours.
Cette requête regroupe les événements par poste et par exécutable.
Une ligne de DeviceProcessEvents représente un événement de processus, et non un ordinateur distinct.
Un même poste peut donc générer de nombreuses lignes pour PHP ou Nginx, sans qu’il s’agisse de plusieurs installations ou attaques.
Simulation pédagogique — données entièrement fictives.
Nous pouvons identifier les processus réellement démarrés durant la période.
Cela ne prouve pas qu’ils sont encore actifs au moment de l’analyse.
7. Rechercher les ports en écoute de PHP et Nginx
C’est une étape importante.
Un poste de développement peut exécuter PHP et Nginx sans nécessairement être accessible depuis le réseau.
Nous allons examiner les événements de création de sockets en écoute enregistrés par Defender.
Comment interpréter LocalIP ?
| Adresse d’écoute | Signification |
|---|---|
127.0.0.1 |
Interface locale IPv4 |
::1 |
Interface locale IPv6 |
0.0.0.0 |
Toutes les interfaces IPv4 |
:: |
Écoute IPv6 non limitée au bouclage |
Simulation pédagogique — données entièrement fictives.
⚠️ 0.0.0.0 ne signifie pas « exposé à Internet »
Un processus qui écoute sur toutes les interfaces IPv4 n’est pas nécessairement joignable depuis le réseau.
Les règles du pare-feu, les routes, la segmentation et les éventuelles traductions d’adresse doivent être vérifiées.
Il faut également confirmer que le serveur web transmet des requêtes à une installation PHP vulnérable.
8. Examiner les communications associées à PHP et Nginx
Après les ports d’écoute, nous pouvons examiner les événements réseau associés aux processus PHP et aux serveurs web.
Cette recherche permet de distinguer plusieurs catégories de communications.
Communication impliquant
l’interface locale de l’appareil.
Adresse distante relevant
d’un espace réseau privé.
Adresse distante publique, à interpréter selon le contexte de la connexion.
Simulation pédagogique — données entièrement fictives.
⚠️ Une limite importante
DeviceNetworkEvents ne remplace pas les journaux HTTP du serveur web.
Une absence de résultat ne prouve pas qu’aucune connexion entrante n’a atteint l’application.
Pour rechercher des tentatives d’exploitation précises, les journaux Nginx, Apache, reverse proxy et WAF constituent des sources complémentaires.
9. Rechercher les processus suspects lancés par PHP ou Nginx
Dernière étape : examiner les processus enfants déclenchés par PHP ou par le serveur web.
Dans certaines situations, une application compromise peut être à l’origine d’un lancement inattendu de commandes système.
Cette recherche permet d’obtenir une vue regroupée des processus enfants, sans parcourir des dizaines de lignes répétitives.
Quels événements méritent une investigation ?
Nginx lançant d’autres processus
Nginx ou des processus console
attendus dans son environnement.
Lancement inattendu de PowerShell,
CMD ou d’outils de téléchargement
depuis PHP ou un serveur web.
Simulation pédagogique — données entièrement fictives.
Un processus enfant inhabituel peut être parfaitement légitime.
À l’inverse, une exploitation ne produit pas nécessairement un processus enfant visible.
Cette méthode constitue un contrôle comportemental complémentaire, pas une signature de détection exhaustive des vulnérabilités PHP2Shell.
10. Que faire lorsqu’un poste est concerné ?
Les requêtes précédentes servent à qualifier l’exposition.
Mais la priorité reste l’application des correctifs.
01 — Identifier l’installation
Vérifier la version de PHP, sa finalité et le responsable de l’application.
02 — Qualifier l’exposition
Déterminer si PHP sert uniquement à exécuter des scripts ou s’il traite des requêtes web.
03 — Réduire la surface d’attaque
Limiter temporairement l’accessibilité des services concernés si nécessaire, avec l’équipe sécurité.
04 — Mettre à jour PHP
Installer une version corrigée ou un paquet fournisseur intégrant les correctifs.
05 — Redémarrer les services
Vérifier que les processus utilisent bien les binaires corrigés après mise à jour.
06 — Contrôler la remédiation
Réexaminer la version et les vulnérabilités dans Defender Vulnerability Management.
Vérifier localement les ports ouverts
Sur Windows, cette commande PowerShell en lecture seule permet de vérifier les ports HTTP et HTTPS actuellement en écoute.
Cette commande complète les événements historiques observés dans Defender.
Elle ne démontre pas, à elle seule, qu’une connexion est possible depuis un réseau extérieur.
PHP documente des mesures temporaires permettant de réduire certains chemins d’exploitation.
Ces mesures ne constituent pas une protection complète.
La mise à jour reste la remédiation de référence.
11. Peut-on vraiment affirmer que les postes sont sécurisés ?
Après ces six requêtes, nous disposons d’une méthodologie pour mieux comprendre la surface d’exposition PHP de nos postes Windows.
Mais il faut distinguer les éléments que Defender peut observer des conclusions qu’une investigation complète permettrait d’établir.
| Vérification | Ce qu’elle permet d’établir |
|---|---|
| Inventaire PHP | Logiciel détecté |
| Recherche CVE | Association appareil / vulnérabilité |
| Processus PHP | Démarrage observé |
| Événements d’écoute | Écoute historique, exposition à qualifier |
| Communications réseau | Activité réseau partiellement visible |
| Processus enfants | Indices comportementaux à interpréter |
| Absence de compromission | Non démontrable avec ces seules requêtes |
Un logiciel installé n’est pas nécessairement exécuté.
Un logiciel vulnérable n’est pas automatiquement exploitable depuis le réseau.
Un serveur web actif n’est pas nécessairement accessible depuis Internet.
Et surtout, l’absence d’alerte ne constitue pas une preuve d’absence de compromission.
Conclusion : ne vous limitez pas aux serveurs !
PHP2Shell rappelle que les environnements de développement présents sur nos postes de travail peuvent eux aussi faire partie de la surface d’attaque.
Avec Microsoft Defender XDR et Advanced Hunting, nous pouvons identifier les installations PHP, rechercher les vulnérabilités et examiner les activités susceptibles de nécessiter une investigation.
Mais ces recherches ne remplacent ni la correction des logiciels, ni la vérification des configurations réseau, ni l’analyse des journaux web.
L’objectif n’est pas de conclure « tout va bien » après six requêtes KQL, mais de savoir où chercher, comment interpréter les résultats et quelles actions engager pour réduire le risque.
📚 Sources officielles
- PHP — Avis de sécurité du 21 octobre 2026
- CERT-FR — Multiples vulnérabilités dans PHP
- PHP — Actualités et mises à jour Windows 2026
- Microsoft Learn — DeviceTvmSoftwareInventory
- Microsoft Learn — DeviceTvmSoftwareVulnerabilities
- Microsoft Learn — DeviceProcessEvents
- Microsoft Learn — DeviceNetworkEvents
Article rédigé le 29 octobre 2026.
Les visuels sont des reconstitutions fictives.
Les requêtes KQL sont fournies à titre de méthode d’investigation défensive.
Les résultats et la couverture peuvent varier selon les environnements.
