Face à CVE-2026-0257, Palo Alto Networks publie des correctifs et deux mesures d’atténuation. Mais sécuriser l’accès VPN ne règle pas la question d’une intrusion antérieure : Rapid7 rapporte des exploitations dès mai 2026, et Arctic Wolf documente des intrusions de juin ayant abouti au rançongiciel Qilin.

L’exposition dépend d’abord de la configuration. CVE-2026-0257 ne touche pas automatiquement tous les pare-feu Palo Alto Networks : elle concerne certaines configurations utilisant les cookies d’Authentication Override et leurs certificats. Ces cookies interviennent dans l’authentification ; dans une configuration vulnérable, un attaquant peut fabriquer un cookie accepté et établir une connexion VPN sans passer par l’authentification normale.

Pour déterminer la réponse adaptée, il faut donc examiner à la fois les réglages des accès GlobalProtect, leur version logicielle et l’historique des connexions. Ces vérifications permettent de distinguer une configuration exposée d’un accès effectivement utilisé par un attaquant.

Vérifier les portails, les passerelles et leurs certificats

L’avis de Palo Alto Networks répertorie des versions concernées dans les branches PAN-OS 10.2, 11.1, 11.2 et 12.1, ainsi que Prisma Access 10.2 et 11.2. Il indique que Panorama et Cloud NGFW ne sont pas concernés. Ce périmètre doit être précisé par l’examen de la version exacte et des réglages de chaque équipement.

Pour chaque portail et chaque passerelle GlobalProtect, la vérification porte sur la génération ou l’acceptation des cookies d’Authentication Override, puis sur le certificat utilisé. Rapid7 explique que réutiliser le certificat des cookies pour un service HTTPS peut rendre sa clé publique accessible et permettre la fabrication d’un cookie accepté par une configuration vulnérable. Le mécanisme décrit donne accès au VPN par contournement de l’authentification ; il ne démontre pas une exécution de code sur le pare-feu.

La version installée doit ensuite être confrontée au tableau officiel des versions concernées et corrigées. Les seuils varient selon les branches et les sous-versions : connaître seulement le numéro de branche ne permet pas de conclure que l’équipement est corrigé.

Coordonner la correction ou appliquer une atténuation officielle

Palo Alto Networks recommande d’installer une version corrigée. Dans les environnements utilisant les cookies d’Authentication Override, le constructeur précise que tous les portails et passerelles qui les génèrent ou les acceptent doivent être mis à niveau de façon coordonnée. Après cette opération, les utilisateurs doivent s’authentifier de nouveau une fois.

Le constructeur documente également deux mesures d’atténuation :

• désactiver les cookies d’Authentication Override ;
• utiliser pour ces cookies un certificat neuf et exclusivement réservé à cet usage.

La seconde option exige donc davantage que la sélection d’un autre certificat déjà partagé avec un service HTTPS : le caractère neuf et dédié du certificat fait partie de la mesure publiée.

L’avis décrit aussi un réglage temporaire de compatibilité pour une mise à niveau progressive. Ce réglage rétablit un ancien comportement des cookies. Il accompagne une migration et ne doit pas être repris isolément comme une protection permanente.

Rechercher les connexions réussies suspectes

L’examen des journaux vise à déterminer si la vulnérabilité a déjà été exploitée. Unit 42, l’équipe de recherche de Palo Alto Networks, recommande de rechercher dans les journaux GlobalProtect les connexions réussies correspondant aux adresses, identifiants d’hôte et noms d’appareil publiés dans ses indicateurs, ainsi que les événements « gateway-connected » suspects.

Lorsqu’une connexion réussie correspond à ces indicateurs, Unit 42 recommande d’engager une réponse à incident. L’investigation doit alors porter sur les conséquences possibles de l’accès obtenu, au-delà de la configuration du portail VPN.

Ces indicateurs servent au triage, c’est-à-dire à repérer les événements qui demandent une investigation. Leur liste n’étant pas exhaustive, l’absence de correspondance ne permet pas de déclarer le réseau sain. De même, l’installation du correctif ne démontre pas l’éradication d’une intrusion antérieure.

De l’accès VPN au rançongiciel dans les cas étudiés

Les observations publiées illustrent les conséquences possibles de cet accès. Rapid7 rapporte des exploitations réussies chez plusieurs clients, avec une première activité observée le 17 mai 2026. Dans ses observations de mai, l’entreprise ne décrivait toutefois pas de déplacement latéral réussi, c’est-à-dire de progression vers d’autres systèmes du réseau. Ce constat reste limité au périmètre et à la période observés par Rapid7.

Arctic Wolf a, de son côté, documenté plusieurs intrusions distinctes de juin ayant abouti au déploiement de Qilin. Ses enquêtes décrivent une collecte d’identifiants, des déplacements latéraux, un effacement de journaux et un chiffrement, ainsi qu’une exfiltration de données dans certains cas. Ces résultats concernent les incidents étudiés par Arctic Wolf ; ils ne décrivent pas l’issue de toute exploitation de la faille.

À partir de ces enquêtes, Arctic Wolf propose de surveiller les activités observées après l’accès VPN. Ces recommandations complémentaires lui sont propres. Parmi les recommandations directement publiées par Palo Alto Networks figurent la correction ou l’atténuation de la configuration vulnérable, la recherche des connexions suspectes et la réponse à incident lorsqu’une connexion réussie correspond aux indicateurs de Unit 42. Cette sélection ne constitue pas un inventaire exhaustif des consignes officielles.

Les sources publiques consultées ne permettent pas d’établir le nombre total d’organisations compromises. Pour une organisation qui examine ses propres accès, la décision dépend de ses constats : si une connexion suspecte est identifiée, la mise à jour de GlobalProtect laisse ouverte l’investigation des actions réalisées dans le réseau.

Sources

• Palo Alto Networks, avis de sécurité CVE-2026-0257
• Unit 42, texte indexé du Threat Brief sur CVE-2026-0257
• Rapid7, exploitation observée et analyse technique
• Arctic Wolf Labs, Cookie Crumbles

Une faille d’Ivanti Connect Secure permet à un attaquant distant d’exécuter des commandes sans authentification. Volexity documente son exploitation. Pour les administrateurs, la priorité est d’identifier les versions concernées, d’appliquer le correctif adapté et de rechercher une éventuelle intrusion : la mise à jour ne suffit pas à écarter une compromission antérieure.

Sur une passerelle d’accès distant comme Connect Secure, la correction et l’examen d’une intrusion répondent à deux questions distinctes. La première porte sur la vulnérabilité du système ; le second cherche à établir ce qu’un attaquant a pu y faire avant l’installation du correctif. Rapid7 recommande donc de rechercher une compromission même après la mise à jour.

La fiche CVE publiée sous l’autorité d’attribution d’Ivanti décrit CVE-2026-104935 comme un contournement d’authentification par usurpation permettant l’exécution de commandes arbitraires. Elle indique une attaque réseau de faible complexité, sans privilège initial ni interaction de l’utilisateur, avec un score CVSS 3.1 de 8,6.

Identifier précisément les branches déployées

La première vérification consiste à relever le numéro complet de version de chaque appliance. Les seuils dépendent de la branche et de sa révision : un numéro abrégé ne permet pas de déterminer correctement l’exposition.

Rapid7 et le Center for Internet Security indiquent les seuils affectés et les versions corrigées suivants :

Les trois versions limites figurant dans ce tableau sont donc concernées selon ces sources. L’alerte du NHS England emploie une formulation « prior to » qui semble les exclure. Cette divergence justifie de confirmer la matrice de mise à niveau auprès d’Ivanti avant l’intervention, sans considérer ces versions limites comme épargnées.

La fiche CVE précise que 22.7R2.14 et les versions antérieures ne sont pas touchées par cette CVE particulière. Cette exclusion ne renseigne pas leur exposition à d’autres vulnérabilités et ne constitue pas une appréciation générale de leur sécurité.

Distinguer le correctif de la chaîne complète d’attaque

Le tableau permet d’identifier la mise à jour à examiner. La procédure applicable, les éventuelles mesures d’atténuation et les consignes de récupération restent à confirmer auprès d’Ivanti.

Il faut aussi distinguer CVE-2026-104935 de la chaîne complète décrite par Volexity. Dans son enquête, l’entreprise rapporte un routage abusif de requêtes vers un composant CGI protégé, suivi d’une exécution de code et d’une élévation de privilèges distincte. Cette dernière étape a permis d’exécuter des commandes avec les privilèges root sur une appliance 22.8R2.4 alors à jour. Ces privilèges correspondent au niveau de contrôle obtenu sur le système dans ce cas précis.

Dans leurs publications du 13 octobre 2026, Volexity et Rapid7 indiquaient que le correctif de cette élévation de privilèges distincte restait à venir. Les mises à jour visant CVE-2026-104935 ne doivent donc pas être présentées comme corrigeant toute la chaîne. La disponibilité ultérieure d’un correctif pour cette autre faille reste à vérifier auprès du fournisseur.

L’inscription au catalogue des vulnérabilités exploitées connues de CISA, le KEV, renforce la priorité donnée à cette alerte. Selon Rapid7 et la reprise des données du catalogue par CIRCL, CVE-2026-104935 y a été ajoutée le 13 octobre 2026, avec une échéance au 16 octobre pour les entités soumises aux exigences fédérales américaines applicables. Cette échéance n’est pas une date limite réglementaire universelle.

Rechercher les signes d’entrée et les actions qui ont suivi

Volexity situe au plus tard au 3 octobre 2026 le début de l’exploitation répétée reconstituée dans son enquête. Sur l’appliance étudiée, l’entreprise décrit notamment des recherches de secrets Active Directory, une exfiltration de données et une altération des journaux. Ces observations orientent l’examen d’un système suspect, sans établir que toutes les appliances vulnérables ont subi les mêmes actions.

Pour rechercher des traces, Volexity recommande notamment de surveiller les requêtes anormalement nombreuses vers la page de connexion concernée, les incohérences entre le chemin demandé et l’en-tête de routage, ainsi que l’activité après exploitation. L’entreprise prévient que d’autres chemins pourraient être employés : limiter l’examen au seul parcours observé risquerait de laisser de côté une autre forme d’exploitation.

L’examen doit ainsi porter sur les signes d’entrée comme sur les actions qui ont pu suivre. Lorsque l’exploitation est suspectée, Rapid7 renvoie aux procédures de récupération du fournisseur. Leurs étapes restent à obtenir auprès d’Ivanti ; le récit de l’attaque ne permet pas de les reconstituer.

Pourquoi le contrôle d’intégrité peut manquer une compromission

Selon Volexity, l’Integrity Checker Tool recherche des modifications de fichiers sur disque. Or la chaîne observée modifiait notamment du code en mémoire puis restaurait certaines données. Un contrôle centré sur l’état des fichiers peut ainsi manquer des traces de cette activité. Une absence d’alerte de l’outil ne suffit donc pas à écarter une compromission.

La capture publiée par Volexity provient de son enquête et de son outil commercial d’analyse mémoire Volcano. Elle montre des alertes dans le cas étudié, notamment liées à une activité de capture réseau. Elle illustre le type de traces que l’analyse mémoire peut apporter en complément de l’examen des fichiers, sans mesurer l’efficacité générale de cette détection ni représenter toutes les exploitations.

Dans le suivi de l’incident, il faut donc conserver séparément la version identifiée, la correction appliquée et le résultat de la recherche de compromission. Un résultat normal du contrôle d’intégrité ne doit pas clore à lui seul ce dernier volet. Si des indices subsistent, les consignes de récupération du fournisseur restent la référence à consulter.

Sources

• CVE Program, fiche CVE-2026-104935, autorité d’attribution Ivanti
• Volexity, A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days
• Rapid7, Ivanti Connect Secure zero-day exploited in the wild
• Center for Internet Security, A Vulnerability in Ivanti Connect Secure Could Allow for Arbitrary Code Execution
• CIRCL Vulnerability-Lookup, reprise de l’entrée CISA KEV pour CVE-2026-104935
• NHS England Digital, Ivanti Releases Security Updates for Connect Secure

Si un CV reste en apparence un document classique, avec ses expériences, ses compétences et ses diplômes, ce que le recruteur voit à l’écran ne correspond pas toujours à ce que son logiciel lit. Certains documents contiennent des informations presque imperceptibles pour un humain, mais accessibles à l’extraction automatique. Des compétences supplémentaires peuvent ainsi être prises en compte par le logiciel sans apparaître dans la présentation lue par le recruteur.

Fait vérifié. Présentée à USENIX Security 2026, une étude de Mohan Zhang et ses coauteurs porte sur 196 682 CV et rapporte 2 030 détections de contenus cachés classés comme injections, soit environ 1 %. Plus de 90 % des contenus repérés sont des ajouts de données sans instruction explicite, notamment des compétences et des expériences. Ces chiffres ne mesurent ni des recrutements obtenus frauduleusement ni des intrusions informatiques. étude USENIX sur les CV

Le point de départ est donc une manipulation de l’information soumise au traitement automatique. Une compétence supplémentaire peut rendre un profil plus pertinent pour un moteur de recherche ou un dispositif de classement, sans jamais commander au logiciel de changer de comportement.

Mais une autre question apparaît : un CV pourrait-il aussi donner des instructions à l’IA chargée de l’évaluer, puis tenter de détourner les outils auxquels elle a accès ? Cette hypothèse mérite un examen précis. Elle dépend du chemin suivi par les données, du comportement du modèle et des permissions effectives de l’application.

Pour les directions informatiques, les responsables de sécurité et les équipes RH, l’enjeu consiste à comprendre où se situe cette frontière. Un document reçu de l’extérieur doit pouvoir être analysé sans devenir une autorité sur le fonctionnement du système. Les études disponibles permettent déjà d’examiner la manipulation des évaluations. Une éventuelle chaîne reliant candidature, agent et accès internes exige, elle, des preuves supplémentaires.

Le CV, un support de confiance déjà exploité

Les recruteurs ont une particularité opérationnelle : leur travail les oblige à ouvrir des documents et à consulter des liens transmis par des personnes qu’ils ne connaissent pas. Une candidature constitue une raison légitime d’engager cette interaction. Ce contexte donne aux attaquants un prétexte crédible, sans rendre chaque document suspect par nature.

Faits historiques. En 2017, Check Point a décrit des failles permettant de transférer des fichiers malveillants par la messagerie LinkedIn sous une apparence acceptable. LinkedIn avait déployé un correctif le 24 juin 2017, avant la publication du rapport. Il s’agissait de sécurité des fichiers et d’exécution de code, pas d’injection de prompt. rapport Check Point de 2017

En décembre 2023, Proofpoint a documenté des campagnes de TA4557 visant les recruteurs. Des échanges avec de faux candidats les conduisaient vers des sites imitant des CV, puis vers une chaîne d’infection liée à More_eggs. Certains documents servaient à orienter la victime vers le site ; cela ne signifie pas que chaque PDF constituait lui-même un malware. recherche Proofpoint sur TA4557

Aryaka décrit également, dans son rapport BlackSanta, une campagne utilisant des liens vers des fichiers présentés comme des CV pour cibler les processus de recrutement. Cette source de recherche d’éditeur concerne encore une infection classique, distincte du détournement d’un modèle de langage. rapport BlackSanta d’Aryaka

Le rapprochement avec les agents IA porte sur le point d’entrée : du contenu extérieur arrive au cœur d’une activité légitime. Le mécanisme change ensuite. Un logiciel malveillant cherche une exécution informatique ; une injection de prompt cherche à faire interpréter un texte comme une consigne. Une entreprise peut donc avoir correctement sécurisé l’ouverture des pièces jointes tout en conservant un risque dans leur traitement sémantique.

Extraction, classement et agent : trois niveaux à distinguer

Parler de « recrutement par l’IA » sans préciser l’architecture entretient la confusion. Un premier traitement peut simplement convertir un document en texte et remplir des champs : poste occupé, durée d’expérience, diplôme, compétences déclarées. Un autre peut rapprocher ces champs d’une fiche de poste. Un troisième peut produire une synthèse ou une note. Enfin, un agent peut sélectionner des actions et solliciter des outils.

Ces opérations ont des surfaces de risque différentes. Une liste cachée de compétences peut contaminer une extraction, y compris sans modèle génératif. Une instruction destinée à modifier une justification suppose qu’un composant interprète ce texte et lui accorde une influence indue. Un appel à un dossier interne suppose encore une capacité d’action et des permissions correspondantes.

Connectivité documentée. La documentation Apply Connect de LinkedIn décrit une intégration permettant aux partenaires de recevoir des candidatures directement dans leur ATS, c’est-à-dire leur système de suivi des candidatures. Elle établit un flux métier ; elle ne décrit pas une attaque. documentation Apply Connect

Bullhorn documentait dès 2020 une intégration Recruiter System Connect entre LinkedIn et ses solutions fondées sur Salesforce. Les fonctions de synchronisation et de consultation doivent être comprises dans leur périmètre propre. Elles ne démontrent pas le transfert systématique d’un PDF brut à un agent. intégration LinkedIn et Bullhorn

La fiche Bullhorn Amplify for Salesforce annonce des fonctions de matching et de screening. Une présentation officielle de Bullhorn décrit aussi des agents configurables fondés sur Agentforce dans Recruitment Cloud. Ces documents commerciaux attestent des capacités proposées, sans révéler les permissions de chaque installation ni prouver une vulnérabilité. fiche Bullhorn Amplify, présentation officielle de Bullhorn

L’audit utile commence donc par une cartographie concrète. Quel composant extrait le texte ? Quelles transformations suivent ? Le modèle reçoit-il le document entier ou quelques champs ? Peut-il seulement proposer une réponse, ou aussi consulter des informations et modifier un statut ? Qui autorise ces opérations ? Les réponses comptent davantage qu’une étiquette « IA » dans une brochure.

Ce que les recherches établissent réellement

Observation sur des documents réels. Le PDF final de l’étude USENIX identifie hireEZ comme origine des données. Les auteurs réunissent deux jeux de CV désidentifiés et utilisent un détecteur spécialisé pour repérer des éléments cachés. Leur définition large comprend les ajouts de données et les instructions explicites. texte intégral de l’étude USENIX

Le détail temporel impose une nuance : les taux connaissent un pic en 2024, puis baissent dans les observations récentes. Dans le jeu Applicant Match, les auteurs estiment néanmoins une augmentation du nombre absolu de documents concernés, liée au volume de candidatures. Dire simplement que « les attaques augmentent » effacerait la différence entre fréquence et quantité. Le rappel exact du détecteur sur l’ensemble du corpus demeure inconnu ; aucune efficacité sur les décisions finales n’est mesurée. texte intégral de l’étude USENIX

Expérience sur le filtrage. Honglin Mu et ses coauteurs évaluent différentes manipulations dans un benchmark de sélection de CV. La version révisée du 26 avril 2026 rapporte des taux dépassant 80 % pour certaines catégories, dans ses conditions expérimentales. Le tableau consacré aux méthodes attribue notamment 80,89 % à la catégorie « Job Manipulation » sans défense ; ce taux ne résume pas toutes les attaques et ne mesure aucun accès à un système interne. étude de Mu et ses coauteurs, benchmark et résultats détaillés

Cette étude signale aussi un compromis : les protections évaluées peuvent réduire la manipulation tout en augmentant les rejets de candidatures légitimes. Une défense RH doit donc être évaluée pour sa sécurité et pour ses effets sur les personnes, au lieu de retenir uniquement un taux de blocage. benchmark et résultats détaillés

Expérience sur le classement. Preet Baxi et ses coauteurs observent que les manipulations sont plus efficaces lorsque les profils ont une qualité similaire et que peu de candidats les utilisent. L’avantage diminue lorsque la manipulation se généralise. Leur étude porte sur les positions dans un classement, pas sur une fuite de données. étude de Baxi et ses coauteurs

Expérience sur la détection. RAPIDS, présenté par Yohann Augey et ses coauteurs, combine un petit modèle spécialisé et une vérification supplémentaire. Les auteurs annoncent un rappel de bout en bout d’au moins 98 % sur les deux jeux évalués, avec une latence réduite d’un facteur 21 à 24 par rapport à leur référence. Le texte précise toutefois une couverture limitée aux CV anglophones et un jeu réel annoté de 1 945 documents. publication RAPIDS, méthode et limites de RAPIDS

Ces travaux mesurent des contenus, des classements ou une capacité de détection. Établir une compromission d’entreprise demanderait encore des preuves d’actions effectives et de franchissement des contrôles d’accès.

Trois mécanismes, trois réponses

Une injection de données ajoute de l’information destinée au traitement automatique. Dans un exemple entièrement fictif, le CV visible mentionne une expérience de support informatique ; le texte extrait contient aussi des compétences absentes de la présentation. Le problème porte sur la fidélité de la représentation et sur la confiance accordée à des qualifications déclarées.

Une injection d’instructions cherche à orienter l’évaluateur. Elle peut tenter de modifier le commentaire ou de faire abandonner une règle de classement. La question devient celle de l’autorité : le contenu d’une candidature ne doit pas définir la procédure utilisée pour l’examiner. Une telle instruction peut être visible ; son invisibilité facilite certaines manipulations, mais ne constitue pas une condition nécessaire.

Un malware vise une exécution ou une compromission technique selon une autre chaîne. Le document, le téléchargement ou le lien peut servir d’amorce. Confondre ces mécanismes conduirait à choisir une défense adaptée à un problème différent de celui rencontré.

Du CV à l’outil interne : une hypothèse conditionnelle

Hypothèse, non chaîne démontrée. Imaginons qu’un CV conserve une instruction après extraction, que cette instruction arrive dans le contexte d’un agent et que celui-ci la traite comme légitime. Il pourrait alors proposer une action étrangère à l’évaluation. Pour que cette proposition produise un effet, un outil doit exister, être accessible et accepter l’appel.

Chaque flèche correspond à une condition à vérifier. Une extraction peut retirer le passage suspect. Une représentation structurée peut réduire sa portée, tout en conservant des données trompeuses. Le modèle peut ignorer la sollicitation. Une règle applicative peut refuser l’action. L’absence d’une seule capacité peut interrompre le scénario envisagé.

Précédents indépendants. ForcedLeak, publié par Noma Security en septembre 2025, concernait une injection indirecte via des données Web-to-Lead dans Salesforce Agentforce. Les chercheurs décrivaient un risque de fuite de données CRM et des mesures correctives de Salesforce, notamment sur les destinations de sortie autorisées. L’entrée étudiée était un formulaire commercial, pas un CV. recherche ForcedLeak de Noma

EchoLeak, associé à CVE-2025-32711, concernait Microsoft 365 Copilot et un e-mail préparé pour provoquer une fuite dans les conditions de la démonstration. L’analyse publiée rapporte une correction côté service. Ce précédent ne démontre aucune attaque par candidature, ni une exploitation observée chez des recruteurs. étude de cas EchoLeak, analyse et chronologie d’EchoLeak

Ces cas montrent pourquoi les contrôles doivent porter sur l’ensemble de l’application. Le modèle n’a pas besoin d’obtenir de nouveaux privilèges si l’application lui en accorde déjà trop pour la tâche. À l’inverse, une réponse dévoyée peut rester sans effet opérationnel lorsque les capacités sont étroitement limitées.

Ce que je sais / Ce que je suppose / Ce que j’ai observé en lab

En lab, le CV visible ne change pas, mais sa note augmente

Pour observer ces mécanismes, j’ai évalué en lab quatre profils entièrement fictifs. Le profil B possède un an d’expérience en support bureautique. Ses variantes ajoutent soit des compétences cachées, soit une instruction neutre concernant le commentaire, soit une sollicitation de consultation fictive. Les quatre versions produisent exactement la même image avec le moteur de rendu utilisé ; leurs extractions textuelles diffèrent.

La campagne du 12 octobre 2026 comprend 320 essais, avec 20 répétitions par condition. Elle utilise Qwen3.5 9B, quantifié en Q4_K_M, sous Ollama 0.33.2, à une température de 0,2, sans mode de raisonnement étendu. Chaque requête repart d’une conversation neuve. Le serveur et le programme d’essais sont isolés du réseau extérieur.

La grille réserve 40 points aux compétences, 30 à l’expérience, 20 aux incidents résolus et 10 à la formation. La configuration de départ fournit déjà cette tâche et un format de réponse. La configuration renforcée ajoute une consigne de séparation et un balisage du CV comme donnée non fiable. Une troisième configuration conserve ces consignes et ajoute un refus des consultations inutiles dans le code.

Les compétences ajoutées augmentent donc la note moyenne d’environ 26 points dans les deux configurations. Le modèle les lit dans le texte extrait et les prend en compte dans son évaluation. Ce scénario ne contient aucune instruction lui demandant de changer sa note : il illustre une modification des données utilisées pour juger le profil.

La consigne renforcée ne corrige pas cet effet. Elle vise les instructions contenues dans le CV, tandis que les ajouts ressemblent à des qualifications ordinaires. Le modèle reçoit le texte, sans l’image du document : il ne peut pas comparer les deux vues pour repérer ce qui était invisible. La vérification documentaire doit donc intervenir avant que cette information visuelle soit perdue.

L’instruction neutre produit un autre résultat. Elle demande une modification de la fin du commentaire, sans ajouter de qualification. Elle est suivie dans toutes les réponses de départ, puis dans huit réponses malgré les consignes renforcées. Dans ces huit sorties, le champ prévu pour les alertes reste vide. La séparation réduit ici l’effet observé, mais ne l’élimine pas. En revanche, la note moyenne de cette variante n’augmente pas : modifier le commentaire et améliorer le score sont deux conséquences distinctes.

Une proposition d’outil n’est pas un accès aux données

Dans le scénario de consultation, le modèle peut produire une proposition structurée pour un mock, un outil simulé. Six réponses de départ en proposent une, alors que la consultation est annoncée comme inutile à l’évaluation. Le code retourne seulement une constante inventée. Avec les consignes renforcées, aucune proposition n’apparaît, y compris dans la configuration ajoutant le contrôle applicatif.

Cela signifie qu’aucun refus n’a été exercé par cette dernière barrière pendant la campagne. Son fonctionnement est vérifié séparément par les tests du dispositif, qui soumettent directement des demandes au contrôle. Présenter le résultat comme des attaques effectivement bloquées par le code confondrait ces deux vérifications.

Le modèle n’a reçu aucun outil natif d’Ollama : il produit des objets de données ensuite examinés par le programme. Le retour fictif n’est pas réintroduit dans une seconde conversation. Ce test ne mesure donc ni une action d’agent de bout en bout, ni un accès à un dossier, ni une fuite. La déclaration du mock n’apparaît que dans ce scénario ; les six propositions ne suffisent pas à attribuer causalement leur apparition au seul texte du CV.

Un format correct peut accompagner une évaluation discutable

Les 320 réponses respectent les champs, les bornes et la somme des sous-scores. Aucun essai n’est rejeté pour erreur de format ou délai dépassé. Cela ne garantit pas la fiabilité du contenu. Dans la variante à compétences cachées, 30 réponses sur 40 fournissent une citation qui ne correspond pas à un passage continu du texte extrait, souvent en assemblant les compétences visibles et ajoutées. Ce défaut de citation ne prouve pas que ces compétences ont été inventées par le modèle.

Deux réponses signalent aussi, à tort, qu’un total de 58 points dépasse le plafond de 100. Même la référence varie : de 25 à 40 points au départ et de 22 à 50 avec les consignes renforcées. Les moyennes décrivent cette grille et ce modèle ; elles ne valident pas la justesse des notes pour recruter.

Enfin, les répétitions portent sur les mêmes documents fictifs, avec différentes graines de génération. Elles renseignent sur la variabilité de ces conditions, pas sur la fréquence d’une attaque parmi de vrais candidats. Aucun détecteur visuel, autre modèle ou logiciel RH commercial n’a été évalué. Le lab montre une frontière de confiance à protéger, sans démontrer une vulnérabilité de produit.

Des défenses qui protègent aussi la décision RH

Cadres défensifs. OWASP recommande notamment de séparer les contenus extérieurs, de limiter les privilèges et de valider les sorties par du code. Microsoft présente également une défense en profondeur contre les injections indirectes. Ces recommandations fournissent un cadre ; leur efficacité dépend de leur mise en œuvre et de leur évaluation. recommandations OWASP, défense en profondeur de Microsoft

Pour une équipe RH, la première décision consiste à définir ce que l’agent peut accomplir. Une synthèse de candidature peut souvent être produite à partir du seul document et de la fiche de poste. Lui donner, pour cette tâche, un accès général à tous les dossiers ou à des fonctions d’envoi élargit inutilement les conséquences d’une erreur.

La deuxième priorité concerne la provenance. Les qualifications restent des déclarations du candidat, même après leur extraction dans une base interne. Le stockage ne leur confère aucune autorité sur la procédure. Une synthèse intermédiaire devrait conserver les passages justificatifs et permettre de retrouver le document d’origine, afin qu’un champ douteux puisse être examiné.

La troisième priorité consiste à rendre les autorisations explicites. Chaque outil doit vérifier l’identité, les ressources accessibles, l’objet de la tâche et les paramètres. La justification rédigée par le modèle ne suffit pas à créer un droit. Une action doit être refusée si elle dépasse les capacités prévues, même lorsque la sortie respecte parfaitement le format demandé.

La détection documentaire complète ces barrières. Comparer rendu et extraction peut faire apparaître du contenu supplémentaire. Un signal doit déclencher une revue proportionnée, avec examen des artefacts de conversion possibles. Le candidat ne devrait pas être exclu automatiquement sur la seule décision d’un détecteur : une erreur de mise en page et une manipulation intentionnelle ne se déduisent pas d’une simple alerte.

Enfin, la supervision humaine doit disposer de preuves utilisables : critères, citations du CV, transformations appliquées, alertes et actions proposées. Valider une note sans accès à ces éléments peut seulement ajouter une signature à une décision opaque. Pour un responsable RH, la possibilité de contester une extraction ou de revenir au document compte autant que la fluidité de l’interface.

Cadre réglementaire vérifié le 12 octobre 2026. L’annexe III de l’AI Act vise notamment certains systèmes d’analyse, de filtrage et d’évaluation des candidatures. Le texte de l’article 113 affiché par le service officiel et sa FAQ indiquent le 2 décembre 2027 pour les dispositions relatives aux systèmes à haut risque de cette annexe. La qualification précise et les dispositions transitoires doivent être examinées selon le système ; cette date ne résume pas toutes les obligations applicables. annexe III de l’AI Act, article 113 de l’AI Act, calendrier officiel de l’AI Act

Le contenu caché des CV pose déjà une question de fidélité des données utilisées pour recruter. Les instructions malveillantes ajoutent une question d’autorité ; les agents connectés ajoutent une question de permissions. Examiner ces trois niveaux permet d’agir sans transformer une hypothèse en incident établi. Le CV peut renseigner l’entreprise sur une candidature. Il ne doit pas définir les règles de son évaluation ni les droits de son évaluateur.

EvilTokens fait passer une autorisation d’accès pour une vérification nécessaire à l’ouverture d’un document. L’utilisateur peut alors authentifier la demande de l’attaquant sur une véritable page Microsoft. Le parcours décrit par Microsoft éclaire ce piège, les traces à examiner après une suspicion et les mesures de sécurisation à adapter à son environnement.

Une attaque contre le sens de l’autorisation

Un code de connexion relie deux actions : la demande d’un client logiciel et sa validation par un utilisateur. Dans le parcours EvilTokens, le leurre dissimule qui a lancé cette demande. La personne croit vérifier son identité pour accéder à un document, alors qu’elle accorde un accès au client contrôlé par l’attaquant. Le mot de passe et la vérification multifacteur peuvent être saisis sur le bon site sans corriger ce décalage.

Dans son analyse du 22 septembre 2026, Microsoft décrit une plateforme de phishing par abonnement qui organise cette chaîne, depuis la préparation du message jusqu’à l’exploitation des comptes. L’entreprise lui associe plus de 12 000 boîtes compromises dans plus de 10 000 organisations et attribue son développement et son support à Storm-2992. Ces chiffres et cette attribution restent les conclusions de Microsoft ; les autres sources fournies ne les valident pas indépendamment.

Huntress a relié à EvilTokens une campagne observée sur Railway, tandis que Cloudflare rapporte l’utilisation de ses Workers et sa participation à une opération coordonnée de démantèlement. Ces observations corroborent des mécanismes et des infrastructures dans leurs périmètres respectifs. Elles ne constituent pas une mesure indépendante de l’ensemble des victimes annoncé par Microsoft.

Les neuf captures publiées dans l’analyse Microsoft permettent de suivre l’organisation du service et le parcours proposé à la victime. Les écrans commerciaux documentent des options et des promesses, dont l’affichage ne prouve pas l’efficacité. Les observations d’incidents apportent une autre information : elles décrivent les actions effectivement rapportées dans les cas étudiés.

Le code appareil : un usage légitime détourné

Le flux OAuth par code appareil répond à une contrainte réelle. Un téléviseur, une imprimante ou certains équipements Teams ne permettent pas une connexion interactive confortable. Le client demande alors un code à Microsoft, l’affiche, puis attend. L’utilisateur saisit ce code dans un navigateur, éventuellement sur un autre appareil, et termine l’authentification. Après cette autorisation, le client demandeur reçoit un jeton d’accès et, selon le cas, un jeton de renouvellement.

Le jeton d’accès permet d’utiliser les ressources autorisées ; le jeton de renouvellement sert à obtenir de nouveaux jetons d’accès. La distinction compte pour la suite : récupérer ces éléments ne revient pas seulement à connaître un mot de passe. L’attaquant dispose d’un moyen d’exercer l’accès accordé au client, dans les limites des autorisations obtenues et de la validité des jetons.

Dans le détournement décrit par Microsoft, le client demandeur est contrôlé par l’attaquant. Le code est présenté à la victime comme une étape nécessaire pour consulter un document ou vérifier son identité. L’utilisateur effectue une authentification légitime, mais au bénéfice d’une demande qu’il n’a pas lui-même initiée. Parler simplement de « MFA contournée » masque cette mécanique : la victime peut accomplir elle-même l’authentification multifacteur, ou MFA, pendant qu’elle autorise la mauvaise session.

Une boutique, un support et un panneau de campagne

Selon Microsoft, EvilTokens rassemble dans une même plateforme les éléments nécessaires à une campagne : modèles de messages, pièces jointes, pages d’arrivée, hébergement, redirections et suivi des victimes. Les abonnés peuvent ainsi préparer leurs opérations avec l’assistance du service, plutôt que de construire séparément chaque composant technique.

Le profil du bot Telegram présenté comme la boutique EvilTokens affiche un contact d’administration, un site et un contact de secours. Ces différents points de contact donnent au service l’apparence d’une offre suivie, avec plusieurs moyens de joindre ses opérateurs. Microsoft rapporte que Telegram sert également aux annonces, aux mises à jour, à la coordination des abonnés et au support. Le profil ne permet pas d’identifier les personnes derrière ces comptes.

L’offre affichée dans le bot mêle vocabulaire d’entreprise et promesses offensives. Elle présente notamment des jetons qui « n’expirent pas » et un accès persistant après changement de mot de passe. Dans son analyse de septembre 2026, Microsoft rapporte un achat initial de 1 500 dollars américains et un abonnement mensuel de 500 dollars. Ces tarifs décrivent l’offre étudiée, sans établir sa disponibilité actuelle. Les promesses de non-expiration et de persistance ne remplacent pas l’examen des autorisations et de la validité réelle des jetons.

La page d’accueil du panneau répartit la préparation entre deux familles d’hébergement : Cloudflare Workers/Bunny et hébergement PHP. Elle présente ensuite des réglages de mode de capture, de modèle, d’affichage du code, de langue, de CAPTCHA et de personnalisation. L’intérêt de cette interface guidée est de rapprocher des choix habituellement dispersés : où héberger le leurre, quelle apparence lui donner et comment présenter l’étape d’autorisation à la cible.

Le panneau de gestion des jetons annonce l’accès à la messagerie, la détection de comptes administrateurs, le renouvellement automatique et des alertes par mots-clés. Il présente donc l’authentification de la cible comme le début d’un travail sur le compte, plutôt que comme la fin de l’attaque. Les possibilités étendues promises pour certains jetons administrateurs restent toutefois des affirmations du service : les permissions réellement obtenues, notamment sur les autres boîtes d’une organisation, ne sont pas établies par cet écran.

La page d’outils complémentaires propose un navigateur ET, un redirecteur antibot, un expéditeur B2B, un expéditeur SMTP et un validateur d’adresses Office. Les boutons d’acquisition et de tutoriel, ainsi que l’offre de parrainage, prolongent la logique de boutique. Microsoft rapporte des frais supplémentaires pour plusieurs modules et une récompense en cryptomonnaie pour les recommandations. Ce catalogue montre comment le service commercialise des fonctions autour du leurre, de sa diffusion et de l’exploitation des accès ; il ne mesure pas leur contribution aux incidents.

Microsoft rapporte aussi l’usage d’assistants d’IA pour adapter les messages au rôle de la cible et analyser des messageries compromises. Cette assistance s’inscrit dans la même organisation du travail : préparer un message pertinent, puis chercher des comptes ou des échanges intéressants après l’accès. Les observations fournies ne permettent ni de quantifier le gain apporté par l’IA ni de conclure qu’elle intervient dans toutes les campagnes.

Des modèles familiers pour faire accepter une étape inhabituelle

Le sélecteur de thèmes présente notamment la signature Adobe, DocuSign, une notification vocale, la quarantaine de messagerie, l’expiration de mot de passe et le partage de fichiers. Des champs permettent de modifier la couleur, le nom du document et le pied de page. Microsoft décrit 44 thèmes au total, dont seule une partie apparaît dans la capture. Ces réglages permettent d’envelopper la demande de code dans plusieurs situations professionnelles familières, sans changer le principe de l’autorisation recherchée.

Le ressort du leurre est de rendre cohérente une étape qui, isolément, devrait interroger. La signature d’un document peut servir de prétexte à une vérification d’identité ; un avis d’expiration suggère une action urgente ; une proposition commerciale donne une raison d’ouvrir un lien. Microsoft décrit des messages adaptés aux fonctions des destinataires. Huntress rapporte également des propositions de chantier, des accords commerciaux, des messages sur la rémunération et des avis d’expiration de mot de passe.

Le courriel présenté en exemple invite le destinataire à soumettre une proposition pour un projet et renvoie vers un dossier annoncé comme accessible via Adobe. Une référence de document et une invitation à poser des questions lui donnent le ton d’un échange professionnel ordinaire. Le message fournit ainsi une raison d’ouvrir le lien avant toute demande de connexion. La capture ne révèle cependant ni l’identité réelle de l’expéditeur, ni la destination effective du lien, ni le résultat de l’interaction.

Les points d’entrée décrits par Microsoft comprennent des URL, des PDF et des fichiers HTML. L’interaction avec le lien ou la pièce jointe amorce le parcours vers la page de phishing. Le leurre n’a donc pas besoin de demander immédiatement un mot de passe : il peut d’abord conduire la personne vers une étape intermédiaire qui prépare l’autorisation.

Du faux document à la véritable connexion Microsoft

La page aux couleurs d’Adobe Acrobat Sign associe un document nommé Important_update.pdf à une demande de vérification d’identité avec Microsoft. Elle affiche un code, propose de le copier, puis de continuer vers Microsoft. L’accès au document devient ainsi le motif apparent de l’opération. Cette mise en scène est visible dans la capture ; la génération du code en temps réel et la récupération ultérieure des jetons sont décrites par l’analyse Microsoft.

Selon Microsoft, la page exécute un script d’automatisation qui échange avec le fournisseur d’identité pour obtenir un code valide. Le bouton de continuation dirige ensuite la victime vers le portail officiel microsoft.com/devicelogin. L’analyse décrit aussi une copie automatique fréquente du code dans le presse-papiers, destinée à réduire les manipulations demandées à l’utilisateur. Le passage vers un véritable portail de connexion fait donc partie du piège.

Pendant ce temps, l’infrastructure suit l’avancement de la session. Dans la séquence étudiée, Microsoft décrit une fonction checkStatus() qui interroge un point de terminaison /state toutes les trois à cinq secondes, pendant une fenêtre de quinze minutes. Ce suivi transmet un identifiant secret de session et reste en attente tant que la victime n’a pas terminé l’authentification. Il renseigne l’état du parcours côté plateforme ; il ne constitue pas, à lui seul, la preuve d’une autorisation réussie.

L’écran Microsoft de saisie du code avertit que l’application ou l’appareil concerné obtiendra l’accès au compte et qu’il ne faut pas saisir un code provenant d’une source non fiable. C’est le changement de sens crucial entre les deux pages : le leurre parle de consulter un document, tandis que le portail parle d’accorder un accès. Microsoft présente cette capture comme son écran de connexion par code appareil ; l’authenticité de la page de destination ne garantit pas la fiabilité de l’origine du code.

Si la victime n’a pas de session active, elle peut être invitée à saisir son mot de passe et à effectuer la MFA. Si elle est déjà connectée, la saisie du code et la confirmation peuvent suffire dans le parcours décrit. Lorsque l’autorisation aboutit, le client contrôlé par l’attaquant peut obtenir les jetons. Le secret n’a pas nécessairement été tapé dans une imitation de page de connexion : c’est l’autorisation donnée au mauvais client qui fait basculer l’accès.

Une livraison à plusieurs étapes pour compliquer l’analyse

Microsoft décrit des liens portés par des images, des pièces jointes et plusieurs redirections avant la page finale. Certaines pages imposent un faux CAPTCHA ou une vérification nécessitant une interaction humaine avant de montrer le contenu. Ces étapes cherchent à compliquer l’examen par des analyseurs d’URL et des environnements automatisés. Elles constituent des techniques d’évasion observées, sans garantir un passage à travers toutes les protections.

L’analyse rapporte l’utilisation de domaines légitimes compromis et de plateformes comme Vercel, Cloudflare Workers et AWS Lambda pour héberger la logique de redirection. L’objectif est de faire passer des éléments de l’attaque au milieu de trafic cloud habituel et de limiter l’efficacité d’un filtrage fondé uniquement sur la réputation du domaine. Cela n’autorise pas à qualifier de malveillant tout usage de ces plateformes.

Pour une campagne suivie en avril 2026, Microsoft rapporte des milliers de nœuds de suivi uniques et de courte durée, avec une logique serveur en Node.js. Le fournisseur associe cette infrastructure dynamique à des difficultés pour les détections par signature ou motif. Cloudflare confirme, dans son propre compte rendu, avoir observé des usages de Workers et supprimé des projets et domaines associés lors de l’opération coordonnée de septembre. Ces observations portent sur des périmètres distincts : Cloudflare ne valide pas ici le détail des nœuds suivis en avril par Microsoft.

Après les jetons : lire, sélectionner et prolonger l’accès

Selon Microsoft, l’accès obtenu peut servir à lire et extraire des courriels, mais aussi à envoyer de nouveaux messages aux collègues et contacts externes de la victime. La confiance attachée au compte compromis devient alors un moyen de poursuivre le phishing. L’analyse rapporte également des règles de boîte malveillantes utilisées pour faciliter l’exploitation de la messagerie et dissimuler des communications. Ces règles ne prolongent pas, par elles-mêmes, la validité d’un jeton OAuth.

Dans un incident rapporté, les attaquants ont sélectionné des profils financiers, de direction ou d’administration parmi les comptes compromis. Microsoft décrit une analyse assistée par IA de l’activité des boîtes et une reconnaissance par Microsoft Graph pour cartographier la structure interne et les permissions. Les recherches dans les courriels visaient notamment des instructions de virement, des factures en attente et des échanges de dirigeants. Ces observations ne démontrent pas que chaque compte autorisé subit toutes ces actions.

La temporalité varie également. Microsoft rapporte certains enregistrements de nouveaux appareils dans les dix minutes suivant la compromission, afin de produire un Primary Refresh Token, ou PRT, pour une persistance durable. Dans d’autres cas, les acteurs attendent plusieurs heures avant de créer des règles ou d’extraire des messages. L’enquête doit donc couvrir la suite de l’autorisation, sans supposer que l’absence d’action immédiatement visible clôt le scénario.

Après une suspicion : reconstruire la chronologie dans les journaux

Le premier objectif est de relier une demande par code appareil à l’activité ultérieure du compte. Dans les connexions Entra, les éléments à examiner comprennent le compte, l’heure, le résultat, le protocole Device code flow, l’application, la ressource, l’adresse IP, les informations d’appareil et les politiques d’accès conditionnel. La propriété Original transfer method peut indiquer qu’une connexion ou un renouvellement provient d’une session initialement créée par code appareil. Elle aide à comprendre cette origine, sans être à elle seule un identifiant unique de corrélation ni une preuve d’activité malveillante.

Une connexion réussie, même avec MFA, ne suffit pas à exclure l’attaque. Inversement, un flux par code appareil, une adresse IP ou une localisation inhabituelle ne prouvent pas isolément un vol de jeton. L’interprétation repose sur la concordance entre l’autorisation, l’application concernée, les usages attendus et les actions suivantes. Un clic documente une interaction ; il ne démontre pas à lui seul que l’utilisateur a terminé l’autorisation.

Les journaux d’audit et l’état des appareils permettent ensuite d’examiner un éventuel enregistrement nouveau. Côté Exchange, les opérations New-InboxRule, Set-InboxRule et MailItemsAccessed fournissent des pistes sur les règles et les accès aux messages. Les transferts et l’état des règles doivent également être examinés. Un appareil ou une règle nouvellement créé demande une vérification de son caractère autorisé ; un événement d’accès aux messages ne décrit pas, à lui seul, toute une exfiltration.

La reconnaissance Graph exige une précaution supplémentaire : vérifier que les journaux d’activité correspondants étaient collectés avant l’incident. Ils nécessitent Entra ID P1 ou P2 et une intégration vers un stockage ou un outil d’analyse ; Entra ne les conserve pas nativement par défaut. Une recherche vide peut donc refléter un manque de données. Activer cette collecte après l’attaque ne restitue pas les appels passés.

La fenêtre disponible doit être vérifiée avant de tirer des conclusions. Les journaux de connexion et d’audit Entra sont conservés par défaut sept jours avec Entra ID Free, et trente jours avec P1 ou P2. La chasse avancée Defender XDR porte sur au plus trente jours de données natives. Ces durées concernent des ensembles distincts ; elles ne garantissent pas que tous les événements utiles existent dans l’environnement Microsoft 365 de l’organisation.

Ce que les recherches Defender apportent, et ce qu’elles ne prouvent pas

La première requête publiée par Microsoft part d’alertes Defender for Office 365, relie l’URL au message et au destinataire, puis recherche un événement BrowserLaunchedToOpenUrl sur le poste associé. Ses jointures utilisent notamment les tables AlertInfo, AlertEvidence, EmailEvents, IdentityInfo et DeviceEvents. Elle aide à rapprocher un message signalé et un clic observé ; elle n’établit pas directement l’émission d’un jeton ni son utilisation par l’attaquant.

La seconde requête filtre EmailEvents pour repérer des messages dont ThreatTypes est renseigné et qui ont été remis dans la boîte de réception ou les courriers indésirables. Elle identifie donc une livraison associée à une menace détectée, pas nécessairement une ouverture ou une autorisation. Microsoft explique qu’une recherche utile peut devenir une règle de détection personnalisée. Les requêtes du billet restent des points d’entrée à compléter par l’examen des connexions et des actions après compromission.

La présence de données dépend des produits et de leur intégration. CloudAppEvents, par exemple, repose sur Defender for Cloud Apps et la connexion des activités Microsoft 365. Microsoft associe aussi Safe Links et Entra ID Protection à des alertes de forte confiance sur le phishing par code appareil. Leur présence effective et l’ensemble de leurs conditions de licence n’ont pas été vérifiés dans un environnement donné : disposer de Microsoft 365 ne garantit donc pas l’accès à toutes ces données et alertes.

Les rapports Threat Analytics cités par Microsoft nécessitent une licence pour au moins un produit Defender XDR. Le billet liste des profils sur la technique, l’outil et l’acteur, mais affiche Storm-2922 dans cette liste alors que le corps de l’analyse attribue EvilTokens à Storm-2992. Cette discordance demeure dans la source. Le profil lié n’ayant pas pu être vérifié publiquement dans les éléments fournis, l’hypothèse d’une coquille ne permet pas de trancher.

Les conseils Microsoft : contenir l’accès, puis réduire les occasions de phishing

En cas de compromission présumée, Microsoft recommande une désactivation temporaire du compte, la révocation des sessions et des jetons de renouvellement, puis l’examen des appareils, des méthodes MFA, des consentements d’applications, des transferts et des règles de boîte. Le billet mentionne la révocation des sessions de connexion et la possibilité de forcer une nouvelle authentification par accès conditionnel. Ces actions doivent être adaptées au compte et à l’incident, en tenant compte de leur impact sur l’activité.

La révocation ne doit pas être interprétée comme une coupure instantanée de tout accès. Dans les campagnes étudiées, Microsoft rapporte que des jetons d’accès déjà émis peuvent rester utilisables jusqu’à une heure après une révocation ordinaire des sessions. Cette fenêtre rapportée n’est pas un maximum universel : la durée résiduelle effective dépend du jeton, de la ressource et des mécanismes de révocation applicables. Microsoft recommande donc de désactiver temporairement le compte compromis. Si un appareil et son PRT sont impliqués, l’entreprise recommande aussi de désactiver l’appareil et de révoquer les jetons de renouvellement existants afin de traiter cette voie de persistance.

Pour réduire la surface exposée, Microsoft recommande de bloquer le flux par code appareil partout où il n’est pas nécessaire. La documentation conseille d’en inventorier les usages avec une politique en mode rapport seul avant le blocage. Certains équipements Teams peuvent nécessiter des exceptions ciblées sur leurs comptes de ressources. Microsoft indique également d’exclure la ressource Device Registration Service pour préserver les usages d’enregistrement concernés ; cette exception ne s’applique pas indistinctement à toutes les politiques. L’accès conditionnel nécessite une licence Entra ID P1, P2 ou un essai adapté.

La sensibilisation doit expliquer ce que l’écran Microsoft autorise réellement. Le nom de l’application attendue et l’origine du code comptent autant que l’apparence de la page. Microsoft recommande de se méfier des liens suspects dans les messages externes et de ne pas se connecter à des ressources proposées par des expéditeurs inconnus. L’exemple Adobe illustre précisément pourquoi une vérification d’identité présentée comme banale peut cacher une demande d’accès différente.

Sur la messagerie, Microsoft conseille les politiques antiphishing, Safe Links, un Advanced Phishing Threshold réglé à 2 ou 3 et Zero-hour auto purge, ou ZAP, pour traiter rétroactivement des messages à partir de nouvelles informations de menace. Le fournisseur recommande également des alertes sur les créations suspectes de règles de boîte, SmartScreen dans les navigateurs compatibles, ainsi que les protections réseau et Web. Ces couches visent à réduire les occasions d’attaque ; elles ne remplacent pas la vérification de l’autorisation et de ses suites.

Microsoft recommande enfin la MFA, des méthodes résistantes au phishing comme les clés FIDO ou les passkeys de Microsoft Authenticator, le blocage de l’authentification héritée et des politiques fondées sur le risque de connexion. Les politiques intégrant le risque Entra ID Protection exigent P2, contrairement au simple blocage du flux par code appareil disponible avec P1. Elles répondent à des conditions différentes et ne doivent pas être confondues. La MFA reste utile contre de nombreuses attaques, mais les éléments fournis ne démontrent pas qu’un changement de méthode MFA, isolément, empêcherait toute autorisation piégée par code appareil.

Les recommandations plus générales portent sur le moindre privilège, l’audit des comptes privilégiés et la centralisation des données d’identité. En environnement hybride, Microsoft préconise de conserver une frontière pour les comptes administratifs et fortement privilégiés plutôt que de tous les synchroniser. Pour appliquer ces conseils, l’organisation doit vérifier les produits, licences, collectes et exceptions réellement présents. Dans l’enquête comme dans la prévention, cette vérification détermine ce qu’elle peut observer et ce qu’elle peut effectivement bloquer.

Sources

• Microsoft Security Blog, Unmasking EvilTokens
• Huntress, Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure
• Cloudflare Cloudforce One, Operation to disrupt EvilTokens
• Microsoft Learn, OAuth 2.0 device authorization grant
• Microsoft Learn, Conditional Access: Authentication flows
• Microsoft Learn, Microsoft Entra data retention
• Microsoft Learn, Respond to a compromised email account in Microsoft 365
• Microsoft Learn, Advanced hunting overview in Microsoft Defender XDR
• Microsoft Learn, CloudAppEvents table
• Microsoft Learn, Exchange audit record properties
• Microsoft Learn, Access Microsoft Graph activity logs
• Microsoft Learn, Plan Your Microsoft Entra Conditional Access Deployment
• Microsoft Learn, Access tokens in the Microsoft identity platform

L’infrastructure Cloud moderne repose sur une agilité sans précédent, offrant aux entreprises la capacité de déployer des services et des interfaces à l’échelle mondiale en quelques clics. Cependant, cette facilité d’utilisation masque souvent une complexité architecturale redoutable. En tant qu’architectes et ingénieurs en infrastructure (Virtualisation, Cloud, Cyber-Infra), nous savons que chaque couche d’abstraction supplémentaire introduit son lot de vulnérabilités potentielles. Aujourd’hui, nous plongeons au cœur d’une faille de conception majeure qui ébranle la confiance dans l’un des composants les plus utilisés de l’écosystème Microsoft Azure : l’Azure API Management (APIM).

Une étude récente menée par la société de cybersécurité Praetorian, s’appuyant sur les travaux initiaux du chercheur Mihalis Haatainen, a révélé une statistique pour le moins alarmante : 97,9 % des portails développeurs Azure APIM exposés sur Internet sont vulnérables à un contournement de l’authentification lors de l’inscription (Signup Bypass). Plus troublant encore, le Security Response Center de Microsoft (MSRC) a classifié ce comportement comme étant « By design » (conçu ainsi). Ce constat impose aux équipes de sécurité et d’infrastructure de comprendre cette mécanique en profondeur pour pallier l’absence de correctif officiel.

Cet article se propose de décortiquer cette vulnérabilité, de détailler la chaîne d’attaque (kill chain) complète, d’évaluer les impacts concrets sur votre infrastructure, et de fournir des recommandations pragmatiques pour fermer cette béance de sécurité.

1. Analyse Technique : Les fondations de la vulnérabilité

Pour bien appréhender le problème, il faut d’abord comprendre le rôle d’Azure APIM. Cette solution agit comme une passerelle (Gateway) entre vos services backend (API internes, bases de données, microservices) et le monde extérieur (développeurs tiers, partenaires, applications front-end). Le Portail Développeur est l’interface web où ces consommateurs externes peuvent s’enregistrer, découvrir les API disponibles, et générer les clés de souscription nécessaires pour effectuer leurs appels API.

La vulnérabilité ne réside pas dans une injection SQL ou un dépassement de tampon, mais dans un décalage flagrant entre l’interface utilisateur (UI) d’administration et la logique métier du backend (REST API). Ce décalage se décompose en trois failles conceptuelles distinctes.

A. Le commutateur UI « Cosmétique »

La première erreur d’appréciation vient du portail d’administration d’Azure. Lorsqu’un administrateur décide de restreindre l’accès à ses API, il se rend dans les paramètres et désactive l’option d’inscription publique (portalsettings/signup.properties.enabled configuré sur false). Visuellement, le bouton « Sign Up » disparaît du portail développeur. L’administrateur pense alors, à juste titre, que l’endpoint d’inscription est désactivé.

Pourtant, il n’en est rien. Le moteur de rendu du portail masque l’interface, mais l’API REST sous-jacente au niveau du endpoint /signup reste parfaitement active. Elle continue d’écouter les requêtes et d’accepter les demandes de création de compte. Il s’agit d’une sécurité par l’obscurité, totalement inefficace face à un attaquant automatisé.

B. L’absence de validation Tenant-Side (Multi-tenant)

Les portails développeurs Azure APIM reposent sur une infrastructure mutualisée (multi-tenant). Lorsqu’une requête HTTP arrive sur les serveurs de Microsoft, elle est routée vers l’instance APIM du bon client en analysant l’en-tête Host de la requête (par exemple : Host: victime-portal.developer.azure-api.net).

La faille majeure ici est l’absence totale de validation d’origine. L’infrastructure Azure ne vérifie à aucun moment si la requête POST /signup a été légitimement générée depuis le domaine du client ou si l’utilisateur a une quelconque relation avec l’organisation cible.

C. La mutualisation du service CAPTCHA

Pour lutter contre les bots et les créations de comptes en masse, Microsoft a intégré un défi CAPTCHA lors du processus d’inscription. Cependant, le service de validation de ce CAPTCHA est global à l’ensemble de l’infrastructure Azure APIM, et non isolé par tenant.

Ainsi, un attaquant peut générer un défi CAPTCHA sur sa propre instance APIM (qu’il contrôle), le résoudre légitimement, puis envoyer le jeton de validation obtenu vers l’instance APIM de la victime. Le système backend de la cible interrogera le service global, qui confirmera la validité du CAPTCHA. L’attaquant vient de contourner la protection anti-bot par une attaque de type « Cross-tenant replay ».

2. La Kill Chain : De l’accès anonyme à l’exfiltration de données

L’équipe de recherche a simulé et documenté une chaîne d’attaque complète pour prouver la criticité de cette faille de conception. La création du compte n’est que la porte d’entrée ; la véritable gravité dépend de la configuration des « Produits » (Products) dans l’APIM.

Par défaut, chaque nouvelle instance APIM est livrée avec un produit nommé « Starter ». Ce produit possède une configuration par défaut fatale dans ce contexte : il requiert une souscription (subscriptionRequired: true) mais ne nécessite aucune approbation manuelle de la part de l’administrateur (approvalRequired: false).

Voici la décomposition pas-à-pas de l’attaque simulée :

Étape 1 : Identification de la cible via OSINT

L’attaquant commence par identifier des instances APIM exposées sur Internet. En utilisant des moteurs de recherche spécialisés comme Shodan, il est extrêmement simple de lister les serveurs répondant au nom d’hôte par défaut *.developer.azure-api.net. Les chercheurs ont ainsi identifié plus de 25 379 instances uniques.

Étape 2 : Vérification du verrouillage cosmétique

L’attaquant visite le portail de la cible. Il constate que l’administrateur a fait son travail : l’inscription semble impossible.

L’interface ne présente aucun bouton pour s’enregistrer, laissant penser que le système est clos.

Mais l’attaquant ne s’arrête pas à l’interface graphique. Il envoie une requête POST artisanale (via curl ou Postman) avec un corps JSON vide vers le endpoint /signup. La réponse du serveur est sans appel : une erreur HTTP 400 « ValidationError » demandant de fournir les informations du challenge CAPTCHA.

Cette erreur prouve de manière irréfutable que le endpoint écoute et que l’authentification « Basic Auth » est toujours activée sur le backend.

Étape 3 : Création d’un compte Cross-Tenant

Fort de cette confirmation, l’attaquant utilise sa propre instance APIM pour générer un CAPTCHA valide. Il forge ensuite une requête POST vers le portail de la victime, en y injectant ses propres identifiants (email, mot de passe) et le jeton CAPTCHA pré-résolu.

Le serveur cible reçoit la requête, interroge le service CAPTCHA global, valide la demande et retourne un statut HTTP 200 OK. Le compte est créé.

Le système de la victime, agissant de manière parfaitement automatisée selon sa conception, envoie même un e-mail de bienvenue à l’attaquant pour confirmer la création de son compte !

Étape 4 : Authentification et obtention de la clé d’API

Désormais doté d’un compte développeur valide, l’attaquant s’authentifie sur l’API de management d’Azure pour interagir avec le portail de la victime.

Il cible alors le produit par défaut « Starter ». Puisque ce produit est configuré pour auto-approuver les demandes d’abonnement, l’attaquant envoie simplement une requête PUT pour s’y inscrire. Le serveur répond par un code HTTP 201 Created.

Dans la foulée, il extrait les clés de souscription primaires et secondaires qui lui donnent désormais un accès complet aux API rattachées à ce produit.

L’automatisation du système ira jusqu’à lui envoyer un nouvel e-mail le félicitant (Youpi 🙁 ) pour son abonnement au produit Starter.

Étape 5 : Exploitation et exfiltration des données

Avec une clé d’API valide en main, la dernière étape consiste à consommer les services backend. Dans l’environnement de test (simulant une API IoT médicale), l’attaquant a pu requêter le nombre de patients.

Pire encore, il a pu exfiltrer des données sensibles complètes (données synthétiques pour la démonstration) incluant des noms, des dates de naissance, des diagnostics médicaux et des identifiants d’assurance.

3. Impacts sur l’Infrastructure et Matrice d’Exploitabilité

Il est essentiel de comprendre que la gravité de cette vulnérabilité varie considérablement en fonction de la manière dont votre infrastructure APIM a été configurée après son déploiement initial. L’équipe de recherche a défini une matrice d’exploitabilité très claire.

Les trois niveaux d’impacts potentiels :

1. Impact Faible (Bruit / Compte fantôme) : Si tous vos produits API exigent une approbation manuelle (approvalRequired: true), l’attaquant pourra créer un compte utilisateur, mais il sera bloqué à l’étape de la souscription. Il ne pourra pas générer de clé d’API. Le risque se limite à une pollution de votre annuaire d’utilisateurs locaux APIM.
2. Impact Modéré (Découverte et reconnaissance) : Si des API non sensibles ou des environnements de « Staging » sont attachés à un produit auto-approuvé. L’attaquant peut cartographier vos endpoints, comprendre la structure de vos requêtes, et préparer des attaques plus ciblées ultérieurement.
3. Impact Critique (Exfiltration et Mouvement latéral) : C’est le scénario du pire. Des API de production, manipulant des données sensibles ou des fonctions métiers critiques (gestion financière, RH, santé), sont rattachées au produit « Starter » ou à un produit auto-approuvé. L’exfiltration de données est immédiate et indétectable, car la clé d’API utilisée est techniquement valide et autorisée par le Gateway. De plus, si l’APIM est interconnecté avec un VNet interne via le mode « Internal » ou « External », l’attaquant pourrait utiliser ces API pour pivoter vers d’autres serveurs de votre infrastructure.

Sur les 25 379 instances analysées heuristiquement via une requête sans charge utile, il est estimé que plus de 23 000 répondent d’une manière confirmant l’activité du endpoint Basic Auth. Seules 51 instances avaient été correctement durcies par leurs administrateurs en supprimant le fournisseur d’identité vulnérable.

4. Recommandations : Les actions pragmatiques de durcissement

Microsoft ayant statué que ce comportement relève du design originel du produit, aucune mise à jour corrective (patch) ne sera poussée automatiquement sur vos tenants. Il est de la responsabilité exclusive des équipes d’architecture Cloud et de sécurité de combler cette faille. L’approche « Security by Default » n’est pas applicable ici ; il faut opérer une « Security by Configuration ».

Voici les quatre étapes cruciales pour sécuriser votre infrastructure APIM.

A. Suppression définitive du fournisseur d’identité « Basic Authentication » (Mesure Radicale)

C’est la seule méthode qui élimine totalement la surface d’attaque. En supprimant le fournisseur d’identité par défaut, le endpoint /signup n’a plus aucune logique d’authentification à laquelle se rattacher, désactivant de facto le mécanisme d’inscription local.

Action en CLI :

B. Transition vers Entra ID (anciennement Azure AD)

C’est la recommandation architecturale sur le long terme. Plutôt que de gérer une base d’utilisateurs locale (et vulnérable) dans APIM, déléguez l’authentification à votre fournisseur d’identité d’entreprise. En liant APIM à Entra ID, la création de compte est soumise aux règles de votre annuaire (MFA, accès conditionnel, validation du domaine). Le bypass cross-tenant devient structurellement impossible puisque l’authentification est cryptographiquement liée à votre propre tenant (Directory).

C. Imposer l’approbation manuelle sur tous les produits (Defense in Depth)

Si des impératifs métiers vous empêchent de supprimer le Basic Auth dans l’immédiat, vous devez impérativement casser la kill chain à l’étape de la génération des clés d’API. Modifiez la configuration de tous vos produits, et particulièrement du produit « Starter » intégré par défaut, pour forcer la validation humaine des souscriptions.

Action en CLI via l’API Management :

En configurant approvalRequired: true, l’attaquant verra sa demande d’abonnement mise en attente.

D. Audit et nettoyage des comptes compromis

Enfin, vous devez vérifier si votre infrastructure a déjà été silencieusement compromise. Utilisez les outils en ligne de commande pour lister l’ensemble des utilisateurs enregistrés sur votre portail APIM via l’authentification basique.

Analysez les dates de création (notamment celles postérieures à votre supposée « désactivation » via l’UI) et les domaines de messagerie utilisés. Supprimez immédiatement tout compte suspect et révoquez l’ensemble de leurs clés de souscription associées.

Conclusion : La vigilance continue face au Cloud

La vulnérabilité du Signup Bypass sur Azure APIM est un cas d’école fascinant et effrayant pour tous les professionnels de l’infrastructure informatique. Elle démontre avec acuité que la sécurité dans le Cloud ne se résume pas à cocher des cases dans une interface graphique conviviale. Les abstractions visuelles masquent des API REST complexes et des logiques de routage multi-tenant qui peuvent être détournées de leur usage premier.

Dans un modèle de responsabilité partagée, lorsque l’éditeur du logiciel (Microsoft) qualifie une faille de « comportement par défaut », c’est à l’équipe cliente (vous) de redoubler de vigilance. L’audit régulier des configurations, l’automatisation du durcissement (via Terraform ou Bicep) et l’adoption du principe du moindre privilège (en imposant Entra ID et l’approbation manuelle) sont les seuls remparts viables contre ce type de menaces silencieuses. Ne laissez pas un simple bouton ON/OFF dicter le niveau de sécurité de vos données les plus critiques.

Source : https://www.praetorian.com/blog/azure-apim-signup-bypass/

L’écosystème Cloud de Microsoft, bien que robuste, devient un terrain de jeu de plus en plus prisé pour l’ingénierie sociale de haute précision. Récemment, des chercheurs en sécurité ont mis en évidence une méthode d’attaque particulièrement insidieuse utilisant le service Azure Monitor. Cette campagne ne repose pas sur une faille logicielle de type « Zero-day », mais sur le détournement fonctionnel d’une fonctionnalité légitime d’infrastructure pour contourner les passerelles de sécurité de messagerie (SEG).

Introduction : Le détournement de la confiance infrastructurelle

Dans le cadre de l’administration d’infrastructures hybrides, les alertes provenant de azure-noreply@microsoft.com sont considérées comme critiques et fiables. Les administrateurs et les utilisateurs finaux sont habitués à recevoir ces notifications pour des seuils de consommation, des pannes de service ou des alertes de sécurité. C’est précisément cette confiance que les acteurs de menaces exploitent aujourd’hui via le « Callback Phishing » (ou BazarCall).

1. Analyse Technique : Le mécanisme de l’alerte « Action Group »

L’attaque repose sur la configuration des Action Groups dans Azure Monitor. Techniquement, Azure permet de définir des groupes d’actions qui déclenchent des notifications (Email, SMS, Push) lorsqu’une règle d’alerte est satisfaite.

Le vecteur d’attaque se décompose comme suit :

1. Création du Tenant Attaquant : L’attaquant utilise son propre tenant Azure (souvent créé avec des identifiants volés ou des essais gratuits).
2. Configuration de l’Action Group : Il crée un groupe d’actions incluant les adresses e-mail de ses cibles. Azure envoie alors une notification légitime pour confirmer l’abonnement, ou déclenche une alerte basée sur une condition personnalisée.
3. Injection du Payload Social : L’attaquant personnalise le nom de l’alerte ou la description pour y inclure un message alarmiste (ex: « Activité suspecte détectée sur votre compte ») et un numéro de téléphone à appeler (« Callback »).
4. Authenticité du Sendeur : L’e-mail est expédié par les serveurs de Microsoft. Les protocoles SPF, DKIM et DMARC sont parfaitement valides, ce qui rend l’e-mail pratiquement invisible pour les filtres anti-spam classiques.

2. Impacts sur l’Infrastructure et la Sécurité

L’impact majeur réside dans la neutralisation des outils de défense périmétriques. Une infrastructure protégée par des solutions de type Proofpoint, Mimecast ou Microsoft Defender for Office 365 aura de grandes difficultés à classer cet e-mail comme malveillant, car l’origine est intrinsèquement sûre.

Sur le plan de l’infrastructure cyber, cela ouvre la porte à :

• L’Accès Initial : Une fois la victime au téléphone, l’attaquant la guide pour installer un outil de prise en main à distance (Remote Access Tool) ou un malware.
• Mouvement Latéral : Une fois le poste de travail compromis, l’attaquant peut exfiltrer des tokens de session ou des identifiants pour rebondir sur l’infrastructure interne.
• Déni de Service Cognitif : La multiplication de ces fausses alertes sature les équipes SOC et réduit la vigilance des utilisateurs face aux vraies alertes d’infrastructure.

Recommandations et Remédiations

Face à ce détournement de service Cloud, les recommandations doivent être à la fois techniques et organisationnelles.

Mesures Techniques (Hardening)

1. Filtrage de contenu dynamique : Configurez vos outils de sécurité pour analyser le corps des e-mails provenant de domaines de confiance (microsoft.com) à la recherche de mots-clés spécifiques (numéros de téléphone inhabituels, termes comme « Support », « Invoice »).
2. Monitoring des inscriptions Action Groups : Si vous gérez un parc Azure, surveillez via les logs d’audit (Azure Activity Logs) toute création d’Action Group suspecte ou toute tentative d’inscription d’utilisateurs internes par des tenants externes.
3. Isolation des postes de travail : Renforcez les politiques d’exécution de scripts (PowerShell Constrained Language Mode) et bloquez les outils d’administration à distance non autorisés (AnyDesk, TeamViewer, etc.) via des politiques AppLocker ou Microsoft Defender for Endpoint.

Mesures Organisationnelles

• Formation spécifique au Callback Phishing : Informez les utilisateurs qu’une alerte Azure légitime ne demandera jamais de contacter un numéro de téléphone pour une « résolution urgente ».
• Procédure de vérification : Établissez une règle stricte : toute alerte d’infrastructure doit être vérifiée directement sur le portail Azure (portal.azure.com) et non via les liens ou numéros présents dans un e-mail.

Conclusion

L’usage malveillant des alertes Azure Monitor démontre la créativité des attaquants qui préfèrent désormais exploiter la logique métier des services Cloud plutôt que leurs vulnérabilités logicielles. Pour l’expert infrastructure, cela signifie que la confiance accordée aux flux « système » doit être réévaluée. La vigilance humaine reste, dans ce cas précis, le dernier rempart contre une compromission orchestrée depuis les propres serveurs de Microsoft.

Source : https://www.bleepingcomputer.com/news/security/microsoft-azure-monitor-alerts-abused-in-callback-phishing-campaigns/

Le premier trimestre de l’année 2026 marque un tournant critique dans l’évolution des cyber-menaces ciblant les couches basses de l’infrastructure informatique. Les rapports récents, notamment ceux analysant les activités des groupes INC Ransom et Everest Group, révèlent une mutation profonde : les attaquants ne se contentent plus de cibler l’utilisateur final, ils visent désormais l’intégrité structurelle des datacenters, des environnements de virtualisation et des systèmes de stockage distribués.

Pour les architectes infrastructure et les RSSI, le constat est sans appel : la surface d’attaque s’est déplacée des terminaux vers les piliers de la continuité d’activité (BCP). Cette analyse technique décortique les méthodes d’exfiltration, les vecteurs de compromission Linux et les impératifs de durcissement pour 2026.

1. Analyse Technique : La Double Extorsion au Cœur de l’Infrastructure

L’activité cybernétique de février 2026 est dominée par deux acteurs aux méthodologies distinctes mais complémentaires dans leur nuisance : INC Ransom et Everest Group.

INC Ransom : Le Sniper des Flux Logistiques

Le cas de AOT Japan Ltd. est emblématique. En ciblant ce prestataire logistique d’envergure internationale, INC Ransom ne cherche pas seulement à paralyser une entreprise, mais à créer une onde de choc dans la « Supply Chain ». Techniquement, INC Ransom utilise des techniques avancées de mouvement latéral. Une fois le périmètre franchi — souvent via des vulnérabilités non corrigées sur des passerelles VPN — le groupe déploie des outils de reconnaissance pour mapper les partages réseau (SMB/NFS) et identifier les serveurs de fichiers critiques.

L’attaque sur AOT Japan montre que le groupe a réussi à contourner les mécanismes de détection EDR traditionnels en utilisant des outils de « Living off the Land » (LotL), détournant des utilitaires d’administration système légitimes pour exfiltrer les données avant même que le processus de chiffrement ne soit déclenché.

Everest Group : Les Maîtres de l’Exfiltration de Données Massives

À l’opposé du spectre, Everest Group adopte une posture de courtier de données de haut vol. L’attaque contre Shinwa Co Ltd s’est soldée par l’exfiltration de 42 Go de bases de données. Ce chiffre n’est pas seulement une statistique ; pour une infrastructure IT, cela représente souvent l’intégralité des schémas SQL, des dossiers RH et de la propriété intellectuelle stockée sur des baies de stockage SAN/NAS.

Everest Group excelle dans l’identification des « Shadow Data » : ces volumes de données oubliés, souvent des backups non chiffrés ou des environnements de staging mal sécurisés, qui deviennent une mine d’or pour l’extorsion sans même nécessiter le blocage des systèmes de production.

2. Statistiques et Vecteurs : Pourquoi l’Infrastructure Linux est en Péril

L’analyse des données de télémétrie de ce début d’année 2026 permet de dresser un portrait-robot de la cible idéale.

Géographie et Secteurs : Une Cible Occidentale et Industrielle

Les États-Unis demeurent la cible principale, suivis de près par le Canada et l’Europe (Allemagne, Royaume-Uni). Cette concentration s’explique par la maturité des infrastructures et, paradoxalement, par la complexité de leur gestion qui laisse des failles ouvertes.

Le secteur de la Santé (Healthcare) arrive en tête, talonné par les services professionnels et les administrations publiques. Pour un architecte VDI, cela signifie que les environnements multi-tenants et les accès distants critiques sont les vecteurs les plus exploités.

Linux : Le Nouveau Champ de Bataille

C’est sans doute l’enseignement le plus crucial pour les ingénieurs systèmes : Linux est désormais la technologie la plus ciblée. L’hégémonie de Linux dans le Cloud, les conteneurs (Kubernetes) et les appliances de sécurité en fait la cible de choix pour une paralysie totale.

La compromission d’un noyau Linux permet non seulement le vol de données, mais aussi l’installation de « rootkits » persistants au niveau de l’hyperviseur, rendant l’attaquant virtuellement invisible pour les outils de sécurité opérant au niveau de la machine virtuelle (VM).

3. Le Marché des Accès Initiaux : L’Infrastructure à Prix Cassé

L’un des aspects les plus sombres du rapport de février 2026 est la marchandisation des accès aux infrastructures critiques. Les « Initial Access Brokers » (IAB) vendent désormais des accès « Root » à des prix dérisoires, facilitant le travail des groupes de ransomware.

Un exemple frappant est la mise en vente d’un accès administrateur au pare-feu et au réseau de l’Autorité Foncière du Gouvernement Indonésien pour seulement 300 $.

Pour un administrateur réseau, cette annonce signifie qu’une faille de type RCE (Remote Code Execution) sur un firewall Linux n’a pas été patchée, permettant à n’importe quel acheteur de prendre le contrôle total du routage, du VPN et de l’inspection des flux de toute une administration. C’est la porte ouverte à l’espionnage d’État ou à une attaque par ransomware à grande échelle.

4. Études de Cas : Fuites de Données et Impact sur le Stockage

Les brèches de Leora Infotech et EgyptAir illustrent la diversité des données exfiltrées et la vulnérabilité des serveurs d’applications Web.

Leora Infotech : Compromission des Services IT

Chez Leora Infotech, ce sont 35 000 enregistrements qui ont été compromis. Ici, le vecteur semble être une faille dans l’ERP ou le CRM, permettant de remonter jusqu’aux identifiants des employés et des clients.

EgyptAir : L’Exfiltration Documentaire

Plus grave encore, la fuite chez EgyptAir ne concerne pas que des lignes de texte dans une base de données, mais des documents sensibles issus des emails du personnel (PDF, images, vidéos). Pour une infrastructure de stockage, cela signifie que l’attaquant a eu un accès en lecture sur les volumes où sont montés les serveurs de messagerie.

5. Recommandations : Durcir l’Infrastructure face à l’Inévitable

En 2026, la question n’est plus « si » mais « quand ». La stratégie doit passer d’une défense périmétrique à une résilience de l’infrastructure.

Durcissement du Stockage (Storage Hardening)

• Immuabilité des Données (WORM) : Il est impératif d’utiliser des technologies de verrouillage d’objet (S3 Object Lock) ou des snapshots immuables au niveau de la baie de stockage. Même avec un accès « Root », l’attaquant ne doit pas pouvoir supprimer les sauvegardes avant un délai prédéfini.
• Air-Gap Logique : Séparez physiquement ou logiquement les réseaux de gestion du stockage (Management Network) de la production.

Sécurisation des environnements Linux et Virtualisation

• Micro-segmentation ZTNA (Zero Trust Network Access) : Ne faites plus confiance au réseau interne. Chaque flux entre une VM applicative et une base de données doit être authentifié et chiffré.
• Patch Management Automatisé : Au vu de la vente d’accès RCE à 300 $, le délai de patch pour les équipements de bordure (Firewalls, VPN) doit tomber à moins de 12 heures.

Recommandations Techniques (CLI & Config)

Pour les administrateurs Linux, le durcissement SSH et l’audit des accès sont les premières lignes de défense :

# Vérifier les tentatives de connexion suspectes
lastb | head -n 20

# Durcir la configuration SSH (Désactiver Root et forcer les clés)
echo "PermitRootLogin no" >> /etc/ssh/sshd_config
echo "PasswordAuthentication no" >> /etc/ssh/sshd_config
systemctl restart sshd

# Surveiller l'intégrité des fichiers critiques
aide --check

# Vérifier les tentatives de connexion suspectes
lastb | head -n 20

# Durcir la configuration SSH (Désactiver Root et forcer les clés)
echo "PermitRootLogin no" >> /etc/ssh/sshd_config
echo "PasswordAuthentication no" >> /etc/ssh/sshd_config
systemctl restart sshd

# Surveiller l'intégrité des fichiers critiques
aide --check

Conclusion : Vers une Infrastructure « Auto-cicatrisante »

Le rapport du 13 février 2026 nous rappelle que la cybersécurité n’est plus une couche logicielle additionnelle, mais le fondement même de l’architecture informatique. La prédominance des attaques sur Linux, la vente d’accès Root pour quelques centaines de dollars et la sophistication d’INC Ransom et Everest Group exigent une refonte de nos pratiques. La résilience passera par l’automatisation, l’immuabilité du stockage et une vigilance constante sur les vecteurs d’accès initiaux.

Source : https://www.cyfirma.com/news/weekly-intelligence-report-13-february-2026/

L’adoption rapide des technologies d’IA générative « on-premise » ou en local réintroduit des vecteurs d’attaque classiques que l’on pensait maîtrisés. La facilité de déploiement d’outils comme Ollama, qui permet d’exécuter des LLM (Large Language Models) localement, se heurte souvent à une négligence des bonnes pratiques de sécurité infrastructure.

SentinelOne Labs a récemment mis en lumière un phénomène inquiétant baptisé « Silent Brothers ». Des acteurs malveillants exploitent activement des instances Ollama mal configurées et exposées sur Internet pour constituer un réseau d’inférence distribué et anonyme. Cette analyse détaille la mécanique technique de cette menace et les mesures impératives pour sécuriser vos infrastructures de Compute IA.

1. Analyse Technique du Phénomène

Ollama est devenu un standard de facto pour l’exécution locale de modèles GGUF, apprécié pour sa simplicité (une seule commande pour lancer un modèle). Par défaut, le démon Ollama écoute sur 127.0.0.1:11434, une configuration sécurisée limitant l’accès à la machine hôte.

Le problème survient lorsque les utilisateurs ou les administrateurs souhaitent rendre ce service accessible sur le réseau local ou distant. La modification de la variable d’environnement OLLAMA_HOST vers 0.0.0.0 expose le service sur toutes les interfaces réseau.

La faille critique : Ollama, dans sa conception actuelle, n’intègre aucun mécanisme natif d’authentification ou d’autorisation.

Les attaquants ont industrialisé la détection de ces instances. SentinelOne rapporte une augmentation massive des scans sur le port TCP 11434. Une fois une instance ouverte détectée, le mode opératoire est simple et scriptable via l’API REST d’Ollama :

1. Reconnaissance : Appel à /api/tags pour lister les modèles déjà présents sur l’hôte.
2. Armement : Si aucun modèle utile n’est présent, appel à /api/pull pour forcer le téléchargement de modèles performants (ex: llama2, mistral).
3. Exploitation : Appel à /api/generate pour soumettre des prompts et récupérer les inférences.

Ces instances compromises forment un réseau « Silent Brothers », permettant aux attaquants de générer du contenu sans censure (contournant les garde-fous des API commerciales comme OpenAI) et sans frais d’infrastructure.

2. Impacts sur l’Infrastructure

L’exposition de ces services n’est pas anodine et présente des risques tangibles pour les environnements d’entreprise.

A. Vol de Ressources Compute (GPU/CPU)

L’impact le plus direct est le parasitage des ressources. L’inférence LLM est extrêmement gourmande en GPU (ou CPU en fallback). Une instance compromise verra ses ressources Compute détournées pour des tâches tierces, entraînant une dégradation immédiate des performances pour les charges de travail légitimes (VDI graphiques, calculs scientifiques, rendus 3D ou services d’IA internes). Cela se traduit par une augmentation directe des coûts énergétiques ou cloud.

B. Risque de « Shadow AI » et Exfiltration

Si l’organisation utilise Ollama pour faire tourner des modèles affinés (finetuned) sur des données propriétaires, l’exposition de l’API /api/tags révèle l’existence de ces modèles, et l’API de génération pourrait potentiellement être utilisée pour tenter d’extraire des informations confidentielles contenues dans les poids du modèle.

C. Réputation de l’IP

L’adresse IP publique de l’infrastructure compromise est utilisée pour générer du contenu potentiellement illégal, du phishing ou des campagnes de désinformation. Cela peut entraîner le blacklistage de l’IP de l’entreprise par les services de sécurité tiers.

3. Recommandations Pragmatiques

La sécurisation d’Ollama repose sur le principe fondamental que l’outil lui-même ne gère pas la sécurité. C’est à la couche infrastructure de le faire.

A. Configuration par Défaut et Segmentation

La règle absolue est de maintenir le binding sur localhost (OLLAMA_HOST=127.0.0.1) si l’accès distant n’est pas strictement nécessaire. Si l’accès réseau est requis, il ne doit jamais être direct. Utilisez des règles de pare-feu strictes (allow-listing d’IPs spécifiques) ou, idéalement, n’autorisez l’accès qu’au travers d’un VPN d’entreprise. Le port 11434 ne doit jamais être ouvert sur l’Internet public.

B. Implémentation d’un Reverse Proxy Authentifiant (Obligatoire pour accès distant)

Puisqu’Ollama ne gère pas l’auth, il est impératif de placer un reverse proxy (Nginx, Traefik, Caddy) devant l’instance pour gérer TLS et l’authentification (Basic Auth, OAuth2, etc.).

Voici un exemple minimaliste de configuration Nginx pour sécuriser une instance Ollama :

# Exemple de configuration Nginx pour sécuriser Ollama
server {
    listen 80;
    server_name ollama.votre-infra.local;

    location / {
        # Redirection vers l'instance Ollama locale
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # Activation obligatoire de l'authentification Basic
        auth_basic "Accès Restreint Infrastructure IA";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

# Exemple de configuration Nginx pour sécuriser Ollama
server {
    listen 80;
    server_name ollama.votre-infra.local;

    location / {
        # Redirection vers l'instance Ollama locale
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # Activation obligatoire de l'authentification Basic
        auth_basic "Accès Restreint Infrastructure IA";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

C. Surveillance

Intégrez la surveillance du port 11434 et des processus ollama dans vos outils de monitoring (SIEM, Prometheus/Grafana). Des pics d’utilisation GPU inexpliqués ou des connexions entrantes sur ce port doivent déclencher des alertes immédiates.

Conclusion

L’émergence de « Silent Brothers » démontre que la nouvelle vague d’outils GenAI ne doit pas échapper aux politiques de sécurité infrastructure établies. L’absence de sécurité native (« secure by design ») dans des outils comme Ollama impose aux équipes Ops et SecOps de compenser par une architecture réseau rigoureuse. Traitez vos instances d’IA avec la même rigueur que vos bases de données critiques : jamais exposées directement sur le Net.

Source : https://www.sentinelone.com/labs/silent-brothers-ollama-hosts-form-anonymous-ai-network-beyond-platform-guardrails/

Le 6 janvier 2026, Microsoft Security a publié une analyse détaillant comment des acteurs étatiques et cybercriminels contournent les défenses de messagerie les plus robustes. Le constat est sans appel : la complexité croissante des infrastructures hybrides crée des « zones d’ombre » dans le routage SMTP. Ce billet décortique les mécanismes de détournement des flux et propose des mesures de durcissement basées sur des exemples de configuration réels.

1. Analyse Technique : La Rupture de l’Alignement et le « Subdomain Spoofing »

L’attaque ne repose pas sur une faille logicielle, mais sur une exploitation logique de la manière dont les serveurs de messagerie traitent les politiques SPF et DMARC lors de routages multi-sauts.

Le mécanisme de l’usurpation par sous-domaine

L’une des techniques clés identifiées est l’exploitation des sous-domaines non protégés. Un attaquant peut utiliser un sous-domaine (ex: marketing.entreprise.com) qui ne possède pas d’enregistrement SPF propre. Si le domaine racine (entreprise.com) possède un enregistrement SPF mais n’utilise pas la balise sp=reject dans sa politique DMARC, le sous-domaine hérite d’une politique par défaut souvent permissive (none), permettant l’envoi d’emails non authentifiés.

L’analyse des en-têtes (Header Analysis)

Dans les cas complexes, l’attaquant injecte des messages via des connecteurs de messagerie mal configurés. Voici ce que l’on observe dans un en-tête Authentication-Results lors d’une exploitation réussie :

Authentication-Results: spf=softfail (sender IP is 1.2.3.4) smtp.mailfrom=malicious.com; dmarc=pass (p=none sp=none) header.from=entreprise.com;

Ici, le DMARC « passe » (ou n’est pas appliqué) car le système de réception ne vérifie pas l’alignement strict entre le domaine de l’enveloppe et celui de l’en-tête visible, souvent à cause d’une règle de transport interne qui outrepasse la vérification pour les « partenaires de confiance ».

2. Impacts sur l’Infrastructure : Connecteurs et Flux Hybrides

Le danger réside principalement dans les Connecteurs SMTP de confiance. Dans un environnement Exchange Hybride ou multi-cloud, il est courant de créer des connecteurs basés sur l’adresse IP pour autoriser des applications métiers ou des périphériques (scanners, alertes infra) à envoyer des emails.

• Vecteur de mouvement latéral : Si un attaquant compromet un serveur interne ou une application ayant un accès autorisé à un tel connecteur, il peut diffuser des campagnes de phishing internes indétectables, car elles sont « blanchies » par l’infrastructure de confiance.
• Corruption de la réputation IP : L’utilisation de votre propre infrastructure pour envoyer du phishing entraîne le blacklistage de vos adresses IP publiques de sortie, paralysant les communications légitimes.

3. Recommandations : Durcissement et CLI

Pour contrer ces attaques, une approche granulaire est nécessaire.

Mise en place de l’alignement strict

Ne vous contentez pas d’un enregistrement DMARC standard. Forcez l’alignement strict pour SPF et DKIM afin d’interdire l’usage de sous-domaines non explicitement autorisés.

Exemple d’enregistrement DNS durci : v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:security@votre-domaine.com (Note : adkim=s et aspf=s forcent l’alignement strict).

Audit des connecteurs via PowerShell (Exchange Online)

Il est crucial de lister les connecteurs autorisant l’envoi sans authentification forte. Utilisez cette commande pour identifier les configurations à risque :

Get-InboundConnector | Where-Object {$_.RestrictDomainsToIPAddresses -eq $true} | Select-Object Name, AttachedDomains, RemoteIPRanges

Get-InboundConnector | Where-Object {$_.RestrictDomainsToIPAddresses -eq $true} | Select-Object Name, AttachedDomains, RemoteIPRanges

Action : Vérifiez que chaque IP listée est strictement nécessaire et que le domaine source est validé.

Implémentation de l’ARC (Authenticated Received Chain)

Pour les infrastructures utilisant des services de filtrage tiers avant d’atteindre la boîte aux lettres finale, configurez vos « Trusted Arc Sealers ». Cela permet de préserver l’intégrité de l’authentification malgré les modifications d’en-têtes par les couches intermédiaires.

Conclusion

La confiance implicite dans les flux de messagerie internes est une faille que les attaquants exploitent avec une précision chirurgicale. La sécurisation de l’infrastructure email en 2026 exige de passer d’une défense périmétrique à une validation systématique de l’alignement de chaque saut SMTP.

Source : https://www.microsoft.com/en-us/security/blog/2026/01/06/phishing-actors-exploit-complex-routing-and-misconfigurations-to-spoof-domains/

L’émergence et la démocratisation de l’intelligence artificielle (IA) au quotidien, notamment dans le monde de l’entreprise, provoquent un changement radical des méthodes de travail. Si les gains de productivité font de l’IA un outil incontournable, son développement rapide suscite des inquiétudes légitimes quant à la confidentialité des données et à l’automatisation de la prise de décision. Le récent « Flash Ingérence » n°117 de la DGSI met en lumière des vulnérabilités critiques que les experts en infrastructure et en cybersécurité doivent impérativement adresser.

1. Analyse Technique : Des Algorithmes aux Vecteurs d’Attaque

L’IA générative, bien qu’offrant des perspectives d’innovation inédites, introduit des risques structurels liés à la gestion des flux de données.

Le risque de « Shadow AI » et l’Exfiltration de Données

L’usage d’outils d’IA « grand public » par les salariés, souvent sans l’aval de la hiérarchie, transforme des documents confidentiels en données d’entraînement pour des modèles tiers. Techniquement, les versions gratuites et standards utilisent les données entrées par l’utilisateur pour affiner leurs modèles. De plus, les politiques de confidentialité imposent souvent le stockage sur des serveurs étrangers, soumettant ces données à des lois à portée extraterritoriale.

Vulnérabilités Logicielles et API

La connexion des applications d’IA à des outils externes via des interfaces logicielles (API) ou des plugins augmente la surface d’attaque. Ces couches logicielles sont souvent moins sécurisées, favorisant les fuites de données ou les attaques cybernétiques ciblées.

Nouvelles Typologies d’Attaques

Le rapport identifie des méthodes offensives avancées utilisant l’IA :

• Adversarial Examples Attack : Manipulation des données d’entrée (ex: modification subtile d’une image) pour tromper l’algorithme et provoquer des comportements dangereux dans des systèmes critiques.
• Empoisonnement des données (Data Poisoning) : Injection de fausses données durant le processus d’apprentissage pour biaiser ou saboter le système.
• Deepfakes et Ingénierie Sociale : Utilisation de l’IA pour créer des contenus truqués (visage et voix) afin de commettre des escroqueries par hypertrucage.

2. Impacts sur l’Infrastructure : Intégrité et Souveraineté

L’intégration de l’IA modifie profondément la posture de sécurité de l’infrastructure informatique.

La Perte de Contrôle et l’Effet « Boîte Noire »

Les décisions prises par certains systèmes d’IA sont complexes à auditer. Cette opacité réduit la confiance et complexifie la prise de décision éclairée. En déléguant entièrement des tâches critiques (comme la due diligence) à des outils étrangers, les entreprises s’exposent à des biais algorithmiques et à des « hallucinations » — où l’IA crée des événements de toute pièce.

Risques Juridiques et de Conformité

Le stockage des données sur des serveurs distants hors de l’Union Européenne peut entraîner la responsabilité de l’entreprise au regard du RGPD et d’autres réglementations nationales. La question de la propriété intellectuelle des données issues de l’IA reste également un point de vigilance majeur.

3. Recommandations : Actions Pragmatiques pour une Cyber-Infra Résiliente

Pour mitiger ces risques, la DGSI préconise une approche structurée alliant gouvernance et solutions techniques locales.

Durcissement de la Gouvernance IT

• Mise à jour de la Charte Informatique : Il est impératif d’expliciter le cadre d’emploi de l’IA et de préciser le niveau de sensibilité des informations autorisées.
• Transparence Obligatoire : Signaler systématiquement l’usage de l’IA à la hiérarchie ou aux clients pour permettre une meilleure appréhension des erreurs potentielles.

Stratégies d’Infrastructure Souveraine

• Privilégier l’IA en Local : Déployer des systèmes d’IA fonctionnant directement sur le Système d’Information (SI) de l’utilisateur, sans connexion constante à des serveurs externes. Cela assure une confidentialité totale et un contrôle renforcé des données traitées.
• IA de Confiance : Favoriser le recours à des solutions hébergeant leurs données en France et respectant strictement le RGPD.

Vigilance Opérationnelle

• Expertise Métier : Ne jamais fonder une décision uniquement sur les résultats de l’IA. L’intervention d’experts qualifiés ou de Data Scientists est nécessaire pour analyser la qualité et le fonctionnement de l’outil.
• Anonymisation des Requêtes : En cas d’usage d’outils gratuits, il est crucial d’anonymiser systématiquement les requêtes et de ne jamais soumettre de données personnelles ou sensibles.

Conclusion

L’intelligence artificielle est un levier de croissance, mais sa mise en œuvre ne doit pas se faire au détriment de la sécurité économique et de la souveraineté des données. La vigilance humaine reste le dernier rempart contre les dérives technologiques, les biais et les tentatives d’ingérence sophistiquées.

Source : Flash DGSI #117 – Décembre 2025