En bref
Dans de nombreux audits internes, le chemin entre un poste utilisateur standard et l’administration du domaine ne tient pas à une vulnérabilité logicielle mais à quelques configurations héritées : identifiants en clair dans les partages et les scripts, comptes de service à mot de passe devinable, droits ACL en cascade jamais revus, protocoles d’authentification encore relayables, et sauvegardes joignables depuis le domaine. Fermer ces cinq catégories réduit l’exposition au rançongiciel plus efficacement que n’importe quel outil supplémentaire.
Pourquoi ce ne sont presque jamais des exploits
L’image du rançongiciel : définition entrant par une faille inédite est trompeuse. Dans la quasi-totalité des cas observés, l’accès initial vient d’un hameçonnage : définition réussi ou d’un identifiant valide acheté, et la suite n’est pas de l’exploitation : c’est de l’usage de fonctionnalités légitimes mal bornées.
C’est une bonne nouvelle, parce qu’une configuration se corrige sans attendre le correctif d’un éditeur. C’est aussi une mauvaise nouvelle : ces configurations sont anciennes, souvent posées par quelqu’un qui n’est plus là, et personne n’ose les toucher.
Les cinq catégories qui reviennent
- Identifiants en clair accessibles à tout utilisateur du domaine : scripts de connexion, partages, modèles de stratégie de groupe, documentation interne, dépôts de code internes. C’est un chemin à la fois court et courant.
- Comptes de service à mot de passe faible ou ancien, avec des privilèges élevés et une rotation jamais effectuée parce que « ça risque de casser la production ».
- Droits en cascade dans l’annuaire : un groupe de support qui peut réinitialiser le mot de passe d’un groupe qui administre un serveur qui détient une session d’administrateur du domaine. Chaque maillon paraît raisonnable, la chaîne ne l’est pas.
- Protocoles d’authentification héritée encore actifs, sans signature obligatoire, permettant le relais d’une authentification capturée vers un service privilégié.
- Sauvegardes joignables et modifiables depuis le domaine. Un rançongiciel qui chiffre aussi les sauvegardes transforme un incident en crise existentielle.
L’ordre de correction par effet et par effort
- 1Sortez les sauvegardes du domaine : authentification distincte, copie hors ligne ou immuable, et un test de restauration réel, mesuré plutôt que déclaré.
- 2Chassez les identifiants en clair : recherche systématique dans les partages, les scripts et les stratégies de groupe. Chaque secret trouvé est mis en rotation, pas seulement supprimé du fichier.
- 3Traitez les comptes de service : mots de passe longs et gérés, privilèges ramenés au nécessaire, et mécanismes de rotation automatique quand la plateforme le permet.
- 4Exigez la signature des protocoles d’authentification et désactivez l’authentification héritée, par vagues, en mesurant d’abord ce qui l’utilise encore.
- 5Cartographiez les droits en cascade avec un outil de graphe, puis coupez les arêtes qui mènent à l’administration du domaine, en commençant par celles qui ne servent plus.
- 6Cloisonnez les chemins d’administration : postes dédiés, comptes à privilèges distincts des comptes bureautiques, interdiction d’ouvrir une session privilégiée sur un poste utilisateur.
Mesurer plutôt que supposer
Un audit interne a un avantage sur toute liste de bonnes pratiques : il montre les chemins qui existent chez vous, dans votre annuaire, avec vos héritages. Il donne un graphe, un délai, et un ordre de correction fondé sur ce qui casse le plus de chemins pour le moins d’effort.
Deuxième effet, souvent sous-estimé : il mesure ce que votre socle de détection voit passer. Beaucoup d’organisations découvrent à cette occasion que les actions les plus bruyantes de la mission n’ont déclenché aucune alerte, ou en ont déclenché une que personne n’a lue.
Que demander à un prestataire d’audit interne ?
- Un graphe de chemins plutôt qu’une liste de constats isolés : de quel point de départ, vers quel objectif, par quelles étapes.
- Un point de départ réaliste : un compte utilisateur standard sur un poste standard, pas un administrateur du domaine fourni d’emblée.
- La distinction claire entre les chemins exploités de bout en bout et ceux qui restent théoriques.
- Le détail de ce que la détection a vu, à quelle heure, et de ce qui est resté silencieux.
- Les règles d’engagement sur les actions risquées : extraction de la base d’annuaire, modification de comptes, arrêt de services.
- Un plan de correction ordonné par nombre de chemins coupés plutôt que par gravité de chaque constat.
À retenir
- 1Le rançongiciel progresse grâce à des configurations héritées bien plus qu’à des failles inédites.
- 2Sortir les sauvegardes du domaine est le correctif au meilleur rapport effet / effort.
- 3Les identifiants en clair dans les partages et les scripts restent le chemin le plus court.
- 4Un audit interne donne un délai mesuré et un graphe, là où une liste de bonnes pratiques reste générique.
Sources citées
- Steal or Forge Kerberos Tickets: Kerberoasting (T1558.003), MITRE ATT&CK
- Unsecured Credentials (T1552), MITRE ATT&CK
- Adversary-in-the-Middle: Name Resolution Poisoning and SMB Relay (T1557.001), MITRE ATT&CK
- Inhibit System Recovery (T1490), MITRE ATT&CK
Comment ces chemins se traduisent-ils dans le référentiel MITRE ATT&CK ?
Le référentiel ATT&CK : définition du MITRE décrit les comportements observés des attaquants en tactiques et en techniques. Les catégories de cet article y ont un équivalent précis, ce qui permet de relier un constat d’audit à ce que vos outils de détection sont censés voir.