Utiliser des comptes Administrateur local Windows, Partie I

Utiliser des comptes Administrateur local Windows, Partie I
Utiliser des comptes Administrateur local Windows, Partie II
Utiliser des comptes Administrateur local Windows, Partie III

Dans les articles sur les hackers et leurs techniques, il est souvent fait mention de comptes Administrateur local Windows. Avant Windows 7, le compte Administrateur était créé par défaut sans mot de passe. Il s’agissait d’une mauvaise pratique de sécurité, et les hackers n’ont jamais cessé d’en profiter depuis.

Depuis Windows 7, les comptes Administrateur local sont désactivés par défaut. Vous devez les désactiver dans votre domaine quelle que soit votre version de Windows ! Mais pour différentes raisons, dont certaines fondées sur des idées erronées, les comptes Administrateur local sont toujours présents dans de nombreux environnements. Bien trop souvent, le service informatique leur a attribué des mots de passe faciles à deviner, voire même parfois un mot de passe identique dans de vastes parties du domaine.

Si les hackers parviennent à mettre un pied dans le système, la recherche de ce compte Administrateur local doté de droits particuliers figure en bonne place dans leur liste d’opérations diaboliques. Ils tentent ensuite d’utiliser ces comptes lorsqu’ils entament la phase latérale de leur post-exploitation.

En bref : ils devinent le mot de passe du compte de l’Administrateur local, s’emparent des hachages de mot de passe des utilisateurs du domaine avec mimikatz, et se déplacent sur le réseau.

Mais j’en ai besoin !

Parfois, ils n’ont même pas besoin de se procurer le hachage des mots de passe utilisateur du domaine. Dans de nombreux environnements, les mots de passe des comptes Administrateur local sont eux-mêmes définis sur le même modèle : lorsque vous en devinez un, vous pouvez en déduire tous les autres.

En pratique, vous rencontrerez peut-être l’opposition du service informatique qui soutiendra que les comptes Administrateur doivent être disponibles, peut-être parce que des processus ou logiciels dépendent de leur existence.

Y-a-t-il moyen de conserver les comptes Administrateur tout en leur donnant moins de pouvoir ?

Microsoft donne quelques conseils concernant leur sécurisation. Pour l’essentiel, vous configurez un Objet de stratégie de groupe (GPO) pour désactiver l’accès réseau, le bureau distant et quelques autres services par le biais de l’Attribution des droits utilisateur.

Juste pour voir comment cela fonctionne, je suis retourné sur le désormais célèbre domaine Acme que j’ai créé dans Amazon Web Services.

Supposons que les mots de passe des comptes Administrateur locaux d’Acme soient basés sur un modèle (nom du serveur, suivi d’une séquence numérique) pour faciliter le travail de l’équipe informatique déjà submergée.

Dans mon scénario fictif, j’ai utilisé l’utilitaire Vanilla psexec qui, soit dit en passant, a joué un rôle dans l’attaque récente de ransomware NotPetya, pour opérer un déplacement latéral sur le serveur Taco. Revêtant alors ma casquette de testeur d’intrusion, j’ai saisi le mot de passe Administrateur présumé sur Taco et, ô miracle, ça a marché.

Vous pouvez voir ci-dessous le fruit de mes activités dans psexec avant que je définisse l’Objet de stratégie de groupe.

Une fois que j’ai eu terminé de définir l’Objet de stratégie de groupe, l’utilitaire psexec a signalé que mon nom d’utilisateur et mon mot de passe étaient incorrects – l’Attribution des droits utilisateur jouait son rôle. Si vous essayez de faire cette opération chez vous, pensez à exécuter gpupdate /forcesur le contrôleur de domaine afin de déclencher la synchronisation des Objets de stratégie de groupe vers tous les membres du domaine.

Cette solution constitue un compromis qui vous permet de conserver les comptes Administrateur local tout en empêchant les hackers de les exploiter facilement pour se déplacer sur le réseau.

Ne modifiez pas des mots de passe avec les Préférences de stratégie de groupe

La chose à faire est de désactiver l’Administrateur local puis de définir des groupes au niveau du domaine possédant des droits limités sous le groupe Administrateurs local. Nous expliquerons plus loin comment effectuer cette opération.

Mettons que vous soyez déterminé à conserver ces comptes Administrateur local ; vous réalisez que les mots de passe ont été définis de manière à privilégier l’aspect pratique (et non la sécurité). Vous voulez donc renforcer les mots de passe au niveau global.

Un jour, Microsoft a décidé d’introduire des Préférences de stratégie de groupe (GPP) dans Windows server 2008 pour étendre les GPP. Une des nouvelles capacités GPP vous permettait de mettre à jour les informations des utilisateurs et des groupes pour tout un domaine.  À un moment donné, vous aviez la possibilité de modifier les mots de passe puis de les pousser dans le domaine.

Toutefois, les pirates ont identifié une vulnérabilité importante dans le processus d’attribution de mot de passe des GPP. Lorsque Windows a chiffré les mots de passe, il a divulgué (hum…) la clé de chiffrement dans sa documentation technique.

Depuis, Windows a publié un correctif, et dans l’instance AWS avec laquelle j’ai travaillé récemment, la saisie de mot de passe était désactivée (en grisé dans l’illustration ci-dessous).

Malgré tout, un peu plus tôt au cours de mes expériences, j’ai lancé une instance AWS non corrigée dans laquelle j’ai eu la possibilité de saisir le mot de passe. Et bien entendu, j’ai pu extraire le mot de passe chiffré par AES à partir du dossier SYSVOL.

À coup sûr, de nombreux autres serveurs dans le monde n’ont pas le correctif GPP. En fait, les utilitaires de test d’intrusion tels que crackmapexec recherchent des mots de passe chiffrés (voir l’option -gpp-passwords) dans le dossier SYSVOL puis les déchiffrent.

Heureusement, Microsoft a trouvé un autre moyen de mettre à jour de façon groupée les mots de passe Administrateur, une solution au nom accrocheur de Local Administrator Password Solution (LAPS). Elle est téléchargeable ici. J’ai prévu de l’essayer, je vous tiendrai au courant des résultats.

Groupes limités

La meilleur façon de gérer les comptes Administrateur local est de passer par le GPO des Groupes restreints, disponible sous Configuration ordinateur > Stratégies > Paramètres Windows> Paramètres de sécurité. Ce GPO gère le groupe Administrateurs locaux en vous laissant y ajouter un groupe au niveau du domaine puis en pousser les modifications dans le domaine. En bref : vous avez un groupe spécial d’utilisateurs contrôlé de manière centralisée. Ces utilisateurs possèdent juste les droits nécessaires aux tâches d’administration qu’ils doivent effectuer en local.

Pour mon domaine Acme, j’ai délégué les pouvoirs de l’Administrateur local au groupe Acme-IT (ci-dessous).

Nous reviendrons la prochaine fois sur d’autres subtilités de l’utilisation des Groupes restreints. Et nous parlerons aussi des Unités d’organisation (OU), qui permettent de segmenter le domaine et de renforcer la sécurité de nos Groupes restreints.