Archives de catégorie : Securite informatique

Cybersécurité, Entreprise, Linux, Logiciels, Mise à jour, Red Hat, Securite informatique

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

Laisser un commentaire

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.

backdoor, Cybersécurité, Entreprise, Espionnage Spy, Mise à jour, Securite informatique, Social engineering

RingCentral : 1,6 million de comptes exposés

La cyberattaque contre RingCentral change d’échelle : 1,6 million de comptes exposés et attribue l’intrusion au groupe cybercriminel ShinyHunters.

L’incident de sécurité reconnu par RingCentral fin juillet 2026 concerne désormais environ 1,6 million d’adresses électroniques uniques identifiées dans les données diffusées. Le corpus contient également des noms, numéros de téléphone et adresses postales. Aucun mot de passe ne figure parmi les catégories d’informations actuellement confirmées. RingCentral indique avoir stoppé l’activité malveillante et affirme que sa plateforme principale n’a pas été affectée. ZATAZ confirme également l’implication de ShinyHunters dans cette intrusion. Le groupe revendique l’exfiltration de 623 Go de données.

Une « portion limitée » qui atteint 1,6 million

Fin juillet, RingCentral avait reconnu une campagne d’ingénierie sociale ayant permis un accès non autorisé à certains de ses systèmes. La société évoquait alors une « portion limitée » de sa clientèle, sans communiquer d’estimation chiffrée sur le nombre de personnes concernées.

Les données désormais disponibles donnent une autre mesure de l’incident. Leur analyse fait apparaître environ 1,6 million d’adresses mails uniques. Ce nombre représente des comptes identifiés dans le corpus diffusé par les pirates et ne correspond donc pas nécessairement à 1,6 million d’entreprises clientes différentes.

Cette distinction est importante pour mesurer correctement l’impact. RingCentral fournit des services de téléphonie, de communication cloud et de collaboration à des organisations pouvant compter de nombreux utilisateurs. Plusieurs adresses rattachées à une même entreprise peuvent ainsi figurer dans la fuite.

Les informations exposées comprennent des noms, des adresses électroniques, des numéros de téléphone et des adresses postales. Aucun mot de passe n’est présent.

Ce type d’assemblage conserve pourtant une forte valeur opérationnelle pour un attaquant. Une identité associée à une adresse professionnelle, un téléphone et une localisation physique facilite la préparation de scénarios crédibles d’ingénierie sociale. Un pirate peut personnaliser davantage un courriel, un appel téléphonique ou une tentative d’usurpation en utilisant plusieurs informations exactes sur sa cible.

Les utilisateurs professionnels constituent une population particulièrement intéressante dans ce contexte. La connaissance de leur environnement de communication peut faciliter des tentatives visant à obtenir des informations complémentaires, provoquer une réinitialisation de compte ou convaincre une victime de suivre une procédure frauduleuse.

RingCentral affirme avoir interrompu l’activité malveillante après sa découverte. L’entreprise indique également avoir fait appel à une société spécialisée dans l’investigation numérique. Selon ses déclarations, aucune nouvelle activité non autorisée n’a été observée après la mise en œuvre des mesures correctives. Ce qui n’empéche pas les centaines de Go de données volées a être diffusés ! La plateforme principale n’aurait pas été compromise et les services seraient restés opérationnels durant l’incident.

ShinyHunters derrière l’intrusion selon ZATAZ

L’autre évolution concerne l’identité des attaquants. ZATAZ confirme que ShinyHunters est bien impliqué dans l’opération visant RingCentral. ShinyHunters affirme avoir dérobé environ 623 Go de données avant d’en publier une partie après l’échec d’une tentative d’extorsion. La chronologie permet également de comprendre pourquoi l’affaire prend aujourd’hui une dimension différente. L’incident s’est produit en juillet 2026. RingCentral a rendu publique la compromission le 28 juillet. Les données ont ensuite fait l’objet d’une diffusion, avant que l’ampleur d’environ 1,6 million de comptes soit détaillée publiquement le 14 août.

backdoor, Cybersécurité, Entreprise, Mise à jour, OS X, Patch, Securite informatique

Des Mac compromis via une faille Screen Sharing

Une faille de Screen Sharing corrigée par Apple est désormais exploitée activement, avec accès root et installation de mineurs Monero sur plusieurs Mac exposés.

La vulnérabilité CVE-2026-65400 affectant Screen Sharing sur macOS est désormais associée à des compromissions réelles. Le NCSC néerlandais rapporte plusieurs machines exposant le port 5900 sur Internet sur lesquelles des attaquants ont obtenu des privilèges root avant d’installer un mineur Monero. Apple avait publié des correctifs le 6 août 2026 pour macOS Tahoe 26.6.1, Sequoia 15.7.9 et Sonoma 14.8.9. Aucun vol de données ou d’identifiants n’est confirmé à ce stade. L’accès root ouvre toutefois un champ d’action beaucoup plus large, notamment sur les fichiers, sessions, secrets applicatifs et ressources accessibles depuis les postes compromis.

 

 

Une authentification contournée jusqu’au niveau root

L’alerte change de dimension depuis que l’exploitation de CVE-2026-65400 ne relève plus d’un risque théorique. Le NCSC-NL indique avoir reçu des signalements concernant plusieurs systèmes macOS dont le service Screen Sharing était directement accessible depuis Internet sur le port 5900. Dans chacun des cas observés, l’attaquant avait réussi à obtenir un accès root. Ce niveau de privilège correspond au contrôle le plus élevé sur un système Unix comme macOS. Les compromissions documentées ont ensuite conduit à l’installation d’un mineur de cryptomonnaie Monero. Apple avait pourtant corrigé la vulnérabilité dès le 6 août 2026. Les mises à jour concernées sont macOS Tahoe 26.6.1, macOS Sequoia 15.7.9 et macOS Sonoma 14.8.9. Le constructeur décrit CVE-2026-65400 comme un défaut d’authentification affectant Screen Sharing. Un attaquant présent sur le réseau peut, selon cette description, parvenir à s’authentifier auprès du service sans disposer d’identifiants valides. Cette caractéristique explique le risque particulier pesant sur les machines dont Screen Sharing est exposé directement sur Internet. Un service destiné à l’administration ou à l’assistance distante devient alors un point d’entrée potentiel vers le système lui-même.

Qu’est-ce que Screen Sharing ?

Screen Sharing est la fonction de partage d’écran intégrée à macOS. Elle permet d’afficher et de contrôler à distance l’écran d’un Mac depuis une autre machine. Elle peut servir à l’assistance technique, à l’administration d’un poste ou à l’accès distant à son propre ordinateur. Lorsqu’elle est activée et accessible depuis Internet, cette fonction devient aussi un service exposé aux tentatives de connexion. Dans le cas de CVE-2026-65400, la faille permet précisément de contourner l’authentification normalement nécessaire pour accéder à ce service.

Le 12 août, le NCSC-NL a ajouté la mention « exploitation active connue » à son bulletin. De nouvelles alertes publiques ont suivi le 15 août 2026. Cette chronologie place les organisations face à un scénario classique en cybersécurité : un correctif existe, tandis que des systèmes non mis à jour ou toujours exposés restent exploitables. Le nombre exact de victimes n’est pas communiqué. Le NCSC néerlandais confirme seulement plusieurs compromissions. Des recherches indépendantes recensent parallèlement plusieurs dizaines de milliers de services Screen Sharing accessibles depuis Internet. Ce volume ne peut pas être assimilé à un nombre de machines vulnérables. Une exposition du service n’implique ni que la version de macOS soit affectée, ni que l’exploitation ait réussi.

L’accès root élargit fortement le risque opérationnel

L’impact observé est pour l’instant concret et limité à ce qui a été confirmé : contrôle root sur les Mac compromis et déploiement de logiciels de minage Monero. Aucun vol de données, aucune extraction d’identifiants et aucune fuite d’informations ne sont documentés dans les cas rapportés. L’absence de preuve de vol ne réduit toutefois pas la portée technique d’un accès root. Une machine contrôlée à ce niveau peut potentiellement exposer ses fichiers locaux, les sessions ouvertes, les secrets utilisés par des applications et les ressources auxquelles le poste dispose déjà d’un accès. Ces possibilités relèvent du potentiel offert par la compromission, pas d’actions secondaires actuellement attribuées aux attaquants. Cette distinction reste essentielle pour évaluer la menace sans extrapolation. Les faits établis décrivent une exploitation active, une élévation jusqu’au niveau root et l’installation d’un cryptomineur. Les scénarios de récupération de secrets ou de rebond vers d’autres ressources sont techniquement plausibles, sans être démontrés dans les incidents signalés. Les postes administrés à distance constituent un cas particulièrement sensible. Lorsqu’un service Screen Sharing écoute directement sur Internet, l’attaquant n’a plus besoin d’un accès préalable au réseau interne pour atteindre la surface exposée. La faille d’authentification devient alors une porte d’entrée située au périmètre même du système. La chronologie renforce également l’enjeu de réaction. Apple a distribué ses correctifs le 6 août. Six jours plus tard, le NCSC-NL signalait officiellement une exploitation active connue. Le 15 août, de nouvelles alertes publiques confirmaient que la vulnérabilité devait désormais être considérée comme une menace opérationnelle et non comme une simple faiblesse corrigée sur le papier. Pour les équipes de sécurité, CVE-2026-65400 illustre ainsi le risque créé par l’association de trois facteurs : un service d’administration exposé, une faille permettant de contourner l’authentification et des machines n’ayant pas encore reçu le correctif disponible.

backdoor, Cybersécurité, Entreprise, Espionnage Spy, Mise à jour, Securite informatique

SAP Commerce Cloud : une faille critique déjà exploitée

Trois jours après son correctif, une faille critique de SAP Commerce Cloud fait déjà l’objet de tentatives d’exploitation visant des plateformes exposées sur Internet.

La vulnérabilité CVE-2026-58231 place SAP Commerce Cloud sous surveillance étroite. Corrigée par SAP le 11 août 2026, cette faille affichant un score CVSS de 10.0 permettrait une exécution de code sans authentification ni action préalable de l’utilisateur. Des chercheurs ont détecté des tentatives d’exploitation dès le 14 août, alors qu’aucune activité hostile n’était encore signalée deux jours auparavant. Plus de 4 200 systèmes présentant une empreinte SAP Commerce Cloud seraient accessibles depuis Internet, principalement en Europe et en Amérique du Nord. Leur vulnérabilité effective reste inconnue. Une intrusion réussie pourrait ouvrir l’accès à des services métiers connectés, notamment ERP, CRM, stocks et commandes.

Du correctif aux premières attaques en trois jours

La chronologie resserrée constitue le principal signal d’alerte autour de CVE-2026-58231. SAP a publié son correctif le 11 août 2026 dans la note de sécurité 3771065. Le 12 août, aucune exploitation active n’était encore rapportée. Dès le 14 août, des chercheurs observaient cependant des tentatives contre des environnements SAP Commerce Cloud. De nouvelles publications spécialisées ont relayé l’alerte le 15 août.

La faille concerne le Data Hub Adapter des branches COM_CLOUD 2211 et 2211-JDK21. Son score CVSS maximal, 10.0, traduit une combinaison particulièrement défavorable pour les défenseurs. L’attaque ne requiert aucune authentification et aucune interaction d’un utilisateur. Une exploitation réussie peut permettre l’exécution de code arbitraire et compromettre des composants internes accessibles depuis l’instance concernée.

Cette rapidité entre publication du correctif et activité offensive réduit fortement la fenêtre disponible pour les entreprises. Une vulnérabilité publique devient rapidement exploitable lorsque suffisamment d’informations techniques permettent à des attaquants de comprendre le mécanisme défaillant et de rechercher des cibles accessibles.

Le signal doit toutefois être interprété avec précision. L’existence de la vulnérabilité et son niveau critique sont confirmés par SAP ainsi que par le NVD. En revanche, l’exploitation active repose actuellement sur des observations réalisées par des chercheurs et reprises par plusieurs sources spécialisées. SAP ne l’a pas encore officiellement qualifiée comme exploitation active.

Aucune victime identifiée publiquement ni campagne de vol massif de données n’est confirmée à ce stade. L’enjeu immédiat concerne donc davantage l’exposition et la capacité d’intrusion que les conséquences documentées d’attaques déjà réussies.

Les systèmes métiers derrière la vitrine e-commerce

SAP Commerce Cloud ne constitue pas seulement une interface de vente exposée aux internautes. Dans une architecture d’entreprise, une plateforme de commerce électronique peut communiquer avec plusieurs briques internes nécessaires aux stocks, commandes, comptes clients ou traitements administratifs.

Une compromission de l’instance peut ainsi transformer un service accessible depuis Internet en point d’entrée vers des ressources moins directement exposées. Selon l’architecture déployée, les attaquants pourraient atteindre des services reliés à un ERP, un CRM, des systèmes de gestion des stocks, des traitements de commandes ou d’autres composants internes.

Aucune catégorie précise de données volées n’est actuellement confirmée. Il serait donc prématuré d’affirmer que des informations clients, financières ou commerciales ont déjà été exfiltrées. Le risque porte sur les données et services que l’instance compromise serait autorisée à consulter ou solliciter, ainsi que sur les relations de confiance établies avec les systèmes voisins.

L’ampleur potentielle de la surface exposée ajoute une dimension particulière à l’incident. Shadowserver aurait identifié plus de 4 200 systèmes accessibles depuis Internet présentant une empreinte associée à SAP Commerce Cloud. La majorité se situerait en Europe et en Amérique du Nord.

Ce chiffre ne correspond toutefois pas au nombre de serveurs vulnérables. Une empreinte détectable indique la présence apparente de la technologie, sans démontrer que la version concernée par CVE-2026-58231 est utilisée ni que le correctif du 11 août n’a pas été appliqué. Assimiler les 4 200 systèmes à autant de cibles exploitables conduirait donc à surestimer l’exposition réelle.

Pour les équipes de sécurité, la priorité réside dans la vérification des versions et l’application de la note SAP 3771065 sur les environnements concernés. La surveillance doit aussi porter sur les systèmes connectés à Commerce Cloud, puisque la valeur d’un accès initial dépend souvent des privilèges, flux applicatifs et relations internes disponibles après l’intrusion.

La séquence observée illustre enfin une dynamique désormais centrale du renseignement cyber : entre divulgation d’une faille critique et premières tentatives offensives, la fenêtre de réaction peut se mesurer en quelques jours.

Cybersécurité, Entreprise, Espionnage Spy, Linux, Mise à jour, Securite informatique, Social engineering

ChocoPoC cible les chercheurs en vulnérabilités

Des chercheurs français en cybersécurité ont identifié une campagne sophistiquée utilisant de faux exploits CVE pour infecter les environnements des pentesters avec un cheval de Troie Python.

Une enquête menée par YesWeHack et Sekoia révèle une attaque de chaîne d’approvisionnement visant directement les chercheurs en vulnérabilités. Depuis fin 2025, des acteurs malveillants diffusent de faux dépôts GitHub proposant des preuves de concept pour des failles critiques. Sept dépôts piégés ont été identifiés. Leur installation déclenche des dépendances Python malveillantes capables de déployer ChocoPoC, un RAT conçu pour voler des fichiers, récupérer des identifiants et exécuter des commandes.

Des exploits CVE transformés en pièges

L’affaire débute le 25 juin 2026. Après la publication d’un modèle Nuclei consacré à Joomla JCE, l’équipe de YesWeHack reçoit une suggestion concernant deux preuves de concept associées à une vulnérabilité critique Joomla. L’un des dépôts, consacré à CVE-2026-48908, attire rapidement l’attention.

Son fichier de dépendances réclame un paquet Python inconnu nommé « frint ». Celui-ci installe à son tour « skytext », publié récemment sur PyPI. Le paquet se présente comme une bibliothèque destinée à produire rapidement des couleurs dans un terminal. Son contenu réel est beaucoup moins décoratif.

Skytext distribue des extensions compilées pour Linux et Windows. L’analyse de la version Windows révèle du code obfusqué, une exploration du Process Environment Block, des fonctions résolues dynamiquement et plusieurs blocs chiffrés. Le programme vérifie également son environnement avant d’exécuter son activité malveillante.

Cette précaution complique fortement l’analyse automatisée. Le code recherche notamment la présence d’un fichier portant un nom précis, comme « EXPLOIT_POC.py ». Sans ce contexte, aucune charge utile ne se déclenche. Un échantillon isolé dans un bac à sable peut ainsi sembler inoffensif.

Lorsque les conditions attendues sont réunies, l’extension déchiffre plusieurs composants et modifie l’environnement Python. Elle installe une version détournée du paquet _distutils_hack ainsi que des fichiers .pth. Ces éléments sont ensuite chargés lors du démarrage d’un nouvel interpréteur Python.

Cette persistance permet de lancer choco.py, le téléchargeur intermédiaire de ChocoPoC. Celui-ci récupère une nouvelle charge utile grâce à un jeu de données hébergé chez Mapbox. Les requêtes DNS peuvent passer par DNS-over-HTTPS, notamment via AliDNS ou Cloudflare, afin de contourner certains mécanismes locaux de filtrage.

Le trafic conserve par ailleurs l’apparence d’une connexion légitime vers l’API Mapbox. Cette infrastructure sert de point mort pour récupérer le RAT et échanger des informations, réduisant la visibilité du canal de commande.

Une campagne pensée pour les outils offensifs

Le dernier étage de l’infection est un RAT (logiciel espion) écrit en Python. ChocoPoC peut collecter des données issues de Chrome, Brave, Edge et Firefox, notamment les mots de passe, cookies, historiques et informations de remplissage automatique.

Il recherche également certains fichiers locaux, des bases de données, des historiques de commandes shell, des informations réseau et la liste des processus actifs. L’opérateur peut lancer des commandes système, exécuter dynamiquement du code Python, récupérer des fichiers ou modifier la fréquence des communications avec le serveur de contrôle.

L’enquête a permis d’identifier au moins sept dépôts GitHub malveillants associés à des vulnérabilités très médiatisées. Les leurres visaient notamment FortiWeb, React2Shell, MongoBleed, PAN-OS, Ivanti Sentry, Checkpoint VPN et Joomla SP Page Builder.

Deux chaînes de dépendances apparaissent. En 2025, plusieurs dépôts utilisaient les paquets « slogsec » et « logcrypt.cryptography ». En 2026, les opérateurs ont privilégié « frint » et « skytext ». Malgré ces changements, YesWeHack et Sekoia relèvent plusieurs caractéristiques communes, dont le même identifiant de fonctionnalité Mapbox, des contrôles environnementaux similaires et des mécanismes identiques contre les relances récursives.

Ces éléments conduisent les chercheurs à attribuer avec une forte confiance les deux périodes d’activité au même acteur. Selon leur analyse, l’opérateur aurait régulièrement changé de comptes GitHub, PyPI et Mapbox pour limiter les blocages et compliquer le suivi de son infrastructure.

Les adresses électroniques utilisées pour certaines publications semblent également liées à des comptes compromis. Des identifiants concernant deux des quatre adresses étudiées figuraient dans des bases de données de fuites, dont l’une probablement issue d’une infection par infostealer.

Les statistiques de téléchargement renforcent l’inquiétude sans démontrer, à elles seules, une compromission. Le paquet skytext aurait enregistré environ 2 400 téléchargements sur Linux et Windows, avec une majorité sous Linux. Plusieurs hausses coïncident avec la divulgation ou l’exploitation publique de vulnérabilités importantes.

Le risque dépasse donc la seule machine d’un chercheur. Un pentester compromis peut manipuler des identifiants clients, des rapports confidentiels, des données techniques sensibles ou des informations concernant des systèmes vulnérables.

ChocoPoC illustre ainsi une évolution préoccupante du renseignement cyber : le code visible peut rester crédible tandis que l’infection se déplace vers les dépendances, transformant l’urgence autour des nouvelles CVE en véritable surface d’attaque.

backdoor, Banque, Cybersécurité, Espionnage Spy, Securite informatique, Social engineering

WindRelay et SpyNote, le relais NFC passe à l’attaque

Un malware Android inédit combine contrôle à distance, fraude au crédit et relais NFC, permettant à des escrocs de détourner une carte bancaire pendant un appel.

WindRelay, un malware Android conçu pour transmettre en temps réel les échanges NFC d’une carte bancaire. Associé au cheval de Troie d’accès distant SpyNote, il s’intègre dans une fraude mêlant ingénierie sociale, prise de contrôle du smartphone, usurpation d’identité et paiement sans contact détourné. Dans un cas analysé, l’opération complète s’est déroulée durant un appel de seulement 13 minutes. Les chercheurs ont relié 23 échantillons de WindRelay, soumis entre novembre 2025 et juillet 2026, à plusieurs campagnes observées notamment en Tchéquie, Slovaquie et Slovénie. L’étendue réelle des victimes reste inconnue.

Treize minutes pour prendre le contrôle du téléphone

Le scénario étudié par la société Group-IB (Group-IB, société de cybersécurité fondée en Russie en 2003 et désormais basée à Singapour, après avoir quitté le marché russe en 2023.) illustre l’intégration croissante entre manipulation téléphonique et outils malveillants Android. L’attaque commence par un appel frauduleux destiné à gagner la confiance de la cible. La victime est ensuite conduite à installer SpyNote, dans une version personnalisée portant son propre nom. Cette personnalisation constitue un indice important sur la préparation de l’opération. Les fraudeurs disposaient au minimum d’informations permettant d’identifier précisément leur cible, notamment son nom et son numéro de téléphone. Les éléments disponibles ne permettent toutefois pas de déterminer l’origine de ces données personnelles. Il suffit de voir les alertes de ZATAZ pour comprendre la problématique de la fuite de données, aujourd’hui.

Une fois SpyNote installé, les attaquants obtiennent un accès à distance au terminal Android. Dans le cas documenté, cette compromission leur permet d’installer un second programme, WindRelay, puis d’accéder à l’environnement bancaire de la victime.

La fraude ne s’arrête pas à la prise de contrôle du smartphone. Les opérateurs utilisent l’accès obtenu pour souscrire un crédit au nom de la personne ciblée. Celle-ci peut ainsi se retrouver avec une dette contractée frauduleusement avant même que la phase NFC ne débute.

L’étape suivante exploite directement la carte bancaire physique. Toujours guidée pendant l’appel, la victime est invitée à approcher sa carte de son téléphone. WindRelay transmet alors en temps réel les communications NFC vers une infrastructure contrôlée par les escrocs. Ceux-ci peuvent exploiter le relais depuis un autre terminal afin de réaliser une transaction.

L’ensemble de cette séquence, installation du RAT, déploiement du second malware, accès bancaire, crédit frauduleux et relais NFC, a été réalisé durant un appel de 13 minutes !

SpyNote dispose par ailleurs de fonctions de collecte plus étendues. Les informations fournies ne permettent pas d’affirmer que toutes ont été employées au cours de cette attaque précise. L’analyse doit donc distinguer les capacités techniques du logiciel des actions effectivement observées.

Le relais NFC devient une chaîne de fraude complète

23 échantillons WindRelay ont été découverts dans plusieurs campagnes detectées. Ces fichiers ont été soumis à l’analyse entre novembre 2025 et juillet 2026. Quatre infrastructures de commande associées ont également été identifiées. Ces 23 échantillons ne représentent pas 23 victimes. Ils constituent des artefacts techniques associés à l’activité détectée. Le nombre total de personnes visées ou compromises reste inconnu au moment de la divulgation, publiée le 12 août 2026.

Les échantillons et campagnes sont principalement associés à la Tchéquie, à la Slovaquie et à la Slovénie. Cette implantation s’inscrit dans un contexte régional où plusieurs formes de fraude NFC avaient déjà été observées. Le rapport 2025 du European Payments Council cite le relais NFC et la technique dite « Ghost Tap » parmi les menaces émergentes contre les paiements. Selon ce document, ces attaques peuvent se combiner avec des escroqueries utilisant l’accès à distance et conduire à des transactions non autorisées ainsi qu’à une perte de contrôle sur les fonds.

Les données communiquées par Kaspersky indiquent pour leur part une hausse de 188 % des attaques NFC visant Android pendant les quatre premiers mois de 2026 par rapport à la même période de 2025. L’entreprise affirme avoir bloqué 35 600 attaques sur cette période, contre plus de 12 300 un an auparavant.

ESET avait auparavant relevé une multiplication supérieure à 35 des attaques liées au NFC durant le premier semestre 2025, comparé au second semestre 2024. Les premiers usages documentés d’une version modifiée de l’outil open source NFCGate remontent, selon les sources fournies, à fin 2023 en Tchéquie.

D’autres recherches montrent également une diversification des infrastructures. Zimperium indique avoir suivi des campagnes couvrant notamment la Pologne, la Tchéquie et la Slovaquie, avec plus de 70 serveurs de commande et points de distribution identifiés. Des attaquants ont aussi imité la Banque nationale de Slovaquie afin de rendre leurs applications frauduleuses plus crédibles et d’obtenir les autorisations NFC nécessaires.

Des opérations chinoises de Fraud-as-a-Service diffusant des malwares Android compatibles NFC via Telegram avaient été documentés, l’année derniére. Cette précédente enquête mentionnait plus de 54 échantillons et au moins 355 000 $ de transactions frauduleuses confirmées entre novembre 2024 et août 2025 pour un seul fournisseur de terminaux de paiement. WindRelay apporte une évolution distincte : le relais NFC n’est plus seulement une technique isolée. Associé à SpyNote, il devient l’un des maillons d’une chaîne réunissant renseignement préalable sur la cible, contrôle du téléphone, fraude à l’identité, crédit frauduleux et détournement de la carte physique.

APT, Cybersécurité, Entreprise, Espionnage Spy, Securite informatique

City-Forum aspire Salesforce et ServiceNow sans faille

Une campagne active extrait des données de portails Salesforce et ServiceNow exposés aux visiteurs anonymes, en exploitant des permissions excessives plutôt qu’une vulnérabilité logicielle.

Depuis au moins mars 2025, une infrastructure associée au domaine city-forum cible des organisations internationales via Salesforce Experience Cloud et ServiceNow Service Portal. Cette cyber attaque est attribuée à un même acteur utilisant un outil dédié, capable d’automatiser l’énumération de données accessibles aux comptes invités. Télécoms, banques, services financiers, éditeurs logiciels, entreprises de cybersécurité, acteurs de la protection des données et organismes publics figurent parmi les secteurs visés. La campagne, divulguée le 12 août 2026, reste active. Aucun groupe n’est attribué de façon fiable. L’enjeu tient surtout à l’exploitation industrielle de mauvaises configurations SaaS permettant des extractions massives sans authentification préalable.

Des permissions invité transformées en canal d’exfiltration

La campagne, baptisée « City-Forum » par la société Reco, repose sur un principe simple : exploiter ce que les portails SaaS autorisent déjà à consulter. Aucun défaut logiciel n’est nécessaire. Lorsque les droits accordés aux visiteurs anonymes sont trop larges, l’attaquant peut interroger les services disponibles et collecter les informations ainsi exposées.

Selon la configuration de chaque organisation, ces données peuvent comprendre des fiches de comptes, des contacts, des dossiers, des fichiers ou d’autres objets accessibles au profil invité. Aucune liste consolidée n’a été diffusée par l’entreprise. Pas d’informations sur ce qui est dérobée ni identité des organisations concernées.

Les observations convergent vers une infrastructure unique. Les requêtes proviennent de l’adresse IP 158.220.87.79, hébergée chez Contabo, et utilisent presque systématiquement l’agent utilisateur Go-http-client/1.1. Ce dernier correspond au client HTTP utilisé par défaut dans Go. Sa présence constante sur des portails conçus pour des navigateurs suggère une automatisation au moyen d’un programme compilé.

Cette même adresse IP dessert city-forum. Les données DNS passives citées par Reco relient ce domaine à l’infrastructure depuis mars 2025. L’équipe précise ne pas pouvoir dater précisément le début des scans. Elle peut uniquement établir que le serveur est contrôlé depuis cette période. Le volume observé traduit une activité soutenue. Sur la cible la plus sollicitée étudiée, plus de 560 000 événements ont été enregistrés. Ce chiffre ne correspond pas à 560 000 victimes ou personnes compromises. Il mesure les opérations d’énumération détectées sur cette cible.

L’activité progresse actuellement. Les secteurs touchés couvrent plusieurs catégories sensibles, notamment les télécommunications, la finance, les logiciels professionnels, la cybersécurité, la protection des données et le secteur public. Les organisations ne sont pas nommer pour ne pas caractériser individuellement les victimes (et potentiellement ses clients !).

Un outil commun pour Salesforce et ServiceNow

L’intérêt cyber-renseignement de City-Forum tient surtout à son outillage. Le même opérateur semble avoir conçu un programme capable d’interroger deux grands environnements SaaS avec plusieurs techniques complémentaires.

Sur Salesforce, l’acteur emploie l’énumération Aura déjà documentée dans d’autres campagnes visant des comptes invités trop permissifs. Il ajoute toutefois une méthode moins couramment observée : l’accès aux sites Lightning Web Runtime par l’interface UI API et GraphQL.

Les requêtes repérées parcourent successivement différentes versions de l’API, de v56.0 jusqu’à v66.0. L’acteur sonde également des chemins liés à l’auto-inscription, notamment SiteRegister et CommunitiesSelfReg.

Sur ServiceNow, le programme sollicite intensivement le mécanisme natif de recherche du Service Portal via l’endpoint /api/now/sp/search. Les chercheurs décrivent une cadence incompatible avec une utilisation humaine normale. Dans un cas analysé, les volumes sont passés de dizaines de requêtes quotidiennes à plusieurs centaines. Les journaux ServiceNow permettent d’identifier les requêtes, leur provenance, l’utilisateur « guest », l’agent utilisateur et la quantité de données renvoyée. Ils ne conservent toutefois pas le corps des requêtes POST. Une organisation peut donc confirmer un balayage du moteur de recherche et mesurer les réponses obtenues sans nécessairement reconstruire les termes recherchés.

Sur Salesforce, la détection dépend notamment des journaux Event Monitoring. Reco recommande de rechercher l’adresse IP identifiée, Go-http-client/1.1, les volumes anormaux de requêtes Aura ainsi que les appels invités vers les chemins webruntime de LWR.

La campagne présente certaines ressemblances avec des opérations précédemment associées à ShinyHunters, notamment l’énumération de données Salesforce accessibles aux visiteurs. Mais SH n’est pas le seul malveillant à avoir des idées tordues.

Un autre élément distingue City-Forum : la stabilité opérationnelle observée. La même adresse IP et le même domaine sont utilisés depuis au moins mars 2025, sans rotation détectée pendant cette période. Cette caractéristique constitue un signal comportemental, pas une preuve d’identité.

La conclusion technique est plus solide que toute hypothèse attributive : un même outil en Go semble avoir ciblé Salesforce via Aura et LWR, puis ServiceNow depuis une infrastructure commune. Pour la CTI, City-Forum illustre surtout comment des permissions SaaS mal maîtrisées peuvent devenir une interface d’exfiltration industrialisée, sans exploitation d’une vulnérabilité classique.

Cybersécurité, Entreprise, Securite informatique

Hexposure cartographie le risque cyber des PME

Après plusieurs années de réflexion et des mois de développement, Hexposure ouvre sa bêta privée avec une promesse : rendre le risque cyber externe exploitable par les PME.

Hexposure part d’un constat issu du terrain : une exposition critique naît souvent de plusieurs faiblesses apparemment secondaires. Un environnement de préproduction oublié, une clé d’API intégrée dans du JavaScript ou une interface dépourvue d’authentification peuvent, une fois combinés, ouvrir un accès étendu aux données. La plateforme québécoise veut reconstituer ces chaînes d’attaque plutôt que produire des centaines d’alertes isolées. Sans agent ni accès interne, elle cartographie les actifs visibles depuis Internet, analyse plus de 250 contrôles et utilise plus de 30 techniques de reconnaissance. L’objectif consiste à hiérarchiser les problèmes selon leur impact réel, puis à fournir aux PME, startups et MSP des correctifs compréhensibles et vérifiables. Attention, il ne s’agit pas d’un article sponsorisé ou autre placement de produit. Le projet est sexy et je voulais vous en parler.

Reconstituer les chemins d’attaque plutôt qu’empiler les alertes

L’origine d’Hexposure tient à une expérience répétée au fil des mandats de cybersécurité offensive. Pris séparément, certains constats peuvent sembler peu préoccupants. Un sous-domaine de préproduction subsiste en ligne. Une clé d’API apparaît dans un bundle JavaScript. Une interface applicative reste accessible sans mécanisme d’authentification.

Chacun de ces éléments peut être classé comme un signal relativement faible. Leur combinaison change pourtant la lecture du risque. En les reliant, un attaquant peut parfois progresser jusqu’à une exposition complète de données clients.

C’est précisément cette logique que veut traiter Hexposure et son faondateur, Patrick. Les outils de balayage traditionnels peuvent générer des centaines d’alertes, jusqu’à 765 dans l’exemple présenté par son créateur, sans nécessairement expliquer lesquelles forment ensemble une trajectoire exploitable. La charge d’analyse reste alors entre les mains de l’entreprise ou de son prestataire.

Son idée adopte une approche différente. La plateforme cherche d’abord à dresser la carte de ce qu’une organisation rend accessible sur Internet. Cette surface comprend notamment les sous-domaines, les adresses IP, les services actifs, les points d’accès applicatifs et les certificats. Elle couvre également les fichiers exposés, les secrets divulgués et les domaines imitant ceux de l’entreprise.

L’analyse ne s’arrête pas à l’inventaire

Chaque exposition est classée selon son impact potentiel sur l’activité. Le système rapproche ensuite les observations afin de reconstruire le parcours qu’un attaquant pourrait suivre.

Cette méthode vise à transformer une accumulation de signaux techniques en scénario compréhensible. Une faiblesse isolée peut ainsi changer de priorité dès lors qu’elle fournit une étape utile vers une seconde ressource exposée.

La plateforme fonctionne sans agent, sans installation locale et sans accès au réseau interne. Son point d’observation reste donc l’extérieur, dans une logique proche de celle d’un attaquant réalisant une phase de reconnaissance sur une cible accessible publiquement.

Hexposure annonce plus de 30 techniques de reconnaissance et plus de 250 vérifications lors de chaque analyse. Le processus est relancé chaque mois. Les corrections apportées entre deux analyses sont également revalidées automatiquement afin de vérifier que les expositions identifiées ont réellement disparu.

Sa première cohorte bêta privée est désormais ouverte, avec un nombre de places annoncé comme limité. Elle cible particulièrement les personnes responsables du risque externe dans les PME, les startups et les fournisseurs de services gérés, notamment les MSP.

Bref, derrière cette bêta, l’enjeu de renseignement cyber est clair : identifier ce qu’un adversaire peut voir, comprendre comment il peut relier ces informations et réduire les chemins d’attaque avant qu’ils ne soient exploités.