Les cybercriminels trompent les utilisateurs à travers de fausses applications Microsoft OAuth pour accéder à des comptes Office 365, One Drive, Outlook… Un moyen de contourner les systèmes d’authentification multifacteur.
Les experts de Proofpoint ont découvert un moyen astucieux de la part des cybercriminels pour voler des identifiants. « Le groupe identifié crée de fausses applications Microsoft OAuth (SharePoint ou Docusign) et des redirections vers des URL malveillantes pour ses opérations de phishing visant à au vol d’informations d’identification » explique le fournisseur dans un blog. Il ajoute, « la campagne utilise ces applications comme un leurre et une passerelle pour mener d’autres activités, principalement pour obtenir l’accès à des comptes Microsoft 365 via le phishing MFA ».
Les applications OAuth utilisent la plateforme d’identité de la firme de Redmond (Azure AD/ Entra ID) pour demander l’autorisation d’accéder à des données dans des services comme Microsoft 365, OneDrive, Outlook, Teams ou SharePoint au nom d’un utilisateur.
Un moyen de contourner le MFA
Selon Proofpoint, les applications usurpées utilisaient des noms, des logos et des messages d’autorisation convaincants pour inciter les utilisateurs à approuver l’accès, sans déclencher d’alarme. Lorsqu’une victime cliquait sur « accepter », elle était redirigée par captcha vers une fausse page de connexion Microsoft. L’étape captcha sert de moyen anti-bot pour empêcher les scanners automatisés de repérer l’attaque. En arrière-plan, des kits de phishing comme Tycoon ou ODx capturent à la fois les identifiants de connexion et les jetons de session, utilisés ensuite par les attaquants pour contourner le MFA et obtenir un accès permanent aux comptes Microsoft 365.
« Les campagnes de phishing s’appuient sur des kits de phishing de type AiTM (attacker-in-the-middle) à authentification multifactorielle (MFA) comme Tycoon », ont ajouté les chercheurs. « Ce type d’attaque pourrait être utilisé pour la collecte d’informations, le déplacement latéral, l’installation de malware ou pour mener d’autres campagnes de phishing à partir de comptes compromis », ont-ils précisé. Cette méthode est particulièrement dangereuse, car les jetons OAuth peuvent survivre aux réinitialisations de mot de passe. Même si un utilisateur compromis change son mot de passe, les attaquants peuvent toujours utiliser les autorisations accordées pour accéder aux courriels, aux fichiers et à d’autres services cloud jusqu’à ce que le jeton OAuth soit révoqué. Selon Proofpoint, la campagne a abusé de plus de 50 marques de confiance, y compris des entreprises comme RingCentral, SharePoint, Adobe et DocuSign.
Des mesures de Microsoft pour réduire la menace
Dans le cadre de cette campagne, des milliers de messages malveillants ont été envoyés à partir de comptes professionnels compromis, chacun usurpant l’identité d’entreprises bien connues. Certains leurres demandaient des autorisations d’apparence anodine comme « voir votre profil » et « maintenir l’accès aux données auxquelles vous avez donné accès ». Proofpoint a signalé les applications incriminées à Microsoft au début de l’année 2025, notant que les prochaines modifications des paramètres par défaut de Microsoft 365, annoncées par l’éditeur en juin 2025, devraient limiter considérablement la capacité des attaquants à abuser de l’accès aux applications tierces. Les actualisations ont commencé à être déployées à la mi-juillet et devraient être terminées en août 2025. Microsoft n’a pas répondu immédiatement à la demande de commentaires.
Proofpoint recommande de mettre en œuvre des mesures efficaces de prévention des compromissions de messagerie, de bloquer les accès non autorisés dans les environnements cloud et d’isoler les liens potentiellement malveillants dans les courriels pour garder une longueur d’avance sur la campagne. De plus, la sensibilisation des utilisateurs aux risques de sécurité de Microsoft 365 et le renforcement de l’authentification à l’aide de clés de sécurité physiques basées sur FIDO pourraient s’avérer utiles. Les identifiants d’application Microsoft OAuth malveillants et les empreintes digitales Tycoon observés dans la campagne ont également été partagés afin d’établir une détection.
Baptisée Fire Ant, une campagne d’espionnage soutenue par la Chine exploite des failles dans l’hyperviseur ESXi de VMware. Elle touche les instances non corrigées pour contourner les défenses et persister au sein des cibles.
L’hyperviseur de type 1 ESXi de VMware a le vent en poupe auprès des cybercriminels. Après le gang de ransomware Scattered Spider, c’est autour d’une campagne d’espionnage nommée Fire Ant de s’en prendre à l’outil de virtualisation. Soutenue par la Chine, elle a été démasquée par les équipes de Sygnia, spécialiste de la sécurité et elle est active depuis le début de 2025. Les cyber-espions exploitent des failles critiques dans les environnements VMware pour gagner un accès non authentifié à l’infrastructure de virtualisation et déployer des logiciels malveillants persistants comme VirtualPita et autobackup.bin.
Selon Ev Kontsevoy, CEO de Teleport (éditeur de solutions de PAM), ce vecteur d’attaque est classique des Etats. « Fire Ant exploite les vulnérabilités des infrastructures et utilise des identifiants volés pour infiltrer les systèmes », a-t-il déclaré. « Cette tactique n’est pas exceptionnelle. En raison de son efficacité et de sa difficulté à être détectée, de nombreux groupes affiliés à des États adoptent désormais la même approche. » Même si l’entreprise de services de cybersécurité n’a pas voulu attribuer cette campagne à un acteur spécifique, elle note que les outils, les vecteurs d’attaque axés sur VMware, le temps de travail et les frappes au clavier correspondent étroitement aux conclusions précédentes sur le groupe UNC3886 lié à la Chine.
Un accès initial via les failles de VMWare
Les attaquants se sont servis de la vulnérabilité CVE-2023-34048 dans VMware vCenter pour exécuter du code à distance sans authentification (RCE), avant de récupérer les informations d’identification des comptes de service « vpxuser », créés automatiquement par vCenter pour gérer les hôtes ESXi avec des privilèges d’administration complets. Comme vpxuser est exempté des restrictions du mode verrouillage, les attaquants pouvaient conserver le contrôle au niveau de l’hôte sur tous les serveurs ESXi connectés, les machines physiques exécutant l’hyperviseur ESXi, même si les connexions directes étaient désactivées. Avec ces privilèges d’administration complets, les attaquants ont implanté des portes dérobées persistantes telles que VirtualPita et autobackup.bin, et ont désactivé le daemon de journalisation du système (vmsyslogd) afin de couvrir leurs traces lors des redémarrages.
Kontsevoy qualifie cela d’échec de la gestion des identités. « Les attaquants ont utilisé des identifiants volés pour créer des portes dérobées et imiter les actions légitimes des employés à l’aide d’outils courants et fiables », a-t-il fait remarquer. « En effet, une fois qu’une identité franchit une frontière technologique, sa trace est perdue. Personne ne peut voir où elle va ensuite. Ce manque de visibilité donne aux portes dérobées la capacité de passer inaperçues et aux attaquants de réintégrer l’infrastructure sans être détectés. » De plus, les attaquants ont exploité la vulnérabilité CVE-2023-20867 pour exécuter des commandes hôte-invité non authentifiées via VMware Tools/PowerCLI, accédant ainsi aux machines virtuelles invitées et extrayant les identifiants de domaine en mémoire.
Un mouvement latéral grâce au tunneling
Une fois à l’intérieur, Fire Ant a contourné la segmentation du réseau en exploitant la vulnérabilité CVE-2022-1388 dans les équipements F5 BIG-IP, et ils ont pu ainsi déployer des tunnels cryptés tels que les web shells Neo-reGeorg pour atteindre des environnements isolés, en tirant même parti de l’IPv6 pour contourner les filtres IPv4. « L’acteur malveillant a montré qu’il avait une compréhension approfondie de l’architecture et des politiques réseau de l’environnement cible, contournant efficacement les contrôles de segmentation pour atteindre des actifs internes, vraisemblablement isolés », a déclaré Sygnia dans son blog. « En compromettant l’infrastructure réseau et en créant des tunnels à travers des systèmes de confiance, l’acteur malveillant a systématiquement contourné les limites de segmentation, atteint des réseaux isolés et établi une persistance trans-sectorielle. » Les attaquants ont constamment adapté leurs techniques, en modifiant par exemple les outils, en dissimulant les fichiers et en déployant des portes dérobées redondantes, afin d’échapper à la détection et de retrouver l’accès après le nettoyage.
Sygnia a conseillé aux entreprises de corriger les composants VMware vulnérables, de faire tourner les identifiants des comptes de service sécurisés et d’appliquer le mode de verrouillage ESXi pour restreindre l’accès à l’hôte. Le fournisseur recommande également d’utiliser des Jump Hosts d’administration dédiés, de segmenter les réseaux de gestion et d’étendre la surveillance pour inclure vCenter, ESXi et les équipements qui manquent souvent de visibilité traditionnelle sur les terminaux. « La seule façon d’empêcher les pirates soutenus par des Etats et autres criminels d’accéder facilement aux infrastructures est d’unifier les identités », a ajouté M. Kontsevoy. « En fédérant toutes les identités, qu’elles soient humaines, logicielles, matérielles ou artificielles, les entreprises peuvent obtenir une source unique de vérité et une visibilité complète sur l’entrée et la circulation des identités dans leurs systèmes. »
Des pirates francophones ont mené une campagne de scan sur des sites web. En exploitant des failles et des mauvaises configurations, ils ont accédé aux données sensibles de milliers de clients de services AWS. Ils utilisent les mêmes outils que le groupe ShinyHunters aujourd’hui disparu.
Selon deux chercheurs en cybersécurité, Noam Rotem et Ran Locar, une opération menée par un groupe de cybercriminel baptisé Nemesis (qui reprend les techniques du groupe ShinyHunters) a abouti à la violation de 2 To de données appartement à des milliers de clients AWS. Les informations dérobées portaient sur les clients, des identifiants AWS et du code source. « Dans le cadre d’une campagne de grande envergure, les pirates ont scanné des millions de sites web et exploité les…
Il vous reste 91% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
L’éditeur Securiti a présenté Gencore AI, un outil qui s’appuie sur les capacités existantes de sécurité et de conformité des données pour l’adapter à la protection et à la gouvernance de l’IA générative.
La sécurité des systèmes d’IA génératives, des copilotes ou des agents IA monte en puissance. Pour répondre à cette problématique, Securiti vient de lancer Gencore AI, un outil pour contrôler et sécuriser les données de l’entreprise servant aux solutions créant des modèles d’IA. « La connexion sécurisée aux systèmes de données, avec la garantie que les contrôles et la gouvernance sont respectés tout au long du pipeline d’IA, est le principal obstacle au déploiement à grande échelle de systèmes d’IA générative dans les entreprises », a déclaré Rehan Jalil, le CEO de Securiti.
« Constatant que la majorité des données d’entreprise sont des données non structurées, il est essentiel de gouverner et de contrôler ces actifs quand ces données sont exploitées pour alimenter l’IA », a-t-il expliqué. « Par ailleurs, comme les technologies de Gencore AI sont propriétaires, les entreprises peuvent se connecter en toute sécurité à des centaines de systèmes de données tout en préservant les contrôles et la gouvernance des données », a-t-il ajouté.
Des graphes de connaissances maison
En s’appuyant sur les contrôles de sécurité existants, Gencore AI de Securiti construit des systèmes d’IA alignés sur les politiques et les exigences règlementaires de l’entreprise pour protéger les données sensibles contre les attaques malveillantes. « Avec Gencore AI, les entreprises peuvent construire facilement et rapidement des systèmes d’IA sécurisés de niveau entreprise », a fait valoir Rehan Jalil. « L’outil est alimenté par un graphe de connaissances unique qui maintient des informations granulaires et contextuelles sur les données et les systèmes d’IA ». Le graphe de connaissances unique auquel fait référence le dirigeant s’appelle « Data Command Graph », ou graphe de commande des données.
« La fonction tire parti de la capacité de Securiti à découvrir « les données sensibles et les systèmes d’IA à travers une série de cloud publics, des cloud de données, de cloud privés et d’applications SaaS, sur la base de centaines de classificateurs intégrés et de plus de 400 connecteurs natifs. », a-t-il détaillé. Apparemment, ce graphe fournira des informations granulaires jusqu’au niveau du fichier, de la colonne, de la ligne ou du CLOB (Character Large Objects), en prenant en charge des « milliards de nœuds ». Cette fonctionnalité peut faciliter le traitement d’énormes quantités de données non structurées, en plus des données structurées, sur lesquelles les entreprises forment généralement leurs modèles intelligents.
Un pare-feu LLM avec des capacités contextuelles
À mesure que les entreprises déploient des solutions GenAI à grande échelle, les pare-feux LLM deviennent extrêmement pertinents en tant qu’outil de sécurisation des interactions de l’IA, comme la détection et le blocage des accès non autorisés aux données et des comportements anormaux. Il existe plusieurs fournisseurs de pare-feu LLM, notamment Open AI, Nvidia, Anthropic et Scale AI. Selon Securiti, par rapport aux offres existantes, le pare-feu LLM de Gencore AI comprend des fonctionnalités supplémentaires, notamment des contrôles alignés sur les recommandations de l’OWASP (Open Worldwide Application Security Project), des politiques de sécurité préconfigurées pour l’IA et la prise en compte du contexte des données.
« Gencore AI protège automatiquement les informations sensibles et maintient la gouvernance des données de l’entreprise », a affirmé Rehan Jalil. « Grâce à ses connaissances réglementaires intégrées, Gencore AI garantit aussi la conformité des processus d’IA avec les réglementations pertinentes, comme l’IA Act européen et le cadre de gestion des risques liés à l’IA (AI RMF) du NIST américain. » GenCore AI de Securiti est déjà disponible sous forme d’abonnements divers, basés sur les fonctions.
Les sites de phishing ciblant spécifiquement les terminaux mobiles sont de plus en plus nombreux rapporte Zimperium Labs dans une étude. Les MDM et les gestionnaires de mot de passe peuvent être de bons outils pour se protéger de campagnes en constante amélioration.
Il y a quelques années le phishing se concentrait majoritairement sur les ordinateurs (PC ou portables). Cette époque est révolue selon un rapport de Zimperium Labs qui constate une augmentation sensible des campagnes d’hameçonnage ciblant les smartphones. L’enquête, basée sur les données de recherche de l’équipe de la société, révèle que plus de la moitié (54 %) des entreprises ont subi une violation de données après un accès inapproprié des employés à des informations sensibles et confidentielles depuis leurs mobiles.
« Plus précisément, en 2023, 82% des sites de phishing examinés par Zimperium ciblaient précisément les terminaux mobiles et diffusaient du contenu formaté pour les smartphones ce qui représente une augmentation de 7% au cours des trois dernières années », indique le rapport. « C’est le signe que de plus en plus d’attaques de phishing ciblent les utilisateurs mobiles. » Trois raisons principales peuvent expliquer cette tendance : l’utilisation accrue des terminaux personnels dans le cadre professionnel, une mauvaise cyber-hygiène sur les smartphones et l’exploitation de l’IA par des acteurs malveillants.
Une surface d’attaque croissante et un piratage plus facile
Selon Zimperium, cette hausse est liée au fait que, par rapport aux ordinateurs de bureau, les smartphones sont souvent moins bien protégés. Une mauvaise hygiène de sécurité et des écrans plus petits sur les terminaux pourraient empêcher les utilisateurs de remarquer les tentatives d’hameçonnage et les barres d’URL cachées. Si l’on ajoute à cela le fait que les smartphones sont de plus en plus utilisés dans le monde du travail, leur ciblage à des fins d’hameçonnage appelle à des mesures immédiates. D’après l’étude, 71 % des employés utilisent des smartphones pour leurs tâches professionnelles, et 60 % d’entre eux s’en servent pour communiquer dans le cadre de leur travail. Aujourd’hui, 82 % des employés sont autorisés, d’une manière ou d’une autre, à prendre leurs mobiles dans le cadre de politiques BYOD (bring your own device), si bien qu’environ la moitié (48 %) des employés utilisent des smartphones personnels pour accéder à des informations liées au travail, et chacun d’entre eux passe en moyenne trois heures par jour sur son smartphone dans le cadre professionnel.
« Les terminaux mobiles étant devenus essentiels au fonctionnement des entreprises, il est crucial de les sécuriser, en particulier pour se protéger contre la grande variété de types d’attaques de phishing », a déclaré Patrick Tiquet, vice-président de la sécurité et de l’architecture chez Keeper Security. « Les entreprises doivent mettre en œuvre des politiques de gestion de flotte mobile (Mobile Device Management) robustes, en veillant à ce que les terminaux fournis par l’entreprise et ceux en BYOD soient conformes aux normes de sécurité. Des mises à jour régulières des mobiles et des logiciels de sécurité garantissent une correction rapide des vulnérabilités, et donc de se prémunir contre les menaces connues qui ciblent ces utilisateurs ».
Du M-ishing sophistiqué
L’hameçonnage est considéré comme le principal problème de sécurité dans l’espace mobile, tant dans le secteur public (10 %) que dans le secteur privé. Plus important encore, 76 % des sites d’hameçonnage utilisent désormais le protocole HTTP pour tromper les utilisateurs sur la sécurité de la communication. « L’utilisation du HTTPS pour le phishing n’est pas complètement nouveau », a rappelé Krishna Vishnubhotla, vice-président de la stratégie produit chez Zimperium. « Le rapport de l’année dernière avait révélé qu’entre 2021 et 2022, le pourcentage de sites de phishing ciblant les mobiles était passé de 75 à 80 %. Certains d’entre eux utilisaient déjà le HTTPS, mais il a surtout montré que plus de campagnes ciblaient les mobiles », a-t-il ajouté. «
Cette année, nous constatons une hausse fulgurante du ciblage des appareils mobiles, signe de maturation des tactiques sur mobile, et c’est logique. Les smartphones se prêtent bien au phishing, car l’utilisateur voit rarement l’URL dans le navigateur ou les redirections rapides. De plus, nous sommes conditionnés à croire qu’un lien est sécurisé s’il y a une icône de cadenas à côté de l’URL dans nos navigateurs. Sur les téléphones portables en particulier, les utilisateurs devraient regarder au-delà de l’icône du cadenas et vérifier soigneusement le nom de domaine du site web avant de saisir des informations sensibles », a expliqué M. Vishnubhotla. « La recrudescence des attaques de phishing ciblées sur mobiles appelle à la mise en place urgente de solutions de sécurité avancées, basées sur l’IA, capables de détecter et de bloquer les menaces sophistiquées en temps réel », a estimé Stephen Kowski, Field chief technology officer chez SlashNext. « Les acteurs de la menace utilisant de plus en plus des protocoles sécurisés tels que HTTPS, les mesures de sécurité traditionnelles ne sont plus suffisantes pour protéger les utilisateurs et les entreprises. »
MDM et gestionnaires de mots de passe à la rescousse
Selon les experts, les MDM et les gestionnaires de mots de passe peuvent s’avérer utiles pour se protéger contre l’hameçonnage. Les premiers offrent aux entreprises d’appliquer des politiques de sécurité, de contrôler les autorisations des applications et de s’assurer que les appareils sont mis à jour avec les derniers correctifs de sécurité, réduisant ainsi le risque d’exploitation du phishing. « Les solutions MDM, qui assurent la conformité et limitent l’accès aux données en fonction de l’état de l’appareil, garantissent une stratégie de sécurité mobile complète qui ne se limite pas aux seules mises à jour du système d’exploitation », a fait valoir M. Tiquet. « Un chiffrement fort et une gestion automatisée des correctifs peuvent renforcer la protection des appareils ».
Quant aux gestionnaires de mots de passe, ils génèrent et stockent des mots de passe complexes et uniques, empêchant les utilisateurs de réutiliser leurs informations d’identification sur plusieurs services, ce qui constitue souvent une cible pour le phishing. « L’application de l’authentification multifactorielle (MFA) ajoute une couche supplémentaire de protection des données sensibles », a ajouté M. Tiquet. « Les gestionnaires de mots de passe jouent un rôle crucial en générant et en stockant des mots de passe forts et uniques et en prenant en charge des méthodes avancées d’authentification multifactorielle ».
L’éditeur Solarwinds a colmaté une brèche dans Web Help Desk. Le problème vient d’un erreur de développement dans l’outil ITSM laissant des identifiants codés en dur.
Dans ses travaux, le chercheur en cybersécurité Zach Hanley s’est penché sur la CVE-2024-28986 concernant Web Help Desk (WHD), un outil d’ITSM de Solarwinds pour les centres de support informatique. Il a trouvé une autre faille critique dans cette solution entrainant l’accès à distance à des informations sensibles codées en dur. La vulnérabilité, référencée CVE-2024-28987, avec un score CVSS de 9,1 sur 10, a été qualifiée de « critique ». « Un utilisateur distant non authentifié pourrait accéder à des fonctionnalités internes et modifier des données en exploitant la vulnérabilité située au niveau des identifiants codés en dur dans le logiciel Solarwinds Web Help Desk », a déclaré l’éditeur dans un bulletin de sécurité comprenant un correctif.
Une erreur de développement
L’origine du bug est à chercher du côté des développeurs. Ils ont oublié de retirer certaines informations d’identification codées en dur dans Web Help Desk. Cet outil est utilisé dans des secteurs d’activité critiques tels que la santé, l’administration et les services financiers utilisent WHD, et une vulnérabilité facilitant l’accès à distance à leurs systèmes peut mettre en danger des données sensibles.
Même si aucune exploitation active n’a encore été signalée, Solarwinds recommande d’appliquer rapidement des correctifs pour avoir une longueur d’avance sur les acteurs malveillants. Le chercheur, à l’origine de la découverte a salué la rapidité de l’éditeur pour livrer un correctifs « j’ai signalé une vulnérabilité critique à Solarwinds vendredi après avoir creusé dans la récente CISA KEV CVE-2024-28986 pour WebHelpDesk, et je vois que quatre jours plus tard, ils ont déjà livré un correctif ! », a écrit M. Hanley sur X. « D’autres détails seront publiés le mois prochain », précise-t-il.
Autres correctifs
Outre cette vulnérabilité de l’identifiant codé en dur dans WHD, le correctif comporte aussi une petite mise à jour logicielle ciblée pour remédier à des vulnérabilités spécifiques, dont une version améliorée d’un correctif récent pour une vulnérabilité d’exécution de code à distance, référencée CVE-2024-28986, avec un score CVSS de 9,8, affectant le même produit. « Pour votre protection et pour fournir rapidement aux clients Solarwinds une version sécurisée de WHD, nous avons appliqué un correctif de sécurité agressif dans WHD 12.8.3 Hotfix 1 le 13 août 2024 », a déclaré la firme dans une mise à jour antérieure. « Il peut arriver que cette approche ait un impact sur les fonctionnalités du produit comme le Single Sign-On (SSO). »
Selon une étude, les entreprises ne parviennent pas à se défendre totalement ou s’appuient sur une protection incomplète des API, sans visibilité en temps réel.
Selon un rapport de Cloudflare, en raison du manque de visibilité des entreprises sur les API utilisées, celles-ci sont devenues plus complexes à gérer et à protéger contre les abus. Le rapport, basé sur les modèles de trafic observés par le réseau du fournisseur entre octobre 2022 et août 2023, a révélé que les entreprises ne parviennent pas à se défendre entièrement ou s’appuient sur une protection incomplète des API, sans visibilité en temps réel.
« Les API sont difficiles à protéger contre les abus. Elles nécessitent un contexte métier, des méthodes de découverte et des contrôles de vérification des accès plus approfondis que les autres services de sécurité des applications web », a expliqué l’éditeur dans son rapport. « Ceux qui mettent en œuvre la sécurité des API sans avoir une image précise et en temps réel de leur environnement API peuvent bloquer involontairement le trafic légitime ». Le réseau Cloudflare sur lequel se base le rapport comprend des données provenant de ses services de pare-feu d’applications web (Web Application Firewall, WAF), de protection DDoS, de gestion des bots et de passerelle API.
Le shadow API ouvre la surface d’attaque
Dans son analyse, Cloudflare conclut que le trafic API dépasse le reste du trafic Internet. « Les développeurs d’applications utilisent de plus en plus des architectures modernes, basées sur les microservices, et ils ont besoin d’API pour accéder aux services, aux données ou à d’autres applications afin de fournir des fonctionnalités plus riches aux utilisateurs de leurs applications », a déclaré Melinda Marks, analyste senior chez le consultant ESG. « Mais cela signifie plus de surface d’attaque, donc si les API ne sont pas sécurisées, cela crée un point d’entrée pour accéder à ces services, données ou autres applications », a-t-elle ajouté. Cloudflare a également observé que de nombreuses entreprises ne disposent pas d’un inventaire complet de leurs API, ce qui les rend difficiles à gérer. Les outils de machine learning du fournisseur ont découvert près de 31 % d’API REST (Representational State Transfer) en plus que ceux observés par les identificateurs de session fournis par les clients.
Selon Cloudflare, les applications qui n’ont pas été gérées ou sécurisées par l’entreprise qui les utilise, aussi appelées Shadow API ou API fantômes, sont souvent introduites par des développeurs ou des utilisateurs individuels pour exécuter des fonctions métiers spécifiques. « Une étude réalisée par nos soins a révélé des pourcentages élevés (67 %) d’API ouvertes au public, d’API connectant des applications avec des partenaires (64 %) et d’API connectant des microservices (51 %), ainsi que des taux élevés de mises à jour d’API, dont 35 % d’actualisations quotidiennes et 40 % hebdomadaires », a encore déclaré Melinda Marks. « Ce problème est donc lié à l’augmentation constante du nombre d’API et accroît le risque que des pirates veuillent tirer parti de vulnérabilités qui sont généralement le résultat d’une négligence », a-t-elle ajouté.
L’attaque DDoS, principale menace
52% de toutes les erreurs d’API traitées par Cloudflare ont été attribuées au code d’erreur 429, qui est un code d’état HTTP qui alerte contre l’excès de requêtes. Cette constatation est corroborée par le fait que 33 % des mesures d’atténuation des API consistaient à bloquer les dénis de service distribués (Distributed Denial of Service, DDoS). « Les attaques DoS et DDoS, sont souvent sous-estimées ou oubliées, alors que c’est un domaine important », a déclaré l’analyste. « La capacité à bloquer les attaques DoS/DDoS est donc souvent une priorité pour la sécurité des API ». Parmi les autres principales erreurs d’API figurent les mauvaises requêtes (code erreur 400) (13,8 %), les requêtes non trouvées (code erreur 404) (10,8 %) et les requêtes non autorisées (code erreur 401) (10,3 %). « Les applications actuelles sont plus complexes et plus riches en fonctionnalités, avec un nombre croissant d’API qui contribuent à fournir des fonctionnalités complexes, mais cela augmente le risque de sécurité, car chaque API est une surface d’attaque », a déclaré Melinda Marks.
« Nos récentes études ont montré qu’au cours des 12 derniers mois, 92% des entreprises ont été confrontées à un incident de sécurité API, au moins, avec comme conséquence l’exposition des données, la prise de contrôle des comptes, l’attaque par déni de service, etc. Selon Cloudflare, les entreprises peuvent se protéger contre les abus d’API en mettant en œuvre des pratiques pouvant inclure l’unification de la gestion, de la performance et de la sécurité de l’API avec le cloud de connectivité, la mise en œuvre d’un modèle de « sécurité positive » avec la passerelle API qui n’autorise que le trafic reconnu comme « bon » plutôt que d’interdire le trafic reconnu comme « mauvais », l’utilisation de technologies d’apprentissage machine pour la réduction des coûts et la sécurité, et la mesure de la maturité de l’API au fil du temps.
Une faille dans la fonction Multilogin OAuthe de Google est capable de générer des cookies persistant offrant un accès continu aux services de la société. La réinitialisation du mot de passe se révèle inefficace, une aubaine pour les malwares volant des identifiants.
Un exploit apparu en octobre 2023 donne des sueurs froides aux équipes de sécurité, mais fait la joie des cybercriminels. En effet, un endpoint OAuth (protocole autorisant l’accès à une application tierce sans transmettre son mot de passe) non documenté de Google est à l’origine de cet exploit. Ce dernier est capable de généré des cookies d’authentification Google persistants en manipulant des tokens et offrant ainsi un accès continu aux service de la firme même après la réinitialisation du mot de passe. Ce procédé a été révélé la première fois par un pirate, dénommé « Prisma », sur un canal Telegram.
Selon un article du blog de CloudSEK, un spécialiste de la cybersécurité, la racine de l’exploit se situe au niveau d’un point de terminaison OAuth de Google non documenté appelé « MultiLogin ». En l’utilisant, les attaquants sont capables de renouveler les cookies d’authentification expirés et obtenir un accès non autorisé aux services Google actifs d’un utilisateur. Les experts ont découvert ce modus operandi en décortiquant le malware Lumma, un programme volant des identifiants (ou infostealer). Ils ont constaté que l’exploit était aussi présent chez d’autres infostealer : par Rhadamanthys, Risepro, Meduza et Stealc Stealer, et White Snake
La découverte d’un endpoint Multilogin OAuth non documenté
En analysant la base de code de Chromium, CloudSEK a identifié le point de terminaison MultiLogin utilisé comme mécanisme interne qui sert à synchroniser les comptes Google à travers les services. « Ce point d’accès fonctionne en acceptant un vecteur d’identifiants de compte et de jetons d’authentification, des données essentielles pour gérer des sessions simultanées ou passer d’un profil d’utilisateur à un autre de manière transparente », a expliqué la société. « Si la fonction MultiLogin joue un rôle essentiel dans l’authentification des utilisateurs, elle constitue également un moyen d’exploitation si elle est mal gérée, comme en témoignent les récents développements de malware », ajoute-t-elle.
Pour confirmer qu’un serveur MultiLogin a été utilisé pour régénérer les cookies de session dans l’exploit, CloudSEK a, après une discussion avec Prisma, effectué une rétro-ingénierie de l’exécutable de l’exploit fourni par le cybercriminel. L’analyse a révélé le point de terminaison MultiLogin spécifique et non documenté utilisé dans l’exploit.
La réinitialisation des mots de passe insuffisante
L’exploit n’est possible qu’après un premier piratage du système de l’utilisateur pour récupérer des jetons de session valides. Un malware infecte d’abord l’ordinateur d’une victime, souvent à partir de spams ou de téléchargements non fiables. Une fois le système compromis, le malware recherche les cookies de session du navigateur web et d’autres données exploitables pour obtenir un accès non autorisé à des comptes. Les tokens de session volés sont envoyés aux attaquuants, ce qui leur permet d’infiltrer les comptes compromis et d’en prendre le contrôle.
Et même si les utilisateurs détectent la faille et modifient leur mot de passe Google, les jetons volés peuvent toujours être utilisés pour se connecter. Le malware extrait et décrypte les identifiants de compte et les jetons d’authentification des comptes Google actifs en examinant le tableau token_service dans les données Web de Chrome, qu’il utilise avec MultiLogin pour régénérer en permanence les informations de session. Pour atténuer ce risque, il est conseillé aux utilisateurs de se déconnecter complètement, ce qui rendra les jetons de session invalides et empêchera toute exploitation ultérieure.
L’exploit de Lumma, dissimulé par un chiffrement du jeton
Afin de cacher son mécanisme d’exploitation, Lumma a chiffré le jeton d’accès extrait de la table token_service : GAIA ID, un composant essentiel du processus d’authentification de Google. « Quand cette paire est utilisée en conjonction avec le endpoint MultiLogin, elle permet la régénération des cookies de service de Google », a déclaré CloudSEK. « L’innovation stratégique de Lumma réside dans le chiffrement de cette paire token:GAIA ID avec ses propres clés privées. Le chiffrement a été utilisé comme un mécanisme de « boîte noire » qui a permis à Lumma de masquer efficacement son mécanisme principal à d’autres entités malveillantes pour les empêcher de le reproduire ».
Cependant, pour contrer la restriction de Google sur la régénération des cookies basée sur l’adresse IP, Lumma a utilisé des proxies SOCKS à partir de novembre 2023. Or ceux-ci ont révélé certains détails sur les demandes et les réponses, ce qui a compromis la dissimulation.
Un rapport de Venafi montre que les risques de sécurité lors du passage au cloud sont sous-estimés par les équipes de sécurité des entreprises.
Un rapport sur l’état de la sécurité « cloud native » a révélé qu’un nombre considérable d’adoptants du cloud ne comprennent pas les risques de sécurité liés au transfert d’applications existantes vers le « cloud », s’exposant ainsi à un certain nombre d’attaques basées sur le « cloud ». Pour son enquête, l’entreprise Venafi spécialisée dans la cybersécurité, a interrogé 800 responsables de la sécurité et de l’IT travaillant pour des entreprises situées aux États-Unis, au Royaume-Uni, en Allemagne et en France. L’objectif de l’étude était d’examiner les principales menaces et défis auxquels est confrontée aujourd’hui la sécurité « cloud native ».
« Les équipes de développement d’applications vont de plus en plus vite pour maintenir leur entreprise dans le peloton de tête, en se tournant vers des stratégies de conteneurisation et de microservices grâces auxquelles l’amélioration rapide des applications est devenue une réalité », indique le rapport de Venafi. « Très souvent, la sécurité cloud native est à la traîne, et la responsabilité de la prise en charge de la fonction de sécurité au sein des équipes d’ingénierie, de plateforme et de développement reste floue ». Le rapport note que ce manque de clarté est un énorme problème quand il s’agit de sécuriser les identités des machines – les authentificateurs qui sécurisent les communications et les connexions au sein d’un cluster de conteneurs – car elles servent de base à la sécurité cloud native. « Malgré leur importance relative, l’application des identités machine dans les implémentations cloud natif – services mesh, sécurité du cycle de développement des logiciels et signature du code des artefacts de développement – est fréquemment mal comprise », ajoute le rapport.
Des répercussions sur les coûts et la sécurité
Les personnes interrogées dans le cadre de l’étude ont révélé qu’elles passaient rapidement au cloud pour se débarrasser des longs cycles de développement et de publication d’applications, car elles ne peuvent pas se permettre d’attendre de nouvelles fonctionnalités essentielles. 87 % des personnes interrogées ont déclaré avoir transféré leurs anciennes applications dans le cloud. Plus de la moitié (59 %) des personnes interrogées ont déclaré ne pas comprendre les risques de sécurité liés au transfert des applications existantes vers le cloud. Par ailleurs, 53 % des personnes interrogées ont admis qu’elles avaient simplement transféré leurs applications dans le cloud, la majeure partie du code de l’application restant inchangée.
Autre inconvénient du passage aveugle au cloud : le coût associé à l’opération. « 52 % des entreprises ont souffert de la prolifération des clouds et du niveau de leurs factures depuis qu’elles ont transféré leurs applications existantes dans le cloud », indique le rapport. « 77 % de ceux qui en ont souffert ont reconsidéré le transfert de leurs applications vers le cloud ». Une autre tendance clé mise en évidence par l’étude est que la course au cloud a fait de la conteneurisation un choix populaire parmi les développeurs, 84 % des répondants à l’enquête estimant que Kubernetes serait bientôt la principale plateforme utilisée pour développer toutes les applications. Or, au fur et à mesure que l’utilisation de Kubernetes augmente et mûrit, la complexité des stratégies « cloud native » devient plus évidente.
Plus de défis avec Kubernetes
Les répondants ont convenu d’un certain degré d’incertitude en ce qui concerne l’adoption de Kubernetes, 75 % d’entre elles estimant que la vitesse et la complexité de Kubernetes et des conteneurs créaient des angles morts en matière de sécurité. Parmi les autres problèmes majeurs liés à la conteneurisation, on peut citer les difficultés d’application des correctifs (43 %), les vulnérabilités causées par des configurations erronées (41 %), les pannes dues à des certificats mal gérés (32 %) et l’échec des audits de sécurité (22 %). 59 % des personnes interrogées ont déclaré avoir rencontré des problèmes de sécurité dans des environnements Kubernetes ou de conteneurs. Les principales causes de ces problèmes sont les brèches dans le réseau (42 %), les vulnérabilités des API (41 %) et la mauvaise configuration des certificats (39 %). La mauvaise configuration des certificats – un défi pour l’identité des machines – s’est avérée être une préoccupation plus importante aux États-Unis, avec 45 %.
En outre, 68 % des sondés ont déclaré que les développeurs n’utilisaient parfois pas de certificats parce que leur émission ralentit le processus de développement. Malgré les défis liés aux identités des machines, ils sont 88% à estimer que le concept d’identité des machines est essentiel au succès des modèles zero trust. Cependant, l’appropriation de la gestion de l’identité des machines n’est toujours pas claire, 74 % des répondants s’inquiétant du fait que les développeurs sont confrontés à plusieurs priorités contradictoires, de sorte que la sécurité n’arrive pas toujours en tête de leurs préoccupations.
Le SIEM nativement cloud d’IBM, QRadar prend désormais en charge l’interopérabilité des clouds hybrides, les solutions open source et la détection automatisée des menaces.
Toilettage d’hiver pour QRadar, l’offre SIEM en mode cloud d’IBM qui intègre plusieurs éléments dans la surveillance des cloud hybrides, des solutions open source et des wokload d’IA. L’offre combine la structure SIEM existante de la suite QRadar avec des capacités d’IA générative et de détection des menaces pour améliorer l’ingestion des données et la mise à l’échelle de la recherche et de l’analyse.
« Nous avons reconstruit notre SIEM à partir de zéro, en utilisant Red Hat Open Shift comme architecture de données sous-jacente et en tirant parti d’une technologie d’entreposage de données haute performance pour la gestion des logs », a déclaré Chris Meenan, vice-président de la gestion des produits chez IBM Security. « Les clients actuels de QRadar pourront désormais moderniser leurs opérations de sécurité avec une base de données construite spécifiquement pour les besoins des environnements hybrides multicloud », a-t-il ajouté. IBM QRadar Cloud-Native SIEM sera disponible d’ici la fin de l’année, d’abord en mode SaaS, en attendant la livraison des logiciels pour les environnements sur site et multicloud prévue pour 2024.
Du SIEM natif pour l’interopérabilité
Construit sur Red Hat OpenShift pour un déploiement agnostique, le SIEM d’IBM sera ouvert à un « niveau fondamental », de façon à assurer l’interopérabilité avec de multiples fournisseurs de cloud et leurs outils. QRadar s’appuiera sur des logiciels libres et des normes ouvertes pour les fonctions principales, notamment les règles de détection des menaces et les langages de recherche. « L’approche ouverte d’IBM est absolument essentielle pour permettre aux clients de profiter des avantages du cloud dans les environnements hybrides multicloud », a déclaré Chris Meenan. « D’autres fournisseurs proposent une architecture basée davantage sur une approche de cloud unique, ce qui fait que les analyses de sécurité, les intégrations et les options de recherche fonctionnent bien dans leur cloud natif, mais sont difficiles à mettre en œuvre dans un environnement de cloud hybride distribué ».
Dans le cadre de cette orientation « ouverte », le SIEM d’IBM prend en charge les règles unifiées communes et partagées du langage de détection Sigma, si bien que les clients peuvent importer d’autres indicateurs provenant directement de la communauté responsable de la sécurité à mesure de l’évolution des menaces. L’utilisation de technologies open source promet une « recherche fédérée et des capacités de chasse aux menaces », avec la possibilité de rechercher et d’enquêter sur les menaces à travers toutes les sources de données du cloud et sur site d’une « manière unique et unifiée, sans déplacer les données de leur source d’origine », a déclaré IBM. Cependant, l’approche « cloud-natif » en elle-même pourrait ne pas suffire à IBM pour concurrencer les acteurs existants. « Cette seule architecture cloud-native n’offre pas d’avantage à IBM par rapport à des fournisseurs comme Devo, Google, Microsoft et Splunk qui ont adopté une stratégie similaire », a déclaré Jon Oltsik, analyste chez ESG. « IBM doit rivaliser sur les caractéristiques/fonctionnalités, mais le fournisseur a de bons arguments à faire valoir en matière d’ouverture, de fédération des données, de soutien des normes, d’écosystème de partenaires, etc. »
IA et automatisation
Pour automatiser la détection des menaces et les processus d’investigation, le SIEM restructuré introduit et emprunte plusieurs capacités d’IA. Parmi les fonctionnalités à base de cette technologie, on peut citer la priorisation des alertes, l’enquête sur les menaces et la détection adaptative. Les algorithmes d’IA développés par IBM servent à réduire le bruit et à automatiser le regroupement, la contextualisation et l’escalade des alertes prioritaires. L’enquête sur les menaces utilise également des moteurs d’IA pour effectuer des recherches automatisées dans les systèmes connectés, générant une chronologie visuelle de l’attaque, des correspondances MITRE ATT&CK et des actions recommandées. La détection adaptative fait référence à la mise à jour automatique des règles de détection à mesure de l’arrivée des informations. « Les technologies d’IA de QRadar ont été développées au sein d’IBM et affinées pendant plusieurs années, entraînées sur des millions d’alertes provenant de milliers de clients, ainsi que sur le contexte externe des menaces et les modèles historiques de réponse des analystes », a encore déclaré Chris Meenan. « Certaines de ces capacités d’IA ont aussi été développées en collaboration avec l’équipe des services de cybersécurité d’IBM, qui gère les opérations de sécurité pour des milliers de clients dans le monde ».
Simultanément à cette annonce, IBM a fait part de son intention de lancer des capacités de sécurité génératives basées sur l’IA via QRadar Suite au début de 2024. Celles-ci seront principalement construites sur watsonx, la plateforme d’IA et de données de l’entreprise. « Compte tenu de son expérience avec Watson et de l’engagement global d’IBM en faveur de l’IA à l’échelle de l’entreprise, je pense que ses capacités d’IA générative seront solides, mais c’est un domaine qui reste assez déroutant pour les clients », a déclaré Jon Oltsik d’ESG. « IBM doit aider le marché à s’orienter avec un leadership éclairé et faire en sorte que les clients puissent mettre en œuvre l’IA générative en toute transparence. Le fournisseur continuera à soutenir son offre SIEM QRadar actuelle, tout en offrant aux clients une option de transition vers la solution SIEM cloud native ».