Monthly Threat Report avril 2026

Introduction

Le Rapport mensuel sur les menaces de Hornetsecurity vous présente chaque mois des analyses sur les tendances de sécurité de Microsoft 365, les menaces véhiculées par email et l’actualité du secteur de la cybersécurité. Cette édition du Rapport mensuel sur les menaces porte sur les événements marquants du secteur au cours du mois de mars 2026.

Résumé exécutif

• Un seul identifiant volé a permis d’effacer environ 80 000 appareils chez Stryker, à la faveur d’un abus de Microsoft Intune par le groupe Handala, lié à l’Iran. Le groupe a affirmé que l’attaque avait touché des bureaux dans 79 pays. Les plateformes de gestion des appareils constituent désormais une surface d’attaque de premier plan.
• Le ransomware Medusa a contraint 35 cliniques à fermer et a privé l’University of Mississippi Medical Center d’accès à son EHR pendant neuf jours. Le seul centre de traumatologie de niveau I de l’État est ainsi resté fortement perturbé, ce qui confirme que le secteur de la santé reste une cible à forte valeur, avec des conséquences concrètes pour la sécurité des patients.
• La Corée du Nord a compromis le package Axios sur npm, l’une des bibliothèques JavaScript les plus utilisées au monde, avec plus de 70 millions de téléchargements hebdomadaires, dans le cadre d’une attaque de supply chain dont la portée aurait pu être énorme si elle n’avait pas été détectée en moins de trois heures.
• La saison fiscale a entraîné plus de 100 campagnes de phishing distinctes. Les attaquants ont déployé des outils RMM pour conserver un accès persistant après compromission, en plus des campagnes classiques de vol d’identifiants, en ciblant simultanément des particuliers et des institutions financières dans plusieurs pays.
• Les environnements de développement et les écosystèmes open source sont de plus en plus dans le viseur. La campagne npm menée dans la durée par la Corée du Nord et l’attaque contre Axios montrent ensemble une stratégie délibérée et de plus en plus mature visant à compromettre les développeurs pour accéder plus largement aux infrastructures.
• La prolifération des permissions dans SharePoint représente un risque systémique et largement invisible dans la plupart des entreprises. Les groupes imbriqués, les libellés de permissions falsifiés, les liens de partage anonymes persistants et les bibliothèques de documents cachées créent une exposition que les processus d’audit standards détectent rarement et que les procédures de départ des collaborateurs laissent souvent subsister.

Vue d’ensemble des menaces

Les dangers cachés du surpartage dans SharePoint

Microsoft SharePoint est au cœur de la manière dont la plupart des entreprises stockent, partagent et exploitent leurs documents internes en mode collaboratif. Cette place centrale en fait une cible de grande valeur, mais le risque le plus fréquent et le plus sous-estimé n’est pas une intrusion externe. Il s’agit plutôt d’une accumulation lente de permissions excessives et mal comprises, créée en interne au fil du temps.

Dans la plupart des environnements SharePoint, la croissance se fait de manière organique, au fil des activités quotidiennes. Des fichiers sont partagés, des dossiers sont imbriqués, des groupes sont créés puis oubliés, et des liens invités sont générés pour une collaboration ponctuelle sans jamais être révoqués. Le résultat est un paysage de permissions qu’aucun administrateur ne peut visualiser complètement ni auditer avec assurance à l’aide des outils natifs. D’après les propres recherches de Hornetsecurity, une entreprise d’environ 400 employés peut accumuler 2 millions de fichiers dans SharePoint avec plus de 100 000 droits d’accès distincts. À cette échelle, suivre manuellement qui a accès à quoi devient pratiquement impossible.

Ce manque de visibilité crée plusieurs risques de sécurité précis qu’il est utile de comprendre en détail.

Les groupes imbriqués masquent les accès réels

SharePoint n’affiche pas l’appartenance à un groupe lorsqu’un administrateur consulte une entrée de permission. De plus, les groupes existent à deux endroits distincts : Microsoft Entra ID et les anciens SharePoint Groups. Un administrateur qui examine des permissions peut voir un nom de groupe sans disposer d’un moyen concret pour savoir qui en fait réellement partie, ni si ce groupe contient d’autres groupes qui étendent encore davantage les accès. Des attaquants disposant d’un niveau quelconque d’accès administratif peuvent exploiter ce point de manière délibérée en enfouissant des accès dans des structures de groupes imbriqués qui survivent même à des tentatives actives de révocation.

Les libellés de permissions peuvent être falsifiés

SharePoint permet de renommer les niveaux de permission indépendamment des permissions réellement accordées. Un niveau de permission configuré pour donner un contrôle total peut, par exemple, porter le libellé « Lecture ». SharePoint affiche le libellé, et non les permissions sous-jacentes. Les administrateurs qui vérifient les accès ne peuvent donc pas se fier à ce qu’ils voient sans examiner directement la configuration.

Les liens de partage anonymes persistent par défaut

Les paramètres par défaut de Microsoft 365 génèrent des liens de partage anonymes pour les fichiers partagés via Teams. Ces liens restent actifs même après qu’une entreprise tente de retirer l’accès d’un utilisateur, créant ainsi une voie d’exfiltration durable et largement invisible que les processus de départ standards oublient souvent.

Les bibliothèques de documents cachées permettent une exfiltration discrète des données

Les utilisateurs disposant de permissions élevées dans SharePoint peuvent créer des bibliothèques de documents invisibles pour les autres membres, y copier des fichiers sensibles et accorder un accès à des invités externes. Cela permet une exfiltration de données durable et discrète, sans piste d’audit évidente.

Pourquoi c’est important

La conséquence concrète de ces risques est que la plupart des entreprises n’ont pas, à un instant donné, une vision exacte de qui peut accéder à quoi dans leur environnement SharePoint. Et cette réalité dépasse largement la seule question de conformité.

Du point de vue des menaces internes, des employés sur le départ ou mécontents peuvent conserver un accès grâce à des appartenances à des groupes imbriqués ou à des liens anonymes qui survivent aux processus de départ standards. Le blocage de la connexion M365, étape initiale la plus courante lors du départ d’un collaborateur, est lent et n’invalide pas immédiatement toutes les voies d’accès. Un employé qui connaît bien l’environnement peut exploiter cette fenêtre.

Du point de vue d’un attaquant externe, toute compromission de compte dans un environnement où les permissions SharePoint sont très étendues produit un rayon d’impact bien plus large qu’il ne devrait l’être. Un seul compte compromis, doté de permissions que personne n’a auditées, peut donner accès à des années de documents internes sensibles répartis dans plusieurs départements.

Nous recommandons aux entreprises de traiter l’hygiène des permissions SharePoint comme un contrôle de sécurité permanent et non comme une opération de nettoyage ponctuelle. Auditer l’appartenance aux groupes imbriqués, examiner et révoquer les anciens liens invités, valider la configuration des niveaux de permission et définir des politiques sur l’approbation et la durée de partage externe sont autant de mesures concrètes qui réduisent nettement l’exposition, sans attendre qu’un incident de sécurité serve de déclencheur.

La saison fiscale entraîne une hausse des campagnes de phishing visant les contribuables et les institutions financières

Chaque année, à l’approche de la saison fiscale, les acteurs de la menace exploitent de manière prévisible la combinaison du stress financier, de l’urgence liée aux échéances et du volume important de communications sensibles échangées entre particuliers, employeurs et administrations. Mars 2026 n’a pas fait exception. L’équipe de recherche sur les menaces de Proofpoint a documenté plus de 100 campagnes de phishing distinctes sur le thème fiscal actives au début de 2026, ce qui représente une hausse sensible à la fois en volume et en variété par rapport aux saisons fiscales précédentes.

Ces campagnes se répartissaient en deux grandes catégories. La première usurpait l’identité des autorités fiscales, le plus souvent l’IRS, au moyen de leurres évoquant des documents fiscaux expirés, des remboursements en attente ou une vérification de compte obligatoire. Ces campagnes visaient à voler des identifiants ou à installer des outils RMM, comme Datto, N-Able, RemotePC et ScreenConnect, afin d’obtenir un point d’ancrage persistant sur les machines des victimes bien au-delà de l’interaction initiale. La seconde catégorie ciblait directement des institutions financières, au moyen de kits de phishing d’identifiants visant les clients de banques et de prestataires de services financiers dans plusieurs pays, notamment au Canada, en Australie, à Singapour, en Suisse et au Japon, parmi les plus visés.

Les recherches de Proofpoint ont aussi identifié des acteurs de la menace qui diffusaient des malwares de type information stealer via des leurres liés à la fiscalité, ce qui indique que certains opérateurs recherchent moins l’accès à un compte que la collecte en masse d’identifiants et de jetons de session destinés à être revendus ou réutilisés.

Pourquoi c’est important

Le phishing lié à la saison fiscale n’a rien de nouveau, mais l’ampleur et la sophistication observées cette année méritent une attention particulière pour plusieurs raisons.

L’usage d’outils RMM comme charge utile après compromission marque une évolution notable par rapport à l’approche centrée uniquement sur le vol d’identifiants qui dominait historiquement les campagnes liées aux leurres fiscaux. Les outils RMM sont des logiciels légitimes. Les solutions de détection sur endpoint ne les signalent donc souvent pas, et une fois installés, ils donnent aux attaquants un accès distant persistant, à la demande, qu’ils peuvent réutiliser longtemps après la fin de la campagne d’origine. Une entreprise dont un employé a installé une instance RMM contrôlée par un attaquant fin mars peut ne découvrir le problème d’accès que plusieurs mois plus tard.

L’étendue géographique des institutions financières ciblées mérite également d’être soulignée. Ces campagnes ne se concentrent pas sur un seul marché. Les attaquants mènent en parallèle des opérations dans plusieurs régions et adaptent leurs leurres ainsi que leurs kits de phishing aux institutions locales et aux calendriers de déclaration. Les entreprises présentes dans plusieurs pays doivent s’assurer que leurs formations de sensibilisation à la sécurité couvrent les variantes régionales des leurres, et pas uniquement les contenus usurpant l’IRS.

Au niveau de l’utilisateur, la recommandation est simple : les autorités fiscales et les institutions financières n’initient pas de contact par le biais de liens ou de pièces jointes non sollicités dans des emails. Toute communication prétendant présenter un caractère urgent lié à une déclaration, un remboursement ou une vérification de compte doit être considérée avec prudence et vérifiée directement par les canaux officiels.

Incidents majeurs et événements du secteur

Le groupe Handala, lié à l’Iran, détruit environ 80 000 appareils chez Stryker à l’aide de Microsoft Intune

À la mi-mars, une cyberattaque destructrice contre le géant des technologies médicales Stryker a montré à quel point le calcul du risque autour des plateformes de gestion des appareils a changé. Le groupe hacktiviste Handala, lié à l’Iran, attribué au ministère iranien du Renseignement et de la Sécurité (MOIS) et suivi par les chercheurs en sécurité sous le nom de Void Manticore, a compromis un seul compte administrateur Stryker et l’a utilisé pour lancer une commande de suppression à distance de masse via Microsoft Intune, détruisant les installations du système d’exploitation dans toute l’entreprise. Des chercheurs en sécurité ont confirmé qu’environ 80 000 appareils Windows avaient été effacés, tandis que Handala a affirmé que l’attaque avait touché plus de 200 000 systèmes dans 79 pays, un chiffre qui n’a pas été confirmé de manière indépendante. Stryker a confirmé que l’attaque avait été contenue et que les efforts de restauration étaient en cours. Aucun malware n’a été utilisé. Un seul identifiant volé a constitué l’intégralité du vecteur d’attaque.

CISA a réagi en quelques jours en publiant des recommandations invitant les entreprises à examiner et à renforcer leurs environnements Microsoft Intune, en considérant l’événement comme un signal d’alarme montrant comment une infrastructure cloud de gestion des appareils peut être retournée contre les entreprises qui en dépendent. Krebs on Security a également traité l’attaque en détail, notamment son attribution et les schémas de ciblage plus larges du groupe.

Pourquoi c’est important

L’attaque contre Stryker illustre parfaitement comment une capacité présente dans presque toutes les entreprises modernes peut être utilisée comme arme avec une efficacité dévastatrice. Microsoft Intune est largement déployé précisément parce qu’il centralise la gestion des appareils, simplifie l’application des politiques et facilite l’administration à distance à grande échelle. Ces mêmes caractéristiques signifient aussi qu’un seul compte privilégié compromis peut se traduire directement par un effacement à l’échelle de toute l’entreprise, sans outil supplémentaire, sans mouvement latéral dans les réseaux internes et sans malware à détecter côté endpoint.

Plusieurs éléments rendent ce type d’attaque particulièrement préoccupant :

• L’attaquant n’avait pas besoin d’être sophistiqué. Aucun zero-day, aucun implant avancé, aucune présence de plusieurs mois. D’après ce que l’on sait, un seul identifiant volé a suffi à provoquer une perturbation opérationnelle massive dans une entreprise mondiale.
• Les plateformes de gestion des appareils ne sont généralement pas considérées comme une surface d’attaque de premier niveau. Beaucoup d’entreprises investissent fortement dans le durcissement des identités, des endpoints et des contrôles périmétriques, alors que les plans de gestion qui pilotent ces endpoints reçoivent souvent moins d’attention.
• Les attaques destructrices augmentent. Ce cas s’inscrit dans un schéma opérationnel plus large, dans lequel les acteurs liés à l’Iran privilégient la perturbation opérationnelle et la destruction plutôt qu’un accès discret et durable. Lorsque l’objectif est le dommage et non la collecte de renseignement, la rapidité et la portée destructrice priment sur la discrétion.

Pour toute entreprise utilisant Microsoft Intune, Microsoft Endpoint Configuration Manager ou une autre plateforme MDM comparable, cet incident devrait conduire immédiatement à revoir les détenteurs d’accès administratifs, à vérifier que ces comptes sont protégés par une authentification multifacteur résistante au phishing et à déterminer si les commandes d’effacement des appareils nécessitent une autorisation supplémentaire hors bande avant exécution. Le rayon d’impact d’un compte administrateur MDM compromis n’est plus théorique.

Le ransomware Medusa paralyse l’University of Mississippi Medical Center

Fin février, le gang de ransomware Medusa a compromis l’University of Mississippi Medical Center (UMMC), seul centre de traumatologie de niveau I de l’État et seul hôpital pédiatrique, qui emploie environ 10 000 personnes et prend en charge des patients dans tout l’État. L’attaque a forcé l’UMMC à fermer 35 cliniques, à suspendre les opérations chirurgicales non urgentes et à perdre l’accès à son système Epic de dossiers médicaux électroniques (EHR) pendant neuf jours. Le 12 mars, Medusa a publié le nom de l’UMMC sur son site de fuite du dark web, affirmant détenir un grand volume de données exfiltrées, dont des informations de santé sur les patients, et a fixé une échéance de rançon de 800 000 dollars au 20 mars.

Le groupe a aussi revendiqué Passaic County, dans le New Jersey, au cours de la même période de publication, ce qui montre qu’il continue de cibler en parallèle les secteurs de la santé et des administrations.

Pourquoi c’est important

Cette attaque illustre une fois de plus de manière très concrète les conséquences qu’un ransomware peut avoir sur la sécurité des patients dans les environnements de santé. La perte d’accès à l’EHR ne provoque pas seulement des difficultés administratives. Elle perturbe les workflows de soins, oblige les cliniciens à revenir à des procédures papier et peut avoir un effet direct sur les décisions thérapeutiques. Dans un centre de traumatologie de niveau I, de tels retards ont des conséquences graves.

Medusa figure parmi les opérations de ransomware les plus actives de ces derniers mois, et la poursuite de son ciblage des secteurs de la santé et du service public répond à une logique calculée. Ces organisations disposent souvent de budgets IT de sécurité contraints, subissent une forte pression pour rétablir rapidement l’activité et traitent des données suffisamment sensibles pour offrir un fort levier d’extorsion. Dans l’économie du ransomware, ce sont des cibles à forte pression.

Quelques enseignements méritent d’être soulignés :

• Les groupes de ransomware ne sont pas freinés par la dimension humanitaire de leurs cibles. Les organisations de santé ne doivent pas supposer que leur mission les protège. L’opération Medusa a montré à plusieurs reprises que les hôpitaux, les centres de traumatologie et les services publics sont perçus comme des cibles productives, et non comme des zones interdites.
• La résilience des plateformes EHR mérite une attention spécifique. Epic et les systèmes cliniques comparables à l’échelle de l’entreprise représentent des points uniques de défaillance pour les opérations cliniques. Les plans de réponse à incident doivent traiter explicitement des scénarios d’indisponibilité de l’EHR, y compris avec des workflows hors ligne testés.
• L’exfiltration précède désormais le chiffrement comme pratique standard. Au moment où le chiffrement est déployé, les données ont généralement déjà quitté l’environnement. La menace d’une exposition publique des données signifie que la restauration depuis les sauvegardes, bien qu’essentielle, ne couvre plus à elle seule toute l’ampleur d’un incident de ransomware.

Les organisations des secteurs de la santé et des services publics doivent considérer l’activité persistante de Medusa comme une menace durable et non comme un événement isolé.

La Corée du Nord compromet le package Axios sur npm dans une attaque de supply chain particulièrement audacieuse

Le 31 mars, deux versions malveillantes du package Axios sur npm ont été publiées sur le registre npm par des acteurs de la menace liés à la Corée du Nord. Axios est l’une des bibliothèques cliente HTTP JavaScript les plus utilisées au monde, avec plus de 70 millions de téléchargements hebdomadaires. Les versions malveillantes (1.14.1 et 0.30.4) contenaient une dépendance injectée, « plain-crypto-js », qui téléchargeait des charges utiles de type RAT depuis une infrastructure de commande et contrôle nord-coréenne. Les packages sont restés disponibles environ trois heures avant d’être détectés et supprimés.

Microsoft a attribué l’attaque à Sapphire Sleet, tandis que Google Threat Intelligence l’a attribuée de manière indépendante à UNC1069. Les deux groupes sont considérés comme des acteurs liés à la Corée du Nord. Le fait que deux grandes organisations de threat intelligence soient parvenues séparément à des conclusions cohérentes sur l’attribution renforce le niveau de confiance de cette évaluation par rapport aux attributions reposant sur une seule source.

Pourquoi c’est important

Les attaques de supply chain visant l’écosystème npm ne sont pas nouvelles, mais le choix d’Axios comme cible constitue une escalade significative. La plupart des campagnes de packages malveillants ciblent des packages obscurs ou ressemblants, à portée limitée, et reposent sur une erreur de téléchargement de la part des développeurs. Cibler un package disposant de la base d’installation d’Axios relève d’une tout autre logique. Si les versions malveillantes étaient restées disponibles plus longtemps, ou si la détection avait été plus lente, l’ampleur potentielle de la compromission dans les environnements cloud, d’entreprise et de développement aurait été énorme.

Cette attaque s’inscrit aussi dans une campagne nord-coréenne plus large et durable contre les développeurs. Comme nous l’avons indiqué dans l’édition précédente de ce rapport, des acteurs nord-coréens mènent depuis un certain temps la campagne « Contagious Interview », en publiant des packages npm malveillants destinés à viser les développeurs crypto, Web3 et IA via de faux contacts de recruteurs. L’attaque contre Axios reprend le même mode opératoire général, mais avec un rayon d’impact potentiel bien plus grand. Au lieu d’espérer que les développeurs installent par erreur un faux package, ces acteurs sont parvenus à s’introduire dans un package que les développeurs utilisent déjà et auquel ils font confiance par défaut.

Plusieurs implications méritent une attention directe :

• La vérification de l’intégrité des packages n’est plus facultative. Les entreprises qui consomment des dépendances open source à grande échelle devraient déployer des outils SCA et surveiller les changements inattendus de dépendances dans les packages sur lesquels elles s’appuient. La fenêtre de trois heures pendant laquelle ces versions malveillantes d’Axios sont restées disponibles est bien trop courte pour une détection manuelle.
• Les opérations nord-coréennes de supply chain gagnent en maturité. La campagne Contagious Interview a montré de la patience et de l’ampleur. L’attaque contre Axios montre une volonté de viser l’infrastructure centrale plutôt que des cibles périphériques. Ensemble, ces deux éléments décrivent un acteur de la menace plus capable et plus offensif dans sa manière de cibler les écosystèmes de développement.
• Le poste de travail du développeur est une cible de grande valeur. Les attaquants qui compromettent l’environnement d’un développeur obtiennent accès au code source, aux identifiants, aux jetons d’API cloud et, dans de nombreux cas, à des accès directs de déploiement. L’exposition en aval provoquée par la compromission d’un seul développeur peut largement dépasser l’utilisateur lui-même.

Nous recommandons vivement de revoir les outils de contrôle d’intégrité des packages npm, d’évaluer l’hygiène des lockfiles dans les projets actifs et de vérifier que tout environnement qui consomme le package Axios exécute bien une version propre et non compromise.

Prévisions pour les prochains mois

• Les plateformes MDM et de gestion des appareils attireront davantage l’attention des attaquants. L’incident Stryker a montré la portée dévastatrice qu’un seul compte administrateur Intune compromis peut avoir. Il faut s’attendre à ce que les acteurs de la menace, en particulier ceux qui recherchent un effet destructeur, examinent les environnements MDM de manière plus délibérée à mesure que ce mode opératoire est mieux compris et reproduit dans l’écosystème de la menace.
• Les opérations destructrices liées à l’Iran vont continuer à s’intensifier. L’attaque de Handala contre Stryker s’inscrit dans un schéma plus large où des acteurs alignés sur l’Iran privilégient la perturbation plutôt que la discrétion. Tant que les tensions géopolitiques resteront élevées, nous nous attendons à la poursuite de campagnes destructrices contre des organisations occidentales, avec comme catégories de cibles probables les plateformes de gestion des appareils, les infrastructures cloud et les technologies opérationnelles.
• Le secteur de la santé restera une cible prioritaire pour les ransomwares. L’attaque de Medusa contre l’UMMC correspond à une tendance durable observée dans l’ensemble du secteur. La combinaison de budgets de sécurité limités, de la pression pour rétablir rapidement les opérations et de données patients hautement sensibles fait des organisations de santé des cibles fiables. Les groupes de ransomware ne changent pas leur logique ici.
• Les opérations nord-coréennes de supply chain vont gagner en ambition. La progression de la campagne Contagious Interview vers l’attaque contre Axios montre un acteur de la menace qui augmente progressivement à la fois l’échelle et la centralité de ses cibles de supply chain. De futures attaques visant des packages open source fondamentaux, des outils CI/CD ou des magasins d’identifiants de développeurs constituent une suite logique.
• Les campagnes fondées sur des leurres fiscaux vont ralentir, mais la persistance via les outils RMM restera. À mesure que les échéances fiscales passent, le volume de phishing sur ce thème diminuera. En revanche, les organisations dont des employés ont interagi avec des campagnes diffusant des outils RMM pendant la haute saison peuvent toujours héberger des accès persistants non détectés. Un contrôle des endpoints et des logiciels d’accès à distance après la saison fiscale est justifié.
• Les plans de gestion SaaS et cloud continueront d’être ciblés. Dans les incidents de ce mois, un fil conducteur apparaît : les attaquants s’en prennent aux outils qui administrent et orchestrent d’autres systèmes, plutôt qu’aux endpoints pris individuellement. Les plateformes MDM, les registres npm et les magasins d’identifiants cloud s’inscrivent tous dans cette logique. Il faut s’attendre à ce que cette focalisation se renforce.

Recommandations mensuelles

• Auditez immédiatement les accès administrateur MDM. Vérifiez qui détient des rôles administratifs dans Microsoft Intune, Microsoft Endpoint Configuration Manager ou toute autre plateforme MDM comparable. Assurez-vous que ces comptes sont protégés par une authentification multifacteur résistante au phishing, appliquez le principe du moindre privilège pour limiter les personnes pouvant lancer des commandes d’effacement en masse et envisagez d’exiger une autorisation supplémentaire hors bande pour les actions destructrices. L’attaque contre Stryker n’a nécessité ni malware ni mouvement latéral. L’hygiène des identifiants des administrateurs MDM est désormais un contrôle critique.
• Traitez l’indisponibilité de l’EHR comme un scénario d’incident défini. Les organisations de santé doivent veiller à ce que leurs plans de réponse à incident couvrent explicitement les scénarios dans lesquels des plateformes cliniques comme Epic sont indisponibles. Les workflows hors ligne doivent être documentés, testés et connus du personnel clinique avant d’être nécessaires sous pression.
• Effectuez un contrôle RMM après la saison fiscale. Si votre entreprise n’a pas bloqué l’installation d’outils RMM via les contrôles endpoint pendant la saison fiscale, auditez maintenant les endpoints pour détecter toute instance non autorisée d’outils comme ScreenConnect, RemotePC, N-Able ou Datto RMM. Un accès RMM installé par un attaquant est discret, persistant et n’expire pas de lui-même.
• Mettez en place des outils SCA dans l’ensemble des pipelines de développement. La fenêtre de trois heures de l’attaque contre Axios est trop courte pour une détection manuelle. Le contrôle approprié consiste à utiliser des outils SCA automatisés qui surveillent les ajouts inattendus de dépendances ou les anomalies de versions de packages. Complétez cela par de bonnes pratiques d’hygiène des lockfiles et par une vérification de l’intégrité des packages critiques.
• Étendez la sensibilisation à la sécurité pour couvrir les schémas de phishing liés à la saison fiscale. Assurez-vous que les utilisateurs comprennent que les autorités fiscales et les institutions financières n’initient pas de contact par des emails non sollicités contenant des liens ou des pièces jointes. La formation doit traiter à la fois des leurres usurpant l’IRS et des campagnes de phishing spécifiques aux institutions visant les comptes financiers personnels des employés, car les deux ont été actives cette saison.
• Renforcez les identités cloud privilégiées sur l’ensemble des plateformes de gestion. L’attaque contre Stryker, le ciblage persistant des développeurs par la Corée du Nord et la tendance plus large aux attaques contre les plans de gestion ont tous pour point d’entrée une compromission d’identifiants. Imposez une authentification multifacteur résistante au phishing pour tous les rôles d’administration cloud, auditez les autorisations OAuth ainsi que les permissions des comptes de service, et surveillez les actions administratives anormales comme contrôle permanent et non comme mesure réactive.

---

À 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.