La récente vulnérabilité critique de Microsoft SharePoint Server (CVE-2025-53770), activement exploitée dans le cadre d'une campagne à grande échelle, a fait des vagues dans la communauté de la cybersécurité. Variante d'une faille précédemment corrigée, cette vulnérabilité de type "zero-day" permet l'exécution de code à distance sans authentification, ce qui lui permet d'être facilement exploitée par des acteurs sophistiqués de la menace, y compris des groupes parrainés par des États.
Des rapports indiquent que de nombreux serveurs SharePoint ont été compromis dans le monde, affectant des entreprises multinationales et des entités gouvernementales. En particulier, le ministère américain de la sécurité intérieure, le ministère de l'énergie, le ministère de la santé et des services sociaux, ainsi que de nombreuses agences gouvernementales du Québec ont été touchés, ce qui pourrait entraîner des fermetures préventives de sites web et susciter des inquiétudes quant à la sécurité publique et à la confiance dans les services numériques.
Afin d'analyser les implications de cette attaque et de fournir des informations exploitables aux responsables de la sécurité, nous nous sommes entretenus avec Erik Montcalm, vice-président principal des services de sécurité et de la technologie chez SecureOps, un MSSP canadien basé à Montréal, à Prague et à Manille. Avec des décennies d'expérience à la pointe de la cybersécurité, Erik offre une perspective unique sur la gestion de ces menaces critiques et la mise en place de postures de sécurité résilientes.
Erik : C'est grave. Nous apprenons qu'il ne s'agit pas d'une toute nouvelle attaque, mais d'une variante d'une vulnérabilité que Microsoft a mal corrigée en 2020. Il semble qu'ils aient corrigé l'exploit spécifique signalé, mais pas la cause première. Microsoft a également son propre système de notation des vulnérabilités, mais le score CVSS est de 9,8.
Je ne comprends pas pourquoi il n'est pas de 10. Pour moi, c'est aussi terrible que possible. Il est exécutable à distance, il est automatisable et il existe des preuves d'une exploitation active.
Cela signifie qu'il existe des boîtes à outils et que les adversaires mènent une campagne active dans ce domaine. À l'heure actuelle, il y a probablement des dizaines de milliers de robots qui recherchent des systèmes SharePoint exposés, les exploitent ou les mettent sur une liste pour y revenir plus tard. Ils ne savent peut-être même pas ce qu'ils vont faire de ces serveurs SharePoint, mais ils se constituent un fichier. Si votre serveur SharePoint est en ligne, il sera exposé à moins que vous ne l'ayez mis hors ligne ou que vous l'ayez patché immédiatement.
Pire encore, les attaquants regroupent cette faille avec d'autres exploits SharePoint dans une boîte à outils qu'ils appellent "ToolShell". Ainsi, si vous avez corrigé cette dernière faille, mais que vous avez manqué une plus ancienne, vous êtes toujours exposé. SharePoint est devenu une cible super juteuse.
Erik : SharePoint est partout, et les cas d'utilisation varient considérablement. Pour certaines organisations, il ne sert qu'à la documentation interne, mais d'autres l'intègrent à des produits, à l'automatisation, etc. Mais d'autres l'intègrent à des produits, à l'automatisation, ou l'utilisent comme centre de données. Pour certains, cette vulnérabilité n'est donc pas grave. Ils peuvent fermer l'application, et l'impact peut être la perte d'accès à la documentation de leur centre d'appel pour les prochaines 24 heures. En attendant, ils peuvent utiliser les copies papier d'un classeur, même si elles sont un peu dépassées.
D'autres organisations l'intègrent aux données et applications critiques. Nous avons vu les sites web des fonds de pension gouvernementaux tomber en panne au Québec. Cela signifie que les données relatives à la retraite des citoyens sont hébergées sur SharePoint et peuvent être volées par des cybercriminels. C'est à ce moment-là que les RSSI doivent prendre des décisions difficiles et terribles, car l'impact potentiel est énorme. Mais l'impact de l'inaction est également très élevé.
Erik : C'est une décision difficile à prendre, et cela dépend vraiment de l'ensemble de votre stratégie de défense. Nous ne ferions pas de recommandation générale. Le conseil dépend de votre situation unique. Si vous disposez d'une solide défense en profondeur et que vous êtes sûr de pouvoir atténuer le problème jusqu'à l'application d'un correctif ou de pouvoir facilement détecter si quelque chose se produisait, alors vous pouvez probablement garder le site en ligne. Cependant, si vous n'avez pas ce niveau de maturité, ou cette profondeur architecturale et de cyberdéfense, c'est un scénario dans lequel nous pourrions recommander de tout mettre hors ligne pour jeter un coup d'œil.
Erik : Exactement. Le problème ne se limite pas à la fuite d'informations depuis SharePoint. Les attaquants sont très doués pour "vivre de la terre" et pour les mouvements latéraux. Ils utiliseront ce serveur comme point d'entrée pour faire autre chose sur votre réseau. Vous êtes donc confronté à une décision très difficile à prendre : à quelle vitesse pouvez-vous garantir l'endiguement ou quelle investigation devez-vous mener pour vous assurer que vous n'êtes pas confronté à un problème beaucoup plus important ?
Erik : C'est une recommandation standard, mais ce qui n'est pas clair pour moi, c'est de savoir si ces outils Microsoft de niveau inférieur auraient empêché les attaques ou les auraient simplement détectées. Je ne vois pas beaucoup de détails à ce sujet. Je comprends pourquoi certains les ont désactivés ; certains se sentent en sécurité si leur SharePoint n'est pas directement exposé à l'internet et ils les désactivent pour des raisons de performance. C'est toujours un bon conseil d'activer la pile de sécurité Microsoft si vous n'avez pas d'autre EDR, mais je ne suis pas sûr de faire confiance à ces choses pour résoudre le problème, surtout si tôt dans le cycle de vie de l'exploit.
Erik : Je ne me contenterais pas d'appliquer des correctifs, de redémarrer et d'activer ces outils. Pour ce que j'en sais, cela élimine cette vulnérabilité spécifique, mais est-ce que cela élimine tout ce que les attaquants auraient pu faire d'autre ? Probablement pas. S'il s'agit simplement d'un outil automatisé qui s'est introduit, ASMI et Defender AV font probablement un bon travail de nettoyage. Ce qui me préoccupe, ce sont les attaquants plus avancés qui utilisent cela pour s'introduire, reconfigurer manuellement les choses et créer des attaques complexes et des traces laissées. Je ne suis pas sûr que ces menaces soient détectées par AMSI et Defender AV. Cela dit, les outils de niveau supérieur, comme l'édition XDR de Microsoft Defender, seraient mieux adaptés à cette situation.
Erik : Toutes les mesures habituelles ralentiront au moins un attaquant : le moindre privilège, la liste blanche des applications et l'utilisation du MFA. Pour un serveur important comme celui-ci, je le renforcerais conformément aux directives du CIS et m'assurerais qu'il passe par un type de scanner de renforcement.
Je sais qu'il est dérangeant de suivre ces directives de durcissement, car cela vous oblige à faire des pieds et des mains pour que le serveur puisse faire quoi que ce soit par la suite. Mais cela en vaut la peine, si vous hébergez quelque chose d'important.
Au-delà de cela, il s'agira toujours de réagir, n'est-ce pas ? Quelle est la rapidité de réaction de votre équipe ? À quelle vitesse pouvez-vous détecter une attaque grâce aux renseignements sur les menaces ?
Je parierais qu'il y a eu des discussions sur cette vulnérabilité sur le Dark Web bien avant que Microsoft ne publie un communiqué de presse. De telles choses ne se produisent pas sans une vague d'activité. Un programme de renseignement sur les menaces digne de ce nom aurait pu vous prévenir quelques jours ou quelques heures à l'avance. Cela peut s'avérer très utile dans une situation comme celle-ci.
Ensuite, réfléchissez à la rapidité avec laquelle votre équipe peut appliquer des correctifs et assurer une surveillance. Je ne parle pas seulement de surveiller le serveur ou de surveiller cette attaque. Je veux dire que vous êtes vraiment couvert pour la détection d'identité ? Que se passe-t-il à l'intérieur de votre Active Directory ? Ou de votre Entra ? Ce sont autant d'éléments qui vous aideront à reprendre confiance en vous.
Les organisations qui sont très confiantes dans leur capacité à réagir sont restées très peu de temps hors service ou ne l'ont pas été du tout. Ce sont les organisations qui sont bloquées, essayant de comprendre ce qu'il faut faire, qui mettent des jours ou des semaines à réagir.
C'est là que la situation devient inquiétante.
Erik : À court terme, la mesure la plus critique est l'application de correctifs virtuels sur le réseau ou un solide programme de gestion des vulnérabilités, car cela permet de se débarrasser rapidement du problème initial. Mais je dirais qu'en général, la source de ma confiance est un programme SOC mature.
Si j'ai un SOC robuste, je peux être sûr que je détecterai d'autres anomalies. Si nous avons manqué l'intrusion initiale et que les attaquants ont fait la fête sur mon serveur pendant une semaine, c'est une chose. Mais si je pouvais être aussi confiant que possible dans le fait que je remarquerais d'autres serveurs qui ne tournent pas rond, ou de nouveaux comptes qui sont créés, ou toute autre chose que l'attaquant pourrait faire, alors je me sentirais bien dans la situation. Pour ce faire, il faut un programme de surveillance complet et mature, et pas seulement un programme axé sur le serveur SharePoint du périmètre.
Erik : Tout d'abord, il faut analyser l'impact immédiat. Quelles données se trouvent sur ce serveur ? Quel est le pire scénario ? Parallèlement, je mettrais en place une surveillance accrue dans tout l'écosystème Microsoft, Entra ID, Active Directory, tout. Il faut dresser une carte des risques associés et concentrer la surveillance sur ces éléments.
Erik :C'est un obstacle majeur. Vous devez demander à vos architectes et à vos équipes réseau : À quoi ce serveur est-il connecté ? Quelles API utilise-t-il ? Cela suppose que vous ayez un bon partenaire ou un SOC interne capable de s'adapter rapidement.
Erik : Je pense qu'il s'agit d'un exemple très clair de la nécessité d'avoir des plans testés, pré-approuvés et pré-entraînés. Parfois, ces événements dérapent très rapidement. Lorsque cela se produit, les RSSI doivent être en mesure de répondre aux questions des services juridiques, des ressources humaines, du conseil d'administration et même de leurs propres clients. Si vous ne disposez pas des informations nécessaires, les gens perdent confiance.
La seule façon d'avoir ces informations à portée de main est de faire preuve de maturité à chaque étape : maturité dans le SOC, maturité dans la défense en profondeur et l'architecture, et maturité dans la compréhension de votre impact, en sachant où se trouvent vos données et comment elles sont protégées. Il s'agit également d'avoir la préparation opérationnelle nécessaire pour s'assurer que des personnes sont disponibles et que vous n'êtes pas bloqué par le fait que "Joe est en vacances".
Erik : Exactement. C'est la saison des vacances. Pour beaucoup d'entreprises de taille moyenne, il n'y a pas 50 personnes qui savent comment résoudre ces problèmes ; il n'y en a que quelques-unes. Si vous vous rendez compte que vous n'avez pas le personnel nécessaire pour ce travail quotidien, vous devriez vraiment envisager d'avoir un bon partenaire externalisé qui peut intervenir, un partenaire qui vous connaît à l'avance et qui peut faire partie de l'équipe pour aider à répondre à ces questions.
Erik : Les détails dépendent des services utilisés par le client, mais dans tous les cas, notre SOC serait au cœur de la réponse. Tous nos contrats SOC incluent une capacité de pointe, et il s'agit d'un scénario de pointe classique. Nous mettrions immédiatement en place une surveillance accrue et créerions un canal de communication dédié, comme un canal Slack ou une salle Microsoft Teams, où l'équipe du client pourrait poser des questions. Nous deviendrions essentiellement le centre d'échange d'informations pour l'enquête.
Cela ne signifie pas toujours que nous menons l'enquête. C'est parfois prévu dans le contrat, mais notre principal objectif est d'aider le client à obtenir la confiance dont il a tant besoin à ce moment-là, car nous savons qu'il doit répondre à un million de questions. Nous lançons des chasses aux menaces spécifiques et nous les aidons à comprendre tous les systèmes associés et à déterminer si des identités ont été compromises.
Erik : Si nous gérons leur infrastructure, nous mettons en place des correctifs virtuels sur le WAF. Si nous sommes chargés de la gestion des vulnérabilités, cela fait partie de notre traitement standard des incidents. Nous appliquons les correctifs dans l'heure qui suit, c'est-à-dire dès qu'ils sont disponibles. En fait, selon les services de base utilisés par le client, nous serions soit responsables de la majeure partie de la réponse, soit nous jouerions un rôle de soutien essentiel.
Erik : Dans ce cas, c'est un argument de poids. Cet incident montre bien où vont les efforts et l'attention de Microsoft. Il montre simplement qu'ils gèrent leur propre infrastructure en nuage d'une manière différente de celle des solutions sur site. Microsoft est probablement bien meilleur et plus rapide à patcher son propre nuage que 99% des organisations. Pour la plupart des organisations dans le monde, le transfert de ce type d'infrastructure dans le nuage est une chose très souhaitable.
Erik : Les silos ne fonctionnent plus. Ce n'est pas seulement le problème de la sécurité. La cybersécurité ne gère généralement pas l'identité, le réseau ou l'infrastructure. Toutes ces équipes doivent se réunir.
Erik : Cela commence par la collaboration sur des projets, la création de cartes de réseau, la documentation de stratégies d'atténuation appropriées, etc. En général, il faut s'assurer de savoir où se trouvent les données, mais il faut aussi s'entraîner à faire face à une crise. Je recommanderais d'organiser un exercice sur table à partir de ce scénario précis. C'est comme jouer à Donjons et Dragons, mais avec une faille de sécurité. Vous jouez un rôle pour trouver les lacunes dans vos processus. Cependant, tous les deux ans, les organisations doivent aller plus loin et faire des simulations d'attaques réelles, au lieu de rester assises dans une pièce et de faire semblant.
Erik : Prenez des notes sur ce qui s'est bien passé et sur ce qui s'est mal passé. Il est facile d'avoir une vision étroite et de se concentrer sur la solution, mais c'est une occasion en or d'améliorer votre réponse pour la prochaine fois.
Ce que je constate le plus souvent, c'est que les gens ne disposent tout simplement pas des informations dont ils ont besoin pour répondre à ces questions urgentes. Lorsque je demande : "Quels sont les systèmes connectés ? Quelles sont les API utilisées ? Quelles données se trouvent sur ce serveur ?", de nombreuses organisations n'ont pas de réponse correcte et actuelle. Elles ont un instantané du moment où le système a été déployé, mais nous savons tous que ces choses évoluent. Ne pas avoir une vision active et actualisée de son environnement est le plus grand obstacle à l'évaluation de l'impact et à une réponse efficace. C'est le domaine le plus négligé, et c'est par là que je commencerais.
La vulnérabilité de Sharepoint est une histoire active et évolutive. Tenez-vous au courant des derniers changements et consultez les ressources suivantes pour plus d'informations :
Si votre organisation a besoin d'améliorer sa maturité en matière de sécurité. Contactez SecureOps dès aujourd'hui pour savoir comment nous pouvons vous aider à combler les vulnérabilités et à vous protéger contre les menaces liées à ToolShell.