Dans ce numéro
🌡️ Niveau de menace
⚡ Actualités : cinq histoires de sécurité à rattraper
🔎 Analyse approfondie : la faille du départ des collaborateurs
🎣 Est-ce du phishing ?
🔬 Recherche technique : ils n’ont pas volé un mot de passe. Ils en ont forgé un.
🛠️ Outil de la semaine : Tor pour la recherche en sécurité encadrée
👏 Personnalité de la semaine : Romain Thomas
📅 Événement de la semaine : Black Hat USA 2026
📚 Livre de la semaine : Spycraft
😅 Le mème
❓ Une question avant de partir
Vu de l’extérieur, le départ d’un collaborateur peut sembler terminé : l’ordinateur portable est rendu, le badge est désactivé, l’e-mail d’adieu est parti et le gâteau a disparu. C’est une fin convaincante.
Le problème, c’est qu’aucune de ces étapes n’indique à une ancienne session, à un token oublié ou à un lecteur partagé que la personne est partie. Tant que ce départ n’atteint pas les systèmes eux-mêmes, l’accès peut continuer comme si lundi était un jour de travail comme un autre.
C’est là que commence ce numéro : avec un au revoir sans accroc, une piste d’accès en désordre et une question qui devrait être plus facile : qu’est-ce qui fonctionne encore, exactement ?
🌡️Niveau de menace
⚡ Actualités
Cinq versions AsyncAPI de confiance contenaient un malware, et une provenance valide ne les a pas arrêtées
Des attaquants ont compromis les workflows de publication d’AsyncAPI le 14 juillet et publié cinq versions malveillantes réparties sur quatre packages npm. Les packages contenaient Miasma, une porte dérobée capable d’exécuter des commandes sur les systèmes touchés. Le code s’activait à l’import plutôt qu’à l’installation : --ignore-scripts n’offrait donc aucune protection. Les équipes doivent inspecter les fichiers de verrouillage des dépendances, les caches de build et les journaux de CI, puis renouveler les identifiants accessibles aux builds potentiellement touchés.
Deux failles exploitées placent AD FS et SharePoint en tête de la file des correctifs Microsoft de juillet
Microsoft répertorie dans ses notes de version de juillet 622 vulnérabilités, même si les totaux varient selon la méthode de comptage. Deux failles étaient déjà exploitées : CVE-2026-56155 permet une élévation de privilèges locale dans Active Directory Federation Services, tandis que CVE-2026-56164 touche SharePoint sur site et peut être atteinte sans authentification. La CISA a ajouté les deux à son catalogue Known Exploited Vulnerabilities : l’infrastructure d’identité et les serveurs SharePoint exposés deviennent les priorités immédiates.
SonicWall confirme des attaques actives contre deux vulnérabilités de SMA 1000
SonicWall affirme que des attaquants exploitent CVE-2026-15409 et CVE-2026-15410 contre des appliances SMA 1000. La première est une faille de falsification de requête côté serveur (SSRF) notée CVSS 10,0. La seconde peut permettre une injection de code dans certaines conditions. Appliquer le hotfix n’est que la première étape. SonicWall recommande aussi une revue forensique et, si des indicateurs de compromission sont trouvés, de reconstruire l’appliance à partir d’une image de confiance.
De faux identifiants de client OAuth permettent à des attaquants de tester des identifiants Entra sans terminer une connexion
Proofpoint a observé des attaquants qui génèrent un grand nombre d’identifiants d’application OAuth usurpés et utilisent les réponses de Microsoft Entra pour déduire si des comptes et des mots de passe sont valides. Comme la tentative ne produit pas de connexion réussie classique, les règles de surveillance habituelles peuvent la manquer. Parmi les signaux utiles : des noms d’application manquants, des identifiants vides, des volumes inhabituels d’identifiants de client inexistants et des schémas d’erreur comme AADSTS700016 apparaissant à côté de tentatives avec des identifiants valides.
Des chercheurs ont trouvé un chemin de clics synthétiques vers les workflows de Claude for Chrome
Manifold Security indique qu’une autre extension de navigateur ayant accès à claude.ai pourrait générer des clics synthétiques qui déclenchent des tâches prédéfinies de Claude for Chrome impliquant des services comme Gmail, Google Docs, Calendar et Salesforce. L’attaque décrite exige qu’une extension malveillante ou compromise soit déjà présente dans le navigateur. Les organisations qui testent des agents de navigateur doivent revoir les permissions des extensions, limiter les applications connectées et éviter les paramètres d’approbation sans surveillance pour les workflows sensibles.
🔎 Analyse approfondie
La faille du départ des collaborateurs
L’employé était parti depuis des semaines. Le badge ne fonctionnait plus, le compte principal était désactivé et le départ semblait achevé.
Puis quelqu’un a vérifié les journaux du serveur.
Apple affirme qu’un ancien employé qui n’avait pas rendu son ordinateur portable professionnel a trouvé un moyen de revenir dans son réseau interne et de télécharger des fichiers confidentiels sur le matériel. Ces allégations restent devant le tribunal, et la question de l’intention lui appartient. Pour les équipes sécurité, le mystère le plus instructif est ce qui s’est passé avant le téléchargement :
À quoi le système d’Apple était-il encore prêt à faire confiance ?
Reuters a rapporté les allégations et la réponse de l’autre partie.
Le premier suspect : le compte principal
Quand un employé part, le compte d’identité central est généralement le premier endroit où l’on regarde. On le désactive, on coupe l’accès et on marque la tâche comme terminée.
Mais un compte n’est qu’une des façons d’entrer dans un environnement.
Une application peut encore détenir une session active. Un service peut accepter un token émis plus tôt. Un appareil de l’entreprise peut porter un certificat valide. Un script interne peut utiliser une clé d’API créée par l’employé mais stockée ailleurs. Un mot de passe partagé peut n’être lié à aucune identité individuelle.
Chacun de ces éléments peut rester utilisable après la disparition du compte principal.
Prenons un token émis à 9 h du matin. Le compte de l’employé est désactivé à midi, mais l’application valide le token localement au lieu de demander un statut à jour au fournisseur d’identité.
Le fournisseur d’identité sait que le compte est désactivé. L’application sait seulement que le token est correctement signé et n’a pas expiré.
Les deux systèmes semblent fonctionner. La défaillance se trouve dans l’espace qui les sépare.
Le ticket était au vert
Le dossier de départ peut encore sembler parfait :
Le compte a été désactivé.
Le badge a été rendu.
Les demandes de retrait d’accès ont été envoyées.
Le ticket de départ a été clôturé.
Le ticket prouve que le workflow a effectué les actions prévues. Il ne prouve pas que chaque application, chaque appareil et chaque identifiant a cessé d’accepter l’ancien employé.
Si cinq systèmes détenaient un accès et que quatre seulement confirment son retrait, le cinquième n’est pas un succès silencieux. C’est une question sans réponse.
Peut-être que la demande n’est jamais arrivée. Peut-être que le système n’a pas réussi à la traiter. Peut-être que l’accès a été retiré mais que la confirmation n’a jamais été renvoyée. Tant que le résultat n’est pas connu, on ne peut pas traiter ces possibilités comme équivalentes sans risque.
L’ordinateur portable manquant change l’enquête
Un ordinateur portable professionnel n’est pas seulement un actif à récupérer. Il peut contenir des sessions actives, des identifiants stockés localement, des certificats d’appareil et un historique de confiance avec les services internes.
Récupérer l’appareil et révoquer son accès sont donc deux actions distinctes. Un portable peut être déclaré manquant alors que les certificats qui lui sont associés restent valides. Un compte utilisateur peut être désactivé alors qu’une application continue d’accepter une session créée depuis cet appareil.
Le départ physique a eu lieu. La relation technique n’a pas forcément pris fin avec lui.
C’est pourquoi chaque compte, token, clé, certificat et appareil de confiance a besoin de trois informations :
Qui ou quoi en est propriétaire ?
Quels systèmes l’acceptent ?
Comment peut-il être révoqué, renouvelé ou laissé expirer ?
Si le propriétaire est inconnu, le workflow de départ n’a aucune raison fiable d’inclure l’identifiant. Il peut survivre simplement parce qu’aucun système ne considère le départ de l’employé comme pertinent pour lui.
L’indice caché dans le trafic normal
Supposons qu’un ancien token soit utilisé trois semaines après le départ de son propriétaire. Le système de surveillance en reconnaîtrait-il l’importance, ou enregistrerait-il simplement une requête authentifiée réussie de plus ?
Sans contexte de propriété, la requête peut sembler ordinaire. Le token est valide. Le certificat est familier. L’appareil s’est déjà connecté.
Associez l’ancien propriétaire et la date de départ au même événement, et le tableau change. Une requête réussie peut révéler qu’un chemin d’accès a survécu au départ. Des échecs répétés peuvent trahir un script oublié, une session en cache ou un appareil qui tente toujours de se reconnecter.
Rien de tout cela ne prouve une intention malveillante. Cela révèle en revanche que le nettoyage était incomplet, ce que ce contrôle est précisément censé détecter.
Fermer toutes les portes
Chaque chemin d’accès demande une fin différente. Les mots de passe partagés doivent être renouvelés. Les certificats d’appareil peuvent devoir être révoqués. Les sessions existantes doivent être terminées. Les applications autonomes peuvent exiger des changements de compte distincts. Les clés d’API peuvent devoir être remplacées sans perturber les services qui les utilisent.
L’action change, mais la preuve exigée doit rester la même.
Un départ est terminé quand l’organisation peut identifier les chemins d’accès, confirmer que chacun a cessé de fonctionner et détecter ceux qui réapparaissent.
Jusque-là, l’employé peut être parti alors qu’une partie de son accès est encore à l’intérieur.
🎣 Est-ce du phishing ?
Un domaine légitime ne rend pas le workflow légitime. Ne saisissez jamais un code d’appareil que vous n’avez pas généré vous-même.
🔬 Recherche technique
Ils n’ont pas volé un mot de passe. Ils en ont forgé un.
Parfois, l’attaquant n’a pas du tout besoin de votre mot de passe. Il lui suffit que votre serveur croie qu’il l’a déjà.
C’est le cœur dérangeant de CVE-2026-55040, un contournement critique de l’authentification dans Microsoft SharePoint Server sur site, divulgué le 14 juillet 2026 et découvert par Stephen Fewer, chercheur de Rapid7 Labs, d’abord démontré en direct au Pwn2Own Berlin, et non observé dans la nature. Elle porte un score CVSS v3.1 de 9,1 et touche SharePoint Server 2016, 2019 et Subscription Edition.
Comment la confiance se rompt
SharePoint s’exécute sur IIS et ASP.NET, et son modèle d’authentification repose sur les claims : une requête présente un token signé qui affirme une identité, et les modules du backend sont censés vérifier cryptographiquement ce token avant qu’une session ne soit établie. Cette étape de vérification constitue toute la frontière de sécurité : tout ce qui se passe en aval (permissions, panneaux d’administration, accès au contenu) suppose que le token a été correctement vérifié avant d’arriver là.
CVE-2026-55040 a brisé cette hypothèse. Plusieurs faiblesses dans le pipeline de validation JWT de SharePoint faisaient que le serveur pouvait être amené à accepter un token qu’il aurait dû rejeter, et à associer la session obtenue à l’identité revendiquée par le token, et non à celle de l’auteur réel de la requête. Pas de mot de passe. Pas de cookie de session volé. Pas de point d’appui préalable. Juste un token que le serveur voulait bien croire.
Il y a une condition préalable : l’attaquant doit déjà savoir qui il veut usurper. En pratique, la barre est basse : les noms d’utilisateur sont souvent faciles à découvrir par une reconnaissance de routine (énumération AD, OSINT, données de fuites antérieures) et ne sont pas secrets comme peut l’être un mot de passe. Ce que fait la vulnérabilité, c’est transformer « je connais un nom d’utilisateur » en « je suis cet utilisateur, pleinement authentifié, avec tous les accès qu’il a ». Si l’identité choisie est celle d’un administrateur de site, l’attaquant hérite des opérations SharePoint de niveau administrateur sans jamais toucher aux identifiants de cet administrateur.
La surface exposée rend la faille plus grave qu’un défaut purement interne typique : les endpoints concernés se trouvent sous des chemins comme vtibin et _layouts, accessibles à distance sans authentification dans les configurations SharePoint par défaut. Ce n’est pas une API interne confidentielle qu’un attaquant ne peut atteindre qu’avec un point d’appui : elle est exposée par défaut sur tout déploiement accessible depuis Internet.
Pourquoi cela ne s’arrête pas à l’« accès non autorisé »
Voici la partie qui mérite une place dans cette section de la newsletter, et pas seulement une ligne dans des notes de correctif : la recherche de Rapid7 ne s’est pas arrêtée au contournement de l’authentification. Son équipe a constaté que CVE-2026-55040 peut être enchaînée avec une seconde vulnérabilité, actuellement non corrigée, pour atteindre une exécution de code à distance complète et non authentifiée : pas de connexion, pas d’identifiants, pas d’interaction de l’utilisateur, pas même d’identité d’administrateur requise. Les deux failles ont été développées et démontrées ensemble comme participation au Pwn2Own Berlin, puis divulguées de façon responsable à Microsoft en mai. (Remarque : ce composant RCE non corrigé est un problème distinct de CVE-2026-58644, une RCE par désérialisation que Microsoft a aussi corrigée le 14 juillet : il ne faut pas confondre les deux.)
Le calendrier de divulgation de Microsoft mérite d’être cité, car il montre à quel point cela a été orchestré :
18 mai 2026 : Rapid7 divulgue à Microsoft la chaîne d’exploitation complète de la RCE non authentifiée
20 mai 2026 : Microsoft confirme les résultats et répartit la remédiation sur deux cycles de mise à jour : le contournement de l’authentification en juillet, le composant RCE en août
29 mai 2026 : Rapid7 accepte un embargo de 30 jours sur les détails techniques après la divulgation de juillet, à condition de publier plus tôt si une exploitation dans la nature ou une divulgation par un tiers survient d’abord
14 juillet 2026 : la divulgation publique de CVE-2026-55040 et le correctif sortent ensemble lors du Patch Tuesday
Le correctif de juillet ne clôt donc pas l’histoire : il l’interrompt. Il brise la chaîne au premier maillon, avant même que le second soit corrigé. Toute organisation qui corrige CVE-2026-55040 aujourd’hui est protégée contre la chaîne actuellement connue, puisque la moitié RCE n’est pas atteignable sans une identité forgée valide au préalable. Mais la leçon de fond, qu’une identité forgée, une fois acceptée, est fonctionnellement indiscernable d’une vraie, ne disparaît pas avec un cycle de correctifs, et le correctif RCE d’août est de fait une seconde échéance déjà inscrite au calendrier.
État de l’exploitation : au moment de la rédaction, la CISA et Microsoft n’ont pas classé CVE-2026-55040 comme activement exploitée dans la nature : Microsoft l’a étiquetée « Exploitation More Likely » plutôt que comme exploitation confirmée. C’est un statut sensiblement différent de trois autres CVE SharePoint corrigées dans le même cycle (CVE-2026-32201, CVE-2026-45659, CVE-2026-56164), dont la CISA a confirmé qu’elles sont activement exploitées, pour l’accès non autorisé, la RCE, le vol de clés machine IIS et la persistance de malware. Aucune preuve de concept publique de CVE-2026-55040 n’est disponible pour l’instant ; Rapid7 a retenu les détails techniques complets sous son embargo de 30 jours. Les équipes sécurité ne doivent pas prendre cette période calme pour un délai de grâce : c’est un compte à rebours programmé vers août.
Ce que nous surveillons
L’alerte actuelle de la CISA sur le durcissement de SharePoint est rédigée pour les CVE sœurs déjà activement exploitées, et non pour CVE-2026-55040 en particulier, mais les comportements qu’elle décrit (vol de clés machine IIS, abus de désérialisation, persistance, déploiement de malware) relèvent des mêmes catégories d’activité de post-exploitation que nous attendrions une fois que la moitié RCE de cette chaîne deviendra publique. Si votre instance SharePoint était accessible depuis Internet avant le 14 juillet, le correctif répond à « suis-je encore vulnérable ? », mais pas à « ai-je déjà été utilisé ? ». À rechercher sur toute instance exposée, d’après notre propre lecture du schéma de menace :
Des actions d’administration ou des modifications de contenu ou de permissions provenant de sessions qui ne correspondent à aucun événement de connexion réel
De nouveaux administrateurs de collections de sites ou des attributions de rôles élevés sans ticket correspondant au help desk ou à la gestion des changements
Des requêtes inhabituelles ou anormales vers vtibin / _layouts dans les journaux IIS antérieurs au correctif
Tout mouvement latéral ou toute tentative d’authentification provenant du compte de service SharePoint ou de l’identité du pool d’applications
Des connexions sortantes ou de nouvelles tâches planifiées lancées depuis le serveur SharePoint lui-même
Le même schéma, encore
FortiBleed concernait un accès qui change de mains : des identifiants collectés, vérifiés et vendus comme du stock. Ici, il s’agit d’un accès qui n’a jamais vraiment existé : une session que le serveur a été trompé en croyant légitime, sans aucun vol. Mécanisme différent, même conclusion : quand il y a quelque chose de visible à quoi répondre, la compromission décisive a peut-être déjà eu lieu en silence, en amont. Et ici, la seconde moitié de la chaîne est encore à venir.
🛠️ Outil de la semaine
Tor
Tor est souvent associé à la navigation anonyme, mais pour les équipes sécurité, l’un de ses rôles les plus utiles est l’investigation encadrée.
Où il s’insère
Imaginez que le nom d’une entreprise apparaisse sur un site de fuites de ransomware. Le message affirme que des fichiers internes ont été volés et donne à l’organisation un délai pour répondre.
Avant de traiter cette affirmation comme une fuite confirmée, un analyste doit inspecter la page, consigner ce qui a été publié et déterminer si les échantillons de données sont authentiques. Le faire depuis un navigateur d’entreprise ordinaire peut révéler l’adresse IP publique de l’organisation à l’infrastructure examinée.
Le navigateur peut divulguer plus qu’une adresse IP. Les cookies, les extensions, les polices et d’autres caractéristiques peuvent aider à distinguer un visiteur d’un autre. L’activité de recherche peut aussi se mélanger aux comptes habituels et à l’historique de navigation de l’analyste.
Tor Browser crée une séparation entre l’investigation et l’environnement de navigation habituel de l’organisation. Il fait passer le trafic par plusieurs relais, masque l’adresse IP d’origine à la destination et inclut des protections conçues pour rendre le fingerprinting du navigateur plus difficile.
Comment fonctionne la connexion
Un navigateur ordinaire se connecte généralement directement à la destination. Le site peut donc voir l’adresse IP publique d’où provient la requête.
Tor fait passer la connexion par plusieurs relais avant qu’elle n’atteigne la destination. Chaque relais ne connaît que l’étape précédente et l’étape suivante du trajet. La destination voit l’adresse du dernier relais Tor, et non l’adresse IP d’entreprise ou personnelle de l’analyste.
Cette conception permet aussi d’accéder aux services onion. Ces services fonctionnent à l’intérieur du réseau Tor et servent couramment à la publication axée sur la confidentialité, à la communication sécurisée et, dans certains cas, à des sites de fuites criminels et à des forums clandestins.
Un workflow pratique
Ouvrez Tor Browser dans un environnement de recherche dédié, séparé de la navigation d’entreprise ordinaire. Visitez le service onion concerné et consignez l’affirmation, l’heure de publication, l’organisation touchée et tout délai indiqué. Capturez la page et conservez l’URL d’origine afin que les preuves puissent être examinées même si le message change ou disparaît. Examinez attentivement les échantillons visibles. Comparez les noms de fichiers, les structures de documents ou des marqueurs non sensibles avec les informations internes avant de conclure que les données sont authentiques. Consignez ce qui a été vérifié, ce qui reste une affirmation de l’attaquant et ce qui ne peut pas encore être confirmé. Transmettez les conclusions au processus de réponse à incident sans télécharger ni rediffuser de données exposées inutiles.
Ce workflow peut donner à l’équipe de réponse une réponse précoce à une question utile : ce message est-il du bruit recyclé, une affirmation sans preuve à l’appui ou un signe crédible qui exige une investigation immédiate ?
Au-delà de la surveillance des ransomwares
Tor peut soutenir d’autres formes de recherche en sécurité. Les analystes peuvent l’utiliser pour examiner une infrastructure de phishing, suivre des pistes de renseignement sur les menaces, surveiller les mentions des domaines d’une entreprise ou étudier la façon dont des identifiants et des accès volés sont mis en vente.
Il peut aussi aider les chercheurs à atteindre des ressources de sécurité indisponibles ou restreintes là où ils se trouvent. Dans chaque cas, son but est le même : créer une distance entre l’investigation et l’identité ou le réseau de la personne qui la mène.
Ce qu’il ne remplace pas
Tor ne garantit pas un anonymat complet. Se connecter à un compte personnel, réutiliser un nom d’utilisateur connu, révéler des informations identifiantes ou interagir selon un schéma de communication familier peut identifier le chercheur, quel que soit le chemin réseau.
Les fichiers téléchargés introduisent un autre risque. Ouvrir un document dans une application externe peut créer une connexion en dehors de Tor ou exposer des informations sur l’appareil. Les fichiers suspects doivent être traités dans un environnement d’analyse isolé, et non ouverts directement depuis la session de recherche.
Tor ne protège aussi que les applications configurées pour y faire passer leur trafic. Il ne protège pas automatiquement toutes les connexions de l’appareil, et faire passer un autre navigateur par le réseau Tor n’apporte pas les protections de confidentialité intégrées à Tor Browser.
Il ne remplace ni un poste de recherche isolé, ni la protection des endpoints, ni une manipulation soigneuse des preuves, ni un avis juridique, ni des procédures d’investigation claires. Tor protège le trajet vers la destination. La sécurité de l’investigation dépend toujours de ce qui se passe avant, pendant et après la connexion.
👏 Personnalité de la semaine
Romain Thomas est un ingénieur sécurité connu pour son travail en rétro-ingénierie, en protection logicielle et en obfuscation sur Android, iOS, macOS et Windows.
Ce qui rend la contribution de Romain T particulièrement précieuse, c’est qu’il partage ce qu’il construit avec l’ensemble de la communauté de la sécurité.
Romain a créé LIEF, une bibliothèque open source qui aide les chercheurs et les développeurs à analyser et modifier des formats exécutables comme PE, ELF et Mach-O. Aujourd’hui, LIEF soutient de nombreux projets de rétro-ingénierie, d’instrumentation et de sécurité.
Son travail open source comprend aussi des contributions à QBDI et QBDL, ainsi qu’Open Obfuscator, un projet qu’il a lancé pour faire progresser la protection des applications mobiles.
Cette reconnaissance ne récompense pas un seul outil réussi. Elle récompense des années passées à rendre un travail de sécurité complexe plus accessible et à donner à d’autres chercheurs une base plus solide sur laquelle construire.
Cette semaine, ce travail, et la personne qui le porte, méritent d’être mis en lumière.
📅 Événement de la semaine
Événement de la semaine : Black Hat USA 2026
Black Hat USA commence le samedi 1er août, avec quatre jours de formation technique avant que les summits, les présentations de recherche et les démonstrations Arsenal se poursuivent la semaine suivante.
Même sans voyage à Las Vegas, c’est une semaine utile pour suivre le programme. Les recherches divulguées à Black Hat orientent souvent les discussions qui suivent sur les vulnérabilités, la détection et l’outillage. Le programme de cette année accorde une attention particulière aux menaces autonomes liées à l’IA, à l’identité et à la confiance, à la sécurité des infrastructures et aux outils défensifs open source.
📚 Livre de la semaine
Spycraft: The Secret History of the CIA’s Spytechs, from Communism to al-Qaeda
Par Robert Wallace, H. Keith Melton et Henry R. Schlesinger
Spycraft raconte comment les ingénieurs de l’Office of Technical Service de la CIA ont conçu des caméras, des déguisements, des dispositifs de dissimulation et des systèmes de communication pour des environnements hostiles. Sa leçon vaut encore pour la cybersécurité : la technologie change, mais une sécurité efficace repose sur la compréhension de l’adversaire, de l’environnement et de la personne qui utilise l’outil.
😅 Le mème
Si quelqu’un quittait votre organisation aujourd’hui, pourriez-vous prouver, sans vérifier chaque système à la main, que chaque compte, session, token, clé et identifiant partagé qui lui était lié a cessé de fonctionner ?
The Breach Brief, L’équipe Ostorlab : ils n’ont pas volé un mot de passe. Ils en ont forgé un.