Shadow IT : 8 éditeurs en médiane par société du SBF 120, lisibles dans
son DNS

Demandez à votre DSI la liste exhaustive des actifs que votre organisation expose sur Internet. Vous recevrez un tableur, propre, rassurant, à jour de l'an dernier. Lancez ensuite une vraie découverte d'assets exposés, et préparez-vous : le chiffre réel sera toujours plus grand. Quelque part entre "tiens, on a encore ce sous-domaine ?" et "attendez, ce serveur tourne depuis 2021 ?".

Bienvenue dans le monde merveilleux du shadow IT : tout ce qui existe, tourne, écoute sur un port, et que personne ne gère. Il se traque avec des outils concrets : l'EASM, l'OSINT et les logs de certificate transparency. Et par une source qu'on oublie, alors qu'elle tient en une requête : le DNS de votre propre domaine, où une bonne part des services SaaS rattachés un jour à l'organisation ont laissé un jeton de vérification. Je l'ai lu le 6 octobre 2026 pour 704 organisations. Une société du SBF 120 y nomme 8 éditeurs en médiane, et 43 sur 119 en nomment 11 ou plus.

Le shadow IT, c'est quoi au juste ?

Le shadow IT (informatique fantôme) désigne tout matériel, logiciel ou service cloud utilisé dans une organisation sans la connaissance ni l'approbation de la DSI. Ça part rarement d'une mauvaise intention : une équipe marketing qui monte un sous-domaine pour une landing page, un dev qui déploie une API de test "juste pour deux semaines", un prestataire qui crée un bucket de stockage pour un livrable. Personne ne ferme rien. Et l'actif reste là, exposé, oublié. Sa variante récente, l'IA non autorisée en entreprise, ne laisse même pas d'actif derrière elle : la donnée part à l'usage.

Ce que le DNS de 704 organisations dit de leurs SaaS

Pour rattacher un domaine à un service en ligne, l'éditeur demande presque toujours la même preuve : publier à la racine du domaine un enregistrement TXT de la forme atlassian-domain-verification=… ou docusign=…. C'est le préalable au SSO, à la reprise des comptes ouverts avec une adresse de l'entreprise, ou à l'envoi de mails au nom du domaine. Une fois l'opération faite, il est rare qu'on retire l'enregistrement. La zone DNS devient ainsi un registre public et cumulatif des services SaaS auxquels l'organisation a été rattachée un jour.

Les distributions ne se ressemblent pas. Au SBF 120, 118 sociétés sur 119 ont au moins un jeton, la médiane est de 8 éditeurs (quartiles 5 et 13) et la plus chargée en compte 24. Dans les communes de plus de 20 000 habitants, la médiane tombe à 1, et 102 sur 488 n'en ont aucun. Universités et CHU sont entre les deux, avec une médiane de 3. La lecture la plus prudente : plus une organisation a de directions métier qui achètent leurs outils, plus son domaine a été branché sur des services différents, et plus la question "qui suit encore ce service ?" se pose souvent.

La liste ressemble à un organigramme des achats : bureautique, signature électronique, emailing, autorité de certification, outils de conception, gestion du consentement. Elle contient aussi un éditeur d'IA générative, Anthropic, à égalité avec Cisco Webex, ce qui rappelle que la vague récente emprunte le même chemin que les précédentes. Le sujet a son propre article, le shadow AI et ce que le DNS en montre.

Pourquoi c'est une affaire de shadow IT

Un jeton n'est pas du shadow IT au sens strict : pour le publier, il a fallu quelqu'un qui administre la zone DNS. Mais il en fabrique trois formes. D'abord le service oublié : un essai de 2022, un outil remplacé, un projet arrêté, dont le jeton survit et dont le compte d'organisation survit parfois aussi, avec des utilisateurs actifs que plus personne ne revoit. Ensuite la carte offerte : n'importe qui lit cette liste en une requête et sait sur quelle plateforme de signature, de tickets ou de visioconférence calquer un faux mail crédible, ce qui en fait une matière première du phishing ciblé. Enfin le bruit : au SBF 120, une société publie en médiane 5 enregistrements TXT qu'aucun motif connu n'attribue, et jusqu'à 67 pour la plus chargée. Une zone que personne ne sait relire est une zone où personne ne remarquera l'ajout suivant.

L'exercice se refait chez soi en une ligne, et chaque enregistrement mérite un propriétaire nommé :

# tous les TXT de la racine du domaine : jetons, SPF, et le reste
dig +short TXT example.fr @1.1.1.1 | sort

La mesure : une requête DNS par organisation, le 6 octobre 2026

Quatre panels figés avant la mesure à partir de sources publiques : les 119 sociétés du SBF 120 (composition Euronext du jour, dont 10 émetteurs étrangers, d'où "sociétés du SBF 120" et non "entreprises françaises"), 65 universités, 488 communes de plus de 20 000 habitants et 32 CHU et CHR. Pour chacune, le domaine de son site officiel, et une requête TXT à sa racine posée sur deux résolveurs publics (1.1.1.1 et 9.9.9.9) entre 18 h 19 et 18 h 22 UTC. On ne retient que ce que les deux voient ; aucune divergence n'a été constatée. Les enregistrements sont attribués par une liste fermée de 86 motifs d'éditeurs. L'analyse a été faite hors ligne le 7 octobre, puis relue par une contre-expertise.

Trois limites comptent. Un jeton prouve qu'un domaine a été vérifié un jour, pas qu'un service est utilisé aujourd'hui. Un éditeur vérifié par une autre méthode (courriel, fichier, sous-domaine) n'est pas vu, donc les comptes sont des minorants. Et seul le domaine du site est lu, alors que le domaine de messagerie peut différer.

Pourquoi c'est dangereux, au-delà du simple désordre

Un attaquant ne fait pas la différence entre votre fierté architecturale et le vieux WordPress que personne n'a patché depuis trois ans. Il scanne, il trouve, il rentre par le maillon faible. Et le maillon faible, c'est presque toujours un actif que vous ne saviez même pas avoir en ligne. Voici le bestiaire classique de la découverte d'assets exposés :

• Buckets de stockage mal configurés : S3, Azure Blob ou Google Cloud Storage ouverts en lecture publique. Le grand classique de la fuite de données.
• Portails d'administration exposés : sous-domaines oubliés avec une page de login, souvent sans authentification multifacteur.
• VPN et passerelles d'accès distant obsolètes : des équipements legacy toujours en ligne, avec des CVE connues et publiques.
• Frameworks web non patchés : WordPress, Drupal ou un vieux framework JS sur un site qu'on a oublié de débrancher.
• Environnements de dev et de staging : serveurs de test avec des identifiants par défaut ou faibles.
• Enregistrements DNS abandonnés : des entrées qui pointent vers une ressource décommissionnée, vulnérables au subdomain takeover.

On ne protège pas, on ne patche pas, on ne surveille pas ce qu'on ne voit pas. Une part notable des violations de données part d'un actif inconnu ou non géré, parce qu'il est resté hors du champ de la supervision.

L'écart entre l'inventaire et la réalité

Quand une organisation déploie pour la première fois un outil de découverte d'assets, elle découvre presque toujours bien plus d'actifs que ce que documente son inventaire. Et ce ne sont pas des actifs anodins : panels d'admin exposés, applications non patchées, bases de données oubliées, DNS pendants.

La colonne de droite le montre : la majorité de votre surface d'attaque réelle vit dans des sources que la DSI ne consulte jamais, et que l'attaquant consulte systématiquement.

Comment détecter le shadow IT : la méthode de l'attaquant

Les sources qui trahissent vos actifs oubliés sont publiques : tout le monde y a accès, vous comme l'adversaire. Le tout est de regarder en premier. Voici le flux de reconnaissance, du nom de domaine racine jusqu'à l'actif vulnérable.

Certificate Transparency : le registre public de vos sous-domaines

Depuis que les autorités de certification doivent journaliser publiquement chaque certificat TLS émis (avec tous les Subject Alternative Names), il existe un registre permanent et consultable de quasiment tous vos sous-domaines ayant eu un certificat, y compris ceux qu'aucune page ne lie. Outils côté offensif comme défensif : crt.sh, censys.io, subfinder, amass.

Lister les SAN d'un domaine connu n'est que le premier niveau. On peut aller bien plus loin en pivotant sur les certificats partagés (même empreinte, même organisation) pour relier des actifs inconnus, voire d'autres domaines racine, à votre périmètre : la méthode complète est détaillée dans débusquer le shadow IT par les certificats partagés.

De la découverte ponctuelle à la surveillance continue (EASM)

Faire tourner subfinder un dimanche, c'est bien. Mais le shadow IT est un flux, pas un stock : un nouveau sous-domaine apparaît chaque semaine, un certificat est émis, une instance cloud est lancée. Une photo ponctuelle est périmée le lundi matin. C'est le rôle de l'EASM (External Attack Surface Management) : un processus continu et automatisé qui découvre, inventorie et surveille vos actifs exposés, en corrélant CT, DNS, WHOIS, APIs cloud et OSINT, puis priorise les vulnérabilités. Si la discipline vous est encore floue, on la reprend de zéro dans qu'est-ce que l'EASM.

Là où le pentester fait un instantané approfondi à un instant T, l'EASM tient la carte à jour en permanence et vous alerte quand un nouvel actif douteux apparaît. Les deux sont complémentaires : l'EASM trouve la cible, le pentest confirme l'exploitabilité. C'est ce que propose la découverte continue d'assets de notre plateforme EASM, qui mappe en continu ce que vous exposez vraiment, y compris les actifs hostiles montés autour de votre marque, comme les domaines de typosquatting qui usurpent votre nom pour piéger vos utilisateurs.

Cette logique de cartographie permanente est aussi au cœur des obligations réglementaires actuelles : le lien avec l'article 21 de la directive est détaillé dans NIS2 et l'inventaire de ce que vous exposez. Et quand un actif suspect est identifié, l'étape suivante est de tester réellement son exploitabilité, via un pentest web blackbox ou un scan automatisé. La différence entre les deux approches est détaillée dans pentest vs scan de vulnérabilité.

Que faire de tout ce qu'on vient de déterrer ?

Découvrir, c'est 50 % du travail. L'autre moitié, c'est décider quoi faire de chaque actif. Une approche simple en quatre temps :

1. Attribuer : à qui appartient cet actif ? Sans propriétaire, pas de décision possible.
2. Décider : on garde (et on le met sous gestion), ou on décommissionne proprement (DNS, certificat, ressource cloud).
3. Corriger : pour ce qu'on garde, patcher les CVE, fermer les ports inutiles, activer le MFA, restreindre les buckets.
4. Surveiller : remettre l'actif dans la boucle de monitoring continu pour éviter qu'il redevienne du shadow IT dans six mois.

Le réflexe contre-productif est de tout vouloir traiter d'un coup. Priorisez par exposition réelle et criticité : un panel d'admin sans MFA et un bucket ouvert passent avant la landing page promotionnelle de 2019, et le second facteur qu'on y remettra n'est pas un détail : toutes les méthodes d'authentification multifacteur ne se valent pas face à un attaquant. La corrélation CVE permet justement de trier le bruit du danger.

À retenir

• Le shadow IT, c'est tout actif exposé que personne ne gère : sous-domaines oubliés, buckets ouverts, APIs de staging, DNS pendants.
• Le DNS est un registre public de vos SaaS : le 6 octobre 2026, une société du SBF 120 y nommait 8 éditeurs en médiane, une commune de plus de 20 000 habitants 1. Chaque jeton oublié signale un service à revoir et renseigne un attaquant.
• C'est dangereux parce qu'on ne patche ni ne surveille ce qu'on ne voit pas : une part notable des violations part d'un actif inconnu ou non géré.
• L'écart entre l'inventaire officiel et la réalité est le plus souvent large, révélé dès le premier scan de découverte d'assets.
• Les sources publiques (certificate transparency, DNS passif, scan de ports) trahissent vos actifs. Regardez-les avant l'attaquant.
• Une découverte ponctuelle ne suffit pas : le shadow IT est un flux. L'EASM en assure la cartographie continue, le pentest confirme l'exploitabilité.

Votre vrai inventaire IT est dans les logs CT, le DNS passif et les APIs cloud, plus que dans votre tableur. Reste à savoir qui le consultera en premier, vous ou l'attaquant.

Questions fréquentes