EN
en direct

Le ransomware Warlock traverse les SharePoint des infrastructures critiques un an après les zero-days ToolShell

Un an après les zero-days SharePoint ToolShell, le groupe chinois Warlock — suivi comme Longlegs par Symantec — a frappé un service d’eau, un opérateur télécom, une administration régionale et une université, en désactivant la protection de 40 machines en deux heures. Corrigez vos SharePoint sur site, surveillez les chargements de pilotes BYOVD et chassez les indicateurs publiés par Symantec et Carbon Black.

Un panneau de commande industriel d’une station de traitement d’eau, sombre et hors tension, une seule lampe d’alarme ambre allumée en haut.

Juin 2025. Warlock, un ransomware lié à la Chine, émerge et, un mois plus tard, se fait connaître en exploitant la chaîne de zero-days SharePoint baptisée ToolShell. 22 juillet 2026. Lors d’une intrusion décortiquée par Symantec, le groupe désactive la protection de 40 machines en deux heures avant de déployer son ransomware sur 33 d’entre elles. 2 octobre 2026. Symantec et Carbon Black publient une analyse complète et des indicateurs de compromission. Pourquoi c’est important : plus d’un an après les correctifs, les failles SharePoint restent la porte d’entrée préférée d’un groupe qui vise l’eau, les télécoms et l’administration.

Une cible qui a changé de nature

Le rapport de Symantec et Carbon Black — qui suivent l’acteur sous le nom de Longlegs — décrit un glissement de cible net. Depuis environ deux mois, Warlock se concentre sur des organisations de pays lusophones et hispanophones d’Europe, d’Afrique et d’Amérique latine, et sur des secteurs qui dépassent l’habituel trio des victimes de ransomware. Un service public de l’eau, un opérateur télécom, une administration régionale et une université figurent parmi les cibles confirmées.

Ce choix n’est pas anodin. Les infrastructures critiques et les collectivités sont des cibles à la fois plus sensibles et souvent moins défendues que les grandes entreprises privées, tout en offrant le même levier de négociation — une interruption de service qui se chiffre immédiatement. Le groupe, apparu en juin 2025, a d’abord bâti sa notoriété en juillet 2025 en exploitant ToolShell, une chaîne de quatre failles zero-day dans Microsoft SharePoint référencées CVE-2025-49704, CVE-2025-49706, CVE-2025-53770 et CVE-2025-53771.

ToolShell, un an après, reste la porte d’entrée

Le point le plus marquant du rapport tient à la persistance du vecteur. En août 2026, Microsoft a observé les groupes étatiques Linen Typhoon et Violet Typhoon utiliser les mêmes exploits ToolShell, aux côtés d’un acteur ransomware que l’éditeur suit sous le nom de Storm-2603. Autrement dit, un an après leur divulgation et leur correction, les failles SharePoint servent encore de point d’entrée initial, y compris à des acteurs qui n’ont pas besoin d’un zero-day pour entrer.

La mécanique est classique. L’attaquant exploite une faille d’un SharePoint sur site pour déposer un web shell compatible avec plusieurs versions du produit, puis l’utilise pour pivoter dans le domaine. Le danger n’est pas tant la faille elle-même que la surface non corrigée : chaque serveur SharePoint exposé ou en retard de patch est un point d’entrée potentiel, et Warlock le sait.

Un « tueur d’EDR » déployé sur 40 machines en deux heures

L’intrusion du 22 juillet 2026 est le morceau le plus technique, et le plus inquiétant. Deux jours après l’accès initial, l’attaquant a mené une reconnaissance puis supprimé des artefacts intermédiaires. Le 31 juillet, il a déployé un outil de désactivation des protections qui a neutralisé l’antivirus et l’EDR d’au moins 40 hôtes en environ deux heures, avant que le ransomware Warlock n’apparaisse « presque aussitôt que la protection était désactivée sur chaque hôte », sur 33 machines.

La technique de désactivation repose sur le BYOVD — bring your own vulnerable driver. L’attaquant charge un pilote signé K7RKScan, vulnérable à CVE-2025-1055, pour obtenir les privilèges nécessaires à la neutralisation des protections. C’est la faille du modèle de confiance de Windows : un pilote signé mais vulnérable est accepté par le noyau, puis exploité pour désarmer les défenses. La leçon opérationnelle est directe — bloquer les pilotes vulnérables connus et surveiller les chargements de pilotes anormaux.

SYSVOL, VS Code et NetExec : un déploiement qui contourne les silos

Le déploiement du ransomware illustre une connaissance fine de l’Active Directory. Le binaire a été déposé dans le partage SYSVOL, un emplacement public répliqué sur chaque contrôleur de domaine. C’est, selon les chercheurs, une méthode connue pour pousser une charge vers tout un réseau d’un coup, via un script de connexion ou une stratégie de groupe, plutôt que machine par machine.

Pour la persistance et le mouvement latéral, l’attaquant a installé l’exécutable principal de Visual Studio Code Insiders en tant que service, afin d’utiliser la fonction de tunnel intégrée de VS Code pour se reconnecter aux machines compromises. Sur l’un des systèmes, les chercheurs ont aussi trouvé NetExec, un framework open source de test d’intrusion utilisé pour l’énumération de l’Active Directory, l’aspersion d’identifiants et l’exécution de commandes à distance. L’ensemble dessine un opérateur qui ne se contente pas de chiffrer : il s’installe durablement, puis frappe.

Le blocage des pilotes BYOVD est une politique, pas un produit

La technique du BYOVD est connue depuis des années, et la parade existe. Microsoft maintient une liste de blocage des pilotes vulnérables, appliquée par défaut sur Windows 11 via la protection contre les pilotes vulnérables de Microsoft Defender. Mais sur les parcs hétérogènes — et singulièrement sur les serveurs SharePoint, qui tournent souvent sous Windows Server — cette protection n’est pas toujours active, ou ne couvre pas l’ensemble des pilotes signés anciens.

Le cas du pilote K7RKScan illustre le problème. Le pilote est signé, donc accepté par le noyau, mais il porte une vulnérabilité exploitable (CVE-2025-1055) que l’attaquant utilise pour neutraliser les protections. Bloquer ce pilote suppose d’activer le blocage des pilotes vulnérables et de maintenir la liste à jour — une politique de configuration, pas une fonctionnalité qui s’installe toute seule. Sur une infrastructure critique, c’est pourtant le seul moyen de contrer la vitesse de Warlock, qui désactive 40 machines en deux heures.

Pourquoi SharePoint sur site reste une cible

Le vecteur ToolShell ne serait pas aussi efficace si les serveurs SharePoint sur site n’étaient pas encore massivement déployés. Beaucoup d’organisations maintiennent un SharePoint interne pour des raisons de conformité, de dépendance à des applications métier, ou simplement par inertie — des serveurs qui sortent du radar des équipes de sécurité mais restent joignables sur le réseau interne. C’est exactement la surface que Warlock exploite : une faille corrigée depuis un an, mais un parc qui n’a jamais été mis à jour, et un point d’entrée que les chercheurs décrivent comme « toujours viable » plus d’un an après l’émergence du groupe.

Ce qu’il faut faire

La réponse tient en cinq actions, dans l’ordre.

  • 1. Corriger SharePoint. Appliquez les correctifs ToolShell sur tous les serveurs SharePoint sur site, y compris ceux qui ne semblent plus utilisés. C’est le point d’entrée initial de Warlock et il reste exploitable un an après.
  • 2. Bloquer les pilotes BYOVD. Déployez le blocage des pilotes vulnérables connus — à commencer par K7RKScan (CVE-2025-1055) — et activez la journalisation des chargements de pilotes.
  • 3. Surveiller SYSVOL. Inspectez le partage SYSVOL et les stratégies de groupe à la recherche de binaires inattendus ou de scripts de connexion modifiés.
  • 4. Restreindre les tunnels. Contrôlez l’usage de VS Code et de ses tunnels dans le parc, et bloquez les exécutables non approuvés installés en tant que services.
  • 5. Chasser les IOC. Croisez les indicateurs de compromission publiés par Symantec et Carbon Black avec vos journaux, en priorité sur les secteurs de l’eau, des télécoms et de l’administration.

Verdict

Si vous exploitez un SharePoint sur site, traitez ToolShell comme une dette encore ouverte et vérifiez immédiatement l’état de correction de chaque serveur : Warlock entre par cette porte un an après, et il n’est pas le seul. Si vous gérez une infrastructure critique ou une collectivité, considérez que votre secteur est désormais dans la liste des cibles et durcissez la visibilité EDR — le groupe désactive 40 machines en deux heures, une vitesse qui exige une détection des pilotes BYOVD en amont, pas après coup. Si vous croyez que le ransomware est un problème de grandes entreprises, ce cas montre le contraire : l’eau, les télécoms et l’administration sont en première ligne, avec un vecteur que le patch seul, appliqué tardivement, ne suffit pas à fermer.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

Citrix presse de patcher une faille RCE dans NetScaler qui frappe les appliances SAML

Le 9 octobre 2026, Citrix publie un correctif pour CVE-2026-107406, un débordement mémoire qui permet d’exécuter du code à distance ou de faire planter NetScaler ADC et Gateway configurés en fournisseur ou consommateur SAML. Passez en 14.1-73.46 ou 13.1-64.29, ou désactivez la configuration SAML si elle ne sert pas.

LMCache expose une RCE critique non corrigée via un simple message ZeroMQ sur les serveurs vLLM

Le 7 octobre 2026, JFrog révèle la faille CVE-2026-105192, une exécution de code à distance non authentifiée de gravité 9,8 dans LMCache, le cache qui accélère les serveurs LLM comme vLLM, sans correctif disponible. Si votre cache LMCache écoute sur une adresse routable, isolez-le immédiatement plutôt que d’attendre un patch.

← Retour au fil

Tapez au moins deux caractères.

↑ ↓ naviguer ↵ ouvrir esc fermer