10 méthodes pour identifier et protéger les utilisateurs AD Privileged

Compromettre des comptes privilégiés est l'avant-dernier objectif de la plupart des cyberattaques — une fois que les attaquants obtiennent un accès privilégié, ils peuvent alors accomplir leur but final, qu'il s'agisse de voler ou de chiffrer des actifs d'information ou de perturber les opérations commerciales. Typiquement, les cybercriminels s'implantent dans un réseau en compromettant un compte de faible niveau sur une machine locale. En utilisant une variété de techniques, ils tentent ensuite de prendre le contrôle des comptes plus privilégiés dont ils ont besoin pour accéder aux données sensibles et aux systèmes de l'organisation. Dans les environnements Active Directory (AD), le véritable prix est un compte d'Administrateur de Domaine, mais souvent, n'importe quel compte privilégié suffira.

Éléments clés de Privileged Access Management

Un attaquant avec un accès privilégié peut se déplacer assez librement à travers votre AD domain et accéder à vos ressources informatiques les plus précieuses. Par conséquent, pour maintenir la sécurité et la conformité, il est impératif d'établir une gouvernance d'identité forte et une gestion des accès sur tous les comptes privilégiés dans votre environnement AD.

Plus précisément, garantir la sécurité de vos systèmes et de vos données implique deux composants clés :

• Identifier quels utilisateurs ont quels privilèges pour quels actifs informatiques
• Détection lorsqu'un compte obtient un accès Privileged Access Management pour la première fois

Il est essentiel de comprendre que le Privileged Access Management n'est pas un effort ponctuel. À mesure que les utilisateurs sont intégrés et changent de rôles et que l'environnement informatique évolue, les droits et les adhésions aux groupes changent, et les équipes de sécurité doivent détecter tout changement qui pourrait être malveillant ou autrement inapproprié.

Ci-dessous se trouvent les 10 meilleures méthodes que vous pouvez utiliser pour protéger vos comptes d'utilisateurs privilégiés contre les compromissions. Elles font partie d'une stratégie de sécurité complète pour empêcher les utilisateurs non autorisés d'obtenir un accès privilégié à AD.

1.Gérez étroitement les groupes privilégiés intégrés comme les Domain Admins.

Les groupes privilégiés intégrés à AD tels que les Administrateurs, les Domain Admins, les Enterprise Admins et les Schema Admins sont un point de départ évident. Ensuite, il y a le groupe des Administrateurs locaux sur chacun de vos points de terminaison Windows, qui fournissent un accès privilégié à ces systèmes.

Identifier les membres de chacun de ces groupes est aussi simple que de consulter l'onglet Propriété des membres du groupe dans Utilisateurs et ordinateurs Active Directory (ADUC). Une autre méthode consiste à utiliser le cmdlet PowerShell Get-ADGroupMember, comme illustré dans la capture d'écran ci-dessous. C'est la méthode préférée lorsque vous devez analyser plusieurs groupes rapidement.

Gardez à l'esprit que les revues périodiques des membres du groupe offrent un aperçu de l'état du groupe à ce moment précis seulement. Néanmoins, c'est un bon point de départ.

2. Vérifiez la présence de groupes imbriqués à l'intérieur des groupes privilégiés.

Il est essentiel de vérifier si les groupes privilégiés ont des groupes comme membres, car ces groupes imbriqués accordent à leurs membres tous les droits d'accès du groupe privilégié. Par exemple, dans la capture d'écran ci-dessous, vous pouvez voir qu'un des membres du groupe Domain Admins est un groupe appelé LabPowerUsers — ce qui signifie que tout membre du groupe LabPowerUsers dispose de privilèges administratifs sur l'ensemble du domaine.

Il faut, dans la mesure du possible, éviter l'imbrication de groupes, en particulier au sein des groupes privilégiés, car cela offre aux attaquants un moyen d'accéder aux ressources critiques et aux données avec moins de risques de déclencher des alarmes — ils ajoutent un compte qu'ils contrôlent à un groupe imbriqué, plutôt que directement au groupe privilégié parent, qui peut être plus étroitement surveillé.

Comme montré précédemment, la cmdlet Get-ADGroupMember révèle uniquement les membres immédiats du groupe interrogé, donc elle listera tous les groupes imbriqués mais pas leurs membres. Une manière de montrer également les membres de tous les groupes imbriqués est d'utiliser le filtre LDAP indiqué en rouge ci-dessous :

      param([string]$groupDn )
$s = new-object system.directoryservices.directorysearcher
$s.searchroot = new-object system.directoryservices.directoryentry
$s.filter = “(&(memberOf:1.2.840.113556.1.4.1941:=$groupDn))”
$s.propertiestoload.add(“name”)
$s.propertiestoload.add(“objectclass”)
$r = $s.FindAll()
foreach ($e in $r)
{Write-Host
$e.Properties.objectclass[$e.Properties.objectclass.Count-1]:
$e.properties.name
      

Si ce code est enregistré sous forme de script (.GetNestedMembers.ps1), il peut être exécuté comme suit, en spécifiant le Nom Distinctif du groupe souhaité :

      .GetNestedMembers.ps1 -groupDn “CN=Administrators,CN=Builtin,DC=lab,DC=local”
      

La sortie affiche le nom du groupe et énumère ses membres :

      group : Domain Admins
user : bosshogg
user : azuresync
user : Barry Vista
user : Randy Smith
user : AdminService
      

Pour obtenir rapidement une visibilité sur les privilèges élevés sans tous les tracas et les dépenses de script, de nombreuses organisations choisissent d'investir dans un outil de Privileged Access Management (PAM) tiers tel que la Netwrix PAM solution.

3. Faites attention aux permissions des unités organisationnelles (OU).

En plus d'obtenir des privilèges par l'appartenance à un groupe, les utilisateurs peuvent se voir déléguer le contrôle au niveau de l'unité organisationnelle. La capture d'écran ci-dessous montre un groupe se voyant déléguer des privilèges à l'OU des ventes ; chaque membre de ce groupe sera capable d'accomplir les tâches sélectionnées, y compris la modification de l'appartenance de tout groupe dans l'OU des ventes.

Suivre les permissions des unités d'organisation (OU) est compliqué à cause de l'héritage. Comme dans la sécurité NTFS, les permissions des OU parents se propagent aux OU enfants et aux objets feuilles. Cela peut entraîner un grand nombre d'utilisateurs ayant des privilèges élevés qui sont difficiles à découvrir, comme illustré dans la capture d'écran suivante qui montre toutes les OU enfants et objets feuilles de l'OU Sales :

Bien que vous puissiez rompre l'héritage d'une unité d'organisation parente, cela peut causer des problèmes, tels que des responsables incapables de gérer les objets dont ils sont responsables.

Pour générer des événements d'audit chaque fois qu'un objet d'annuaire est accédé, vous pouvez utiliser la stratégie de groupe AD Group Policy. Allez dans Configuration de l'ordinateur > Paramètres Windows > Paramètres de sécurité > Configuration de la stratégie d'audit avancée > Stratégies d'audit > Accès DS et configurez Audit des modifications du service d'annuaire comme indiqué ci-dessous.

Gardez à l'esprit que l'activation de cet audit générera un volume énorme d'entrées de journal, donc la révision manuelle des journaux d'audit prendra beaucoup de temps. De plus, les entrées de journal n'indiqueront pas quelles permissions sont attribuées ; elles révèlent simplement que les permissions pour une unité d'organisation particulière doivent être examinées.

4. Recherchez des droits équivalents à ceux d'un administrateur sur les contrôleurs de domaine (DCs).

Les contrôleurs de domaine sont des machines spéciales qui exécutent le système d'exploitation Windows Server et fournissent des services essentiels d'authentification et d'autorisation. Il est donc important de rechercher des comptes avec des privilèges de niveau administrateur sur vos DCs. Par exemple, un compte de service pourrait se voir accorder le droit de sauvegarder ou de restaurer des fichiers sur les DCs. Les attaques peuvent compromettre ces comptes en utilisant des outils open-source comme Mimikatz pour découvrir leurs hachages de mot de passe puis en craquant leurs mots de passe en clair.

Vous pouvez identifier quels comptes disposent de ces droits sur la base de :

• Révision de la politique des contrôleurs de domaine par défaut
• En utilisant un script PowerShell
• Utilisation d'outils de Privileged Access Management (PAM) tels que Netwrix PAM solutions

5. Découvrez les utilisateurs ayant l'autorité de réinitialisation de mot de passe sur d'autres comptes.

La capacité de réinitialiser le mot de passe d'un compte utilisateur est très recherchée par les acteurs de menaces, car réinitialiser le mot de passe d'un compte leur permet de prendre le contrôle du compte. Ce droit est inclus dans l'autorisation de Contrôle total. Vous pouvez également déléguer la permission spécifique de réinitialiser les mots de passe d'autres utilisateurs en utilisant l'assistant de Délégation de contrôle, comme indiqué ci-dessous :

Dans l'exemple ci-dessous, les membres du groupe de support PC ont la permission de réinitialiser les mots de passe des administrateurs de domaine. Par conséquent, en compromettant le compte de n'importe quel membre du groupe de support PC, un attaquant peut facilement obtenir des privilèges élevés à l'échelle du domaine.

Fouiller manuellement chaque UO et objet utilisateur pour voir qui a ce privilège prend du temps et est sujet à erreurs, et essayer d'auditer manuellement toute l'activité de réinitialisation de mot de passe est tout aussi irréalisable. Netwrix AD security facilite la visualisation des comptes ayant le droit de réinitialisation de mot de passe. La capture d'écran ci-dessous montre un environnement dans lequel 1 000 utilisateurs dans le domaine prod.net peuvent avoir leur mot de passe réinitialisé par 15 personnes différentes :

6. Surveillez l'utilisation des comptes de service Privileged Access Management.

Un conseil précédent soulignait la nécessité de surveiller les comptes de service qui disposent de droits d'accès sur un contrôleur de domaine (DC) équivalents à ceux des administrateurs. Mais les risques associés aux comptes de service ne se limitent pas aux DC. Des charges de travail telles qu'Exchange, SQL Server, les solutions de sauvegarde et d'autres applications d'entreprise fonctionnent sous des comptes de service qui ont souvent des privilèges administratifs, et toute personne connaissant les identifiants de tels comptes peut les utiliser à des fins malveillantes.

Les mots de passe des comptes de service ne sont souvent pas changés régulièrement, voire jamais, donc il n’est pas toujours clair qui les connaît exactement. Même si les mots de passe des comptes de service sont régulièrement modifiés, l'activité de connexion de ces comptes devrait être auditée pour s'assurer qu'ils sont utilisés uniquement pour leurs services assignés et non pour des activités illicites, telles que la connexion interactive à un contrôleur de domaine.

Utiliser le journal de sécurité sur un contrôleur de domaine pour déterminer si un compte de service est utilisé de manière inappropriée nécessite d'assembler plusieurs pièces d'un puzzle. Par exemple, l'événement 4768 indique qu'un ticket d'authentification Kerberos a été demandé et le 4672 indique que des privilèges spéciaux ont été attribués à une nouvelle ouverture de session, mais ils doivent être corrélés avec l'événement 4624 (un compte a été connecté avec succès).

7. Découvrez les utilisateurs disposant d'un accès en écriture aux GPOs qui sont appliqués aux DCs ou aux serveurs exécutant des applications avec Privileged Access Management.

La stratégie de groupe est un outil puissant pour gérer à la fois les utilisateurs et les machines comme les DC, les serveurs d'applications et les points de terminaison Windows. C'est pourquoi les attaquants tentent d'en prendre le contrôle et pourquoi il est impératif pour vous de surveiller qui a un accès en écriture à tout objet de stratégie de groupe (GPO).

Un bon point de départ consiste à examiner les permissions sur tous les GPOs qui sont liés soit à la racine du Domaine soit à l'OU des Contrôleurs de Domaine. Cela se fait facilement en consultant l'onglet Délégation de la politique des Contrôleurs de Domaine par défaut, comme indiqué ci-dessous :

8. Identifiez tous les comptes utilisateurs ayant accès à une solution de Directory Management.

De nombreuses organisations utilisent des solutions tierces pour simplifier les tâches de gestion AD. Ces solutions peuvent parfois permettre deux méthodes d'attaque pour les acteurs de menaces cherchant à obtenir un accès privilégié.

• La première implique l'utilisation d'un compte de service ou proxy qui se voit accorder un accès privilégié à tout ou partie de AD pour permettre les fonctions de gestion de la solution.
• La deuxième méthode utilise un compte quelconque avec des permissions attribuées au sein de la solution de gestion. Ici, un utilisateur de bas niveau pourrait se voir accorder la capacité d'effectuer des tâches privilégiées (par exemple, réinitialiser le mot de passe d'un autre utilisateur) sur un sous-ensemble de comptes AD. Selon le niveau de délégation, prendre le contrôle d'un compte comme celui-ci peut être tout aussi avantageux que d'être un Domain Admin.

Pour gagner en visibilité sur ces risques, vous devez inventorier toutes les applications de gestion utilisées. Notez qu'elles ne résident souvent pas sur un contrôleur de domaine. Ensuite, vous devez identifier tous les comptes de service et de proxy qui ont un accès privilégié, et surveiller ce que ces comptes font. La plupart des solutions de gestion fournissent un moyen d'établir une piste d'audit pour surveiller les comportements inappropriés. Toutes alertes générées par ces applications peuvent également être transmises à une solution SIEM si une est disponible.

Alternativement, Netwrix Auditor peut envoyer des résumés d'activité quotidiens détaillant tous les changements apportés au matériel et aux logiciels, aux tâches planifiées, aux applications, aux paramètres réseau et plus encore sur vos serveurs Windows. Ci-dessous une capture d'écran montrant toutes les applications installées :

9. N'oubliez pas les administrateurs d'infrastructure de virtualisation.

Pour sécuriser votre environnement AD virtuel, vous devez savoir quels comptes ont un accès privilégié à votre infrastructure virtuelle. N'oubliez pas que toute personne qui gère l'environnement virtuel hébergeant des DC ou des serveurs membres dispose d'un accès administratif équivalent à celui d'une machine physique.

Par exemple, si vous utilisez Hyper-V, les membres du groupe local des Administrateurs Hyper-V ont un accès de niveau administrateur sur le système d'exploitation invité. De même, dans les environnements VMware, l'utilisateur root sur un système ESXi dispose du même niveau d'accès. Et bien que les serveurs membres ne puissent pas héberger AD, toute application de gestion ou compte de service disposant de privilèges AD présente le même risque.

10. Empêchez les administrateurs de laisser des traces de leurs identifiants.

Lorsqu'un utilisateur se connecte à un système, des morceaux d'informations d'identification restent souvent après que l'utilisateur se soit déconnecté. Ces informations peuvent inclure des mots de passe en clair, des hachages de mots de passe, des hachages NTLM et des tickets Kerberos. En utilisant des outils tels que Mimikatz, les attaquants peuvent facilement exploiter ces artefacts laissés dans la mémoire des serveurs et des postes de travail pour s'authentifier en tant que comptes privilégiés. Par exemple, les mots de passe en clair peuvent simplement être réutilisés, et les hachages peuvent être transmis dans le cadre d'une demande d'authentification, en utilisant des outils de piratage supplémentaires pour accéder à d'autres systèmes.

Malheureusement, il est presque impossible d'identifier les machines qui possèdent des artefacts d'informations d'identification privilégiées. Par conséquent, votre attention doit se porter sur la détermination des endroits où les utilisateurs privilégiés se connectent.

Comme mentionné précédemment, vous pouvez surveiller l'ID d'événement 4627 (Des privilèges spéciaux attribués à une nouvelle ouverture de session) sur tout système Windows actuel pour les groupes connus comme privilégiés. Et vous pouvez surveiller l'ID d'événement 4769 (Un ticket de service Kerberos a été demandé) sur vos DCs pour identifier les ouvertures de session privilégiées.

Après avoir une idée de la manière dont les comptes privilégiés sont utilisés, assurez-vous que les paramètres WDigest empêchent que les mots de passe en clair soient stockés en mémoire. Vous devriez également interdire l'utilisation des comptes privilégiés sur les postes de travail des utilisateurs pour garder leurs identifiants sécurisés, et utiliser un compte avec des privilèges d'Administrateur Local pour résoudre les problèmes des utilisateurs finaux.

Garder un contrôle strict sur les comptes Privileged Access Management

Les comptes d'utilisateurs privilégiés — des comptes avec des droits d'Admin local sur une machine jusqu'à ceux avec des privilèges complets de Domain Admin — sont régulièrement ciblés par les adversaires. Pour prévenir les violations et les temps d'arrêt, vous devez savoir qui sont vos utilisateurs privilégiés et surveiller les changements qui pourraient affecter l'accès privilégié. Cependant, si vous comptez sur des outils natifs, l'évaluation et la surveillance sont des processus chronophages et sujets à erreurs. Pour la surveillance fiable 24/7 dont vous avez besoin pour protéger vos comptes privilégiés contre les compromissions et les abus, vous avez besoin d'outils tiers automatisés. La suite de solutions Netwrix vous offre la visibilité nécessaire pour détecter et contrer les tentatives d'escalade de privilèges et l'abus de privilèges.