Elouan

Protéger et surveiller un domaine Active Directory

Les mesures les plus efficaces sur un domaine : cloisonnement des comptes d'administration, LAPS, Protected Users, signature SMB et LDAP, et les événements à surveiller.

Elouan

Série Active Directory · article 4 sur 4
  1. Active Directory : les briques d'un domaine
  2. Kerberos de bout en bout
  3. NTLM et ses faiblesses
  4. Protéger et surveiller un domaine Active Directory

Un domaine Active Directory n’est presque jamais compromis par une faille spectaculaire. Il l’est par une accumulation de petites facilités : un administrateur qui se connecte partout avec le même compte, un mot de passe local identique sur toutes les machines, un compte de service qui n’a pas changé de mot de passe depuis dix ans. Les mesures qui corrigent ça sont connues, documentées par Microsoft et par l’ANSSI, et souvent gratuites.

Le principe : contenir les identifiants

Les articles précédents ont montré une chose : dans un domaine, les identifiants sont tout. Un hash NT ou un ticket suffit à agir au nom d’un compte. La protection d’un domaine repose donc sur une idée simple : les identifiants d’un compte puissant ne doivent jamais se retrouver sur une machine moins sûre que lui.

Quand un administrateur ouvre une session interactive ou RDP sur un poste (voir les types de logon dans la série Systèmes), ses identifiants restent dans la mémoire de ce poste. Si ce poste est compromis, l’attaquant peut les récupérer. C’est la chaîne qui mène le plus souvent d’un simple poste piégé à la compromission du domaine.

Le cloisonnement des comptes d’administration

Le modèle de cloisonnement (« tiering », repris par Microsoft dans son enterprise access model) découpe le système d’information en niveaux :

NiveauContenuRègle
Niveau 0Contrôleurs de domaine, autorité de certification, systèmes qui contrôlent l’identitéAdministrés uniquement par des comptes de niveau 0, depuis des postes de niveau 0
Niveau 1Serveurs et applicationsComptes de niveau 1, jamais utilisés sur les postes
Niveau 2Postes de travail et utilisateursComptes de support dédiés

La règle d’or : un compte ne se connecte jamais sur une machine d’un niveau moins sûr que le sien. Un administrateur du domaine ne fait pas de support sur un poste utilisateur avec son compte d’administration.

S’y ajoutent deux habitudes :

  • des comptes séparés : un compte de bureautique pour les mails et le web, un compte d’administration pour administrer ;
  • des postes d’administration dédiés (PAW), sans messagerie ni navigation, depuis lesquels on administre les niveaux sensibles.

La mesure la plus efficace… et la plus contraignante

Le cloisonnement demande de changer des habitudes bien installées. C’est souvent là que se joue la résistance. Mais c’est aussi la mesure qui casse le plus de chemins d’attaque d’un coup.

Les mots de passe des comptes locaux et de service

LAPS pour les administrateurs locaux

Si toutes les machines ont le même mot de passe administrateur local, compromettre une seule machine donne accès à toutes. Windows LAPS génère un mot de passe unique pour chaque machine, le renouvelle régulièrement et le stocke dans l’annuaire, lisible seulement par les personnes autorisées.

Les comptes de service

Les comptes de service ont souvent trois défauts : des droits trop larges, un mot de passe choisi par un humain, et un mot de passe qui ne change jamais. Les remèdes :

  • utiliser des comptes de service gérés (gMSA) : le domaine génère un mot de passe long et aléatoire et le renouvelle automatiquement ;
  • à défaut, des mots de passe longs et aléatoires (plus de 25 caractères), stockés dans un coffre ;
  • réduire leurs droits au strict nécessaire, et ne jamais les mettre dans les groupes d’administration du domaine.

Les protections intégrées à Windows

MesureCe qu’elle apporte
Protected UsersPour ses membres : pas de NTLM, pas de RC4 ni de DES dans Kerberos, pas de délégation, pas de mise en cache des identifiants, TGT limités à 4 heures
Credential GuardIsole les secrets d’authentification hors de la mémoire classique de lsass.exe, grâce à la virtualisation
Protection de LSA (RunAsPPL)Fait tourner lsass.exe en processus protégé, pour bloquer l’accès à sa mémoire par les programmes non autorisés
Comptes sensibles non délégablesEmpêche la délégation Kerberos pour les comptes d’administration

Protected Users se teste avant de se généraliser

Ses restrictions cassent ce qui dépend de NTLM, de RC4 ou de la délégation. On l’applique d’abord aux comptes les plus sensibles, après des tests, et jamais aux comptes de service ou de machine.

Durcir les protocoles

Les articles sur Kerberos et NTLM ont montré où se trouvent les faiblesses. Les réglages correspondants :

  • Signature SMB obligatoire sur les serveurs et les postes ;
  • Signature LDAP et channel binding sur les contrôleurs de domaine ;
  • Désactivation de LLMNR et NBT-NS ;
  • Désactivation de NTLMv1 (et de LM), puis réduction progressive de NTLM après audit de ses usages ;
  • Abandon de RC4 au profit d’AES pour Kerberos ;
  • Nettoyage de SYSVOL : aucun mot de passe dans les scripts ou les anciennes préférences de GPO.

Réduire les privilèges

  • Vider les groupes privilégiés : les Admins du domaine ne devraient compter qu’une poignée de comptes nominatifs. Les groupes d’opérateurs (comptes, sauvegarde, serveurs) devraient être vides.
  • Revoir les délégations et les droits sur les objets : avec le temps, des droits sont accordés à des comptes ou des groupes qui n’en ont plus besoin, et certains mènent indirectement au contrôle du domaine. Des outils d’audit comme PingCastle ou les points de contrôle Active Directory du CERT-FR aident à les repérer.
  • Désactiver les comptes inutilisés et les comptes de personnes parties.

Surveiller les contrôleurs de domaine

Les événements à remonter en priorité vers un SIEM :

ÉvénementCe qu’on cherche
4728 / 4732 / 4756Ajout d’un membre à un groupe, surtout un groupe privilégié
4720Création d’un compte
4624 / 4672Ouverture de session d’un compte d’administration en dehors des postes prévus
4769Demandes de tickets de service inhabituelles (volume, chiffrement RC4)
4625 / 4771Échecs d’authentification en rafale
4776Authentifications NTLM, pour mesurer et réduire leur usage
7045Service installé sur un contrôleur de domaine
1102Journal de sécurité effacé

Un compte leurre, avec un nom attrayant et aucun usage légitime, est aussi un excellent détecteur : toute activité sur ce compte mérite une alerte.

Après une compromission

Si un attaquant a obtenu des droits d’administration du domaine, nettoyer les machines ne suffit pas. Parmi les opérations indispensables :

  • réinitialiser le mot de passe du compte krbtgt deux fois, en laissant la réplication se faire entre les deux réinitialisations (le contrôleur de domaine accepte la clé actuelle et la précédente) ;
  • réinitialiser les mots de passe des comptes privilégiés et des comptes de service ;
  • rechercher les comptes, droits et persistances ajoutés par l’attaquant ;
  • dans les cas les plus graves, envisager la reconstruction du domaine.

Ces opérations se préparent : Microsoft publie un guide de récupération de forêt, et l’ANSSI comme les CSIRT accompagnent ce type de situation.

L'essentiel

  • Le modèle de cloisonnement (tiering) sépare les comptes : ceux qui administrent les contrôleurs de domaine ne se connectent jamais sur les serveurs ou les postes ordinaires.
  • Un administrateur du domaine qui ouvre une session interactive ou RDP sur un poste laisse ses identifiants dans la mémoire de ce poste. C'est le risque principal que le cloisonnement évite.
  • LAPS donne à chaque machine un mot de passe administrateur local unique et renouvelé automatiquement.
  • Le groupe Protected Users interdit NTLM, RC4 et la délégation pour ses membres, et limite la durée de leurs tickets.
  • Comptes de service : mots de passe longs et aléatoires, ou comptes de service gérés (gMSA) dont le mot de passe est géré par le domaine.
  • Signature SMB et LDAP obligatoires, LLMNR, NBT-NS et NTLMv1 désactivés, RC4 abandonné au profit d'AES.
  • Après une compromission du domaine : réinitialisation du mot de passe de krbtgt deux fois, avec un délai de réplication entre les deux.

Idées reçues

Les administrateurs du domaine utilisent leur compte d'administration pour lire leurs mails et naviguer, par simplicité. Quel est le problème ?

L'erreur courante. Penser que c'est seulement une question de bonne pratique.

En réalité. Un mail piégé ou un site malveillant s'exécute alors avec les droits d'administrateur du domaine. Les comptes d'administration doivent être distincts des comptes de bureautique, et utilisés depuis des postes dédiés à l'administration, sans messagerie ni navigation.

Pourquoi réinitialiser le mot de passe de krbtgt deux fois ?

L'erreur courante. Dire qu'une seule fois suffit.

En réalité. Le contrôleur de domaine accepte les tickets chiffrés avec le mot de passe actuel de krbtgt et avec le précédent. Après une seule réinitialisation, l'ancienne clé reste donc valable. La seconde réinitialisation, faite après la réplication de la première, invalide définitivement les tickets forgés avec la clé compromise.

Mettre tous les administrateurs dans Protected Users, c'est sans risque ?

L'erreur courante. Répondre oui, puisque ça renforce la sécurité.

En réalité. Il faut tester avant : ses membres ne peuvent plus utiliser NTLM, ni RC4, ni la délégation, et les identifiants ne sont plus mis en cache. Un service ou une application qui en dépend cesse de fonctionner. Et il ne faut jamais y mettre les comptes de service ou de machine. On l'applique progressivement, en commençant par les comptes à hauts privilèges.

Quels événements surveiller en priorité sur les contrôleurs de domaine ?

L'erreur courante. Tout collecter sans priorité.

En réalité. Les modifications des groupes privilégiés (4728, 4732, 4756), les créations de comptes (4720), les ouvertures de session de comptes d'administration hors des postes prévus (4624, 4672), les demandes de tickets de service anormales (4769, en particulier en RC4), les échecs d'authentification en rafale (4625, 4771), les services installés sur les DC (7045) et l'effacement des journaux (1102).

Tester ses connaissances

Références

  • Active Directory (5e éd.)Brian Desmond, Joe Richards, Robbie Allen, Alistair G. Lowe-Norris · O'Reilly
  • Windows Security Monitoring : Scenarios and PatternsAndrei Miroshnichenko · Wiley

Textes de référence en ligne