Monthly Threat Report Mai 2026

Introduction

Le Monthly Threat Report de Hornetsecurity by Proofpoint vous apporte chaque mois des informations sur les tendances de sécurité M365, les menaces véhiculées par email et l’actualité du secteur de la cybersécurité. Cette édition du Monthly Threat Report se concentre sur les événements du secteur survenus en avril 2026. Comme il s’agit d’une édition consacrée à l’actualité et à l’analyse, le rapport de ce mois privilégie une analyse approfondie des menaces émergentes et des recherches sectorielles plutôt que des sections de données statistiques.

Résumé exécutif

• De nouvelles recherches de notre maison mère, Proofpoint, révèlent que la moitié des entreprises dans le monde ont subi un incident de sécurité lié à l’IA, confirmé ou suspecté, y compris parmi les 63 % qui déclarent déjà disposer de contrôles de sécurité pour l’IA. Ce constat met en évidence un écart croissant entre la rapidité de déploiement de l’IA et le niveau de maturité des contrôles censés l’encadrer.
• CVE-2026-31431, baptisée « Copy Fail », permet à tout utilisateur local non privilégié d’obtenir un accès root sur pratiquement toutes les grandes distributions Linux exécutant des kernels publiés depuis 2017, au moyen d’un exploit Python de 732 octets présenté comme fiable à 100 % sur les distributions concernées. Des correctifs sont disponibles et doivent être appliqués immédiatement.
• OpenAI a indiqué qu’une mauvaise configuration de GitHub Actions a exposé son infrastructure de certificats de signature de code à l’attaque de supply chain visant Axios npm du 31 mars, bien qu’aucune compromission de données utilisateur, de systèmes ou de propriété intellectuelle n’ait été confirmée. Les anciennes applications desktop OpenAI pour macOS cesseront de fonctionner après le 8 mai 2026.
• Notre Threat Intelligence Lab a documenté une campagne persistante de diffusion de Remcos RAT active depuis au moins novembre 2025, utilisant des leurres de phishing liés à des bons de commande et une chaîne d’exécution multicouche, sans fichier, conçue pour échapper aux outils de détection qui s’appuient sur l’analyse de binaires déposés sur le disque.
• Email reste le principal vecteur de menace : 63 % des personnes interrogées dans le rapport 2026 AI and Human Risk Landscape de Proofpoint le citent comme le point d’entrée d’attaque le plus courant. Parmi les entreprises ayant subi des incidents, 67 % ont impliqué email comme canal de compromission.
• Seul un tiers des entreprises se disent pleinement prêtes à enquêter sur un incident de sécurité lié à l’IA, ce qui révèle une faille critique non seulement dans les contrôles de prévention, mais aussi dans la capacité de réponse aux incidents à mesure que les menaces pilotées par l’IA gagnent en maturité.

Vue d’ensemble des menaces

Remcos RAT est de retour : une chaîne d’attaque multicouche et sans fichier conçue pour contourner la détection

Notre Threat Intelligence Lab a documenté une campagne de phishing persistante diffusant Remcos RAT via une chaîne d’exécution en plusieurs étapes et sans fichier, observée de manière répétée depuis novembre 2025.

La campagne débute par un email trompeur qui imite un processus de bon de commande. Les objets suivent le modèle de communications d’approvisionnement légitimes (« Order Request: UAB Sarens – PO #SB-0407026-001 » dans l’exemple observé). La pièce jointe utilise un camouflage par double extension : un fichier portant l’extension .txz semble être un document, mais il s’agit en réalité d’une archive compressée contenant une charge utile exécutable.

À partir de cette tromperie initiale, l’attaque se déroule en quatre étapes conçues pour limiter les artefacts sur le disque et échapper à la détection :

Étape 1 : un script Visual Basic (VBS) s’exécute via wscript.exe et lance PowerShell avec un indicateur de contournement de la politique d’exécution afin de réduire la visibilité.

Étape 2 : l’étape PowerShell télécharge ce qui semble être une image PNG depuis un serveur distant. L’image contient du contenu encodé masqué ajouté après des données d’image légitimes, ce qui réduit le nombre de fichiers intermédiaires écrits sur le disque et contribue à une chaîne d’exécution globale encore plus sans fichier.

Étape 3 : plusieurs couches de désobfuscation traitent le contenu masqué : substitution de caractères, inversion et décodage base64, puis reconstruction d’un exécutable .NET doté d’un en-tête MZ valide.

Étape 4 : l’assembly .NET est chargé directement en mémoire via la méthode AppDomain.Load, sans jamais passer par le disque. Plusieurs indicateurs confirment que la charge utile est Remcos RAT : artefacts mutex propres à Remcos, clés de registre sous HKCU\SOFTWARE\Rmc-HQO1B7 et schémas de communication TLS chiffrés correspondant aux empreintes JA3 de Remcos 3.x/4.x.

Pourquoi c’est important

Aucune technique utilisée dans cette chaîne n’est nouvelle. Son efficacité vient de son orchestration : chaque étape transmet proprement le relais à la suivante, ce qui réduit la surface de détection. Les antivirus qui analysent les binaires déposés sur le disque ne détecteront généralement pas une charge utile chargée directement en mémoire. Certains filtres de sécurité email plus anciens peuvent laisser passer une archive contenant un chargeur VBS lorsqu’aucun exécutable évident n’est présent. Les entreprises qui s’appuient uniquement sur une détection périmétrique, sans surveillance comportementale au niveau des endpoints, risquent fortement de passer à côté de cette chaîne.

La nature persistante de cette campagne mérite également l’attention. Active depuis au moins novembre 2025, il ne s’agit pas d’une opération opportuniste ponctuelle. La régularité du leurre lié au bon de commande et la sophistication technique de la chaîne de diffusion montrent qu’un opérateur a affiné cette approche au fil du temps et l’a jugée efficace.

Nous recommandons de considérer toutes les pièces jointes d’emails professionnels comme des chaînes d’exécution complètes potentielles, et non comme des fichiers isolés. Les contrôles de sécurité qui évaluent les chaînes de diffusion dans leur ensemble, plutôt que leurs étapes individuelles, ont beaucoup plus de chances d’identifier des campagnes de ce type.

Indicateurs de compromission (IOC)

Domaines : – nrmlogistics[.]ro - dentalux202[.]ydns[.]eu 

Adresses IP : – 107.172.139.23 – 193.230.215.22 – 94.198.96.165 

Empreintes de fichiers (SHA-256) : – 95e6c6c13f65217f41c371abf6d03594b2bfed2259a1813bb4222fb2d3c32745 (PNG avec charge utile masquée) – 53c3e0f8627917e8972a627b9e68adf9c21966428a85cb1c28f47cb21db3c12b (charge utile) – bd835498f0526e2a80da2efc58cddf96834dbfe9924e4465130602bce7a3314a (archive) – 5bd356b14a0647170924904f7c0411d62ca79733594fe6f7d8277dd68c1ca217 (chargeur VBS)

Recherche Proofpoint : la moitié des entreprises dans le monde ont déjà subi un incident de sécurité lié à l’IA

Le rapport 2026 AI and Human Risk Landscape de Proofpoint, publié le 28 avril 2026 et fondé sur une enquête menée auprès de plus de 1 400 spécialistes de la sécurité dans 12 pays et 20 secteurs, met en lumière un constat qui devrait amener les entreprises à réévaluer leur posture de sécurité liée à l’IA : la moitié des entreprises dans le monde ont subi un incident de sécurité lié à l’IA, confirmé ou suspecté, y compris parmi celles qui disposent déjà de contrôles de sécurité pour l’IA.

Le contexte de déploiement est important. 87 % des entreprises ont fait passer les assistants IA au-delà du stade pilote, et 76 % mènent activement des pilotes ou déploient des agents autonomes. Cette rapidité a clairement dépassé la maturité de la sécurité : 42 % des entreprises ont signalé un incident lié à l’IA suspect ou confirmé, et parmi les 63 % qui déclarent disposer d’une couverture de sécurité pour l’IA, la moitié a tout de même subi un incident. Les contrôles existent, mais ils ne suffisent pas.

Plusieurs données du rapport méritent une attention particulière :

• Email reste le principal vecteur d’attaque. 63 % des personnes interrogées citent email comme vecteur de menace le plus courant, et parmi les entreprises ayant subi des incidents, 67 % ont impliqué email comme canal de compromission.
• Les systèmes d’IA constituent désormais eux-mêmes des surfaces d’incident. 36 % des entreprises déclarent être confrontées à des menaces impliquant spécifiquement des assistants ou des agents IA. Parmi les entreprises victimes d’incidents, 53 % indiquent qu’un système d’IA était directement impliqué.
• Le niveau de préparation aux investigations est dangereusement faible. Seul un tiers des entreprises se disent pleinement prêtes à enquêter sur un incident de sécurité lié à l’IA. 41 % peinent à corréler les menaces entre différents canaux, alors même que cette visibilité transversale est indispensable lorsqu’un agent IA constitue un composant compromis.
• La fragmentation des outils aggrave le problème. 94 % des personnes interrogées jugent la gestion de plusieurs outils de sécurité au moins modérément difficile, et plus de la moitié la décrivent comme très ou extrêmement difficile. Cette surcharge opérationnelle dégrade à la fois la rapidité de réponse et la visibilité dont les entreprises ont besoin lorsqu’un incident survient.

Pourquoi c’est important

Le secteur de la sécurité passe depuis des années à ajuster ses défenses face à des acteurs malveillants humains qui exploitent des utilisateurs humains. Les systèmes d’IA introduisent une troisième variable : une entité automatisée, de confiance et privilégiée, qui fonctionne à la vitesse des machines et peut être manipulée, mal configurée ou compromise directement. Le défi est renforcé par le fait que peu d’entreprises ont développé les playbooks de réponse aux incidents, la couverture de journalisation ou les outils d’investigation nécessaires pour analyser un agent IA compromis ou détourné.

Les données montrent que l’approche actuelle, qui consiste à déployer largement l’IA tout en ajoutant autour d’elle des contrôles de sécurité classiques, ne fonctionne pas. La moitié des entreprises disposant déjà de contrôles ont tout de même subi des incidents. Ce n’est pas une base acceptable.

Les conclusions de Proofpoint mettent en avant trois lacunes concrètes à traiter en priorité : la couverture de formation (47 % des personnes interrogées n’ont pas reçu de formation suffisante en sécurité de l’IA), la visibilité sur l’activité de l’IA et des agents (42 % signalent des lacunes à ce niveau) et l’alignement de la gouvernance entre les équipes (41 % font état d’un manque d’alignement). Il ne s’agit pas de problèmes exotiques d’ingénierie de sécurité. Ce sont des lacunes organisationnelles et de processus qui peuvent être corrigées sans attendre que le marché des outils arrive à maturité.

Incidents majeurs et événements du secteur

« Copy Fail » (CVE-2026-31431) : un bug vieux de neuf ans dans le kernel Linux accorde un accès root à n’importe quel utilisateur local

Le 29 avril 2026, l’entreprise de sécurité Theori a rendu publique la CVE-2026-31431, une vulnérabilité d’élévation locale de privilèges dans le kernel Linux désormais connue sous le nom de « Copy Fail ». La faille avait été signalée à l’équipe de sécurité du kernel Linux cinq semaines plus tôt, le 23 mars, avec des correctifs disponibles dans la semaine suivant ce signalement et des correctifs upstream intégrés le 1er avril. Bleeping Computer a couvert la divulgation publique, et The Hacker News a confirmé indépendamment l’étendue et la gravité du problème.

La vulnérabilité présente un score CVSS de 7,8 et affecte pratiquement toutes les grandes distributions Linux exécutant des kernels publiés depuis 2017, jusqu’à la version 6.19.12 incluse. Les distributions confirmées comme affectées comprennent Ubuntu, Amazon Linux, RHEL, SUSE, Debian, Arch, AlmaLinux et d’autres encore dans l’écosystème Linux au sens large. Son périmètre est vaste.

La cause profonde est un bug logique dans le modèle cryptographique authencesn du kernel Linux, introduit lorsqu’une optimisation de tampon en place a été ajoutée en 2017 aux routines de chiffrement AEAD (Authenticated Encryption with Associated Data) du kernel. En combinant l’interface socket AF_ALG avec l’appel système splice(), un utilisateur local non privilégié peut déclencher une écriture contrôlée de 4 octets dans le page cache de n’importe quel fichier lisible du système. Lorsqu’elle vise un binaire setuid-root, l’issue est un accès root. Theori l’a démontré à l’aide d’un script Python de 732 octets, en affirmant une fiabilité d’exploitation de 100 % sur les distributions concernées.

Les versions corrigées du kernel sont 6.18.22, 6.19.12 et 7.0. Ubuntu 26.04 (Resolute) et les versions ultérieures ne sont pas affectées. Pour les systèmes sur lesquels une mise à niveau immédiate du kernel n’est pas possible, la mesure d’atténuation intermédiaire recommandée consiste à désactiver de manière persistante le module de kernel algif_aead. La CISA a ajouté CVE-2026-31431 à son catalogue Known Exploited Vulnerabilities (KEV), confirmant une exploitation active dans la nature et fixant au 15 mai 2026 la date limite de remédiation pour les systèmes fédéraux.

Pourquoi c’est important

Les vulnérabilités d’élévation locale de privilèges sont souvent considérées comme moins prioritaires que l’exécution de code à distance, car elles exigent déjà un certain niveau d’accès. En pratique, cette lecture sous-estime régulièrement leur importance réelle. Dans les environnements Cloud, les infrastructures conteneurisées et les scénarios d’hébergement mutualisé, la barrière à un accès « local » est souvent plus faible qu’il n’y paraît : une application web compromise, un compte à faibles privilèges obtenu par phishing ou une évasion de conteneur peuvent tous fournir le point d’appui à partir duquel une élévation locale de privilèges devient un accès root.

Cette faille présente en outre la particularité d’exister dans des kernels Linux en production depuis 2017. Neuf années d’infrastructures stables et largement déployées, exposées à une voie fiable et désormais publique vers un accès root, représentent une fenêtre d’exposition significative. Les entreprises doivent traiter ce point comme une priorité élevée de patching, malgré la qualification « locale uniquement » du score CVSS, en particulier pour les workloads Cloud, les systèmes de développement et tout environnement dans lequel plusieurs utilisateurs ou services partagent l’accès au kernel sous-jacent.

OpenAI révèle une exposition limitée liée à l’attaque de supply chain visant Axios npm

Comme nous l’avions expliqué dans l’édition d’avril de ce rapport, le 31 mars 2026, des acteurs malveillants nord-coréens ont publié sur le registre des versions malveillantes du package Axios npm, restées disponibles environ trois heures avant d’être détectées puis supprimées. OpenAI a depuis révélé que sa propre infrastructure figurait parmi les environnements exposés.

La version malveillante d’Axios (1.14.1) s’est exécutée dans un workflow GitHub Actions chez OpenAI le 31 mars. Ce workflow était lié aux certificats de signature de code utilisés pour authentifier les applications desktop d’OpenAI. OpenAI affirme n’avoir trouvé aucune preuve d’accès à des données utilisateur, de compromission de ses systèmes ou de sa propriété intellectuelle, ni d’altération de ses logiciels publiés. L’exposition s’est limitée à l’infrastructure de certificats touchée par le workflow concerné.

La réponse d’OpenAI s’est concentrée sur la rotation des certificats touchés. En conséquence, les anciennes versions des applications desktop OpenAI pour macOS ne recevront plus de mises à jour et pourraient cesser complètement de fonctionner à compter du 8 mai 2026. Les personnes utilisant d’anciennes versions doivent les mettre à jour.

Selon les propres informations d’OpenAI, la cause profonde était une mauvaise configuration dans le workflow GitHub Actions : le workflow pointait vers une floating tag au lieu d’un hash de commit précis et aucune politique minimumReleaseAge n’était configurée pour les versions entrantes de packages. Il s’agit dans les deux cas de pratiques standard de durcissement de la supply chain qui auraient empêché l’exécution du package malveillant dans ce pipeline.

Pourquoi c’est important

La divulgation d’OpenAI mérite d’être examinée au-delà du simple message d’exposition limitée, pour plusieurs raisons.

Premièrement, elle illustre en termes concrets le rayon d’impact réel de l’attaque Axios. Les certificats de signature de code d’OpenAI ne constituent pas une infrastructure périphérique. Si ces certificats avaient été remplacés discrètement par des valeurs contrôlées par l’attaquant, la capacité qui en aurait découlé aurait inclus la diffusion de mises à jour logicielles malveillantes se présentant comme des applications OpenAI légitimement signées. C’est une capacité importante à détenir, même brièvement, même si l’enquête d’OpenAI n’a trouvé aucune preuve d’exploitation.

Deuxièmement, la cause profonde est à la fois courante et totalement évitable. Le fait de pointer vers des floating tags plutôt que vers des hash de commit précis dans des pipelines CI/CD constitue un risque de supply chain largement documenté. Le fait qu’une entreprise disposant des ressources et de l’attention portée à la sécurité d’OpenAI ait eu cette mauvaise configuration dans un workflow sensible, proche des certificats, rappelle utilement que les lacunes d’hygiène de supply chain ne sont pas réservées aux équipes sous-dotées.

Troisièmement, la date de fin de support du 8 mai pour les anciennes versions de l’application macOS constitue une conséquence concrète et sensible dans le temps. Les entreprises qui utilisent les outils desktop OpenAI dans leur environnement doivent traiter ce point comme une mise à jour logicielle immédiate, à la fois pour conserver le fonctionnement du service et pour vérifier qu’elles exécutent des logiciels signés avec la nouvelle chaîne de certificats propre.

Prévisions pour les mois à venir

• Les incidents liés à l’IA vont augmenter à mesure que les déploiements agentiques montent en puissance. Les données de Proofpoint montrent que les entreprises les plus avancées dans le déploiement de l’IA subissent déjà davantage d’incidents. À mesure que l’adoption des agents autonomes passe de 76 % en phase pilote à des déploiements de production plus larges, la surface d’attaque augmentera en conséquence. Il faut s’attendre à la fois à des abus opportunistes de données accessibles à l’IA et à des attaques plus ciblées contre les identifiants des agents IA et l’accès aux API.
• La vulnérabilité Copy Fail apparaîtra dans les rapports d’activité post-compromission. Les mises à niveau du kernel exigent des fenêtres de maintenance planifiées dans les infrastructures Cloud et on-premise, ce qui signifie que de nombreux systèmes resteront vulnérables pendant des semaines. Un proof of concept public de 732 octets, présenté comme fiable à 100 %, constitue un outil de post-exploitation attractif. Il faut s’attendre à voir CVE-2026-31431 apparaître dans les investigations d’incidents au cours des prochains mois.
• Les opérations nord-coréennes de supply chain vont continuer à s’intensifier. L’attaque Axios montre une volonté de cibler des infrastructures de développement fondamentales avec une large portée. La séquence formée par Contagious Interview puis l’attaque Axios traduit une progression délibérée vers des cibles à plus fort impact. D’autres attaques contre des packages open source largement utilisés, des outils CI/CD ou des infrastructures d’identifiants de développeur constituent une suite logique.
• La sécurité des pipelines CI/CD retiendra davantage l’attention des entreprises. La divulgation par OpenAI de cette mauvaise configuration liée à une floating tag est le type d’exemple concret, associé à une entreprise nommée, qui déclenche des revues de sécurité internes. Il faut s’attendre à ce que les équipes de sécurité planifient dans les prochains mois des audits de durcissement des pipelines, avec une attention particulière portée aux contrôles de supply chain pour les workflows sensibles impliquant la signature de code et la publication de releases.
• La diffusion de Malware sans fichier et résidant en mémoire va continuer à progresser. La campagne Remcos RAT que nous avons documentée montre que les campagnes efficaces n’exigent pas de techniques nouvelles. Les chaînes d’exécution multicouches et sans fichier deviennent la norme, et non l’exception. Les stratégies de détection qui reposent sur l’analyse de fichiers déposés sur le disque continueront à prendre du retard à mesure que les opérateurs affinent des approches comme celle que nous avons observée.

Recommandations du mois

• Appliquez immédiatement le correctif de CVE-2026-31431 (Copy Fail) sur tous les systèmes Linux concernés. Donnez la priorité aux workloads Cloud, aux systèmes de développement et à tout environnement dans lequel un accès partagé au kernel existe. Pour les systèmes qui ne peuvent pas être corrigés immédiatement, désactivez le module de kernel algif_aead à titre de mesure d’atténuation intermédiaire. Ne considérez pas le vecteur d’attaque « local uniquement » comme une justification pour retarder le patching : le rayon d’impact d’une élévation locale de privilèges dépend de ce à quoi un attaquant a déjà accès, et non de la classification de la vulnérabilité.
• Mettez à jour toutes les applications desktop OpenAI pour macOS. Les anciennes versions ne recevront plus de mises à jour et peuvent cesser de fonctionner. Les entreprises qui utilisent les outils OpenAI dans leur environnement doivent traiter ce point comme une mise à jour logicielle urgente et vérifier que les versions mises à jour exécutent des logiciels signés avec la chaîne de certificats renouvelée.
• Auditez les pipelines CI/CD pour identifier l’usage de floating tags et l’absence de politiques d’ancienneté minimale des packages. La cause profonde de l’incident OpenAI, à savoir un workflow GitHub Actions sensible pointant vers une floating tag plutôt que vers un hash de commit précis, est une mauvaise configuration courante et corrigeable. Passez en revue tous les pipelines traitant des opérations sensibles (signature de code, publication de releases, accès aux identifiants) afin de détecter ce schéma. Veillez aussi à configurer, lorsque c’est possible, des politiques minimumReleaseAge pour la consommation de packages npm.
• Déployez une Security Awareness Training couvrant les chaînes de phishing sans fichier. La campagne Remcos RAT documentée par notre Threat Intelligence Lab contourne l’analyse classique des pièces jointes en diffusant des chaînes d’exécution plutôt que des charges utiles. Les collaborateurs doivent comprendre qu’un email au format professionnel avec une pièce jointe d’archive n’est pas nécessairement sûr, même lorsqu’aucun exécutable évident n’est visible. Une formation permettant de reconnaître les leurres liés aux bons de commande et les pièces jointes d’archives inattendues provenant d’expéditeurs inconnus constitue un contrôle concret et utile.
• Menez un audit structuré de la sécurité de l’IA couvrant les lacunes de formation, de visibilité et de gouvernance. Les recherches de Proofpoint ont identifié trois lacunes fréquentes et traitables dans les entreprises qui subissent des incidents liés à l’IA : une formation insuffisante (47 %), un manque de visibilité sur l’activité de l’IA et des agents (42 %) et un défaut d’alignement de la gouvernance entre les équipes (41 %). Chacun de ces points peut être traité sans attendre la maturité d’outils de sécurité IA spécialisés. Une revue structurée de l’usage des outils d’IA, des accès dont ils disposent, de la manière dont leur activité est journalisée et des politiques qui encadrent leur usage constitue un point de départ réaliste et atteignable pour la plupart des entreprises.

---

À propos d’Hornetsecurity

Hornetsecurity est l’un des principaux fournisseurs mondiaux de solutions de sécurité, de conformité, de sauvegarde et de sensibilisation à la sécurité basées sur le cloud de nouvelle génération, qui aident les entreprises et les organisations de toutes tailles dans le monde entier. Son produit phare, 365 Total Protection, est la solution de sécurité en cloud pour Microsoft 365 la plus complète du marché. Poussée par l’innovation et l’excellence en matière de cybersécurité, Hornetsecurity construit un avenir numérique plus sûr et des cultures de sécurité durables grâce à son portefeuille primé. Hornetsecurity est présent dans plus de 120 pays grâce à son réseau de distribution international, de plus de 12 000 partenaires de distribution et MSP. Ses services haut de gamme sont utilisés par plus de 125 000 clients. Pour plus d’informations, visitez le site www.hornetsecurity.com.