Sous-domaines oubliés : la porte d'entrée préférée des ransomwares

Chaque année, des centaines d'entreprises sont victimes d'attaques qui auraient pu être évitées si elles avaient surveillé leurs sous-domaines. Les sous-domaines oubliés sont l'un des vecteurs d'attaque les plus exploités, précisément parce qu'ils sont invisibles aux équipes de sécurité.

Pourquoi les sous-domaines sont-ils si dangereux ?

Ils héritent de la confiance de votre domaine principal

Un sous-domaine comme old-portal.company.com est perçu comme légitime par les utilisateurs, les navigateurs et les outils de sécurité. Si un attaquant le contrôle, il peut servir du contenu malveillant sous votre marque : pages de phishing, fichiers malveillants, faux portails de connexion.

Ils accumulent une dette technique invisible

Chaque sous-domaine créé il y a 3, 5, 10 ans tourne potentiellement sur un CMS ou un framework vulnérable, non patché. Personne ne pense à le mettre à jour parce que personne ne sait qu'il existe encore.

Le subdomain takeover : le cas le plus critique

Un subdomain takeover se produit quand un sous-domaine pointe vers un service cloud qui a été supprimé. L'enregistrement DNS existe toujours (CNAME vers un bucket S3, une app Heroku, un site GitHub Pages) mais le service a été supprimé. N'importe qui peut recréer ce service et réclamer le sous-domaine.

Les services les plus vulnérables au subdomain takeover

Comment les sous-domaines deviennent-ils des vecteurs de ransomware ?

Scénario 1 : Accès via sous-domaine vulnérable

1. Hacker découvre staging.company.com avec WordPress 5.8 (vulnérable à CVE-2023-2745)
2. Il exploit la vulnérabilité pour obtenir un shell PHP
3. Il pivote vers le réseau interne via la connexion VPN du serveur staging
4. Ransomware déployé sur le réseau interne

Scénario 2 : Subdomain takeover pour du phishing ciblé

1. Hacker découvre outlook.company.com pointant vers Azure (service supprimé)
2. Il réclame la ressource Azure et héberge une fausse page Outlook
3. Il envoie des emails de phishing à tous les employés : "Connectez-vous à votre messagerie"
4. Collecte des credentials Active Directory, accès réseau, déploiement ransomware

Scénario 3 : Ancien sous-domaine avec accès base de données

1. api-v1.company.com — ancienne API avec accès direct à la base de données de production
2. Aucun WAF, aucune authentification robuste
3. Injection SQL pour extraire les données, puis ransom

Comment détecter vos sous-domaines à risque ?

Méthode 1 : Certificate Transparency Logs

crt.sh/?q=%.company.com

Toutes les demandes de certificats SSL incluant votre domaine sont publiques. C'est la source la plus complète de sous-domaines.

Méthode 2 : DNS passif

Outils comme SecurityTrails, PassiveDNS ou Shodan conservent l'historique des enregistrements DNS. Ils révèlent les sous-domaines actifs et historiques.

Méthode 3 : Brute force DNS

Des outils comme subfinder, amass ou massdns testent des millions de combinaisons de noms contre votre domaine.

Méthode 4 : EASM automatisé

Un outil EASM comme Breach Atlas combine toutes ces méthodes et les exécute en continu. Dés qu'un nouveau sous-domaine est détecté ou qu'un sous-domaine existant change d'état, vous êtes alerté.

Checklist de remédiation

• Inventorier tous les sous-domaines actifs avec un outil EASM
• Identifier les sous-domaines pointant vers des services supprimés (potential takeover)
• Désactiver les sous-domaines non utilisés (suppression du CNAME)
• Mettre à jour les CMS et frameworks sur les sous-domaines actifs
• Restreindre l'accès aux environnements de staging (IP whitelist ou VPN)
• Implémenter la surveillance continue pour détecter les nouveaux sous-domaines