Archives de catégorie : Entreprise

Actualités liées à la sécurité informatique des entreprises, PME, PMI, TPE, association, communes.

Cybersécurité, Entreprise, Justice

Cyberattaque : préparer sa plainte sans perdre de temps

Laisser un commentaire

Après une cyberattaque, déposer plainte permet de demander une réponse judiciaire. Préparer les preuves, identifier le bon interlocuteur et documenter l’incident évite de perdre un temps précieux.

Une intrusion informatique ne se résume pas à la remise en service des équipements. L’organisation touchée doit aussi préserver les éléments nécessaires à une enquête et organiser sa démarche de plainte. Qui peut la représenter ? Quels documents transmettre ? Faut-il attendre un rapport technique complet ? Il faut anticiper ces questions, de réunir les premières preuves disponibles et de compléter ensuite le dossier. Elle souligne également les enjeux de reconnaissance du préjudice et d’assurance. Pour les équipes de sécurité comme pour la direction, cette préparation relie la gestion technique de l’incident à ses suites judiciaires, sans attendre de connaître toute l’étendue de l’attaque.

Déposer plainte pour engager la réponse judiciaire

Lorsqu’une entreprise découvre une intrusion, ses premières décisions portent souvent sur les systèmes compromis. Il faut comprendre ce qui s’est produit, contenir l’incident et rétablir les services. La démarche judiciaire doit également trouver sa place dans cette mobilisation. Dans certaines situations, seule la victime connaît les faits. Sans signalement de sa part, les autorités peuvent ignorer l’existence même de l’attaque.

Le dépôt de plainte permet de porter ces faits à leur connaissance et de solliciter une enquête pénale. Celle-ci vise notamment à identifier les responsables et à réunir les éléments permettant leur éventuelle poursuite. La victime n’a donc pas à attendre de connaître l’identité de l’attaquant pour entreprendre sa démarche. L’identification des auteurs constitue précisément l’un des objectifs de l’investigation. En 2025, ZATAZ avait proposé un outil interactif pour préparer une « cyber » plainte.

La plainte contribue aussi à formaliser le préjudice subi. Le document associe cette démarche à la reconnaissance de la qualité de victime, aux possibilités de constitution de partie civile et aux démarches destinées à obtenir réparation. Pour une organisation, l’enjeu dépasse ainsi la seule description d’un dysfonctionnement informatique. Il s’agit de documenter les conséquences d’une action susceptible de relever du pénal.

Les questions d’assurance ajoutent une contrainte de calendrier. DataSecuritybreach.fr vous rappelle le délai de 72 heures après la découverte de l’incident pour le dépôt de plainte lié à l’indemnisation assurantielle, en référence à la loi LOPMI. Ce point doit être traité rapidement avec les interlocuteurs compétents de l’organisation. Attendre une expertise exhaustive avant d’aborder la plainte peut faire perdre un temps déterminant.

La démarche participe enfin à la protection de l’organisation. Elle permet de présenter aux autorités les documents dérobés, les données concernées et les risques identifiés. Le dépôt de plainte ne garantit toutefois ni la récupération des fonds ni l’arrêt de l’exploitation des informations volées. Ces objectifs dépendent des circonstances et des suites données au dossier. A noter que si vous êtes victime d’une fuite de données, le blog zataz propose un guide interactif complet intitulé « Vos données ont fuité. La suite vous appartient.« 

Préparer les preuves et organiser la représentation

Comme l’indique le CLUSIF dans un document diffusé fin octobre, la préparation commence avant l’incident. Identifier un service de police ou de gendarmerie à proximité permet de disposer d’un premier point de contact. Un échange préalable peut faciliter l’orientation vers les interlocuteurs appropriés lorsque survient une attaque. En pleine crise, cette anticipation évite de consacrer les premières heures à rechercher où présenter les faits.

Il faut également savoir qui représentera l’entreprise. Le représentant légal ou une personne disposant d’un pouvoir spécial de représentation. Cette question mérite d’être réglée en amont : la personne qui maîtrise les détails techniques n’est pas nécessairement celle qui dispose du mandat requis. Préparer la délégation utile facilite la démarche lorsque plusieurs équipes interviennent simultanément.

Le dossier initial doit réunir les éléments déjà disponibles. Journaux techniques, captures d’écran, rapports d’analyse et coordonnées des prestataires peuvent aider à comprendre l’incident. Leur utilité tient autant à leur contenu qu’à leur capacité à éclairer les faits présentés. Les équipes doivent pouvoir expliquer ce que chaque pièce montre, sans transformer une hypothèse technique en certitude.

Un dossier encore incomplet ne doit pas devenir un motif d’attente systématique. Le document recommande de présenter une première plainte avec les informations essentielles (le brouillons, daté et indiquant les mises à jour), puis de transmettre des compléments. Cette approche permet d’engager la démarche tandis que l’analyse se poursuit. Une audition ultérieure ou un complément de plainte peut apporter les résultats obtenus après les premières constatations. La volatilité des traces numériques renforce cette nécessité d’agir tôt. Certains éléments utiles peuvent disparaître alors que l’entreprise concentre ses efforts sur le rétablissement de son activité. La conservation des preuves doit donc être intégrée à la réponse à incident, avec les personnes chargées de l’analyse et celles qui préparent le dossier judiciaire.

Enfin, une enquête informatique peut demander du temps. Des auteurs situés à l’étranger, des preuves dispersées et des vérifications successives compliquent les investigations. L’absence de nouvelles immédiates ne permet pas, à elle seule, de conclure à un classement sans suite. La rapidité du signalement et la qualité des pièces transmises restent des contributions concrètes de la victime.

Cybersécurité, Entreprise, Mise à jour, Patch, Securite informatique

Panne Google Cloud : les entreprises face au silence

Laisser un commentaire

La panne de Google Cloud du 20 octobre a perturbé de nombreux sites, dont la banque Revolut et relancé une question stratégique : comment poursuivre son activité lorsque les communications habituelles deviennent indisponibles ?

Une application inaccessible, des paiements perturbés, des équipes privées de leurs moyens d’échange : une interruption informatique peut rapidement désorganiser une entreprise. L’incident de Google Cloud du 20 octobre 2026 replace la continuité des communications au cœur du débat. Data Security Breach souligne une dépendance souvent sous-estimée : plusieurs outils peuvent reposer sur une infrastructure commune. Le retour d’expérience transmis par Revolut à ses clients illustre également les conséquences prolongées d’une panne, certaines opérations nécessitant un délai de régularisation après le rétablissement. L’enjeu dépasse donc la disponibilité technique : il concerne la capacité à coordonner, informer et décider.

Plusieurs applications, une même dépendance

Le 20 octobre, plusieurs services de Google Cloud ont rencontré des difficultés dans la région de Londres. La page officielle de suivi mentionne un incident électrique ayant provoqué une interruption dans la zone europe-west2-b. Une défaillance d’infrastructure peut ainsi se répercuter sur les organisations qui utilisent les services concernés.

Revolut figure parmi les entreprises touchées. Dans le message adressé à ses clients, la société attribue explicitement son interruption de service à cette panne de Google Cloud. Elle indique que le problème a été résolu le jour même et affirme que les fonds comme les données sont restés en sécurité pendant toute la perturbation. Le rétablissement technique ne signifie toutefois pas que toutes les conséquences disparaissent immédiatement. Revolut prévient que certaines transactions par carte, remboursements compris, peuvent demander quelques jours avant d’apparaître sur le compte et d’être répercutées dans le solde. L’établissement précise travailler au traitement de ces opérations et renvoie les clients rencontrant encore des difficultés vers l’assistance accessible dans son application.

Ce décalage illustre une distinction essentielle : remettre un service en ligne et retrouver un fonctionnement entièrement normal constituent deux étapes différentes. Entre les deux, les utilisateurs doivent comprendre ce qui fonctionne, ce qui reste en attente et comment obtenir une réponse. DataSecuritybreach.fr Derbes attire précisément l’attention sur cette fragilité organisationnelle. Une entreprise peut disposer d’une téléphonie sur IP, d’une messagerie instantanée, d’une plateforme collaborative et d’un outil de visioconférence sans bénéficier de quatre voies de secours indépendantes. Ces applications peuvent partager un hébergeur, un fournisseur cloud ou certaines infrastructures. Leur nombre ne renseigne donc pas, à lui seul, sur leur capacité à résister à une défaillance commune. La diversification apparente des interfaces peut masquer une concentration des dépendances.

L’enjeu consiste alors à identifier les communications indispensables. Joindre les collaborateurs, transmettre une décision urgente, répondre aux clients et coordonner les interventions ne peuvent dépendre d’un dispositif dont personne n’a vérifié les possibilités de remplacement.

Autre détail, de taille, nous savons maintenant que Révolut sauvegarde les données chez Google Cloud !

Le secours doit fonctionner pendant la panne

L’existence d’une solution alternative ne garantit pas sa disponibilité au moment critique. Elle peut utiliser le réseau déjà interrompu, demander une authentification inaccessible ou présenter des limites de traçabilité incompatibles avec les exigences de l’activité. La question opérationnelle devient très concrète : les personnes chargées de gérer la crise peuvent-elles effectivement se joindre lorsque leurs outils habituels ne répondent plus ? Un dispositif documenté reste insuffisant si son activation dépend précisément du service défaillant.

L’identification des dépendances et l’expérimentation régulière des moyens de remplacement est indispensable. Pendant que les techniciens rétablissent les systèmes, l’organisation doit conserver la possibilité de transmettre des consignes et d’expliquer la situation à ses interlocuteurs.

Les données européennes donnent une autre dimension à cette réflexion. Publié en juin 2026, le premier rapport commun des autorités européennes de supervision sur les incidents majeurs déclarés dans le cadre de DORA porte sur 3 383 événements. Environ un tiers ont produit des effets transfrontaliers. Ces chiffres concernent les incidents informatiques du secteur financier, et non exclusivement les communications. Ils illustrent néanmoins l’étendue possible des répercussions d’une défaillance numérique.

Orange : des suspensions préventives liées à PHP
Le 22 octobre, Orange a annoncé la fermeture temporaire de certains services après la publication de vulnérabilités PHP le 21 octobre.
Le groupe indique avoir interrompu ces accès pour installer les correctifs et effectuer les contrôles nécessaires.
Plusieurs filiales et entités sont concernées, avec une remise en service progressive des sites et applications.
Une mesure préventive.

Ces situations replacent la disponibilité des échanges dans les décisions de direction. Les performances, les fonctionnalités et les coûts doivent être examinés avec les conséquences d’une interruption prolongée. Les responsables opérationnels et, lorsque nécessaire, les fonctions de conformité ont donc leur place dans cette préparation. Confier une infrastructure à un prestataire ne dispense pas l’entreprise d’organiser sa propre continuité.

Android, backdoor, Cybersécurité, Entreprise, Espionnage Spy, Securite informatique, Smartphone

Midnight Mimosa infecte Android avant le premier démarrage

Des smartphones Android arrivent chez leurs propriétaires avec un logiciel malveillant déjà intégré, capable d’installer des applications discrètement et de détourner leur connexion Internet à des fins frauduleuses.

Midnight Mimosa transforme des téléphones Android à bas prix en supports de fraude publicitaire et, potentiellement, en relais réseau contrôlés à distance. Cette campagne touche des milliers d’appareils dans plus de 150 pays, dont la France. Sa particularité tient à son implantation dans le micrologiciel, le logiciel qui accompagne le matériel et participe au fonctionnement du téléphone. Le propriétaire peut donc recevoir un appareil déjà compromis, sans avoir téléchargé la moindre application suspecte. Les chercheurs décrivent une infection persistante, dotée de privilèges système, dont l’origine exacte dans la chaîne d’approvisionnement reste à établir.

Une infection installée au cœur du téléphone

Le premier téléchargement dangereux n’existe parfois pas. Dans cette affaire, le composant malveillant précède l’utilisateur et bénéficie de droits habituellement réservés au fonctionnement d’Android. Une apparence de service technique suffit ensuite à brouiller les pistes.

Selon les éléments rapportés, le logiciel d’espionnage de téléphone Midnight Mimosa serait actif depuis au moins deux ans. Le Mexique, la France, l’Italie, les États-Unis, l’Allemagne, le Brésil et l’Espagne figurent parmi les pays les plus représentés dans les observations des chercheurs. Ces données décrivent les appareils détectés, sans constituer un recensement exhaustif des victimes.

L’infection concerne notamment des smartphones économiques équipés de plateformes MediaTek, parmi lesquels les Doogee S200 X et Cubot KINGKONG X. Des contrefaçons reproduisant l’apparence de modèles Samsung ou Apple apparaissent également dans les éléments présentés. Cette présence ne permet pas d’attribuer une responsabilité au fournisseur des puces ni aux marques imitées.

Le point d’entrée précis demeure inconnu

L’hypothèse privilégiée est celle d’une introduction au cours de la chaîne d’approvisionnement. Les informations disponibles ne permettent toutefois d’identifier ni l’étape concernée ni les responsables. La découverte d’un composant dans un micrologiciel ne démontre pas, à elle seule, la participation consciente du fabricant.

Le logiciel se présente notamment sous les noms com.android.system.lite et com.android.sys.prot. Ces intitulés évoquent des fonctions internes ordinaires. Derrière cette façade, les composants disposent de signatures et de permissions leur permettant d’agir avec des privilèges élevés. Le gestionnaire d’applications classique ne suffit donc pas à les supprimer. Sur les forums XDA, des propriétaires de téléphones Cubot et Doogee ont signalé le retour d’applications suspectes après leur suppression. Un utilisateur de Doogee Fire 3 Max rapporte une apparition après une mise à jour officielle, suivie d’une disparition après restauration d’un micrologiciel antérieur. Ce témoignage apporte un indice sur son appareil, sans établir un scénario identique pour toute la campagne.

Les capacités décrites dépassent largement l’affichage publicitaire. Midnight Mimosa peut ajouter ou retirer des applications sans solliciter le propriétaire, accorder des autorisations et exécuter du code transmis par ses opérateurs. Le téléphone conserve ainsi un composant capable de renouveler les charges malveillantes.

Publicités invisibles et connexions détournables

Les chercheurs ont recensé environ 32 applications distribuées par ce dispositif. Météo, gestion de fichiers, reconnaissance de texte ou édition audio leur servent de couverture. Ces fonctions familières rendent leur présence moins immédiatement suspecte.

La rémunération repose principalement sur une fraude publicitaire. Les applications utilisent un kit publicitaire légitime pour récupérer de véritables annonces. Leur affichage s’effectue cependant dans des fenêtres invisibles superposées à d’autres applications. Le système publicitaire peut alors comptabiliser une impression sans qu’aucun utilisateur ait réellement vu le contenu.

Certaines variantes automatisent aussi les interactions. Des clics sont produits sans geste du propriétaire, donnant artificiellement de la valeur à une audience inexistante. L’utilisation d’une technologie publicitaire légitime ne rend donc pas légitime l’activité qui l’exploite.

Pour faciliter les installations, le logiciel désactive temporairement l’application Google Play Store, identifiée par com.android.vending, puis la réactive. Bitdefender présente cette séquence comme une tentative de contourner la détection par Play Protect. Certaines variantes falsifient également l’origine déclarée d’une installation pour lui donner l’apparence d’un téléchargement depuis la boutique officielle.

Une autre capacité concerne un proxy TCP, susceptible de faire transiter du trafic extérieur par la connexion du téléphone. L’adresse IP du propriétaire devient alors un point de sortie potentiel pour des activités qu’il ne contrôle pas. L’accès à de tels relais résidentiels peut être commercialisé.

La capacité technique et son exploitation effective doivent être distinguées. Les chercheurs ont confirmé le fonctionnement de l’infrastructure de contrôle associée, sans pouvoir déterminer si les téléphones infectés avaient effectivement relayé du trafic comme proxys.

Treize applications liées à la campagne ont également été repérées sur Google Play avec un code frauduleux similaire. Elles ne disposent cependant pas des privilèges des composants préinstallés. Les assimiler entièrement effacerait une différence essentielle pour comprendre la persistance de l’infection. La suppression nécessite un micrologiciel sain ou une désactivation des composants concernés au moyen d’Android Debug Bridge (ADB). Désactiver ne signifie toutefois pas retirer le code du micrologiciel.

Cybersécurité, Entreprise, Mise à jour, Patch

Des jeux Nintendo Switch tournent sur Xbox Series X

Une démonstration montre plusieurs jeux Nintendo sur Xbox Series X grâce à un émulateur. Cette expérience repose sur le mode développeur, sans jailbreak annoncé de la console.

Faire apparaître Mario sur une Xbox attire immédiatement les regards. Derrière cette démonstration, l’enjeu technique concerne surtout la manière d’exécuter un logiciel conçu pour un autre environnement sans compromettre le système qui l’accueille. Des séquences relayées en ligne montrent plusieurs titres Nintendo fonctionner sur Xbox Series X avec une fluidité visuellement convaincante. Le projet serait dérivé d’Eden, un émulateur Switch adapté à la console Microsoft. Son fonctionnement reposerait sur le mode développeur, dans un espace isolé. L’identité exacte du portage utilisé, ses performances mesurées et sa compatibilité complète restent toutefois insuffisamment documentées dans les éléments fournis.

Une démonstration prometteuse, une portée à préciser

La scène a de quoi surprendre : une console Microsoft affiche des jeux associés à l’univers Nintendo. L’auteur de la démonstration, présenté dans le texte transmis sous le pseudonyme FoxHitoriki, aurait notamment lancé Super Mario Odyssey, Super Mario Wonder et Metroid Prime Beyond. Les images décrites donnent une impression de fluidité, sans fournir les mesures nécessaires pour établir un bilan technique complet.

Cette distinction compte. Une séquence de jeu permet d’observer un fonctionnement à un instant donné. Elle ne suffit pas à démontrer que chaque titre peut être parcouru intégralement, avec un comportement constant et sans anomalie. Aucun relevé de performances, protocole de test ou inventaire détaillé des limitations n’accompagne le récit fourni. La démonstration constitue donc un indice de progression technique, dont la portée doit rester précisément délimitée.

Le projet est présenté comme une adaptation d’Eden, sous le nom NXbox. Cette attribution demeure à formuler au conditionnel : les éléments disponibles ne permettent pas d’identifier avec certitude la version employée dans la vidéo. La documentation publique distingue plusieurs portages, ce qui appelle à la prudence avant d’associer automatiquement les images à un dépôt précis.

Le principe décrit consiste à adapter les demandes graphiques provenant de l’environnement Switch aux capacités de rendu de la Xbox. L’objectif est de permettre à des programmes initialement destinés à une autre machine de fonctionner sur le matériel Microsoft. Il s’agit d’un travail de compatibilité logicielle, dont le résultat visible peut masquer une importante complexité technique.

L’auteur n’aurait communiqué ni explication détaillée ni lien de téléchargement avec sa démonstration. Cette absence limite la possibilité de reproduire exactement l’expérience à partir des seules informations transmises. Elle empêche également d’établir les conditions précises dans lesquelles les jeux ont été exécutés.

Pour le lecteur, la conclusion reste circonscrite : des images présentent plusieurs titres en fonctionnement, tandis que les performances générales et les conditions de reproduction restent à documenter.

Le mode développeur change la lecture cyber

L’élément déterminant concerne le cadre d’exécution. Selon le récit fourni, l’émulateur utilise le mode développeur de la Xbox Series X. Ce fonctionnement crée un environnement isolé destiné à accueillir des applications, sans que la démonstration soit présentée comme un jailbreak de la console.

Cette différence évite une confusion fréquente entre deux situations techniques. Exécuter un logiciel dans un espace prévu pour le développement ne démontre pas, à lui seul, une rupture des protections du système. Rien dans les informations transmises n’établit une exploitation de vulnérabilité, une prise de contrôle générale de la Xbox ou un accès à ses composants protégés.

L’intérêt cyber du sujet réside précisément dans cette frontière. Une console peut accueillir un usage inattendu à travers une fonctionnalité de développement, tout en conservant une séparation entre cet espace et son fonctionnement habituel. La présence d’un émulateur ne constitue donc pas une preuve suffisante de compromission.

Le texte initial évoque également un frein financier, lié à l’activation et à l’inscription au programme développeur Microsoft. Aucun tarif ni détail sur les conditions applicables n’est fourni. Il serait ainsi prématuré de conclure que ce seul facteur empêchera une diffusion plus large. Le coût représente une contrainte annoncée, sans permettre de prévoir l’adoption du projet.

Le rapprochement avec la PlayStation 5 demande la même rigueur. Les articles mentionnés dans le document transmis évoquent une réponse de Sony au piratage et l’utilisation de Xbox Cloud Gaming sur une PS5 modifiée. Leurs pages n’ont pas pu être consultées lors de la vérification. Ces références ne permettent donc pas de préciser ici les mécanismes concernés ni d’établir une équivalence avec l’expérience sur Xbox.

La distinction entre émulation locale, accès à un service distant et modification d’une console reste essentielle pour comprendre ce que montre réellement chaque démonstration.

Cybersécurité, Entreprise

Une puce mémorise les mouvements de l’eau

À Yale, des chercheurs explorent une mémoire actionnée par des fluides, une piste pour piloter des robots souples dans des environnements perturbant le fonctionnement de l’électronique.

Stocker une information grâce à un écoulement devient possible dans une puce microfluidique expérimentale. Des fibres flexibles, installées dans des canaux microscopiques, changent de position sous la pression du liquide. Leurs deux configurations stables peuvent représenter les valeurs binaires zéro et un. L’état conservé influence ensuite la circulation du fluide, donnant au dispositif une mémoire physique de son fonctionnement précédent. L’application envisagée concerne notamment les robots souples, avec l’objectif de concevoir un contrôleur entièrement fluidique.

Des fibres flexibles pour conserver une information

Dans ce dispositif, le support de l’information se trouve dans la configuration des fibres. Le liquide exerce une pression, déplace ces éléments souples et modifie ainsi les passages disponibles dans le réseau. La mémoire correspond donc à une organisation physique, produite par les écoulements précédents.

Le principe repose sur deux positions stables. Une fibre peut occuper l’une ou l’autre, chacune étant susceptible de représenter une valeur binaire. Cette correspondance avec zéro et un permet de rapprocher le mécanisme d’un élément de mémoire informatique.

La distinction compte. Le mouvement des fluides provoque ici le changement d’état, sans commutation électronique de chaque élément. Parler d’une « puce électronique qui mémorise avec de l’eau » entretient donc une ambiguïté sur la nature de l’expérience. Il s’agit d’une puce microfluidique dont les structures flexibles assurent la fonction de mémoire. La présentation officielle de Yale confirme les travaux et précise plusieurs détails du texte initial. Les chercheurs cités sont Abhineet Rajput et Amir Pahlavan. La dimension comparée à la moitié de l’épaisseur d’un cheveu concerne la profondeur des canaux. L’université a présenté cette recherche le 12 octobre 2026.

L’intérêt ne se limite pas à faire basculer une fibre isolée. Les éléments peuvent interagir : leurs positions respectives influencent le comportement du réseau. Une modification locale participe alors à une organisation collective, où l’information dépend à la fois des configurations individuelles et de leurs relations. Cette interaction donne une autre portée au dispositif. Le réseau conserve une trace de son passé, qui intervient dans sa réponse aux écoulements suivants. La mémoire devient ainsi une propriété du fonctionnement physique de l’ensemble, au lieu d’être uniquement associée à un composant chargé d’enregistrer des données.

Un contrôleur fluidique envisagé pour les robots souples

La robotique souple constitue l’application mise en avant. L’objectif serait d’intégrer cette mémoire à une commande utilisant elle-même des fluides. Le dispositif pourrait alors participer au pilotage d’une machine dont le fonctionnement s’appuie sur des variations de pression et sur la circulation dans des canaux. Amir Pahlavan envisage un contrôleur entièrement fluidique jouant le rôle de « cerveau » pour un robot souple. Cette formule décrit une fonction de commande recherchée. Elle ne suffit pas à établir qu’un robot autonome complet a déjà été réalisé à partir de cette puce.

Les environnements soumis à de fortes interférences électromagnétiques expliquent notamment l’intérêt de cette approche. Lorsque ces perturbations compliquent l’utilisation de composants électroniques classiques, une commande reposant sur des mécanismes fluidiques pourrait offrir une autre voie. Cette possibilité reste une perspective d’application, à distinguer de performances démontrées en conditions réelles. La portée de l’annonce doit également rester proportionnée aux informations disponibles. Les chercheurs ne fournissent aucune capacité de stockage, vitesse d’écriture ou durée de conservation permettant une comparaison avec les mémoires informatiques courantes. Il ne précise pas davantage les dimensions d’un futur contrôleur complet ni ses contraintes d’intégration. Ces absences empêchent de présenter le dispositif comme un successeur des supports de stockage actuels. Elles laissent néanmoins apparaître son objectif propre : conserver un état au sein d’un mécanisme susceptible de contribuer directement à la commande d’une machine.

Cybersécurité, Entreprise

Trente Mac mini font revivre le Cray-1

Un musée espagnol a construit une réplique du Cray-1 avec trente anciens Mac mini, une installation qui explique comment plusieurs ordinateurs peuvent unir leurs capacités de calcul.

Le Cray-1 revient sous une forme inattendue. Cinquante ans après son arrivée en 1976, ce supercalculateur emblématique possède une réplique grandeur nature au Musée de l’histoire de l’informatique, en Espagne. Sa structure accueille trente Mac mini, principalement commercialisés en 2012, réunis pour travailler ensemble. Le projet a demandé dix-huit mois de préparation et célèbre également le cinquantième anniversaire d’Apple. Les performances annoncées atteignent jusqu’à 1,5 téraflops sur des calculs matriciels. Cette installation pédagogique permet surtout de comprendre le calcul distribué, tout en rappelant ce que représentait Cray dans l’histoire des machines conçues pour traiter les problèmes scientifiques les plus exigeants.

Cray, un nom majeur du calcul scientifique

Avant de désigner cette étonnante reconstruction, Cray renvoie à un constructeur spécialisé dans les supercalculateurs. Ces ordinateurs sont conçus pour exécuter des calculs particulièrement lourds, avec des applications scientifiques, industrielles et stratégiques. Le nom vient de Seymour Cray, ingénieur américain qui a fondé Cray Research en 1972. Le Cray-1, livré en 1976, est devenu l’une des machines les plus reconnaissables de cette industrie.

Son apparence contribue à sa célébrité. Une structure incurvée, accompagnée d’une banquette, lui donne une silhouette inhabituelle pour un ordinateur. Cette disposition répondait à des contraintes techniques précises. La proximité des composants permettait de raccourcir les liaisons électriques et de limiter les délais de transmission des signaux. Les sièges dissimulaient notamment les alimentations électriques.

Le Cray-1 reposait sur le traitement vectoriel, une architecture adaptée à l’application d’opérations sur des séries de données. Ses usages comprenaient la conception aéronautique, les simulations nucléaires et la cryptographie. Pour les lecteurs intéressés par le renseignement, cette dernière application rappelle le lien ancien entre puissance informatique et traitement de problèmes stratégiques.

La réplique espagnole reprend son enveloppe à l’échelle réelle. À l’intérieur, le travail est confié à des ordinateurs Apple beaucoup plus récents. Il faut donc distinguer la reproduction visuelle du supercalculateur et son architecture informatique. L’installation ne restaure pas les circuits historiques du Cray-1 et ne permet pas, à elle seule, d’affirmer qu’elle reproduit son fonctionnement logiciel. Ce choix sert l’objectif de l’exposition. Les visiteurs peuvent observer comment une tâche de calcul change de dimension lorsqu’elle est répartie entre plusieurs machines. La silhouette historique attire le regard ; les ordinateurs qu’elle abrite rendent visible un principe essentiel du calcul contemporain.

Trente ordinateurs coordonnés dans une même structure

D’après les caractéristiques rapportées dans le texte fourni, l’ensemble comprend cinq Mac mini équipés de processeurs Intel Core i7 à quatre cœurs et vingt-cinq modèles dotés de Core i5 à deux cœurs. L’addition donne soixante-dix cœurs physiques, soit vingt pour les premiers et cinquante pour les seconds. La majorité des appareils datent de 2012. Sur une épreuve de multiplication matricielle, la configuration aurait atteint 1,3 téraflops. Un précédent fonctionnement mobilisant tous les cœurs aurait permis d’obtenir 1,5 téraflops. Ces valeurs décrivent les performances annoncées pour cette charge de travail particulière.

Le Cray-1 d’origine affichait une puissance maximale théorique d’environ 160 mégaflops. La comparaison avec les résultats de la réplique demande donc de la prudence : un plafond théorique et une mesure issue d’un test spécifique ne permettent pas d’établir directement un classement entre les deux architectures. Le musée rapproche deux générations informatiques, sans effacer leurs différences.

Un Mac mini principal assure la coordination des autres ordinateurs, qui fonctionnent sous macOS Mojave 10.14. Les échanges reposent sur MPI, une interface permettant aux programmes répartis sur plusieurs machines de communiquer. Chaque ordinateur constitue un nœud du cluster. L’enjeu consiste à organiser leur coopération pour qu’ils contribuent à un même calcul.

La construction doit également évacuer la chaleur. Les Mac mini sont installés verticalement, sur des supports en aluminium, dans une structure en acier. Cette disposition favorise la convection naturelle et évite l’ajout de ventilateurs au châssis. Elle ne signifie pas que les ventilateurs internes des ordinateurs ont disparu. Le niveau sonore annoncé se situe autour de 30 à 33 décibels.

Le musée envisage ensuite une installation réunissant soixante-dix à quatre-vingts Mac mini équipés de puces M4. Il affiche l’ambition de rejoindre le TOP500 des supercalculateurs. À ce stade, il s’agit d’un objectif annoncé.

Un Apple I vendu aux enchères à un prix record

L’année 1976 occupe également l’actualité des collectionneurs. Un Apple I encore fonctionnel, connu sous le nom de « Hatfield », a été vendu chez Bonhams pour 1 148 200 dollars, frais compris, soit environ 1,02 million d’euros. Selon la maison de ventes, il s’agit d’un record mondial aux enchères pour un Apple I commercialisé, une précision qui évite de confondre cette catégorie avec les prototypes et exemplaires particuliers. La vente s’est achevée le 14 octobre 2026, après vingt-huit minutes de compétition entre deux enchérisseurs.

Cet ordinateur porte la signature de Steve Wozniak sur sa carte mère. Son histoire est documentée jusqu’à son premier propriétaire, Fred Hatfield, dont il conserve le nom. Le lot comprend un écran, un clavier, une alimentation électrique ainsi que plusieurs documents, notamment un manuel et les instructions de l’interface cassette.

Une lettre signée par Steve Jobs en 1978 accompagne surtout la machine. Le cofondateur d’Apple proposait à Hatfield de restituer sa carte mère dans le cadre d’un échange vers un Apple II. Le propriétaire a décliné cette proposition, conservant ainsi son ordinateur de première génération. Bonhams souligne qu’il appartient aux moins de soixante-quinze Apple I authentifiés encore connus, dont une fraction seulement demeure opérationnelle.

Avec ses 8 Ko de mémoire vive et son processeur MOS Technology 6502, l’Apple I appartient à une autre branche de l’histoire informatique que le Cray-1. Le premier incarne les débuts d’Apple et de la micro-informatique ; le second, la recherche de performances pour les calculs scientifiques. Cinquante ans plus tard, l’un devient une pièce de collection à sept chiffres, tandis que la silhouette de l’autre accueille trente ordinateurs personnels réunis en cluster.

Cybersécurité, Entreprise, Mise à jour, Patch, Securite informatique

Patch Tuesday d’octobre : les correctifs prioritaires

Une faille Windows exploitée, des équipements réseau ciblés et des logiciels en fin de support : le Patch Tuesday d’octobre impose de hiérarchiser les interventions de sécurité.

Depuis les mises à jour de septembre, les alertes se multiplient autour des équipements réseau et des environnements Microsoft. Selon le bilan d’Ivanti, octobre totalise 1 407 vulnérabilités corrigées chez Microsoft, dont 78 critiques. Une faille Windows Shell déjà exploitée appelle une intervention prioritaire. Adobe et Mozilla publient également des correctifs importants, tandis que plusieurs produits atteignent leurs échéances de support. Pour datasecuritybreach.fr, ce récapitulatif distingue trois enjeux : corriger les vulnérabilités utilisées dans des attaques, protéger les services exposés et anticiper le retrait des logiciels vieillissants. Le nombre de failles constitue un indicateur, mais leur exploitation doit guider les premières décisions.

Des équipements réseau aux postes Windows, les urgences

Les chiffres communiqués par Ivanti illustrent l’augmentation des vulnérabilités recensées. Sa base dépasse désormais 406 000 CVE, dont plus de 78 000 divulguées en 2026. Ce dernier volume excède les quelque 70 000 références publiées entre 1999 et 2015 inclus.

Au 12 octobre, les divulgations dépassaient de 64 % le total annuel de 2025. Le nombre de vulnérabilités exploitées progressait, lui, de 33 % par rapport à l’ensemble de l’année précédente. Le catalogue de correctifs atteignait 94 % du volume de 2025. Ivanti anticipait un dépassement d’environ 20 % à la clôture de 2026, une projection qui reste distincte du bilan observé.

Les semaines précédant cette publication ont surtout exposé les équipements placés en périphérie du réseau. Chez Citrix, CVE-2026-88779 touche NetScaler lorsque l’appliance fonctionne comme fournisseur de services SAML ou fournisseur d’identité. Cette vulnérabilité zero-day ciblée reçoit un score CVSS de 8,7.

FortiMail est concerné par CVE-2026-104286, une écriture de fichier sans authentification notée 9,8 et signalée comme activement exploitée par la CISA. SonicWall a, de son côté, diffusé le 6 octobre un correctif d’urgence pour CVE-2026-102255. Cette faille SSRF avant authentification affecte SMA1000 et atteint 10 sur l’échelle CVSS. Une activité d’attaque a été observée le 9 octobre, sans compromission confirmée dans le bilan transmis.

Les anciennes vulnérabilités restent également pertinentes pour les attaquants. Le 8 octobre, cinq failles concernant ProFTPD, ONLYOFFICE, Strapi, Struts et BIND ont rejoint le catalogue KEV de la CISA, après leur exploitation attribuée à Flax Typhoon, acteur lié à la Chine.

Chez Microsoft, les 1 407 CVE corrigées se répartissent entre 78 critiques et 1 329 importantes, soit environ 44 % de plus que le précédent record de septembre. La priorité concerne CVE-2026-96951, un contournement de sécurité de Windows Shell déjà exploité. Windows 10, Windows 11 et plusieurs générations de Windows Server sont concernés.

Autre point de vigilance, CVE-2026-108398 affecte .NET Framework 3.5 et les versions 4.6.2 à 4.8.1. Sa divulgation publique ne signifie pas qu’une exploitation est constatée, mais justifie une correction rapide.

Parmi les failles critiques, 65 permettent une exécution de code à distance. Office en concentre 34, dont 19 dans Excel. DHCP Server, Message Queuing, Remote Desktop Services et QUIC figurent aussi parmi les services touchés.

Les fins de support compliquent la maintenance

Corriger suppose encore de disposer de mises à jour. Office 2021, Office LTSC 2021, Windows 10 2016 LTSB et IoT LTSB 2016 atteignent leur fin de support en octobre. Windows 11 24H2 Home et Pro arrivent également au terme de leur maintenance.

Une correction s’impose concernant Windows Server 2012 et 2012 R2 : leur dernière année de mises à jour de sécurité étendues ne commence pas en octobre 2026. Le programme ESU s’est terminé le 13 octobre 2026, selon Microsoft. Cette échéance impose de revoir les systèmes encore dépendants de ces versions.

Exchange Server 2016 et 2019 cumulent deux contraintes dans le bilan fourni : une vulnérabilité critique d’exécution de code à distance, CVE-2026-70571, et une échéance ESU annoncée au 31 octobre. La gestion des correctifs doit donc accompagner celle du remplacement des produits concernés.

Adobe publie dix bulletins couvrant 141 CVE, dont quinze critiques, sans exploitation connue signalée. ColdFusion et Commerce concentrent ces dernières.

Pour ColdFusion, le bulletin APSB26-144 traite dix vulnérabilités critiques. Trois sont accessibles à distance sans authentification : CVE-2026-105899 et CVE-2026-106622, notées 10, ainsi que CVE-2026-106624, évaluée à 9,8. Les versions corrigées sont 2025.0.14 et 2023.0.26.

Commerce compte cinq failles critiques. CVE-2026-103849 et CVE-2026-92909, respectivement notées 10 et 9,8, ne nécessitent aucune authentification. Le correctif d’urgence associé à CVE-2026-75650, publié en septembre, reste également à appliquer. Les huit autres bulletins Adobe relèvent de la priorité 3.

Mozilla corrige, selon le récapitulatif transmis, 79 CVE distinctes avec Firefox 158, ESR 153.5 et ESR 115.43. Trente présentent une sévérité élevée. Plusieurs permettent de sortir du bac à sable, mécanisme destiné à isoler les traitements du navigateur. Aucune exploitation active n’est mentionnée. L’attribution désormais individuelle des CVE contribue aussi à augmenter leur nombre.

Pour datasecuritybreach.fr, les priorités opérationnelles ressortent clairement : traiter Windows Shell, examiner les équipements exposés, puis organiser les migrations et la maintenance restante. Le renseignement sur les menaces devient utile lorsqu’il permet de relier une vulnérabilité exploitée aux systèmes effectivement présents dans l’entreprise.

(Sources Ivanti, Patch Tuesday d’octobre 2026.)
Cybersécurité, Entreprise, Linux, Logiciels, Mise à jour, Red Hat, Securite informatique

L’Urssaf choisit Red Hat pour moderniser son système d’information

L’Urssaf déploie Red Hat sur ses serveurs et son cloud interne. Derrière cette modernisation, un enjeu central : garder la maîtrise de données et de services critiques.

L’Urssaf a retenu Red Hat Enterprise Linux et Red Hat OpenShift comme plateformes de référence pour faire évoluer son système d’information, selon un communiqué publié le 8 septembre 2026. L’organisme privilégie une infrastructure privée isolée, sans recours à un cloud public, afin de conserver la maîtrise de ses données et de ses opérations. Red Hat Enterprise Linux équipe plus de 27 000 serveurs virtualisés, tandis qu’OpenShift anime un cloud interne hébergeant des services destinés aux usagers et aux partenaires. Le dispositif traite jusqu’à deux milliards d’appels API par mois. Pour l’Urssaf, la standardisation doit soutenir la disponibilité des applications tout en limitant la dépendance à un fournisseur unique.

Une infrastructure privée pour des services essentiels

Une interruption du système d’information de l’Urssaf ne concernerait pas seulement ses équipes informatiques. L’organisme collecte les cotisations sociales et les redistribue à l’échelle nationale. En 2025, il indique avoir recueilli près de 602 milliards d’euros auprès de 12 millions d’employeurs et d’entrepreneurs, puis réparti ces fonds entre plus de 800 organismes et régimes de protection sociale. La continuité des applications qui soutiennent cette mission constitue donc une exigence opérationnelle majeure.

C’est dans ce contexte que l’Urssaf a choisi Red Hat Enterprise Linux et Red Hat OpenShift pour accompagner la transformation de son infrastructure. Le premier sert de système d’exploitation à plus de 27 000 serveurs virtualisés qui portent ses principales applications transactionnelles. Red Hat Directory Server prend en charge les annuaires et la gestion des identités. OpenShift fournit, de son côté, la plateforme de son cloud interne.

Le communiqué décrit un environnement privé isolé, dit « air-gapped », sans dépendance à un cloud public. L’objectif annoncé est de garder le contrôle des données des citoyens et de répondre aux exigences réglementaires. Cette architecture place la maîtrise locale de l’infrastructure au cœur du projet. Elle impose aussi à l’Urssaf de disposer des capacités nécessaires pour exploiter et faire évoluer ses plateformes dans la durée.

L’organisme met en avant une infrastructure standardisée, ouverte et interopérable. Il estime que le recours aux technologies open source d’entreprise réduit sa dépendance à un fournisseur unique. Cette orientation concerne à la fois les choix techniques et la gouvernance : Jean-Baptiste Courouble, directeur des systèmes d’information de l’Urssaf, insiste sur le maintien d’un « contrôle architectural local strict ». Il associe cette décision à la stabilité nécessaire au traitement des flux financiers et à la protection des données.

Le choix d’une plateforme commune répond également à un enjeu de sécurité. Lorsque des applications critiques reposent sur un grand nombre de serveurs, la cohérence de leur exploitation compte autant que leur capacité de traitement. Selon Red Hat, la standardisation engagée par l’Urssaf doit renforcer la fiabilité, la résilience et la sécurité de ces services. Le communiqué ne détaille toutefois ni calendrier de migration ni indicateurs permettant de mesurer ces effets.

Un cloud interne pour faire évoluer les applications

La modernisation porte aussi sur la manière de développer et d’exécuter les services numériques. La DSI suit une orientation « cloud first » pour ses applications, tout en s’appuyant sur son propre cloud interne. OpenShift y orchestre des applications conteneurisées, organisées notamment en microservices. Ce modèle vise à faciliter leur évolution sans modifier en bloc l’ensemble du système d’information.

Plusieurs services destinés aux usagers et aux partenaires de la protection sociale sont déjà hébergés sur cette infrastructure. Red Hat annonce un volume pouvant atteindre deux milliards d’appels API par mois et des pointes de 5 000 transactions par seconde. Ces chiffres donnent une idée de l’échelle du dispositif. Ils ne constituent pas, à eux seuls, une mesure de sa disponibilité ou de sa résistance à un incident.

L’Urssaf présente également cette architecture comme un socle pour de futures capacités d’intelligence artificielle, selon les besoins de ses équipes et des citoyens. Aucune application d’IA précise ni date de déploiement n’est annoncée. La priorité décrite dans le communiqué reste la capacité à faire évoluer les services existants tout en conservant une gouvernance locale des opérations.

Pour Rémy Mandon, responsable de Red Hat France, ce modèle pourrait intéresser d’autres acteurs publics soumis à de fortes contraintes réglementaires. Cette appréciation relève de l’éditeur. Le cas de l’Urssaf illustre surtout une décision d’architecture : associer serveurs standardisés, gestion des identités et cloud interne pour exploiter des services numériques à grande échelle.

Sur le plan de la cyber intelligence, l’enjeu sera de suivre les résultats concrets de cette transformation : continuité des services, maîtrise des dépendances et protection des données traitées par l’Urssaf.

Cybersécurité, Entreprise, Mise à jour, Patch, Propriété Industrielle, Securite informatique

Cyber Resilience Act : les 24 heures se préparent avant la crise

Depuis le 11 septembre 2026, une faille exploitée dans un produit numérique peut déclencher une obligation de signalement sous 24 heures. Pour les fabricants, l’enjeu est d’être prêts avant l’alerte.

Le Cyber Resilience Act (CRA) impose désormais aux fabricants de déclarer les vulnérabilités activement exploitées et les incidents graves touchant la sécurité de leurs produits comportant des éléments numériques. Le premier délai, fixé à 24 heures après la prise de connaissance, correspond à une alerte précoce, pas à une expertise achevée. Une notification plus détaillée suit sous 72 heures, puis un rapport final selon la nature de l’événement.

Le délai commence quand le fabricant est informé

Vendredi, 17 h 30. Un chercheur signale qu’une vulnérabilité affectant un logiciel est activement exploitée. Le message arrive dans une boîte générique. Si personne ne le lit avant lundi, le premier obstacle n’est pas technique : l’information n’a pas atteint l’équipe capable d’agir.

Depuis le 11 septembre 2026, le CRA oblige les fabricants concernés à signaler, sans retard injustifié et au plus tard sous 24 heures après en avoir pris connaissance, une vulnérabilité activement exploitée ou un incident grave ayant une incidence sur la sécurité d’un produit comportant des éléments numériques. Cette première déclaration sert à donner l’alerte. Elle ne suppose pas que l’enquête soit terminée.

Le fabricant dispose ensuite de 72 heures pour transmettre une notification plus détaillée. Pour une vulnérabilité activement exploitée, le rapport final doit parvenir au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation. Pour un incident grave, il est attendu dans le mois suivant la notification des 72 heures. Ces étapes permettent d’enrichir progressivement les informations disponibles, à condition de lancer l’investigation sans attendre.

La première décision consiste donc à qualifier ce qui remonte du terrain. Une faille possible, découverte dans une bibliothèque utilisée par l’entreprise, ne suffit pas à établir qu’elle est activement exploitée. À l’inverse, une information reçue par le support, le SOC, un client, un fournisseur ou un chercheur peut nécessiter une escalade immédiate. Le fabricant doit savoir qui examine le signalement, comment il vérifie les éléments disponibles et à quel moment les responsables de la déclaration sont informés.

Cette circulation de l’information demande un point de contact surveillé, une politique de divulgation coordonnée et une équipe chargée de la sécurité des produits. Son nom importe moins que sa capacité à recevoir une alerte, ouvrir une enquête et mobiliser les bonnes personnes le soir, le week-end ou pendant les congés.

Inventaire, responsabilités et accès prêts à l’emploi

Une fois l’alerte reçue, une autre question surgit : quels produits sont réellement touchés ? Le fabricant doit pouvoir relier un composant, une version de bibliothèque ou un firmware à ses logiciels et équipements. Un inventaire exploitable et une nomenclature logicielle, ou SBOM, facilitent ce rapprochement. Sans cette visibilité, les premières heures risquent d’être consacrées à rechercher où se trouve le composant concerné.

La chaîne de décision doit être définie avec la même précision. Sécurité, développement, responsables produit, juridique, conformité et communication ont besoin d’un circuit d’escalade connu. Qui confirme les faits disponibles ? Qui valide le périmètre des produits ? Qui transmet la notification ? Qui prend le relais si la personne désignée est absente ? Une matrice de responsabilités et des remplaçants évitent qu’une déclaration reste bloquée dans l’attente d’une signature.

Les déclarations passent par la Single Reporting Platform (SRP), exploitée par l’ENISA. Son accès repose sur un compte EU Login avec authentification multifacteur. L’organisation peut désigner un représentant principal et des représentants secondaires. Identifier ces personnes et vérifier leurs accès avant le premier incident écarte une difficulté administrative au moment où chaque heure compte.

Les équipes doivent aussi préparer les informations qu’elles chercheront dès le début de l’enquête : produit et versions concernés, composant en cause, éléments attestant l’exploitation, correctif ou mesure d’atténuation disponible, et pays où le produit est commercialisé. Le premier signalement peut rester succinct. Les échéances suivantes exigent toutefois une connaissance de plus en plus précise de la vulnérabilité, de son exploitation et des mesures prises. Un exercice permet de mesurer cette préparation. Le scénario peut tenir en une phrase : une vulnérabilité du produit X est activement exploitée à 17 h 30. Jusqu’au lendemain à la même heure, l’entreprise doit retrouver les versions touchées, joindre ses responsables, établir ce qu’elle sait et déposer l’alerte. Les retards observés indiquent où corriger le processus.

Cette obligation concerne aussi les produits relevant du CRA déjà mis sur le marché avant son application complète, prévue le 11 décembre 2027. Pour la cyber intelligence des fabricants, le changement est immédiat : une alerte n’est utile que si elle peut être reliée rapidement à un produit, qualifiée et transmise aux personnes capables d’agir.

En résumé, les 24 heures ne se gagnent pas le jour de l’incident. Elles se gagnent auparavant, avec un inventaire précis, une SBOM exploitable, une surveillance des vulnérabilités, un canal de signalement efficace, une équipe Product Security identifiée, une procédure d’escalade, des remplaçants, des accès prêts et des exercices réguliers. Le CRA transforme ainsi la gestion des vulnérabilités en processus industriel mesurable, et plus seulement en problème technique traité lorsqu’une faille devient publique.

backdoor, Cybersécurité, double authentification, Entreprise, Mise à jour, Securite informatique, Social engineering

EvilTokens industrialise la fraude grâce à l’IA

Microsoft a démantelé une partie d’EvilTokens, une plateforme cybercriminelle exploitant l’intelligence artificielle pour compromettre des messageries, analyser leurs contenus et préparer des fraudes financières ciblées.

EvilTokens illustre une évolution importante de la cybercriminalité assistée par intelligence artificielle. Lancé en février 2026, le service aurait été associé à plus de 12 000 boîtes mail compromises dans plus de 10 000 organisations. Son fonctionnement dépassait la simple génération de messages frauduleux. Une interface conversationnelle analysait les courriels volés, identifiait les relations de confiance, les responsables financiers et les procédures internes. Pas vraiment une nouveauté dans sa forme, ZATAZ avait révélé la découverte de ce type d’outil, voilà trois ans, mis en place par des pirates informatiques brésiliens. Microsoft et ses partenaires ont saisi 50 sites et neutralisé plus de 150 domaines associés. Au Royaume-Uni, deux hommes ont été arrêtés. L’affaire montre comment l’IA peut transformer un accès initial en renseignement exploitable pour préparer rapidement une fraude.

De la messagerie compromise au renseignement financier

EvilTokens permettait d’abord aux opérateurs criminels de prendre le contrôle de comptes de messagerie. Les victimes étaient incitées à saisir un code d’authentification sur la véritable page de connexion de Microsoft. Elles validaient alors, sans communiquer leur mot de passe, un accès exploitable par les attaquants.

Cette méthode présentait une difficulté supplémentaire pour les défenseurs. Une simple réinitialisation du mot de passe pouvait rester insuffisante lorsque les sessions et les jetons d’authentification associés n’étaient pas révoqués.

L’innovation la plus notable intervenait après l’intrusion. Examiner manuellement plusieurs milliers de courriels demande normalement du temps et une compréhension précise des circuits de décision. EvilTokens automatisait une partie de cette phase de renseignement.

Ses outils pouvaient résumer ou traduire les messages, repérer des échanges financiers, cartographier les responsabilités et identifier des relations de confiance. L’intelligence artificielle recherchait aussi des factures, des discussions liées aux virements ou les personnes disposant d’un pouvoir sur les paiements.

Des commandes prédéfinies aidaient notamment les utilisateurs à repérer les responsables manipulant les fonds ou à déterminer quelles identités seraient les plus crédibles à usurper. L’IA ne servait donc pas uniquement à rédiger un courriel convaincant. Elle contribuait à sélectionner une victime, choisir un interlocuteur à imiter et déterminer un scénario de fraude adapté aux informations découvertes.

Usurpation d’un contact connu

Le service pouvait ensuite proposer des messages se faisant passer pour des contacts connus. L’objectif consistait à exploiter les habitudes, les responsabilités ou les autorisations observées dans la boîte compromise afin d’augmenter les chances d’obtenir un paiement ou une autre action sensible.

En quelques mois, Microsoft a relié EvilTokens à plus de 12 000 messageries compromises appartenant à plus de 10 000 organisations. L’activité observée était particulièrement concentrée aux États-Unis, au Canada, au Royaume-Uni, en Australie, en Inde et en France.

Les victimes appartenaient à plusieurs secteurs, dont la distribution, la construction, les services financiers, l’immobilier, l’enseignement supérieur et la santé.

EvilTokens était commercialisé sur Telegram avec un droit d’entrée de 1 500 $ (conversion en euros impossible sans introduire un taux de change absent des informations fournies), puis un abonnement récurrent de 500 $ (conversion en euros non calculable pour la même raison). Cette offre regroupait compromission de comptes, analyse des boîtes, sélection des cibles et préparation des fraudes dans une même interface.

Un modèle criminel intégré, ciblé par une opération internationale

Les enquêteurs ont également trouvé des éléments indiquant qu’une grande partie d’EvilTokens avait été développée selon une approche de « vibe coding », l’intelligence artificielle assistant directement les créateurs dans la programmation de la plateforme. Plusieurs modèles d’IA auraient aussi contribué aux fonctionnalités proposées.

Cette combinaison abaissait les compétences nécessaires à plusieurs étapes. Des techniques relevant auparavant de l’attaque d’identité, des environnements cloud, de l’ingénierie sociale et de la fraude financière étaient réunies dans un service commercial disposant d’abonnements, d’assistance et de tableaux de gestion.

Pour perturber cette infrastructure, Microsoft a associé action judiciaire et coopération opérationnelle. Health-ISAC s’est joint à la procédure comme coplaignant, notamment parce que des acteurs de la santé figuraient parmi les organisations ciblées.

Avec l’autorisation du tribunal fédéral du district Est de Virginie, Health-ISAC a travaillé avec Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, Shadowserver Foundation et TRM Labs. L’opération a permis la saisie de 50 sites utilisés par le service et la désactivation de plus de 150 domaines supplémentaires liés à son infrastructure.

La coopération avec la Metropolitan Police Service a également débouché sur une opération au Royaume-Uni. Le 11 septembre 2026, les policiers ont arrêté deux hommes âgés de 32 et 38 ans, soupçonnés d’infractions liées à l’exploitation présumée d’EvilTokens. Des appareils numériques et d’autres éléments ont été saisis pour examen. Les deux suspects ont ensuite été libérés sous caution policière, avec conditions, pendant la poursuite de l’enquête. Les défenseurs ont eux-mêmes eu recours à l’IA aprés avoir utilisé la rétro-ingénierie et des outils assistés par intelligence artificielle pour analyser les éléments collectés, accélérer les investigations et identifier les infrastructures soutenant le service.

EvilTokens montre surtout qu’une boîte mail compromise peut devenir presque immédiatement une source structurée de renseignement financier, organisationnel et relationnel exploitable par des fraudeurs assistés par IA.