Le 8 septembre 2026, quelqu’un a enregistré un nom de domaine imitant le nôtre. Sept jours plus tard, il était armé pour envoyer du courrier et filtrait déjà ses visiteurs. Voici la qualification technique complète, ce que nos signalements ont obtenu, et pourquoi la cible n’était probablement pas nous.
Introduction
Une alerte tombe : le domaine hdwsec-cyber[.]com vient d’être enregistré.
Le procédé porte un nom, le typosquatting : acheter un domaine assez proche de celui d’une organisation pour qu’un humain pressé ne fasse pas la différence. Faute de frappe, caractère doublé, extension changée, ou, comme ici, ajout d’un mot crédible. Rien de plus naturel qu’une société nommée HDW Sec qui déposerait aussi “hdwsec-cyber”. C’est ce qui rend la variante efficace : elle n’a pas l’air d’une faute, elle a l’air d’une deuxième adresse.
Nous surveillons ces dépôts pour nos clients. Nous les surveillons aussi pour nous-mêmes. Ce qui suit est la qualification que nous avons produite, telle que nous l’aurions livrée à un client.
Sept jours pour armer un domaine
Le registre donne la chronologie exacte :
Domain Name : HDWSEC-CYBER.COM
Creation Date : 2026-09-08T14:00:33Z
Registry Expiry : 2027-09-08T14:00:33Z
Registrar : OpusDNS GmbH (IANA ID 4340)
Abuse contact : domain-abuse@opusdns.com
Domain Status : clientTransferProhibited
Name Server : NS-CLOUD-D1.GOOGLEDOMAINS.COM ... D4
DNSSEC : unsigned
Domaine créé le 8 septembre à 14h00 UTC. Qualification le 15 septembre à 12h39 UTC. Sept jours entre l’achat et une infrastructure complète, opérationnelle, avec messagerie signée et filtrage des visiteurs.
Enregistré pour un an, le minimum. Personne ne prévoit d’en faire une marque.
Trois détails méritent l’attention. Le statut clientTransferProhibited est un verrou contre le transfert : la personne ne veut pas se faire prendre son domaine. Les serveurs de noms sont ceux de Google Cloud DNS, pas ceux du registrar, ce qui indique une gestion DNS autonome et maîtrisée. Et le WHOIS ne livre aucune identité : coordonnées du titulaire masquées, le serveur du registrar ne répond rien.
L’infrastructure mobilise quatre prestataires distincts :
| Brique | Fournisseur | Élément constaté |
|---|---|---|
| Nom de domaine | OpusDNS GmbH (revendeur grossiste allemand) | Enregistrement, verrou de transfert |
| DNS | Google Cloud DNS | ns-cloud-d1 à d4.googledomains.com |
| Hébergement | Amazon AWS | 100.27.103.217, plage AMAZO-4 |
| Messagerie | Microsoft 365 | hdwseccyber-com01e.mail.protection.outlook.com |
Aucun outil exotique, aucune infrastructure clandestine. Quatre services grand public, une carte bancaire, une heure de travail. C’est là que réside la vraie difficulté : chacun ne voit que sa propre brique. Le registrar ignore ce qui est hébergé, l’hébergeur ignore la messagerie, Microsoft ignore qui détient le domaine. Personne n’a la vue d’ensemble, sauf vous, et c’est pour ça que le dossier de signalement doit être monté quatre fois.
Une boîte aux lettres au nom du dirigeant
C’est le champ DMARC du domaine frauduleux qui livre l’intention la plus claire :
v=DMARC1; p=reject;
rua=mailto:pierre.duteil@hdwsec-cyber.com;
ruf=mailto:pierre.duteil@hdwsec-cyber.com;
fo=0; rf=afrf; ri=604800; pct=100; sp=reject; aspf=r; adkim=r
Deux minutes pour comprendre ce qu’on regarde. Le courrier électronique a été conçu à une époque où personne n’imaginait qu’on puisse mentir sur l’expéditeur. Par défaut, n’importe qui peut envoyer un mail en se présentant comme n’importe qui. Trois mécanismes ont été ajoutés par-dessus pour corriger ça :
- SPF est la liste publique des serveurs autorisés à envoyer du courrier au nom d’un domaine.
- DKIM est une signature cryptographique apposée sur le message, qui prouve qu’il n’a pas été modifié en route.
- DMARC est la consigne qui articule les deux : il dit aux serveurs de messagerie du monde entier quoi faire d’un message qui se réclame de votre domaine sans passer les contrôles, et à quelle adresse envoyer les rapports.
Imaginez que vous déposiez un document officiel indiquant quels imprimeurs ont le droit de produire du papier à en-tête à votre nom, avec la consigne de détruire tout courrier qui n’en viendrait pas, et une adresse où envoyer le compte rendu. C’est DMARC. L’adresse de compte rendu, c’est le champ rua.
Ici, cette adresse est pierre.duteil@hdwsec-cyber.com. Le nom de notre dirigeant, sur le domaine de l’attaquant.
C’est toute l’usurpation en une ligne. Il ne s’agit pas d’une adresse recopiée par négligence : c’est une boîte aux lettres créée délibérément, au nom d’une personne réelle et identifiable, sur un domaine conçu pour passer pour le nôtre. Une adresse qui peut recevoir, puisque les MX pointent vers Microsoft 365, et émettre, puisque SPF et DKIM sont en place. Un client qui reçoit un message de pierre.duteil@hdwsec-cyber.com voit le nom de son interlocuteur habituel et un domaine plausible.
Le reste de l’enregistrement complète le tableau : deux sélecteurs DKIM actifs, selector1 et selector2, hébergés chez Microsoft. La chaîne d’émission n’est pas en projet, elle est opérationnelle.
Pourquoi un attaquant soigne son authentification
Le reste de la configuration mail du domaine frauduleux mérite un arrêt, parce qu’elle est irréprochable.
SPF v=spf1 include:spf.protection.outlook.com -all
DKIM selector1 + selector2, clés 2048 bits hébergées chez Microsoft
DMARC p=reject; sp=reject; pct=100
Traduit en clair, ce domaine annonce au monde entier : seuls les serveurs Microsoft que j’ai déclarés peuvent écrire en mon nom, rejetez tout le reste, sans exception et y compris pour les sous-domaines.
C’est contre-intuitif. On imagine volontiers l’infrastructure malveillante bâclée, montée à la va-vite entre deux portes. Celle-ci est configurée avec plus de rigueur que beaucoup de domaines d’entreprise parfaitement honnêtes.
L’explication n’a rien à voir avec la conscience professionnelle. Le premier problème d’un attaquant, c’est la délivrabilité. Un domaine créé sept jours plus tôt part avec une réputation nulle auprès des filtres anti-spam : sans authentification impeccable, ses messages tombent dans les indésirables et toute l’opération ne sert à rien. SPF strict, DKIM signé, DMARC en rejet, c’est le passeport qui fait atterrir le message dans la boîte de réception. L’attaquant n’a pas configuré sa sécurité, il a configuré sa capacité de nuisance.
Il faut en retenir la contrepartie, qui vaut pour tout le monde : la qualité de l’authentification d’un domaine ne dit rien de ses intentions. Un expéditeur qui passe SPF, DKIM et DMARC n’est pas un expéditeur légitime, c’est un expéditeur correctement configuré. Les deux ne se recouvrent pas, et c’est précisément ce qui rend ce type de domaine si efficace.
Le site n’est pas une vitrine, c’est un sas
Reste la partie web. On s’attendait à une page vide, à une page de parking publicitaire, ou à une redirection vers notre vrai site. C’est autre chose.
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-store
Content-Length: 3061
Premier fait : 200, pas 301 ni 302. Ce n’est pas une redirection. Le serveur sert son propre contenu, sous son propre domaine, avec l’adresse frauduleuse qui reste affichée dans la barre du navigateur.
Ce contenu est une fausse page de vérification anti-robot :
<meta name="robots" content="noindex, nofollow" />
<title>Security check</title>
<h1>Confirm you are human</h1>
<p>This link is protected. Complete the challenge below to continue to your destination.</p>
<form id="captcha-form" method="POST" action="/__captcha/verify">
<input type="hidden" name="r" value="0av1cO0S4cGkDkZV.kcFOlSCWSkwlZx31JJIKsKi5raVOZ6..." />
Le décor est soigné : un bouclier, une typographie sobre, le vocabulaire exact des vraies pages de protection que tout le monde a appris à cliquer sans réfléchir. Mais chaque élément technique trahit sa fonction.
noindex, nofollow demande aux moteurs de recherche d’ignorer la page. Un site légitime ne se cache pas de Google. Cache-Control: no-store interdit toute mise en cache : chaque visite doit repasser par le serveur, donc chaque visite est arbitrée en direct. Et surtout, le champ caché r change à chaque requête. Nos deux captures, à quelques secondes d’intervalle, ont reçu deux jetons différents.
Ce jeton est la clé du dispositif. Ce n’est pas une vraie protection anti-robot, c’est un aiguillage. Un sas qui décide, visiteur par visiteur, où vous envoyer : le chercheur en sécurité, le robot d’indexation ou le service anti-hameçonnage voient une page anodine, tandis que la cible identifiée par son jeton est acheminée vers la charge utile. C’est le principe des systèmes de distribution de trafic, et il explique pourquoi tant de domaines malveillants paraissent inoffensifs quand on les vérifie à la main.
Le test complémentaire est cohérent : une URL aléatoire renvoie 404 sur le domaine frauduleux comme sur le nôtre. Le dispositif imite le comportement de l’origine.
Notre qualification s’est arrêtée là : nous n’avons pas résolu le défi, donc nous ne savons pas ce qui se trouve derrière. Un faux portail de connexion, une page de paiement, un fichier à télécharger : c’est une hypothèse, pas un constat, et cette distinction compte quand les éléments doivent tenir devant un juge.
Le vrai risque : vos clients, pas vous
C’est ici que l’incident cesse d’être une anecdote d’entreprise.
Un domaine imitant le vôtre ne sert pas à vous attaquer. Vos serveurs ne sont pas touchés, vos données ne bougent pas. Vous pouvez avoir la meilleure sécurité du marché, cela ne change rigoureusement rien.
Ce domaine sert à écrire à vos clients, en votre nom, en s’appuyant sur une relation commerciale qui existe déjà. Le destinataire n’a aucune raison de se méfier : il attend effectivement des messages de votre part, et l’expéditeur porte le nom de la personne à qui il parle depuis des mois. Les scénarios sont connus et redoutablement efficaces :
- La fraude au virement. Un changement de coordonnées bancaires annoncé sur une facture en cours. Le montant part chez l’attaquant.
- La collecte d’identifiants. Un faux portail de connexion, aux couleurs de votre société, qui récolte les accès du client.
- La pièce jointe malveillante. Un rapport d’audit, un devis, un compte rendu. Venant d’un prestataire de sécurité, un document de ce type s’ouvre sans hésiter.
Et l’asymétrie est totale : c’est votre client qui perd l’argent ou se fait compromettre, et c’est votre réputation qui encaisse.
Ce qu’en dit le Panorama de la cybermenace 2025
Ce mécanisme n’a rien d’une hypothèse de laboratoire. L’ANSSI le documente dans son Panorama de la cybermenace 2025, qui recense 3 586 événements de sécurité traités sur l’année, dont 1 366 incidents portés à la connaissance de l’Agence, un volume stable par rapport à 2024.
Le rapport consacre une section entière au ciblage des sous-traitants comme vecteur de compromission. L’idée directrice : plutôt que d’attaquer frontalement une cible bien défendue, on passe par un tiers de confiance. La technique y est décrite comme éprouvée depuis au moins 2016, exploitée aussi bien par des acteurs étatiques réputés russes, chinois ou iraniens que par des cybercriminels ordinaires. L’ANSSI cite explicitement l’entreprise de service numérique locale ou spécialisée comme point d’entrée à fort effet de propagation.
L’Agence rapporte pour 2025 plusieurs cas d’attaquants ayant compromis un prestataire pour se latéraliser vers ses clients, via les interconnexions existantes et des identifiants volés. Mais une phrase décrit encore mieux ce qui nous est arrivé : l’ANSSI observe des attaques par rebond où les ressources d’une première entité servent à “forger ou utiliser des éléments crédibles permettant de mieux cibler une deuxième entité”.
C’est exactement la logique du typosquatting, à une nuance près, et elle n’est pas rassurante : dans les cas décrits par l’ANSSI, l’attaquant devait d’abord compromettre le prestataire pour lui voler de quoi paraître crédible. Ici, il n’y a eu aucune intrusion. La crédibilité s’achète chez un registrar, pour une dizaine d’euros, et elle est opérationnelle en sept jours. C’est la version discount de la même attaque, et elle ne laisse aucune trace dans les journaux de la victime dont on emprunte le nom.
Dernier chiffre utile pour situer l’enjeu : les PME, TPE et ETI restent la catégorie d’entités la plus affectée par les rançongiciels dans les incidents traités par l’ANSSI. Ce ne sont pas les organisations qui disposent d’une équipe dédiée à surveiller les dépôts de domaines.
Ce que nous avons fait
Notre réponse a suivi trois temps, dans cet ordre.
1. Figer la preuve avant d’agir. Une archive horodatée contenant les enregistrements DNS complets (SPF, DKIM, DMARC, MX), le WHOIS du domaine et de l’adresse IP, les en-têtes HTTP bruts, le corps des pages servies, et un manifeste d’empreintes SHA-256 couvrant chaque fichier. Ce manifeste est ce qui permet de démontrer plus tard que rien n’a été modifié après coup. Un signalement d’abus qui aboutit fait disparaître l’infrastructure, et avec elle tout ce qui aurait permis d’établir les faits. On documente d’abord, on fait tomber ensuite.
2. Signaler à chaque intervenant. Quatre dossiers distincts, un par prestataire : le registrar pour le domaine, Amazon pour l’instance, Microsoft pour le tenant de messagerie, Google pour la zone DNS. Chacun par son canal dédié, avec les preuves qui le concernent. Un seul signalement ne suffit pas : chaque fournisseur ne peut couper que sa propre brique, et il suffit qu’un maillon tienne pour que l’infrastructure reste debout.
3. Saisir notre avocat. Le dépôt d’un domaine reproduisant une marque et la création d’une adresse au nom d’une personne physique ouvrent des voies de droit distinctes, de la procédure extrajudiciaire de récupération de nom de domaine à la plainte pénale, sans oublier le signalement PHAROS. Cette étape conditionne la première : c’est elle qui détermine la forme que doivent prendre les preuves pour rester exploitables.
Où en est le dispositif
Neuf jours après l’enregistrement du domaine, deux jours après nos signalements, un nouveau relevé donne un résultat partiel.
Le sas web a disparu. La racine du domaine ne renvoie plus la fausse page de vérification mais un 404 au corps vide, et l’adresse IP a changé. Aucun service TLS n’écoute plus non plus.
2026-09-15 100.27.103.217 HTTP 200, page "Security check", 3061 octets
2026-09-17 107.23.27.141 HTTP 404, corps vide, TLS injoignable
C’est le seul point acquis. Tout le reste est intact :
Domaine enregistré, expiration 2027-09-08
DNS ns-cloud-d1 à d4.googledomains.com
MX hdwseccyber-com01e.mail.protection.outlook.com
SPF v=spf1 include:spf.protection.outlook.com -all
DKIM selector1 et selector2 résolvent toujours
DMARC p=reject, rua et ruf toujours sur pierre.duteil@hdwsec-cyber.com
Autrement dit : la vitrine est tombée, la capacité d’envoi ne l’est pas. Le domaine peut toujours écrire à nos clients sous l’identité de notre dirigeant et recevoir leurs réponses, et c’était depuis le début le risque principal. La date de dernière modification au registre n’a pas bougé depuis la création du domaine : le registrar n’a pas encore agi.
Il faut d’ailleurs se garder de lire cette disparition comme une victoire. Le changement d’adresse IP signifie que la zone DNS a été modifiée, donc que quelqu’un contrôle toujours le domaine et l’administre activement. Une instance suspendue laisse un enregistrement figé ; une instance déplacée signale un opérateur qui travaille.
La réponse du registrar
Le registrar nous a répondu le 17 septembre. Sa réponse mérite d’être citée, parce qu’elle est représentative :
Notre client a répondu : “Nous avons examiné le dossier et bloqué la redirection du domaine hdwsec-cyber.com. La redirection vers hdwsec.fr ne devrait plus être active.” J’espère que cela clôt votre dossier.
Deux problèmes.
D’abord, la redirection décrite n’a jamais existé sous cette forme. Notre relevé du 15 septembre montre un code 200 et une page servie sous le domaine frauduleux, pas un 3xx vers notre site. Ce qui a été bloqué est un comportement que nous n’avions pas signalé, et qui avait de toute façon cessé de lui-même deux jours plus tôt.
Ensuite, et c’est l’essentiel, rien de ce qui constitue le danger n’a été touché. Les MX pointent toujours vers Microsoft 365, le SPF autorise toujours l’émission, les sélecteurs DKIM résolvent toujours, et l’enregistrement DMARC porte toujours le nom de notre dirigeant. La date de dernière modification au registre n’a pas bougé : aucune mesure n’a été prise sur le domaine lui-même, ni suspension, ni clientHold.
Un mot enfin sur la formulation, parce qu’elle dit beaucoup. “Notre client a répondu.” Le registrar est un grossiste : il a transmis la question à son revendeur, qui l’a transmise au titulaire du domaine. La réponse proposée pour clore le dossier est donc celle de la personne visée par le signalement, reprise telle quelle. Ce n’est pas une anomalie, c’est le fonctionnement ordinaire d’une chaîne d’intermédiaires, et c’est précisément pourquoi un signalement unique ne neutralise jamais rien.
C’est la réalité de ce type de dossier, et elle mérite d’être dite sans enjoliver : un signalement aboutit rarement d’un seul coup. On obtient une brique, puis une autre, et celle qui compte le plus est souvent la plus lente à tomber. Une réponse d’abus courtoise n’est pas une neutralisation, et un dossier qu’on vous propose de clore n’est pas un dossier clos. Le nôtre reste ouvert, la surveillance aussi.
Qui, et pourquoi ?
Nous n’en savons rien, et nous nous garderons bien d’affirmer le contraire. Le WHOIS est masqué, le domaine est passé par un revendeur grossiste, l’hébergement est chez un fournisseur mondial. Aucun de ces éléments ne désigne quiconque.
Les hypothèses tiennent en une ligne : un concurrent, un opportuniste qui industrialise le dépôt de domaines de marques, une rancune, une opération d’ingérence. Aucune n’est étayée, et une société de sécurité qui accuserait publiquement sans preuve ferait exactement ce qu’elle reproche aux autres.
Ce qu’on peut dire sans se tromper, c’est que le coût d’entrée est dérisoire et que le retour potentiel ne l’est pas. Cela suffit à expliquer le phénomène sans commanditaire romanesque.
Comment s’en protéger
Il n’existe aucun moyen d’empêcher un tiers d’acheter un domaine. Tout se joue sur le délai de détection et la qualité de la réaction.
- Publier une politique DMARC stricte. C’est la mesure numéro un, et elle reste absente d’un grand nombre de domaines d’entreprise. Commencez en observation (
p=none) pour collecter les rapports, puis passez en quarantaine et en rejet. Sans elle, votre domaine est usurpable directement, sans qu’aucun faux domaine ne soit nécessaire. La vérification prend deux minutes et ne coûte rien. - Surveiller les dépôts. Les nouveaux domaines sont publiés en continu. Une veille sur les variantes de votre marque transforme une découverte fortuite, souvent faite par un client déjà piégé, en alerte de quelques heures. Ici, sept jours séparaient l’achat de l’infrastructure opérationnelle : c’est la fenêtre dont vous disposez.
- Déposer les variantes évidentes. Extensions principales, fautes de frappe courantes, préfixes et suffixes crédibles du type “-group”, “-cyber”, “-support”, “-facturation”. Quelques dizaines d’euros par an contre un scénario de fraude.
- Préparer le dossier de signalement à l’avance. Savoir qui contacter, sous quelle forme, avec quelles preuves, et sceller l’ensemble par un manifeste d’empreintes. Le jour J, on gagne des jours.
- Prévenir ses clients. La mesure la moins technique et la plus efficace. Une règle annoncée à l’avance, du type “nos coordonnées bancaires ne changent jamais par mail”, neutralise la majorité des scénarios, quel que soit le domaine utilisé.
En résumé
- Le typosquatting consiste à acheter un domaine proche du vôtre pour exploiter la confiance qu’il inspire
- Sept jours ont suffi, de l’achat du domaine à une infrastructure de messagerie signée et opérationnelle
- L’usurpation tenait en une adresse : une boîte aux lettres au nom du dirigeant, sur le domaine frauduleux
- Le domaine de fraude publiait une authentification irréprochable : SPF strict, DKIM signé, DMARC en rejet. Passer les contrôles ne prouve pas la légitimité de l’expéditeur
- Un attaquant ne soigne pas son authentification par rigueur, mais pour atterrir dans la boîte de réception
- Une page de vérification anti-robot peut être un sas de filtrage : jeton unique par visiteur, chercheurs écartés, cibles acheminées
- Quatre prestataires, quatre signalements : aucun ne voit l’ensemble du dispositif
- Figer la preuve avant de faire tomber l’infrastructure, empreintes SHA-256 à l’appui
- Deux jours après les signalements, le sas web était tombé mais la messagerie restait entière : un retrait partiel n’est pas une neutralisation
- Un registrar grossiste peut clore un dossier sur la seule réponse du titulaire visé : vérifiez toujours vous-même, au DNS, ce qui a réellement été fait
Conclusion
La sécurité d’une entreprise ne s’arrête pas au pare-feu. Elle englobe son nom, sa marque, ses domaines, tout ce qui permet à un tiers de se faire passer pour elle auprès de gens qui lui font confiance. Une surface d’attaque qui ne figure sur aucun schéma d’architecture réseau, et que presque personne ne surveille.
Nous avons détecté ce domaine parce que nous surveillons le nôtre, avec les outils que nous déployons pour nos clients. Sans cette veille, nous l’aurions découvert par un appel embarrassé de quelqu’un ayant déjà viré de l’argent.
Si vous dirigez une organisation qui a des clients, des fournisseurs et une marque identifiable, la question n’est pas de savoir si votre nom intéresse quelqu’un. Elle est de savoir combien de temps il vous faudrait pour l’apprendre.
Chez HDW Sec, nous accompagnons les entreprises sur les deux volets de ce risque : la prévention, avec la surveillance continue des dépôts de domaines et de l’usurpation de marque, la configuration de l’authentification des mails et la sensibilisation des équipes ; le traitement, avec la qualification technique, la collecte de preuves scellées, la conduite des signalements auprès des registrars et hébergeurs, et la coordination avec vos conseils juridiques.
Publié par HDW Sec - Société de cybersécurité basée à Paris.