Détournement de sous-domaines via des CNAME orphelins sur services cloud abandonnés
Je vous propose cet article sur une campagne malveillante d’ampleur, nommée « Hazy Hawk » par les chercheurs, exploite des failles de configuration DNS pour compromettre des sous-domaines légitimes d’organisations réputées. Elle à été identifiée depuis fin 2023,
Ce groupe de menace détourne des sous-domaines en ciblant des enregistrements CNAME « orphelins » pointant vers des services cloud qui ont été abandonnés ou désactivés. En revendiquant ces ressources cloud désormais libres, les attaquants obtiennent le contrôle du sous-domaine visé et l’utilisent pour rediriger les utilisateurs vers des sites malveillants – le tout sous l’apparence d’un domaine de confiance.
Des entités aussi variées que le Centre pour le contrôle des maladies (CDC) américain, des organismes gouvernementaux, des universités (par ex. UC Berkeley) et de grandes entreprises telles que Deloitte, PwC ou Ernst & Young ont ainsi vu l’un de leurs sous-domaines détournés depuis décembre 2023.
Bien que la technique soit sophistiquée, l’objectif de Hazy Hawk n’est pas l’espionnage ciblé ou le vol de données sensibles. Au contraire, ces domaines détournés alimentent un écosystème de fraudes en ligne de masse et de publicités malveillantes.
Profitant de la réputation de leurs cibles, les attaquants redirigent les internautes vers un éventail d’arnaques (faux services de streaming, scareware de type faux antivirus, sites de rencontre factices, escroqueries crypto, etc.) ou les exposent à des logiciels malveillants, tout en dissimulant leur identité réelle. Cet article propose d’analyser en détail cette campagne sous deux angles complémentaires : d’une part les tactiques techniques employées (modus operandi de l’attaque DNS, infrastructures de redirection TDS, abus de notifications push…), d’autre part les enjeux stratégiques (gouvernance du DNS et hygiène numérique, impact sur la confiance des marques, détournement des services cloud, et parallèles avec des méthodes existantes comme l’opération Savvy Seahorse).
Analyse tactique : détournement technique et infrastructure malveillante
Détournement de sous-domaine via CNAME orphelin
Le vecteur principal exploité par Hazy Hawk est le détournement de sous-domaine à travers un enregistrement DNS CNAME mal configuré. En temps normal, un enregistrement CNAME sert d’alias faisant pointer un sous-domaine vers un autre nom de domaine (souvent lié à un service externe ou cloud). Par exemple, un site légitime peut configurer sousdomaine.exemple.com en CNAME vers un service cloud (sousdomaine.cloudprovider.net) pour intégrer un composant hébergé chez un fournisseur.
Dans le cas de Hazy Hawk, le scénario est le suivant :
- Création légitime – L’organisation crée un CNAME pour un besoin spécifique (application web de test, CDN, stockage, etc.), faisant pointer un de ses sous-domaines vers une ressource sur un cloud public (AWS, Azure, etc.).
- Abandon de la ressource – Plus tard, la ressource cloud est décommissionnée (ex : l’application de test est supprimée une fois le projet terminé), mais le CNAME n’est pas supprimé du DNS de l’organisation. Ce CNAME devient « orphelin » car il référence une destination qui n’existe plus.
- Prise de contrôle par l’attaquant – Un acteur malveillant, en l’occurrence Hazy Hawk, identifie cet enregistrement orphelin et enregistre à son tour une ressource auprès du même fournisseur cloud en réutilisant le nom de l’ancienne ressource cible. Ainsi, le sous-domaine de l’organisation pointe désormais vers l’infrastructure contrôlée par l’attaquant.
- Exploitation – L’attaquant peut alors déployer du contenu sur cette ressource cloud pour piéger les utilisateurs accédant au sous-domaine compromis, tout en profitant du nom de domaine légitime (et de sa bonne réputation).
Schéma – Principe d’exploitation d’un CNAME orphelin. À gauche, le sous-domaine d’une organisation (ex: ahbazuretestapp.cdc.gov) pointe vers un service cloud légitime via CNAME. Au centre, ce service est désactivé mais le CNAME n’est pas nettoyé (orphaned). À droite, l’acteur malveillant crée un nouveau service cloud au même nom et y héberge un contenu malveillant, récupérant ainsi le trafic dirigé vers le sous-domaine.
Une telle attaque de subdomain takeover est sournoise car elle ne nécessite pas de compromettre les serveurs de l’organisation ni de casser de mécanisme d’authentification – elle exploite simplement un oubli de configuration DNS. Tant que l’enregistrement orphelin reste en place, l’attaquant a la main sur le sous-domaine visé, pouvant servir tout contenu sous l’apparence d’une page officielle.
On peut noter que ce type de vulnérabilité n’est pas détectable via un simple scan standard, car il faut connaître les patterns DNS spécifiques du fournisseur cloud et disposer de données historiques (par exemple via des services passifs DNS) pour repérer qu’un CNAME pointe vers un service inexistant. En effet, contrairement aux enregistrements DNS expirés pointant vers de simples adresses IP (plus aisément détectables), les CNAME orphelins sur des clouds nécessitent souvent une recherche manuelle et une compréhension approfondie des règles de nommage du provider pour être découverts.
Redirections via TDS et abus des notifications push
Une fois le sous-domaine détourné, Hazy Hawk déploie une infrastructure de redirection en entonnoir afin de monétiser l’accès des victimes. Concrètement, le sous-domaine compromis ne présente généralement pas directement une page malveillante statique. Il héberge plutôt un ensemble de scripts et d’URLs qui vont aiguiller la victime vers divers contenus malicieux de manière dynamique. Les chercheurs ont observé que la plupart des URLs hébergées sur ces sous-domaines compromis font transiter l’internaute à travers un système de distribution de trafic (TDS) avant de le rediriger vers le site final piégé.
Un TDS est une plateforme intermédiaire souvent utilisée par les cybercriminels pour filtrer et répartir le trafic : en fonction du profil de la visite (pays, appareil, provenance, etc.), le TDS décidera de la redirection (vers une page d’escroquerie, un malware différent, ou rien du tout si le visiteur semble être un analyste/robot).
Cela permet aux opérateurs comme Hazy Hawk de cloisonner leur infrastructure et de rester furtifs – l’URL du sous-domaine légitime ne renvoie pas toujours le même contenu, rendant la détection et l’analyse plus difficiles.
Dans le cas présent, les pages servies incitent fréquemment l’utilisateur à cliquer sur “Autoriser” dans une notification de son navigateur, sous un prétexte fallacieux – par exemple, prétendument pour accéder au contenu vidéo désiré. En réalité, cliquer sur « Autoriser » abonne l’utilisateur aux notifications push émanant du site contrôlé par l’attaquant. Dès lors, les cybercriminels peuvent pousser des notifications système invasives contenant des messages d’alerte frauduleux ou des liens toxiques, même lorsque l’utilisateur n’est plus sur le site en question.
Ce mécanisme garantit un impact persistant : la victime continuera de recevoir des pop-ups trompeurs tant qu’elle ne désactive pas manuellement ces notifications malveillantes.
Une fois l’utilisateur piégé par le TDS, plusieurs scénarios d’escroquerie sont possibles en fonction de son profil. Par exemple, lors de l’analyse d’un cas lié au site du CDC, un internaute cherchant à regarder un match de football de Premier League a trouvé en haut des résultats Google un lien en apparence légitime affilié au domaine cdc.gov.
En cliquant, il a été redirigé vers une fausse page de streaming lui demandant de prouver qu’il n’est pas un robot via un CAPTCHA. Après cette “vérification”, le TDS l’a basculé vers un site d’arnaque adapté : selon son appareil et sa localisation, il pouvait s’agir d’un téléchargement de malware déguisé, d’une page l’invitant à installer un faux antivirus, d’une arnaque au support technique lui signalant (à tort) une infection et l’exhortant à appeler un prétendu support Microsoft, ou encore de sites de rencontres factices et autres scams courants. Dans certains cas observés, des liens menaient vers des vidéos pornographiques ou des annonces louches sur des événements sportifs populaires – tout un leurre “actualité/bruit” destiné à attirer un large public vers ces sous-domaines détournés. L’exemple ci-dessous illustre l’un des schémas constatés : une fausse alerte de sécurité Windows s’affiche et une notification push “McAfee” surgit sur le poste de la victime, l’incitant à cliquer pour soi-disant sécuriser sa machine.
Techniquement, Hazy Hawk abuse de la confiance associée aux domaines parents compromis. Les contenus malveillants étant servis sous un domaine légitime (par ex. *.cdc.gov), ils bénéficient d’un référencement privilégié sur les moteurs de recherche et d’un a priori de fiabilité aux yeux du public.
Il n’est pas rare que ces pages factices apparaissent en tête des résultats Google, trompant ainsi de nombreux utilisateurs qui pensent accéder à une ressource sûre alors qu’ils sont redirigés vers une escroquerie. De plus, l’utilisation d’un domaine institutionnel peut contourner certaines mesures de sécurité : par exemple, un filtre proxy d’entreprise autorisera volontiers le domaine cdc.gov (considéré comme safe), laissant passer le trafic vers le sous-domaine compromis. L’attaquant tire donc profit de la réputation du nom de domaine pour maximiser l’efficacité de son arnaque.
Enfin, bien qu’Hazy Hawk s’en tienne jusqu’ici à des finalités opportunistes (fraude financière, installation de adware/malware, génération de clics publicitaires frauduleux, etc.), il convient de noter que d’autres abus sont rendus possibles par ce type de compromission DNS.
Une fois qu’un acteur possède un sous-domaine d’une organisation, il pourrait par exemple héberger une page de phishing plus ciblée en se faisant passer pour le site officiel, ou exploiter le sous-domaine pour charger du code malveillant sur des pages légitimes du domaine principal (si des liens internes y font référence).
Il pourrait aussi tenter d’obtenir un certificat TLS pour le sous-domaine détourné (via Let’s Encrypt par exemple) afin de rendre l’arnaque encore plus crédible, voire configurer des enregistrements MX/SPF pour envoyer des e-mails frauduleux depuis ce sous-domaine.
En somme, la surface d’attaque offerte par un sous-domaine abandonné est large, et Hazy Hawk a choisi de l’exploiter dans le but de monétiser du trafic via des arnaques grand public.
Analyse stratégique : implications et tendances
Failles de gouvernance DNS et hygiène numérique
La campagne Hazy Hawk met en lumière un problème de gouvernance DNS et d’hygiène numérique au sein des organisations. Le fait que des institutions aussi en vue que le CDC ou de grandes entreprises aient laissé subsister des CNAME orphelins indique que la gestion des enregistrements DNS n’est pas toujours rigoureusement intégrée au cycle de vie des projets IT.
Souvent, la création d’un sous-domaine pour un projet cloud est facile et rapide, mais sa suppression une fois le projet terminé est négligée.
Cette « dette technique DNS » peut rester inaperçue pendant des années, jusqu’à ce qu’un acteur malintentionné la découvre. Infoblox souligne que ces attaques par « sous-domaines en déshérence » étaient jusque-là évoquées surtout théoriquement ou à travers de rares exemples isolés, mais Hazy Hawk démontre qu’elles sont désormais réalisées de manière systématique par des attaquants persistants.
En effet, le groupe a su trouver et exploiter en quelques mois un grand nombre de sous-domaines vulnérables à travers le monde, suggérant que cette faille de configuration est plus répandue qu’on ne le pense.
Il en résulte un besoin pressant d’améliorer l’hygiène DNS dans les entreprises et administrations. Cela passe par des processus de gouvernance clairs : tenue à jour d’un inventaire des zones DNS, audits réguliers pour détecter les enregistrements pointant vers des ressources externes inactives, et suppression immédiate de tout enregistrement obsolète.
Cette responsabilité incombe en premier lieu aux équipes en charge du DNS et du cloud au sein de l’organisation. À défaut, des acteurs tiers (par ex. un CERT national ou un fournisseur DNS) pourraient aider à identifier de tels enregistrements orphelins à grande échelle – à l’instar d’une étude menée en 2024 qui estimait à plus d’1 million le nombre de domaines potentiellement vulnérables à des détournements DNS liés à des configurations bancales.
Il convient de souligner que ces faiblesses ne sont généralement pas des failles logicielles intrinsèques (donc pas de CVE attitré), mais bien des erreurs de configuration et de suivi : la prévention passe donc par la rigueur opérationnelle et non par un correctif technique classique.
Impact sur la confiance, la marque et les usagers
Les détournements de sous-domaines tels que ceux orchestrés par Hazy Hawk posent un sérieux problème de confiance numérique. Du point de vue de l’utilisateur lambda, voir une institution de santé publique comme le CDC ou une grande entreprise servir des contenus douteux (malgré elle) est déstabilisant.
Dans le pire des cas, cela peut écorner l’image de marque de l’entité victime : les usagers trompés peuvent lui en tenir rigueur, pensant qu’elle a été directement compromise ou qu’elle cautionne ces messages.
Pour les organisations gouvernementales notamment, l’exploitation de leur domaine dans des arnaques (par exemple afficher du contenu pornographique ou de fausses cagnottes de dons sur un sous-domaine officiel) peut entraîner un préjudice réputationnel et une perte de crédibilité.
Par ailleurs, ces incidents soulignent la difficulté à maintenir la confiance dans l’écosystème global des noms de domaine. Les utilisateurs sont formés à repérer les URL suspectes, mais ici l’URL semble authentique.
Cela complique la tâche de sensibilisation : faut-il désormais se méfier même des bonnes adresses si le sous-domaine est inconnu ? Dans un contexte où le grand public commence à peine à adopter des réflexes de cybersécurité, ce genre d’abus brouille les repères.
Il renforce aussi l’idée qu’une approche “Zero Trust” s’applique aussi à la navigation web : faire confiance aveuglément à un domaine de renom n’est plus toujours sûr.
Enfin, on peut imaginer des conséquences juridiques et financières. Si des tiers subissent un dommage suite à une attaque facilitée par un sous-domaine abandonné (par exemple un malware qui infecte leur système), ils pourraient se retourner contre l’organisation propriétaire du domaine pour négligence.
De même, les autorités de protection des données pourraient considérer qu’un tel laxisme mettant en danger les utilisateurs relève d’un manquement (même si les données personnelles ne sont pas directement impliquées). Ainsi, la gestion du risque DNS devrait être intégrée dans la politique de sécurité des organisations, au même titre que la gestion des vulnérabilités applicatives.
Détournement des services cloud et responsabilités partagées
L’exploitation des CNAME orphelins met également en exergue le détournement de services cloud légitimes à des fins malveillantes. Les attaquants profitent du modèle de ces plateformes cloud (AWS, Azure, etc.) où les noms de ressource sont en libre enregistrement une fois qu’ils sont disponibles. Lorsque l’organisation oublie de retirer son CNAME, le fournisseur cloud n’a pas connaissance de ce lien résiduel – il supprime simplement l’ancienne instance (libérant le nom). Un tiers peut alors réclamer ce nom sans obstacle.
Cela pose la question d’une éventuelle responsabilité partagée : si les clients cloud doivent faire le ménage dans leurs DNS, pourrait-on envisager que les providers implémentent des garde-fous ? Par exemple, certains fournisseurs requièrent une validation de domaine (via un token DNS) pour lier un nom de domaine custom à un service cloud – ce qui pourrait empêcher un autre client de revendiquer ce nom tant que le token existe.
Toutefois, dans le cas de Hazy Hawk, la plupart des sous-domaines détournaient non pas un domaine custom mais un sous-domaine du fournisseur (ex: *.azurewebsites.net). Ces sous-domaines étant la propriété du cloud provider, il est normal qu’ils soient réattribuables librement. La seule parade est donc côté client : ne pas laisser de référence vers un service qu’on n’utilise plus.
Cet abus des ressources cloud souligne par ailleurs le détournement de la philosophie “cloud agile” : la facilité avec laquelle on peut allouer et libérer des ressources fait le bonheur des équipes DevOps, mais ici ce sont des criminels qui en tirent parti pour recycler des domaines abandonnés. Il s’agit d’un rappel que la sécurité dans le cloud est un modèle de responsabilité partagée – le fournisseur sécurise l’infrastructure, mais l’usager doit sécuriser sa configuration. Un enregistrement DNS orphelin est l’équivalent d’une porte laissée ouverte : ce n’est ni la faute de l’hébergeur, ni un bug logiciel, c’est un oubli du propriétaire.
Il est donc crucial que les RSSI intègrent des contrôles spécifiques lors des processus de migration ou de décommissionnement de services : checklists de fermeture incluant la suppression des entrées DNS associées, scans périodiques des enregistrements dangling, etc.
Tactiques similaires et précédents connus (Savvy Seahorse et al.)
La campagne Hazy Hawk n’émerge pas de nulle part : elle s’inscrit dans une tendance plus large d’exploitation créative du DNS par les cybercriminels. Déjà en 2024, un acteur surnommé Savvy Seahorse avait fait parler de lui en détournant à son avantage le fonctionnement des CNAME DNS, selon un rapport d’Infoblox.
Contrairement à Hazy Hawk, Savvy Seahorse ne ciblait pas des enregistrements orphelins, mais utilisait astucieusement des CNAME pour bâtir une infrastructure résiliente de type TDS au service d’arnaques aux faux investissements. Concrètement, ce groupe créait des milliers de sous-domaines éphémères générés algorithmiquement, tous mappés via des CNAME vers un unique domaine de base contrôlé par l’attaquant.
Si un de ces noms était bloqué ou supprimé, il lui suffisait d’en générer un nouveau pointant vers le même canonique, rendant la campagne très agile – le TDS pouvait continuellement ajouter ou retirer des noms sans changer de serveur final. Cette technique a permis à Savvy Seahorse d’échapper aux mesures de takedown pendant des mois, tout en ne laissant qu’un point faible du côté des défenseurs : le domaine de base commun à tous les CNAME (qu’il suffisait théoriquement de bloquer pour neutraliser l’ensemble de l’opération).
Si la finalité diffère (Savvy Seahorse visait des internautes via de faux sites de trading et des pubs Facebook, quand Hazy Hawk vise le référencement naturel sur des domaines d’institutions), on retrouve un schéma commun : tirer profit du DNS non pas en le compromettant frontalement, mais en utilisant ses mécanismes légitimes (CNAME, délégations, etc.) de manière astucieuse pour servir des attaques. Infoblox recense d’ailleurs plusieurs autres groupes à thématique animale (Viper, Lizard, etc.) qui explorent ces vecteurs.
Par exemple, la tactique dite des “Sitting Ducks” (les « canards statiques ») consiste à détourner carrément le serveur NS d’un domaine mal configuré (lors d’une délégation incomplète, dite lame delegation) afin de prendre le contrôle total de la zone DNS.
Un groupe nommé Hasty Hawk a exploité ce type de faille depuis 2022 pour détourner plus de 200 domaines et les utiliser dans des campagnes de phishing (ex. usurpation de pages DHL ou de fausses collectes de dons). On le voit, les cybercriminels innovent en permanence sur ces attaques « à bas bruit » exploitant des configurations faibles du DNS, un domaine jadis réservé aux attaques étatiques (DNS hijacking classique) mais désormais largement adopté par le cybercrime opportuniste.
Croissance du vecteur et inaction courante des entreprises
Il est frappant de constater que, malgré la documentation croissante de ces vecteurs d’attaque DNS, l’inaction demeure fréquente du côté des entreprises concernées. Combien de CNAME orphelins subsistent aujourd’hui sur les DNS d’organisations publiques ou privées ?
Probablement des milliers. Souvent, ce n’est qu’après une attaque ou un signalement externe que l’existence de l’enregistrement oublié est révélée et que des mesures sont prises (par exemple, la suppression du CNAME ou la récupération du contrôle via le provider cloud). Entre-temps, l’attaquant a pu exploiter le sous-domaine pendant des semaines ou des mois.
Plusieurs facteurs expliquent cette inertie : un manque de visibilité sur l’infrastructure DNS totale (surtout dans les grands groupes où les DNS sont gérés par différentes équipes ou prestataires), la priorité donnée à d’autres urgences de sécurité plus médiatisées (patching de failles critiques, réponse aux incidents classiques) au détriment de risques perçus comme théoriques, ou simplement la sous-estimation de l’impact potentiel (« ce n’est qu’un ancien sous-domaine de test, personne n’ira dessus… »).
Hazy Hawk vient précisément démontrer le contraire : même un obscur sous-domaine peut devenir la porte d’entrée vers des milliers d’utilisateurs si un acteur malveillant s’en empare et y implante du contenu frauduleux bien référencé.
Du côté des attaquants, on observe au contraire une montée en puissance de ce vecteur. Les succès de campagnes comme Hazy Hawk risquent d’inciter d’autres groupes cybercriminels à explorer leurs propres variantes.
D’une part, la barrière technique à l’entrée – bien que réelle en termes de savoir-faire DNS – finit par s’abaisser à mesure que des outils automatisés et des listes de ressources cloud disponibles circulent dans les cercles underground. D’autre part, le rendement est au rendez-vous : la monétisation via les arnaques au faux support, aux cryptos ou autres peut s’avérer très lucrative, sans nécessiter le niveau d’organisation d’une opération de ransomware, par exemple.
Ces attaques restent relativement discrètes : elles visent le grand public, causant moins de remous médiatiques qu’une fuite de données ou qu’un site officiel complètement défacé, ce qui peut conduire les victimes (organisations) à traiter cela en interne sans grande communication – et donc sans alerter outre mesure d’autres cibles potentielles.
Il est donc à prévoir que le phénomène des sous-domaines fantômes détournés continuera de s’amplifier si aucune action concertée n’est menée pour y remédier. Les organisations doivent sortir de leur attentisme et considérer sérieusement ce risque, faute de quoi elles pourraient alimenter involontairement, et durablement, l’arsenal des cyber-fraudeurs.
Recommandations pratiques pour les CERT, RSSI et équipes SOC
Face à la menace représentée par Hazy Hawk et les techniques analogues, les professionnels de la sécurité (CERT, RSSI, équipes SOC) peuvent adopter plusieurs mesures proactives pour protéger leur organisation ou leur périmètre de vigilance :
- Audit régulier des enregistrements DNS : Inventoriez périodiquement vos zones DNS à la recherche d’enregistrements orphelins. Portez une attention particulière aux CNAME pointant vers des services tiers (cloud, CDN, SaaS…) et vérifiez que chaque ressource référencée est toujours active et légitime. Des outils dédiés ou des scripts (par ex. un script PowerShell publié par Microsoft) peuvent aider à détecter ces enregistrements « dangling » automatiquement.
- Hygiène DNS dans le cycle de vie des projets : Intégrez la gestion du DNS dans vos procédures de décommissionnement. Lorsqu’un service cloud est interrompu, assurez-vous que tous les alias DNS associés sont supprimés sans délai. N’attendez pas qu’un tiers vous signale une entrée fantôme. Cette discipline doit être formalisée dans les politiques internes et contrôlée via des revues post-projet.
- Surveillance des sous-domaines et du trafic : Mettez en place des alertes ou des indicateurs pour détecter une activité inhabituelle sur des sous-domaines peu utilisés. Par exemple, un pic de requêtes DNS ou de trafic web soudain sur un sous-domaine historiquement inactif peut révéler une exploitation malveillante en cours. De même, surveillez l’apparition de pages indexées sur vos domaines qui ne devraient pas l’être (via des services de veille internet, Google Alerts, etc.).
- Protection au niveau DNS et filtrage : Envisagez l’usage de solutions de DNS Security/Protective DNS pour votre organisation, capables de bloquer la résolution de domaines/subdomains malveillants connus. Des fournisseurs offrent des flux de menace DNS incluant les domaines hébergeant des TDS ou des campagnes actives. Cela peut stopper l’accès aux sites d’escroquerie même si un de vos sous-domaines était compromis sans que vous le sachiez immédiatement.
- Coordination avec les fournisseurs cloud : Si vous découvrez un enregistrement orphelin pointant vers un service cloud abandonné, deux actions sont possibles : (1) le supprimer de votre DNS, évidemment ; (2) contacter le fournisseur cloud pour signaler l’usage abusif de sa plateforme par un tiers ou reprendre vous-même le contrôle de la ressource (en la recréant à votre nom si c’est possible, afin de neutraliser l’attaquant). Une bonne collaboration avec les cloud providers peut accélérer la détection et la fermeture de ces abus.
- Sensibilisation des usagers finaux : Conseillez aux utilisateurs de faire preuve de prudence même face à des domaines familiers. Notamment, recommandez de ne jamais accepter à la légère des notifications push provenant de sites non explicitement sollicités. Dans le cas de Hazy Hawk, refuser l’autorisation de notification stoppe l’une des principales méthodes d’exploitation (les pop-ups persistantes). De manière générale, encouragez les bonnes pratiques de vérification (ex : si un sous-domaine inhabituel d’un site officiel propose un téléchargement logiciel ou demande des informations personnelles, il y a lieu de douter et de contacter l’organisation via ses canaux officiels).
- Partager l’information et les IOCs : En tant que CERT ou équipe SOC, n’hésitez pas à partager les indicateurs de compromission (IOCs) liés à ce type de campagne avec la communauté. Les rapports d’Infoblox et autres ont listé des domaines compromis ; diffusez ces données aux entités concernées et au sein des cellules de veille. Une prise de conscience collective peut inciter plus d’organisations à faire le ménage dans leurs DNS proactivement.
- Réagir vite en cas de détection : Si malgré toutes les précautions, vous constatez (ou on vous signale) qu’un de vos sous-domaines a été détourné, traitez l’incident avec sérieux. Supprimez ou corrigez l’enregistrement DNS fautif sans attendre, puis investiguez l’éventuel impact (ex : des utilisateurs ont-ils été exposés à des malwares ? Vos systèmes internes ont-ils communiqué avec ce sous-domaine piégé, ce qui pourrait indiquer une tentative d’intrusion latérale via des cookies volés ou autre ?). Profitez-en pour passer en revue l’ensemble de vos enregistrements DNS externes, afin d’éviter d’autres mauvaises surprises.
En conclusion, la campagne Hazy Hawk rappelle vigoureusement que la sécurité du DNS – souvent perçue comme un acquis intangible – doit faire l’objet d’une vigilance continue. Un simple enregistrement oublié peut servir de tremplin à des attaques insidieuses touchant des milliers d’internautes et ternissant l’image d’organisations respectées. Pour les professionnels de la cybersécurité (CERT, RSSI, analystes SOC), il s’agit d’un domaine à (re)mettre en haut de la pile des priorités : qu’il s’agisse de former les équipes à une gouvernance DNS rigoureuse, d’outiller la surveillance des configurations, ou d’élaborer des contre-mesures au niveau du réseau, chaque effort contribuera à réduire la surface exploitable par ces nouveaux prédateurs du DNS.
Comme le souligne certain expert, « pour déjouer des acteurs comme Hazy Hawk, les organisations doivent implémenter une gestion DNS robuste – audits réguliers et suppression rapide des entrées liées à des services cloud discontinués ».
En redoublant de prudence et de proactivité sur ce front, les défenseurs que nous sommes peuvent reprendre l’avantage et empêcher que des « sous-domaines fantômes » ne continuent de hanter impunément le cyberespace.
Enjoy !
🔗 Sources et lectures complémentaires
- Infoblox Threat Intelligence – Rapport sur Hazy Hawk (2025) https://blogs.infoblox.com/cyber-threat-intelligence/hazy-hawk-exploits-dns-misconfigurations-to-hijack-trusted-subdomains/
- The Hacker News – « Hazy Hawk Abuses DNS CNAME Records for Subdomain Hijacking » (20 mai 2025) https://thehackernews.com/2025/05/hazy-hawk-abuses-dns-cname-records-for.html
- Bleeping Computer – « Hazy Hawk gang exploits DNS misconfigs to hijack trusted domains » (20 mai 2025) https://www.bleepingcomputer.com/news/security/hazy-hawk-gang-exploits-dns-misconfigs-to-hijack-trusted-domains/
- DarkReading – « Savvy Seahorse and the Rise of DNS-based Traffic Distribution » (2024) https://www.darkreading.com/threat-intelligence/savvy-seahorse-dns-tds-abuse-explained
- Microsoft Security Blog – « How to detect dangling DNS entries in Azure » https://techcommunity.microsoft.com/t5/azure-security-center/detecting-dangling-dns-entries-in-azure/ba-p/1309888
- CERT.be – « DNS Hygiene for Organizations: Preventing Domain Hijacking » https://www.cert.be/en/dns-hygiene-best-practices
- Mozilla Security Blog – « Push Notification Abuse and User Consent Fatigue » https://blog.mozilla.org/en/internet-culture/push-notifications-privacy-consent-abuse/
- OWASP Foundation – « Subdomain Takeover Cheat Sheet » https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Cheat_Sheet.html
- GitHub – Liste communautaire des services vulnérables aux CNAME orphelins (dangling DNS) https://github.com/EdOverflow/can-i-take-over-xyz
- US-CERT / CISA – « Managing DNS Records Securely » https://www.cisa.gov/resources-tools/resources/securing-domain-name-system-dns
