Shadow IT : trouver les actifs exposés que personne
ne gère

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 plus grand. 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. Dans cet article, on définit proprement la bête, on explique pourquoi elle est dangereuse, et surtout on voit comment la traquer concrètement avec l'EASM, l'OSINT et les logs de certificate transparency. Spoiler : vous allez probablement découvrir des choses.

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 spin-up 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é.

L'ampleur du phénomène a de quoi faire pâlir. Selon Cisco, environ 80 % des employés utilisent du shadow IT, et Proofpoint estime que 97 % des applications cloud utilisées en entreprise échappent totalement au contrôle de la DSI. Côté impact, l'analyse de Bitsight recense plus de 230 millions d'expositions rien qu'aux États-Unis, soit plus de 40 % du total mondial.

Pourquoi c'est dangereux (et pas juste « pas propre »)

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 en 2025 :

• 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.

Le problème de fond ? On ne protège pas, on ne patche pas, on ne surveille pas ce qu'on ne voit pas. L'IBM Cost of a Data Breach Report 2025 estime d'ailleurs que 35 % des violations impliquent des actifs non gérés. Le shadow IT n'est pas un angle mort cosmétique : c'est l'angle mort par lequel on se fait défoncer.

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

C'est le moment du tableau qui fait mal. Quand une organisation déploie pour la première fois un outil de découverte d'assets, elle découvre en général 30 à 80 % d'actifs en plus par rapport à son inventaire documenté. 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 résume tout le drame : la majorité de votre surface d'attaque réelle vit dans des sources que la DSI ne consulte jamais. Mais que l'attaquant, lui, consulte religieusement.

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

La bonne nouvelle, c'est que les sources qui trahissent vos actifs oubliés sont publiques. La moins bonne, c'est que 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.

  own2pwn.fr (domaine racine)
        |
        v
  +----------------------------+
  |  Certificate Transparency  |  crt.sh, censys, Google CT
  |  (logs de certificats TLS) |  -> liste des sous-domaines historiques
  +----------------------------+
        |
        v
  +----------------------------+
  |  DNS / WHOIS passif        |  subfinder, amass
  |  brute-force DNS           |  -> sous-domaines actifs + IP
  +----------------------------+
        |
        v
  +----------------------------+
  |  Scan de ports / bannieres |  -> services, versions, technos
  |  Probing HTTP(S)           |     (login? S3 ouvert? VPN legacy?)
  +----------------------------+
        |
        v
  +----------------------------+
  |  Correlation CVE + triage  |  -> risque priorise
  +----------------------------+
        |
        v
   [ Patch / decommission / monitor ]

Certificate Transparency : la mine d'or oubliée

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. D'après ce guide sur les logs CT, on peut extraire près de 300 millions de hostnames uniques de plus d'un milliard d'entrées CT publiques, et environ 30 à 40 % des sous-domaines découverts ne sont liés depuis aucun site principal : autrement dit, des actifs réellement cachés. Outils côté offensif comme défensif : crt.sh, censys.io, subfinder, amass.

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 exactement 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.

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 exactement ce que propose la découverte continue d'assets de notre plateforme EASM, qui mappe en continu ce que vous exposez vraiment.

Cette logique de cartographie permanente est aussi au cœur des obligations réglementaires actuelles : on en parle en détail dans notre article pilier EASM et conformité NIS2. 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 ? On l'a 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 ? 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. 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.
• C'est dangereux parce qu'on ne patche ni ne surveille ce qu'on ne voit pas : ~35 % des violations impliquent des actifs non gérés.
• L'écart entre l'inventaire officiel et la réalité est de 30 à 80 % au 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é.

Bref : votre vrai inventaire IT n'est pas dans votre tableur. Il est dans les logs CT, le DNS passif et les APIs cloud. La seule question qui compte : qui le consultera en premier, vous ou l'attaquant ?