Quatre défis de la surveillance de la sécurité Active Directory

Avec des attaquants développant constamment de nouvelles tactiques pour compromettre les identifiants et les données, il est de plus en plus important de surveiller les systèmes critiques tels que Active Directory (AD) pour détecter les signes d'activité malveillante.

De nombreuses organisations se tournent vers les produits de security information and event management (SIEM) pour obtenir de l'aide. Mais bien que ces solutions puissent être extrêmement puissantes, elles dépendent finalement des journaux d'événements Windows — qui sont compliqués à manipuler et ne fournissent pas les informations nécessaires pour surveiller plusieurs vecteurs d'attaque clés d'AD.

Ce blog explore quatre des principaux défis liés à la sécurisation d'Active Directory et explique les limites de l'utilisation des journaux d'événements pour les résoudre.

Défi 1. Surveillance des modifications d'appartenance aux groupes

Les groupes de sécurité Active Directory sont le principal moyen par lequel les utilisateurs obtiennent l'accès aux ressources informatiques, y compris les données, les machines et les applications. Lorsque les attaquants se déplacent latéralement dans votre environnement, ils ajoutent souvent les comptes qu'ils ont compromis à de nouveaux groupes de sécurité pour obtenir des privilèges supplémentaires, il est donc essentiel de suivre les modifications apportées à l'appartenance aux groupes de sécurité.

Le suivi des modifications apportées aux groupes qui fournissent un accès privilégié est particulièrement important. Cela inclut les groupes intégrés tels que les Domain Admins, les Enterprise Admins et les Schema Admins, ainsi que tous les groupes de sécurité que votre organisation a créés qui fournissent des droits d'accès élevés.

Ce que le journal des événements capture — et ses limites

Active Directory enregistre les modifications apportées aux groupes de sécurité dans le journal des événements. Par exemple, si un utilisateur est ajouté au groupe Domain Admins, AD générera un événement comme celui illustré ci-dessous, qui comprend les détails clés suivants :

• L'ID de l'utilisateur qui a effectué la modification
• Le DN et la classe de l'objet qui a été modifié
• Le type de changement (dans ce cas, qu'un membre a été ajouté)

Figure 1. Exemple d'événement montrant qu'un groupe de sécurité a été modifié

Cependant, le journal des événements présente plusieurs limitations importantes :

• · Aucun enregistrement de l'origine de la modification — Les journaux d'événements ne consignent pas la source d'une modification de l'appartenance à un groupe. Bien qu'une modification du groupe Domain Admins à partir d'un serveur de saut ou d'un contrôleur de domaine (DC) puisse être normale, une modification à partir d'un poste de travail non administratif ou d'une autre machine exposée à Internet peut être un signe révélateur d'une attaque. Sans détails sur l'origine de la modification, il est impossible de donner l'alerte pour des modifications provenant de lieux anormaux.
• · Aucune surveillance de l'appartenance effective aux groupes — Active Directory enregistre uniquement les modifications apportées à l'appartenance directe d'un groupe. Cependant, les groupes peuvent contenir d'autres groupes comme membres. Par conséquent, pour surveiller réellement les changements dans l'appartenance d'un groupe, vous devez surveiller le groupe lui-même et chaque groupe imbriqué en son sein.
• · Incohérences entre les événements — Les événements enregistrés seront différents selon la manière dont un groupe a été modifié. Par exemple, si un utilisateur est ajouté à un groupe en utilisant les interfaces de service d'annuaire Active Directory (ADSI), le journal des événements montrera un événement de suppression pour chaque membre existant du groupe, suivi par un événement qui ajoute de nouveau chaque membre du groupe, suivi par un événement ajoutant le nouvel utilisateur ; donc, ajouter un utilisateur à un groupe de 50 membres générera 101 entrées dans le journal des événements. Et si la modification a été faite en utilisant LDAP, l'identifiant unique de l'objet peut être listé au lieu de son nom distinctif. Ces incohérences peuvent causer de la confusion et de la désinformation dans les produits SIEM, et rendent extrêmement difficile la création de règles efficaces pour agir sur les données collectées.

Défi 2. Surveillance des modifications de la stratégie de groupe

Les paramètres de stratégie de groupe affectent les utilisateurs et les ordinateurs dans tout le domaine Active Directory, y compris, par exemple, qui a un accès administratif aux systèmes. Un seul changement apporté à un objet Group Policy (GPO) peut avoir de graves répercussions sur la sécurité ou provoquer des interruptions de production, donc surveiller ces changements est critique.

Ce que le journal des événements capture — et ses limites

Lorsqu'une stratégie de groupe est modifiée, un événement comme celui illustré à la Figure 2 sera enregistré. Cet événement fournit des informations utiles, telles que l'identité de la personne qui a effectué la modification et l'identifiant de l'objet de stratégie de groupe (GPO).

Figure 2. Événement enregistré pour un changement de stratégie de groupe

Cependant, ces événements manquent des informations critiques suivantes :

• · Détails de quel paramètre a été modifié et ses valeurs avant et après — Les GPOs prennent en charge des centaines de paramètres prédéfinis et personnalisés. Un changement pourrait modifier la page d'accueil du navigateur par défaut pour les utilisateurs, ou donner à tous les utilisateurs le contrôle administratif d'une machine critique. Cependant, le journal des événements ne capture pas le paramètre modifié et en quoi il a été changé.
• · Source de la modification — Comme pour les modifications apportées aux groupes de sécurité, les événements qui enregistrent les modifications de la stratégie de groupe n'indiquent pas l'origine de la modification. La plupart des modifications de GPO devraient provenir de quelques emplacements sélectionnés, et être capable d'identifier les modifications provenant d'emplacements anormaux est essentiel pour détecter rapidement les attaques.

Défi 3. Surveillance des lectures de Directory

Une autre tâche clé pour sécuriser votre Active Directory est de surveiller comment les comptes utilisateurs lisent et énumèrent les objets AD. Les attaquants cherchant à s'implanter dans votre réseau énumèrent souvent des comptes critiques, des groupes et des serveurs afin de découvrir des chemins d'attaque qui mènent à des privilèges élevés et, en fin de compte, à des données sensibles. En surveillant les événements de lecture suspects, vous pouvez détecter cette activité de reconnaissance et arrêter une attaque avant qu'il ne soit trop tard.

Ce que le journal des événements capture — et ses limites

Pour vous aider à voir qui explore Active Directory, le journal des événements capture l'activité de lecture. L'événement affiche des détails concernant le compte utilisateur, l'objet lu et le type d'opération effectuée, comme illustré dans la Figure 3 :

Figure 3. Un événement indiquant qu'une propriété des Domain Admins a été lue

Cependant, essayer d'utiliser ces événements pour surveiller les activités suspectes présente plusieurs inconvénients :

• Trop de bruit — Enregistrer les événements de lecture génère tellement de bruit dans le journal des événements qu'il est presque impossible de trouver des informations précieuses. En effet, une seule instance où un utilisateur regarde un groupe peut générer des dizaines voire des centaines d'événements dans le journal, ce qui rend presque impossible de distinguer une activité suspecte parmi tous les événements légitimes.
• Aucun enregistrement de l'origine de la lecture — De plus, il est impossible de savoir d'où provient l'événement de lecture. Comme nous l'avons vu avec les modifications apportées aux groupes de sécurité et aux GPOs, savoir de quel ordinateur provient un événement de lecture est une information cruciale pour déterminer s'il s'agit d'une lecture inoffensive ou d'un acte de reconnaissance malveillant.
• Trop d'événements d'accès refusé — Il est également essentiel de repérer les utilisateurs qui tentent d'accéder à des informations auxquelles ils n'ont pas le droit. Par exemple, Active Directory peut stocker des mots de passe en clair pour les comptes administratifs dans les attributs des ordinateurs, donc un compte utilisateur qui essaie de lire ces attributs pourrait tenter de compromettre des identifiants privilégiés. Malheureusement, chaque fois qu'un compte consulte un objet pour quelque raison que ce soit, l'action génère des événements d'échec d'accès pour tous les attributs qu'ils n'ont pas le droit de lire, même s'ils n'avaient pas l'intention de lire ces attributs. Ce n'est tout simplement pas une stratégie viable que d'essayer de trouver des événements d'accès refusé réellement suspects parmi l'océan d'événements innocents.
• Aucun moyen simple de surveiller les requêtes LDAP — Les requêtes LDAP sont couramment utilisées pour explorer Active Directory afin de découvrir des utilisateurs, des groupes et des ordinateurs. Malheureusement, Microsoft ne fournit aucun moyen simple de surveiller les requêtes LDAP pour voir la requête émise et son origine. À cause de ce problème, même l'activation de la surveillance LDAP au niveau diagnostic offre peu d'intérêt ; en fait, elle n'est pas conseillée par Microsoft, car cela générerait une quantité énorme de bruit dans les journaux d'événements.

Défi 4. Suivi des événements d'authentification

Avec la récente vague d'attaques basées sur les identifiants, surveiller les modèles d'authentification est crucial pour identifier les comptes compromis, les signes d'pass-the-hash et d'pass-the-ticket attacks, forged Kerberos tickets, ou d'autres exploits utilisés pour obtenir des privilèges et accéder à des données sensibles.

Ce que le journal des événements capture — et ses limites

Active Directory capture des événements pour surveiller l'activité de connexion et d'authentification des utilisateurs sur les contrôleurs de domaine, les serveurs membres et les postes de travail, y compris ceux énumérés dans le tableau suivant :

Bien que ces événements capturent certaines informations utiles, ils ne fournissent pas un moyen efficace de détecter les attaques basées sur l'authentification en raison des lacunes suivantes :

• Trop de bruit — Des événements sont créés chaque fois qu'un utilisateur se connecte à un ordinateur, ce qui représente généralement une quantité énorme d'activités. De nombreux autres événements sont créés en arrière-plan. Par exemple, lorsqu'un utilisateur se connecte à un serveur membre joint à un domaine AD, le serveur initie une connexion à un contrôleur de domaine qui récupère les informations de stratégie de groupe, ce qui entraîne l'apparition d'événements de connexion/déconnexion dans le journal des événements du DC. Il n'est pas possible de désactiver l'enregistrement de l'activité normale de connexion des utilisateurs sans ignorer l'activité de connexion critique à vos contrôleurs de domaine.
• Aucun enregistrement du type de connexion sur les DC — Les journaux ne suivent pas le type de connexion pour les événements de connexion sur les DC, un contexte qui est inestimable pour déterminer si les comptes sont utilisés de manière appropriée. Par exemple, il n'y a pas de moyen simple de différencier une connexion via le Bureau à distance et une connexion réseau via un lecteur réseau mappé ; vous devez collecter les journaux de chaque serveur membre et essayer de les corréler avec les journaux du DC.
• Manque de détails spécifiques au protocole — Les événements manquent également d'autres détails précieux. Par exemple, les événements d'authentification Kerberos n'enregistrent pas les horodatages de durée de vie et de renouvellement des tickets, qui sont des indicateurs précieux de tickets falsifiés utilisés dans l'exploit Golden Ticket. De même, les journaux NTLM ne précisent pas la version de NTLM qui a été utilisée, une information précieuse pour déterminer si vous pouvez désactiver les anciennes versions de NTLM au profit de protocoles plus sécurisés.

Comment Netwrix peut aider

Comme nous l'avons constaté, les journaux d'événements sont insuffisants pour détecter rapidement les attaques et y répondre efficacement. Pour une protection complète, envisagez la solution de sécurité Netwrix Active Directory. Cela vous aidera à :

• Identifiez de manière proactive les lacunes de sécurité grâce à une évaluation des risques approfondie.
• Minimisez les temps d'arrêt coûteux et les perturbations de l'activité.
• Repérez rapidement même les menaces avancées à temps et réagissez promptement.