Détection et notification d'une campagne d'usurpation d'identité via ShinyHunters avant son activation : 61 domaines, 48 ​​marques

Par Adrian Cheek, chercheur principal en cybercriminalité

Le service de recherche sur les menaces de ReliaQuest a publié un bref avis public concernant une campagne de ShinyHunters le 17 août 2026. Cette campagne s'appuyait sur des domaines suivant le modèle « company[.]claims » et indiquait que le groupe avait ajouté l'usurpation d'identité d'une équipe juridique à ses prétextes habituels de service d'assistance et d'informatique. L'avis ne mentionnait aucun domaine et décrivait une structure laissant au lecteur le soin de découvrir les occurrences.

Au cours des trois semaines suivantes, nous avons recensé ces noms de domaine. Résultat : 61 domaines usurpant l’identité de 48 organisations, tous enregistrés auprès d’un même registraire et jamais utilisés. Nous avons informé chaque organisation concernée via H-ISAC, FS-ISAC, RH-ISAC, IT-ISAC, ME-ISAC, A-ISAC et MS-ISAC, la plupart quelques heures seulement après la découverte du domaine. Aucune n’est nommée ici.

La phase d'enregistrement est désormais terminée. Le dernier nom de domaine a été enregistré le 31 août 2026 et aucun autre n'a été enregistré entre le 31 août et le 6 septembre, pour les quatre options de noms de domaine surveillées. Il s'agit de la plus longue période d'inactivité observée durant cette campagne, et elle est survenue sans période de ralentissement préalable. Les chiffres ci-dessous décrivent donc une phase d'acquisition achevée, une situation plus stable que celle que cet article aurait pu envisager une semaine auparavant.

Il s'agit d'une étude de l'infrastructure pré-attaque. Aucun des 61 domaines n'a diffusé de contenu durant la période de collecte. Chacun possède un nom d'hôte actif et 57 d'entre eux disposent d'un certificat valide et publiquement reconnu. Aucun n'a jamais présenté de page à qui que ce soit. Il n'y a pas kit de phishing Pour l'identification, pas de texte d'appât à citer ni de page de destination à capturer, car rien de tout cela n'existe encore. Ce qui existe, c'est l'infrastructure, et c'est cette infrastructure que cet article décrit.

Voici l'état de l'infrastructure. La campagne pourrait être plus avancée. Trois organisations ont signalé des appels d'hameçonnage vocaux au cours desquels l'appelant a mentionné un domaine appartenant à ce groupe. Ces signalements sont parvenus à Flare via les canaux de partage d'informations sectoriels, mais aucun n'a été confirmé de manière indépendante. Ils sont consignés dans ce document comme des témoignages de tiers, identifiés comme non confirmés partout où ils apparaissent, et aucune conclusion ne repose sur eux.

Les données d'enregistrement passif attestent de la construction de l'infrastructure, de ses copropriétaires et de sa date de construction. Elles ne permettent pas d'établir les intentions de l'opérateur, et aucune affirmation de ce type n'est faite ici sur la seule base de ces données. L'intérêt de l'analyse pré-attaque ne réside pas dans l'explication, mais dans la possibilité de bloquer les domaines non encore utilisés et d'informer les organisations qu'ils désignent avant même qu'elles ne soient contactées.

En bref

Tableau 1. Aperçu de la campagne au 6 septembre 2026. Il s'agit de chiffres minimaux. Chaque construction de nom a été trouvée en testant une chaîne de caractères candidate ; l'ensemble réel est donc au moins aussi grand et pourrait l'être davantage.

Note terminologique : ce texte utilise le terme « opérateur » pour désigner la personne ou l’entité ayant enregistré et géré cette infrastructure. Il s’agit d’une affirmation concernant une seule et même entité, étayée par les attributs communs présentés ci-dessous. Cette affirmation est distincte de l’attribution à ShinyHunters, qui provient de rapports publics et est traitée séparément.

Deux thèmes se dégagent de ce qui suit. Le premier concerne la méthode : une infrastructure de ce type peut être identifiée avant son activation, mais seulement si les défenseurs cessent de considérer comme définitives la première convention de nommage observée, ou la première relation d’infrastructure sur laquelle ils s’appuient. Chaque structure a été découverte en devinant une chaîne de caractères, trois sur quatre après l’envoi des premières notifications, et deux groupes initialement comptabilisés comme faisant partie de la campagne se sont avérés appartenir à quelqu’un d’autre.

La seconde mesure concerne la divulgation. Nous avons mis en place un système de notification parallèle à la collecte d'informations, en diffusant des alertes individuelles via quatre organismes sectoriels de partage d'informations au fur et à mesure de l'évolution de la situation, et en les réitérant lors de chaque nouveau changement. La section correspondante détaille les résultats obtenus et les coûts associés.

Toutes les données proviennent de sources passives. Nous n'avons effectué aucune analyse active, aucun sondage de ports, aucune interaction avec l'infrastructure identifiée ni aucune récupération de contenu hébergé.

Principales conclusions concernant la campagne ShinyHunters

• Le modèle de dénomination publié était incomplet. Quatre constructions sont utilisées contre une marque cible, et trois d'entre elles n'ont été identifiées qu'après le début des notifications : la marque seule, nous-[organisation], revendications-[organisation] et [organisation]-revendications, pour les extensions .claims et .com.
• La similarité des serveurs de noms est un signal de regroupement et non d'attribution. Douze groupes de paires de serveurs de noms contiennent chacun entre un et dix domaines, onze organisations ont des domaines répartis sur plusieurs groupes, et une organisation a trois domaines dans trois groupes distincts enregistrés le même jour.
• Aucun des 61 domaines ne possède d'enregistrement d'échange de courrier. Quel que soit l'élément qui amène une victime sur ces domaines, il ne provient pas de ceux-ci, ce qui est incompatible avec une opération menée par courriel à partir de cette infrastructure.
• Le ciblage se concentre sur les secteurs de la santé et de l'assurance. Seize organisations appartiennent au secteur de la santé et douze aux services financiers, dont huit sont des assureurs, des réassureurs ou des courtiers, et trois sont des banques ou des sociétés de crédit à la consommation.
• Le 22 août, cinq jours après l'avertissement qui a révélé la campagne, un domaine usurpant l'identité du fournisseur de sécurité qui l'avait publié a été enregistré au sein de l'infrastructure de la campagne.
• La recherche d'un seul nom d'hôte de serveur de noms Cloudflare a renvoyé 629 candidats pour cinq domaines valides, avec une précision inférieure à 1 %. La recherche de la paire exacte est bien meilleure, mais reste insuffisante à elle seule, comme le démontrent les deux groupes exclus ultérieurement.
• Le système de notification a amélioré la collecte des alertes. Le premier lot d'alertes a révélé une nouvelle convention de dénomination que la simple énumération du modèle initial n'aurait pas permis de déceler. Quarante-huit organisations ont reçu des alertes individuelles par l'intermédiaire de quatre organismes sectoriels sur une période de 19 jours, et six d'entre elles ont été réémises suite à l'apparition de nouveaux domaines.
• Trois organisations ont signalé des appels vocaux d'hameçonnage mentionnant un domaine de ce cluster. Nous n'avons pas confirmé ces signalements. S'ils sont exacts, la diffusion de l'appel précède l'affichage de la page de destination : l'appelant indique une destination qui est provisionnée, certifiée et vide.
• L'enregistrement a duré 36 jours, puis s'est arrêté. Le dernier domaine a été enregistré le 31 août 2026, et six jours de surveillance sur les quatre sites n'ont rien donné depuis.

Où tout a commencé

ReliaQuest a publié l'avis reproduit dans la figure 1. Il vaut la peine d'être lu attentivement, car presque tout ce que Flare a fait par la suite a été une tentative de convertir sa description en une liste.

Figure 1. Avis de ReliaQuest Threat Research, 17 août 2026, reproduit tel que publié. Nous avons identifié le groupe de menaces décrit dans cet article indépendamment de cet avis.

L'avis consultatif fournit trois éléments : un modèle de dénomination, un prétexte et l'attribution d'un acteur.

Nous avons retenu le modèle de dénomination et considéré les deux autres comme du contexte à tester.

La première étape évidente consistait à recenser intégralement le domaine de premier niveau .claims. Il s'agit d'un petit espace de noms Identity Digital, ce qui rend un recensement complet réalisable, contrairement au .com. Ce recensement a porté sur environ 14 750 domaines enregistrés et a permis d'obtenir le groupe initial. Il a également généré une grande quantité d'éléments ressemblant à ce groupe, mais n'en faisant pas partie.

Tout analyste qui suit les recommandations jusqu'à leur conclusion évidente effectuera une recherche dans le dossier .claims et découvrira immédiatement trois populations d'abus distinctes. Elles sont plus importantes et plus anciennes que la campagne, et les distinguer représente la majeure partie du travail.

• Le plus important est un réseau frauduleux de quelque 190 domaines enregistrés depuis juillet 2025 auprès d'un autre registraire, qui usurpent l'identité de marques de portefeuilles et de projets de jetons pour créer des pages de distribution gratuite de cryptomonnaies (airdrops). Une trentaine de ces pages contiennent déjà une fenêtre d'hameçonnage utilisant un réseau de diffusion de contenu (CDN). Un analyste qui examine les domaines en .claims s'intéressera en priorité à ce réseau, car il est le plus visible dans cet espace de noms.
• Opérations de fret et d'expédition utilisant des noms préfixés par des demandes de remboursement sur des plateformes de gestion de fret et de transport.
• Un ensemble de portails de faillite et de réclamations de créanciers. Aucun des deux n'est lié à la campagne décrite ici.

Il existe également une population légitime susceptible de contaminer une liste de blocage si elle n'est pas identifiée. Deux assureurs ont enregistré leurs noms sous l'extension .claims le 18 août, le lendemain de la publication de l'avis. Un fournisseur de technologies de la santé a enregistré l'intégralité de son portefeuille de marques acquises le 20 août, soit dix noms en une seule journée. Un exploitant de terminal maritime a fait de même pour une quarantaine de noms le 1er septembre. Ces trois vagues d'enregistrements sont distinctes selon le bureau d'enregistrement et le profil de risque, et toutes trois témoignent de la diffusion rapide de l'avis et des notifications.

Le volume à lui seul ne permet pas d'identifier la campagne. Sur les 24 mois précédant août 2026, l'espace de noms .claims a enregistré en moyenne 186 enregistrements par mois. On en a dénombré 131 en juillet 2026 et 82 durant les 18 premiers jours d'août. Aucune augmentation soudaine n'a été constatée.

Il s'agit plutôt d'un partage. 25 des 82 enregistrements .claims de la première quinzaine d'août, soit près d'un tiers de tout ce qui est enregistré dans cet espace de noms, appartiennent à un seul opérateur.

Qu'est-ce qui cimente le groupe ?

Aucun attribut isolé ne permet d'identifier l'infrastructure de campagne. Le regroupement est défini par une conjonction, et il convient de préciser quels éléments sont importants.

Tableau 2. La conjonction qui définit le groupe. Aucun élément n'est suffisant à lui seul.

Le moment de la délivrance des certificats mérite une attention particulière, car il est souvent négligé et s'est révélé plus déterminant que tout autre critère dans cette enquête. Dans ce contexte, la délivrance des certificats le jour même, combinée à l'absence de contenu, s'est avérée être le facteur de discrimination le plus efficace entre l'infrastructure de la campagne et les faux positifs analysés, notamment le portefeuille d'investissement de domaines décrit plus loin, où les certificats ont été délivrés sept jours après l'enregistrement et où un domaine affichait déjà une page. Aucune référence n'ayant été établie pour l'ensemble des domaines, cette combinaison est présentée comme un critère de discrimination ayant permis d'éliminer ces faux positifs spécifiques, et non comme une signature universelle.

L'absence d'enregistrements de messagerie sur les 61 noms d'hôte constitue la seconde observation importante. Aucun élément de cette infrastructure n'est configuré pour l'envoi de courriels ; par conséquent, toute action qui amène une victime vers l'un de ces noms d'hôte provient d'ailleurs. Les domaines sont des destinations. Le chemin emprunté par une cible pour y accéder n'est pas visible dans les données d'enregistrement et n'est pas abordé ici.

Quatre constructions, deux extensions

L'avis décrivait un seul schéma. Il en existe quatre.

Tableau 3. Construction par extension. Les deux cellules vides ont été testées et n'ont rien renvoyé.

L'ordre dans lequel ces objets ont été trouvés importe plus que leur répartition.

La forme de base provenait de l'avis consultatif. La forme us- est parvenue par l'intermédiaire d'une organisation ciblée qui a informé son organisme sectoriel de ses observations, trois jours après la diffusion par ce dernier du premier lot d'alertes. Les formes avec préfixe et suffixe ont été découvertes par un analyste saisissant une chaîne de caractères potentielle dans un champ de recherche, huit jours après la publication des premières notifications.

Le suffixe à lui seul expliquait l'existence de quatre organisations qui étaient invisibles jusqu'à ce qu'il soit testé. Ces quatre organisations n'avaient aucun domaine sous aucune autre construction.

Si personne n'avait pensé à utiliser un suffixe, ils n'auraient jamais été avertis.

Deux cellules ont été testées et se sont révélées vides. Aucune revendication d'organisation n'est enregistrée sous .claims, ni aucune revendication d'organisation sous .claims. L'accès à l'extension .com est généralement bloqué par des enregistrements antérieurs, car l'extension .com la plus courante pour une grande marque est déjà réservée à cette dernière.

Douze groupes de paires de serveurs de noms

Cloudflare attribue à chaque compte une paire unique de noms de serveurs de noms issus d'un pool partagé. Les domaines partageant une même paire sont probablement détenus par le même compte, et au sein d'un ensemble déjà filtré selon le registraire, la durée et le modèle d'hébergement, cette association constitue un critère de regroupement fiable. La propriété du compte ne peut être confirmée depuis l'extérieur de la plateforme. Dans cet article, les 12 groupes sont donc décrits comme des groupes de paires de serveurs de noms et considérés comme des regroupements de comptes probables, ce qui représente l'hypothèse la plus plausible étayée par les éléments de preuve.

Les 12 groupes comprennent chacun entre un et dix domaines, ce qui en soi n'a rien d'exceptionnel. En revanche, la répartition des cibles entre eux est plus surprenante.

Onze des 48 organisations possèdent des noms de domaine appartenant à plusieurs groupes. L'une d'elles possède trois noms de domaine, répartis dans trois groupes distincts, tous enregistrés le même jour. Une autre possède trois noms de domaine, répartis dans deux groupes, enregistrés sur trois jours consécutifs. Une troisième possède trois noms de domaine, répartis dans trois groupes, sur deux jours.

Le fractionnement d'une cible entre plusieurs groupes engendrerait des difficultés pratiques et limiterait l'impact d'une suspension de compte, car la suppression d'un groupe désactiverait une partie de l'infrastructure dédiée à la cible, et non la totalité. Les données d'enregistrement ne permettent pas de déterminer si c'est la raison de cette séparation, et aucune intention n'est avancée à ce sujet. Les données montrent simplement que les services d'enregistrement sont organisés autour de groupes d'infrastructure. Les victimes individuelles ne constituent pas l'unité d'organisation, et les cibles sont réparties entre les groupes sans schéma apparent.

Pour un défenseur, la conséquence pratique est que la découverte d'un seul domaine hostile portant sa marque ne donne que très peu d'informations sur leur nombre. Dans cette campagne, 11 organisations en possédaient plusieurs, et aucune n'aurait pu déduire la présence des autres à partir du premier. C'est également la raison pour laquelle six alertes ont dû être réémises.

Ce que prouve et ne prouve pas la paire de serveurs de noms

Cette section existe parce que nous nous sommes trompés lors de la première série de notifications, car nous privilégions la rapidité en nous basant sur les indicateurs et la compréhension de l'époque.

Les notifications initiales indiquaient aux destinataires que les domaines partageant une même paire de serveurs de noms étaient détenus par le même compte et contrôlés par la même entité. Cette affirmation est excessive. Cloudflare sélectionne les paires parmi un ensemble de quelques centaines de noms, ce qui représente des dizaines de milliers de paires possibles pour des dizaines de millions de zones. Il est courant que des comptes sans lien entre eux partagent des paires, et il n'existe aucun moyen externe de vérifier la propriété d'un compte.

Deux mesures extraites de cet ensemble de données lui ont permis de quantifier les données.

Premièrement, la correspondance basée sur un seul nom d'hôte est quasiment inutile. Sur 12 997 domaines Dynadot hébergés sur les serveurs de noms Cloudflare, 629 utilisaient au moins l'un des 28 noms d'hôte associés aux groupes de campagne. Cinq d'entre eux correspondaient exactement à une paire de noms d'hôte. Ces cinq domaines étaient tous des domaines de campagne. Une correspondance basée sur un seul nom d'hôte aurait généré 634 candidats pour seulement cinq résultats positifs.

Deuxièmement, la correspondance exacte entre paires est bien meilleure, mais reste insuffisante. Sur un échantillon plus large et non filtré, 849 domaines correspondaient à une paire de campagnes exactes. Environ 58 d'entre eux appartenaient à l'infrastructure de la campagne. Deux des quatorze paires initialement identifiées se sont avérées appartenir à d'autres personnes : l'une à un investisseur en noms de domaine possédant 758 noms répartis dans un portefeuille de vocabulaire, l'autre à une société d'hébergement générique en possédant 29. Ces deux paires avaient passé les filtres précédents car seuls les deux ou trois domaines de chacune, apparaissant par hasard lors d'une recherche de .claims, avaient été détectés.

La leçon à retenir n'est pas que l'association de serveurs de noms est peu fiable, mais qu'elle privilégie l'association de groupes plutôt que d'identifiants.

Appliqué à un ensemble de données déjà filtré selon le bureau d'enregistrement, la durée d'enregistrement, la date d'émission du certificat et l'absence d'enregistrements de messagerie, cet outil indique avec précision quels domaines sont associés. Appliqué à des données DNS brutes, il ne fournit quasiment aucune information.

précis

La répartition sectorielle est asymétrique, et cette asymétrie reste stable tout au long de la période d'inscription.

Tableau 4. Organismes de partage d'informations par secteur. L'attribution reflète le mode de notification le plus probable. Elle ne constitue pas une adhésion formelle.

Les secteurs de la santé et des services financiers représentent à eux deux 28 des 48 cibles. Dans ces deux secteurs, le terme « sinistres » est un vocabulaire opérationnel essentiel, et non un terme périphérique. Un domaine dédié aux sinistres et portant le nom d'un assureur paraîtra plus crédible aux yeux du personnel de cet assureur, comme s'il s'agissait d'un système interne ou partenaire. Le même domaine, destiné à un fabricant, serait beaucoup moins crédible.

Plusieurs cibles occupent des postes clés dans la chaîne d'approvisionnement, où le vol d'identifiants a des répercussions bien au-delà de la victime : un fournisseur de technologies bancaires centrales, un intégrateur de systèmes, une plateforme de commerce, un gestionnaire de sinistres, un distributeur pharmaceutique, une plateforme de gestion hôtelière. Les données d'enregistrement ne permettent pas de déterminer s'il s'agit d'un choix délibéré ou d'une simple coïncidence.

Un point commun se dégage des libellés : plusieurs domaines utilisent un symbole boursier ou une abréviation courante au lieu du nom complet de l’entreprise, et deux utilisent la marque d’une filiale plutôt que celle de la société mère. Cela correspond à l’hypothèse d’un opérateur se basant sur une source recensant les usages courants des noms d’organisation, même si l’enregistrement ne précise pas le mode de sélection de chaque libellé.

Chronologie et cadence

La campagne a duré 36 jours, dont 25 ont enregistré au moins une inscription. Le volume quotidien a varié de un à cinq domaines. Il n'y a pas de rythme hebdomadaire au sens où on pourrait s'y attendre : les inscriptions ont eu lieu les samedis et dimanches, et les onze jours d'inactivité correspondent à des dimanches, lundis, mardis et un vendredi.

Le week-end est même plus chargé. Les trois jours de plus fort trafic de la campagne ont chacun comptabilisé cinq domaines, dont deux samedis.

Le premier artefact est antérieur au premier nom de domaine de la marque. Le 26 juillet, l'opérateur a enregistré un .com composé d'une suite de caractères apparemment aléatoire, au sein d'un groupe qui allait héberger l'infrastructure de la campagne. Un certificat a été obtenu le jour même, mais aucun contenu n'a jamais été diffusé.

Cela ressemble à un test du processus, effectué la veille du dépôt de la première marque.

Cinq pauses interrompent la fenêtre :

• deux jours après le 2 août
• un jour, le 11 août
• deux jours après le 16 août
• un jour, le 21 août
• cinq jours à partir du 25 août

La pause du 16 août est sujette à interprétation, car elle a débuté la veille de l'avis concernant ReliaQuest et s'est terminée le lendemain. Les inscriptions ont repris le 18 août au rythme habituel.

Cela dit, deux jours ne constituent pas une preuve. La campagne a connu une pause de deux jours deux semaines auparavant sans qu'aucun avis ne soit donné, et les intervalles entre les pauses sont de neuf, cinq, cinq, quatre et quatre jours, sans qu'un rythme régulier ne se soit établi. Il est important de noter ces dates, mais cela n'entraînera aucune conclusion.

La période de surveillance se termine le 31 août, et cette fois-ci, la fermeture semble définitive. La surveillance s'est poursuivie pour les quatre projets de dénomination et n'a rien révélé pendant les six jours précédant le 6 septembre, dépassant ainsi le précédent record de cinq jours. Chaque interruption précédente s'était terminée sans avertissement, une reprise ne peut donc être exclue.

Ce qui est remarquable, c'est l'absence de ralentissement progressif. L'opérateur n'a pas réduit ses activités. La pause de cinq jours, à partir du 25 août, a pris fin avec une reprise le 30 août, marquée par l'ajout de quatre nouvelles organisations, puis d'un seul domaine le 31 août, avant de s'arrêter complètement. Les données d'enregistrement ne permettent pas de déterminer si la phase d'acquisition s'est simplement achevée ou si la campagne a été abandonnée après l'identification des organisations cibles et la notification de celles-ci. La publication de l'information le 17 août n'a pas mis un terme à la campagne, pas plus que la notification de 48 organisations dans les deux semaines suivantes. Les enregistrements se sont poursuivis pendant deux semaines supplémentaires avant de s'interrompre.

Ce qui a suivi l'avertissement est moins ambigu. Le 22 août, un nom de domaine usurpant l'identité du fournisseur de sécurité qui l'avait publié a été enregistré. Ce domaine appartient à un groupe de serveurs de noms contenant déjà six autres domaines liés à la campagne, correspond en tous points aux attributs du groupe et a été enregistré cinq jours après la publication de l'avertissement. Flare estime que cet enregistrement était une réponse à l'avertissement, compte tenu du calendrier et de l'appartenance au groupe.

Cette inscription crée un prétexte inédit. Des organisations de quatre secteurs différents venaient d'être averties de cette campagne. Un contact prétendant provenir du fournisseur ayant identifié la menace, ou un lien vers une page semblant héberger des informations d'alerte, est crédible pour un service de sécurité, contrairement à une démarche auprès d'un autre service. Une équipe formée pour remettre en question les demandes d'assistance inattendues pourrait ne pas s'interroger sur ce qui semble être un suivi de la part d'un fournisseur de renseignements sur les menaces.

Posture de pré-attaque et fenêtre de blocage

À la date de la collecte, aucun des 61 domaines ne diffusait de contenu. Chacun d'eux possédait un nom d'hôte actif. Parmi eux, 57 disposaient d'un certificat valide et publiquement reconnu : 52 avaient été émis le jour même de l'enregistrement et cinq dans les 61 heures suivantes. Quatre domaines ne possédaient aucun certificat. Nous n'avons observé aucun de ces domaines diffuser du contenu ni collecter d'identifiants.

Un domaine possédant un certificat mais ne fournissant aucun service a été provisionné. L'usage prévu de ce domaine n'est pas précisé dans cet ensemble de données. Ce qui est visible, c'est que le travail préparatoire au lancement d'une campagne a déjà été effectué, et que l'étape restante est celle qu'un défenseur peut encore anticiper.

La conséquence pratique est une opportunité qui se présente et se refermera. Comme aucun de ces domaines n'a été observé diffusant du contenu légitime lors de la collecte, leur blocage n'aura probablement que peu ou pas d'impact opérationnel, sous réserve de validation locale. La transparence des certificats fournit un signal utile pour les changements de provisionnement. Un nouveau certificat couvrant un sous-domaine associé à l'authentification, aux services juridiques ou à un autre prétexte plausible justifierait un examen, même s'il n'entraînerait pas à lui seul l'activation. En l'absence de contenu, ces domaines ne peuvent encore rien capturer. Les bloquer aujourd'hui est peu coûteux. Les bloquer après l'apparition d'une page relève de la gestion des incidents.

Activité de livraison signalée

Trois organisations ont signalé avoir reçu des appels vocaux d'hameçonnage au cours desquels l'appelant mentionnait un domaine appartenant à ce groupe. Ces signalements nous sont parvenus par le biais des canaux de partage d'informations sectoriels.

Nous n'avons procédé à aucune vérification indépendante de ces informations. Aucun enregistrement d'appel, transcription ou relevé téléphonique n'a été examiné, et il est impossible de déterminer quel domaine a été mentionné lors de chaque appel, si l'appelant a indiqué un nom de domaine simple ou un nom d'hôte complet, ou si un employé s'est rendu à destination. Les organisations concernées ne sont pas identifiées ici. Il s'agit de comptes tiers, traités comme tels.

Si les rapports sont exacts, ils modifient l'état de la campagne, mais pas celui de l'infrastructure. Les domaines restent vides. Ce qui aurait changé, c'est le séquencement : la diffusion précède la page de destination, l'appelant indiquant une destination provisionnée, certifiée et vide. Cela réduirait également les possibilités, car l'enregistrement spéculatif, l'enregistrement défensif par un tiers et l'investissement dans les domaines restent des explications possibles pour les noms de domaine individuels tant que ces derniers restent inactifs. De plus, le fait qu'un appelant énonce un domaine à haute voix à un employé les supprime pour les domaines concernés.

L'argument en faveur du blocage se renforce. Un domaine vers lequel une victime est redirigée par téléphone est intercepté au niveau du résolveur, qu'une page web y soit associée ou non. Un blocage précoce stoppe l'opération au seul point de la chaîne que le défenseur contrôle totalement.

C’est cette fenêtre qui explique pourquoi la notification s’est exécutée en même temps que la collecte et non après.

Notification en temps quasi réel

Ce type de recherche aboutit généralement à une publication et à une liste d'indicateurs. Ici, les notifications ont précédé la publication.

Le premier lot de 24 alertes a été diffusé le 18 août, le lendemain de l'avis ReliaQuest et le jour même de la constitution du groupe initial. Chaque alerte était un document individuel concernant une seule organisation, mentionnant uniquement ses domaines et comportant des restrictions de traitement. Elles ont été transmises sous forme de trois colis, destinés aux organismes de partage de données des secteurs des services financiers, de la santé, et du commerce de détail et de l'hôtellerie-restauration. Chaque colis était accompagné d'une instruction précisant que les alertes devaient être diffusées individuellement et que le colis ne devait pas être transmis dans son intégralité, car celui-ci nommait tous les membres ciblés du secteur concerné.

La notification a ensuite suivi la collecte au lieu de la conclure. D'autres alertes ont été émises les 21 et 26 août, le 31 août et le 2 septembre, suite aux tests de nouvelles constructions de noms de domaine et à la reprise des enregistrements après la plus longue interruption de la campagne. Six alertes précédentes ont été réémises lorsque de nouveaux domaines ont été découverts, visant des organisations déjà notifiées.

Au moment de la clôture des inscriptions, 57 alertes flash avaient été émises auprès de sept organismes de partage d'informations sectoriels : services financiers, santé, commerce de détail et hôtellerie, technologies de l'information, médias et divertissement, ainsi que les organismes de l'aviation et les organismes interétatiques d'une autorité aéroportuaire municipale. Nous avons contacté directement une organisation, car aucun organisme de partage ne couvre le recrutement de personnel qualifié.

Résultats obtenus par cette approche

Le retour le plus utile n'était pas la gratitude. C'était une construction de dénomination.

Trois jours après le premier lot, une organisation bénéficiaire a signalé à son organisme sectoriel qu'en plus du modèle que nous avions décrit, elle avait également constaté la présence d'un domaine de la forme us-[organisation][.]com, enregistré simultanément et auprès du même registraire. Ce signalement est l'unique origine de la seconde construction. Elle provient d'un opérateur de sécurité qui, après avoir analysé une alerte, a reconnu un élément adjacent ; aucune collecte de données supplémentaire sur le modèle initial n'aurait permis de la reproduire.

Le second résultat a confirmé la logique d'attribution. Sur 48 organisations notifiées, aucune n'a identifié un domaine qui lui est attribué comme étant son propre enregistrement défensif. Pour une campagne fondée exclusivement sur l'inférence de données d'enregistrement, sans contenu ni utilisation observée, il s'agit du meilleur moyen de vérifier si l'ensemble a été correctement constitué, et ce moyen n'est accessible qu'en interrogeant les organisations concernées.

Le troisième élément était visible dans l'espace de noms lui-même. Les enregistrements défensifs sous .claims ont fortement augmenté dans les jours qui ont suivi le début des notifications. Une organisation extérieure au groupe ciblé a notamment enregistré sa marque mère, l'abréviation de son entité juridique et un hôpital affilié en une seule opération. L'opérateur n'avait jamais enregistré de domaine contre cette organisation auparavant. Il s'agissait d'une réaction systématique plutôt que d'un incident isolé, ce qui est pourtant l'objectif d'une campagne de notification.

Quel est le coût de cette approche ?

Envoyer une notification pendant la collecte revient à le faire à partir d'informations incomplètes, et les données le confirment. Onze organisations possédaient plusieurs domaines, et aucune n'aurait pu déduire le second du premier ; six alertes ont donc dû être réémises avec un nombre de domaines corrigé. Quatre organisations n'ont été contactées que grâce à un test de construction de suffixe effectué huit jours après le premier envoi, et quatre autres seulement après la reprise des enregistrements le 30 août.

Une erreur de raisonnement a également affecté les destinataires. Dans les alertes des trois premières semaines, une phrase décrivait deux domaines génériques de vocabulaire d'assurance comme preuve que l'opérateur préparait du contenu leurre. Or, ces domaines appartiennent à un portefeuille d'investissement sans rapport avec le sujet. Cette affirmation a été retirée du manifeste du lot final, qui précisait également qu'aucun de ces domaines n'avait jamais été mentionné comme indicateur et qu'aucun destinataire n'avait été invité à les bloquer ; aucune action n'était donc requise. La correction est décrite en détail dans la section ci-dessous.

Le coût réside dans la turbulence des informations et le risque de propagation rapide d'une erreur. L'alternative consistait à tout suspendre jusqu'à stabilisation de la situation, ce qui aurait impliqué de ne prévenir personne avant le 6 septembre, soit trois semaines après la découverte des premiers domaines et après la finalisation de leur enregistrement par l'opérateur. Pour une infrastructure de pré-attaque, ce compromis est judicieux : la valeur de la découverte diminue à mesure que l'infrastructure s'active, et une notification partielle reçue avant l'activation est plus précieuse qu'une notification complète reçue après. Ce constat se fonde sur le fait spécifique que ces domaines étaient provisionnés et inactifs, et ne s'applique pas à tous les types de recherche.

Analyse croisée par rapport à une campagne contemporaine

Le 6 août 2026, dix jours avant l'avis de sécurité de ReliaQuest, le Google Threat Intelligence Group a publié une analyse d'UNC6671, une opération d'extorsion par vishing utilisant la technique de l'attaquant du milieu pour collecter et exfiltrer des identifiants depuis des environnements cloud d'entreprise. Le profilage public des acteurs malveillants associe UNC6671 au même écosystème ShinyHunters auquel cette campagne est attribuée. Nous avons comparé les deux ensembles de données.

Il n'y a aucun chevauchement d'infrastructure. Chaque domaine racine et indicateur de réseau publié par GTIG a été comparé à 43 169 domaines collectés au cours de cette enquête. Aucun domaine ni adresse n'a correspondu.

Il n'y a pas non plus de chevauchement de cibles. Une recherche DNS passive sur f14 des domaines racines GTIG a révélé 250 sous-domaines portant le nom de victimes et enregistrés à partir de mars 2026. Aucun ne correspond à l'une des 48 organisations impliquées dans cette campagne. Les huit victimes publiquement citées lors de l'activité de janvier 2026, attribuée au même écosystème, n'apparaissent dans aucun des deux ensembles. Les listes de cibles sont disjointes pour trois ensembles d'activités connexes.

L'absence de chevauchement entre 298 organisations est incompatible avec l'hypothèse que les deux ensembles de données proviennent d'une même population cible. Cela ne prouve pas que les opérateurs sont indépendants, et l'ensemble de sous-domaines récupéré par DNS passif ne correspond pas nécessairement à la totalité de la liste cible UNC6671.

Les architectures sont également inversées. UNC6671 place le nom de la victime dans un sous-domaine d'une racine générique à thème d'authentification ; une seule racine dessert donc plusieurs cibles et sa suppression coûte cher à toute une cohorte. Cette campagne place le nom de la victime dans un domaine de second niveau, de sorte qu'un domaine ne dessert qu'une seule cible. La première méthode est moins coûteuse et plus fragile, la seconde plus coûteuse et plus durable. Le bureau d'enregistrement, la répartition de l'hébergement et le thème sémantique diffèrent d'une campagne à l'autre, et le rythme d'enregistrement est inverse : les domaines enregistrés par GTIG ont été opérationnels en quelques minutes, tandis que ceux-ci sont restés inactifs pendant des semaines.

Le point commun entre ces deux techniques réside dans le comportement, et non dans l'infrastructure. Toutes deux sont des attaques de vishing utilisant l'usurpation d'identité, reposent sur la capture d'identifiants par un attaquant intermédiaire, et sont documentées comme exfiltrant des données depuis les mêmes plateformes cloud d'entreprise. GTIG propose l'explication la plus simple dans ses alternatives : des acteurs distincts utilisant des plateformes de phishing standardisées et des services de phishing vocal peuvent déployer des prétextes similaires sans alignement organisationnel.

Cette comparaison étaye une affirmation plus restrictive que celle d'un opérateur partagé. Les techniques utilisées dans cet écosystème sont standardisées. Les listes de cibles, elles, ne le sont pas.

Ce que nous avons mal compris

Trois erreurs relevées dans cette enquête méritent d'être publiées, car il s'agit d'une erreur de catégorie plutôt que d'un simple faux pas, et parce que deux d'entre elles sont parvenues à leurs destinataires avant d'être détectées.

Interpréter la proximité à travers le prisme de la finalité

Deux domaines construits à partir de vocabulaire générique d'assurance sont apparus lors de la première vague de détection de noms de domaine en .claims, enregistrés simultanément quatre jours avant le premier domaine de marque. Ils correspondaient au modèle de registraire et d'hébergement. Ils ont été interprétés comme un leurre, une stratégie mise en place en amont de l'infrastructure de marque, et cette interprétation a été intégrée à toutes les notifications émises durant les trois premières semaines.

Ces noms de domaine appartiennent à un investisseur. Ce même portefeuille contient des centaines de noms de domaine couvrant les secteurs automobile, juridique et financier, répartis sur une douzaine d'extensions.

Les critères de discrimination étaient présents dans les données existantes. Les deux domaines ont obtenu un certificat sept jours après l'enregistrement, alors que chaque domaine du cluster en obtient un le jour même, et l'un d'eux proposait déjà une page descriptive. Un filtre qui les aurait exclus a été contourné par un argumentaire pertinent.

Adhésion au groupe permettant de conférer une adhésion à la campagne

Après l'identification des groupes de paires de serveurs de noms, deux domaines sont apparus dans un groupe de campagne confirmé, portant des noms de marque cibles sous des extensions sans rapport. Tous les attributs d'infrastructure correspondaient, ils ont donc été brièvement considérés comme faisant partie de l'infrastructure de la campagne, avant d'être exclus lors de l'examen, car aucun ne contenait de données relatives aux revendications et une marque sous une extension en cours d'examen représente un cas totalement différent. L'appartenance à un groupe de campagne confirmé n'implique pas que tous les éléments qui le composent fassent partie de la même opération.

En supposant qu'un énumération par échantillonnage soit complète

Une phase de collecte a consisté à parcourir une population filtrée par lots de 500 enregistrements. Comparée aux domaines déjà connus d'autres sources, cette approche a permis d'obtenir un taux de rappel de 71 % : deux des sept domaines de campagne confirmés dans la fenêtre échantillonnée n'apparaissaient dans aucune page consultée. Tout total ainsi obtenu est un minimum, et le présenter comme un total aurait été erroné d'environ un tiers.

Cartographie ATT&CK

Tableau 5. Cartographie des techniques. « Direct » indique une preuve présente dans cet ensemble de données. « Inféré » indique que la technique découle des données observées sans être directement mise en évidence par celles-ci. « Signalé » indique un compte rendu de tiers reçu par les canaux sectoriels et non confirmé par Flare. « Externe » indique des pratiques commerciales documentées et attribuées à cet écosystème dans les rapports publics, incluses par souci d'exhaustivité et non observées ici.

Jugements clés

Grande confiance

• Les 61 domaines constituent une seule et même campagne d'enregistrement coordonnée. Un bureau d'enregistrement commun, des durées d'enregistrement uniformes d'un an, un service de protection de la vie privée commun, une période d'enregistrement continue, un modèle d'hébergement commun, l'absence générale d'enregistrements de messagerie et des groupes de paires de serveurs de noms qui se chevauchent soutiennent cette initiative.
• L'infrastructure mise en place est de nature conflictuelle, et non défensive en matière de protection de marque. Les enregistrements défensifs sont conservés au nom de l'organisation par l'intermédiaire de bureaux d'enregistrement spécialisés, et ne bénéficient pas d'une protection de la vie privée auprès d'un bureau d'enregistrement à bas coût au sein d'un groupe de marques sans lien entre elles. Sur les 48 organisations notifiées, aucune n'a identifié un domaine à son nom comme étant son propre enregistrement.
• L'infrastructure associée à chaque cible est répartie sur plusieurs groupes de paires de serveurs de noms. Cette fragmentation, caractéristique d'une infrastructure compartimentée, limiterait l'impact d'une suppression de compte. Les données ne permettent pas de déterminer si cette séparation est intentionnelle, liée à des raisons opérationnelles ou fortuite.
• Cette campagne et l'activité UNC6671 documentée par GTIG ne partagent ni infrastructure ni cibles. Aucun domaine, adresse ou organisation ciblée n'est commun aux deux, parmi les 43 169 domaines et 298 organisations examinés.

Confiance modérée

• Ce groupe de sites appartient à la campagne ShinyHunters signalée par ReliaQuest. La correspondance avec la description publiée est exacte et la chronologie est cohérente. Aucun indicateur n'a été publié permettant de confirmer ce chevauchement, et aucun contenu n'a été diffusé depuis ces domaines qui pourrait être comparé aux techniques connues.
• L'enregistrement d'un domaine usurpant l'identité du fournisseur de sécurité ayant signalé l'incident est une réponse à cet avis, et non une coïncidence. Ce dépôt a eu lieu cinq jours plus tard, le groupe est connu pour ses activités de campagne, et aucun enregistrement similaire n'apparaît plus tôt dans cette période.
• L'infrastructure est conçue pour faciliter la récupération d'identifiants via un prétexte utilisé en dehors de cette infrastructure. L'absence systématique d'enregistrements de messagerie confirme que l'envoi ne provient pas de ce réseau. Trois rapports non confirmés d'appels mentionnant des domaines du cluster vont dans le même sens. Le mécanisme précis de capture repose sur des pratiques courantes et documentées au sein de l'écosystème concerné, et non sur des éléments de cet ensemble de données.

Faible confiance

• La livraison a commencé pour une partie du groupe. Cette information repose entièrement sur trois rapports de tiers que Flare n'a pas confirmés et qu'elle ne peut corroborer à partir des données d'enregistrement. Le reste de cet article n'en dépend pas, et tout lecteur qui accorde une importance différente aux informations non confirmées devrait les ignorer. (Niveau de confiance faible à modéré)
• La concentration dans les secteurs de la santé et de l'assurance reflète une priorisation sectorielle délibérée. Le déséquilibre est marqué et stable sur toute la période, mais un échantillon de 36 jours est insuffisant pour en déduire une stratégie.
• La pause de deux jours, débutant le 16 août, faisait suite à une divulgation publique. Le moment choisi est révélateur, mais la campagne avait déjà observé une pause d'une durée équivalente deux semaines auparavant, sans qu'aucun avis ne vienne justifier une telle réaction. De plus, deux jours s'inscrivent parfaitement dans la durée habituelle d'une période d'inactivité comprenant onze jours.

Recommandations pour les équipes de sécurité

• Vérifiez les quatre constructions de nommage possibles, et non celle qui a été publiée. Testez votre nom, ses abréviations courantes et son symbole boursier sous les formes [organisation], [organisation]-réclamations, réclamations-[organisation] et nous-[organisation], sur les extensions .claims et .com. Trois de ces quatre constructions ont été découvertes uniquement par des tests manuels de chaînes de caractères après le début des notifications, et la quatrième concernait quatre organisations qui n'apparaissaient sous aucune autre forme.
• Si vous en trouvez un, considérez qu'il y en a plusieurs. Sur les 48 domaines recensés, 11 étaient enregistrés sous plusieurs structures, souvent au sein de différents groupes d'infrastructure et à quelques jours d'intervalle. Aucun n'aurait pu déduire le second enregistrement du premier.
• Élargissez la formation à l'ingénierie sociale au-delà du simple support technique et intégrez-y votre propre équipe de sécurité. Les services gérant les demandes d'indemnisation, les prestations et la correspondance juridique constituent la population cible que cette appellation suggère, et ils sont rarement inclus dans les programmes de sensibilisation axés sur la réinitialisation des mots de passe. Un domaine usurpant l'identité du fournisseur ayant initialement signalé cette campagne a été enregistré cinq jours après la publication de l'avertissement, une manœuvre visant à exploiter les personnes qui viennent d'être informées de la menace.
• Instrumentez l'ensemble de la chaîne d'identité, y compris le nettoyage. La détection de l'inscription ou du remplacement d'un authentificateur immédiatement après une connexion depuis un lieu inconnu est cruciale. Les rapports publics concernant cet écosystème documentent également la suppression des courriels de notification qui en résultent ; par conséquent, le système d'alerte d'inscription seul peut échouer sans laisser de traces.
• Utilisez la transparence des certificats comme signal de provisionnement. Si vous trouvez un domaine correspondant au nom de votre organisation, surveillez l'émission de certificats supplémentaires associés. Un certificat couvrant un sous-domaine d'authentification ou légal mérite d'être examiné, même s'il n'entraîne pas automatiquement l'activation.
• Bloquez le nom, pas l'adresse. Trois domaines de cette campagne redirigeaient vers des hébergements mutualisés standardisés hébergeant plus d'un millier de noms d'hôtes sans lien entre eux. Bloquer l'adresse aurait affecté le trafic légitime sans rien empêcher.

Notification des organisations concernées avant le lancement de la campagne

Ce qui rend cette période digne d'intérêt, ce n'est pas seulement son existence, mais aussi ce qui s'y est passé. La notification a été effectuée en même temps que la collecte des données, contrairement à la procédure habituelle qui intervient après. Chacune des 48 organisations citées dans cette campagne a été alertée par l'intermédiaire de son organisme de partage d'informations sectoriel, la plupart quelques heures seulement après l'identification de leur domaine, et ce sur une période de 19 jours. Cet ordre est crucial. Habituellement, la recherche publie d'abord et notifie ensuite, ce qui laisse souvent à l'infrastructure des mois pour ne pas être signalée. Ici, les alertes ont été émises alors que la situation était encore en cours d'élaboration, car une alerte incomplète diffusée tôt vaut mieux qu'une alerte complète diffusée tard, à condition que les lacunes soient comblées au fur et à mesure de leur identification.

C'est là l'élément essentiel à retenir, au-delà du nombre de domaines et des indices de confiance. La notification a permis de diffuser et d'améliorer les résultats, car les personnes qu'elle protégeait ont contribué à l'avancement de la recherche.

L'infrastructure pourrait encore être activée. Chaque interruption précédente dans l'historique d'enregistrement de cette campagne s'est terminée sans avertissement, et les six jours de silence observés depuis le 31 août n'excluent pas la possibilité d'une septième interruption. Pour l'instant, le réseau est cartographié, les certificats sont émis et aucune notification n'a été envoyée. Les ISAC notifiés disposent des éléments nécessaires pour clore le projet, et les organisations ne figurant pas sur cette liste de cibles spécifiques ont un modèle qu'il est judicieux de comparer à leur propre marque avant qu'un tiers ne le découvre.

Méthodologie et limites

La collecte de données a utilisé des données d'enregistrement de domaines commerciaux, le DNS passif, les métadonnées des certificats et des rapports publics. Nous n'avons effectué aucune analyse active, aucun sondage de ports, aucune interaction avec l'infrastructure identifiée ni aucune récupération de contenu hébergé. Cette étude n'a nécessité aucune intervention sur les systèmes de l'opérateur.

L'énumération a débuté par un recensement du domaine de premier niveau .claims, couvrant environ 14 750 domaines enregistrés. Elle a ensuite été étendue par le biais de pivots de serveurs de noms et de tests ciblés de chaînes de caractères une fois que d'autres constructions de noms ont été identifiées. Chaque construction a été détectée en testant une chaîne candidate. La couverture actuelle doit donc être considérée comme minimale, et d'autres constructions peuvent exister sans avoir été testées.

Tous les chiffres sont à jour au 6 septembre 2026. La dernière inscription observée remonte au 31 août et le suivi n'a rien donné pendant les six jours précédant la publication ; les chiffres correspondent donc à une phase d'inscription qui semble terminée. Chaque interruption précédente de cette campagne s'est terminée sans préavis, et une reprise ne peut être exclue.

Deux des cinq certificats délivrés dans la journée suivant l'enregistrement portent une date de validité antérieure d'un jour à la date d'enregistrement enregistrée, ce qui correspond à une différence de fuseau horaire entre les deux sources et non à une délivrance antérieure à l'enregistrement.

Une phase de collecte a consisté à échantillonner une population filtrée par pagination et a atteint un taux de rappel de 71 % par rapport aux domaines connus d'autres sources. Les totaux présentés ici proviennent de l'analyse des serveurs de noms, qui est limitée et non échantillonnée ; toutefois, cette limitation d'échantillonnage s'applique à toute donnée issue d'une exportation paginée.

Deux paires de serveurs de noms initialement associées à la campagne ont été exclues après examen, car elles ont été identifiées comme appartenant à un portefeuille d'investissement de domaines sans lien avec la campagne et à une opération d'hébergement générique. Deux autres domaines appartenant à un groupe de campagne confirmé ont été exclus car ils ne contiennent aucune information sémantique relative aux revendications. Une étiquette de second niveau correspond à plusieurs organisations plausibles et a été laissée sans attribution plutôt que d'être devinée.

L'attribution à ShinyHunters découle des rapports publics présentés dans la figure 1 et n'a pas été établie indépendamment. Nous avons toutefois constaté que l'infrastructure est coordonnée et conflictuelle. Il est impossible, à partir des seules données d'enregistrement, de déterminer si elle est gérée par le groupe mentionné dans ces rapports, par une entité affiliée ou par un acteur indépendant suivant le même mode opératoire. L'analyse croisée présentée ici apporte un éclairage sur cette question uniquement en démontrant qu'une autre activité attribuée au même écosystème est distincte de celle-ci.

Aucune organisation ciblée n'est nommée dans cet article. Chacune a été notifiée individuellement par l'intermédiaire de son organisme de partage d'informations sectoriel, selon des modalités de traitement restreint. Ces notifications contiennent les domaines, les paires de serveurs de noms et les adresses spécifiques à chaque organisation. Les nommer ici fournirait à un attaquant une liste de cibles consolidée et n'apporterait rien aux défenseurs que leur organisme sectoriel ne leur ait déjà communiqué. Ce sont les chiffres agrégés qui permettent de généraliser ; les noms, non.

Nous n'avons observé aucune attaque liée à cette infrastructure. Les trois signalements d'hameçonnage vocal enregistrés ici proviennent de comptes tiers reçus via les canaux sectoriels, ne sont pas confirmés et sont identifiés comme tels à chaque fois qu'ils apparaissent. Toute organisation observant une activité liée à ces domaines, qu'il s'agisse de contenu d'hameçonnage, de textes d'appât, d'informations sur l'expéditeur ou de données de télémétrie, est invitée à la partager avec l'organisme de partage d'informations sectoriel compétent, selon les modalités qu'elle juge appropriées. Cela permettra de mieux comprendre le calendrier d'activation et le libellé de l'hameçonnage pour la communauté.