Webshells PHP sur Linux : évasion via cookies

Introduction

Microsoft a publié de nouvelles recherches sur une technique furtive de webshell PHP affectant les environnements d’hébergement Linux. Au lieu d’utiliser des paramètres d’URL évidents ou des corps de requête, les attaquants utilisent des cookies HTTP comme canal de déclenchement et de contrôle pour l’exécution malveillante, ce qui rend ces webshells plus difficiles à repérer dans le trafic web normal et les journaux applicatifs.

Pour les équipes de sécurité et les administrateurs qui gèrent des applications web hébergées sur Linux, cela est important, car cette technique permet une persistance discrète, une activation différée et un accès post-compromission plus furtif.

Nouveautés

Microsoft a observé plusieurs variantes de webshell PHP qui reposent toutes sur une exécution conditionnée par des cookies :

• Activation contrôlée par cookie : Le webshell reste inactif à moins que l’attaquant n’envoie des valeurs de cookie spécifiques.
• Obfuscation multicouche : Certaines variantes reconstruisent dynamiquement des fonctions PHP et la logique d’exécution au moment de l’exécution afin d’éviter la détection statique.
• Préparation de la charge utile : Plusieurs échantillons reconstruisent et écrivent des charges utiles secondaires sur le disque uniquement lorsque les conditions de cookie requises sont remplies.
• Comportement interactif de webshell : Les versions les plus simples utilisent un seul cookie comme clé pour activer l’exécution de commandes ou le téléversement de fichiers.
• Persistance via cron : Dans un cas étudié, les attaquants ont utilisé des workflows légitimes du panneau de contrôle d’hébergement pour enregistrer des tâches planifiées qui recréaient le chargeur PHP malveillant s’il était supprimé.

Pourquoi c’est plus difficile à détecter

Les cookies font souvent l’objet de moins de contrôle que les chemins de requête, les chaînes de requête ou les corps POST. En PHP, les valeurs de cookie sont directement accessibles via $_COOKIE, ce qui en fait un canal d’entrée pratique pour les attaquants. Combiné à l’obfuscation et au déploiement progressif des charges utiles, cela permet à des fichiers malveillants de paraître inertes dans le trafic normal et de ne s’activer que lors d’interactions délibérées de l’attaquant.

Impact pour les administrateurs et les défenseurs

Pour les administrateurs IT et sécurité, le risque principal est une exécution de code à distance persistante dans un compte d’hébergement compromis, même sans accès de niveau root. Dans des environnements d’hébergement mutualisé ou avec shell restreint, les attaquants peuvent encore disposer de permissions suffisantes pour :

• Modifier le contenu web
• Déployer des chargeurs PHP
• Recréer des malwares supprimés via des tâches cron
• Maintenir un accès à long terme avec une empreinte minimale dans les journaux

Cela peut compliquer la remédiation, en particulier lorsqu’une tâche planifiée « auto-réparatrice » restaure le webshell après le nettoyage.

Prochaines étapes recommandées

Les administrateurs doivent examiner les recommandations de Microsoft et prioriser les actions suivantes :

• Auditer les applications PHP et les racines web à la recherche de scripts obfusqués suspects
• Examiner les tâches planifiées et les tâches cron pour détecter des mécanismes de persistance non autorisés
• Surveiller les modèles de cookies associés à une exécution inhabituelle côté serveur
• Activer et examiner les détections et analyses de menace de Microsoft Defender XDR
• Rechercher des fichiers PHP accessibles via le web qui écrivent ou incluent des charges utiles secondaires
• Renforcer le monitoring de l’intégrité des fichiers et les permissions dans les environnements d’hébergement Linux

Les organisations qui exploitent des charges de travail PHP exposées à Internet doivent également s’assurer que leurs playbooks de réponse à incident incluent des vérifications de persistance cron, la chasse aux webshells basés sur les cookies et une validation de suivi après le nettoyage.