C'est toujours fun d'avoir un sens de ce qu'une compagnie traverse en écoutant les enregistrements des team meetings.

J'en ai trouvé un juicy aujourd'hui où un Domain Admin s'inquiète que le prochain compromis ne sera pas survivable parce qu'ils n'ont pas de contrôleur de domaine physique. Il croit que le fait que tous les Domain Controllers sont virtualisés veut dire que si l'infrastructure virtuelle s'arrête, ils sont complètement down.

D'abord, il n'a pas 100% tort. S'ils n'ont pas un plan de cold start pour ramener les choses up, alors sure, ne pas avoir de DC physique pourrait être un problème.

Mais son take c'était : « On a seulement survécu au dernier compromis parce qu'un serveur n'est pas tombé. »

N'est-ce pas comme dire que ma maison n'a pas vraiment brûlé parce que le garage est encore debout?

Laisse-moi écouter plus de meetings.

Voici ce que je suis en train d'apprendre sur cette organisation :

Ils ont 40+ Domain Admins. Chacun gère « sa paire » de Domain Controllers. Plus de DCs pour la redondance au lieu de s'assurer que les liens WAN redondants sont en place. Tout le monde croit que le travail qu'ils font sur « leurs » DCs n'affecte pas le reste de l'organisation.

Le Domain Admin qui s'inquiète de la défaillance de l'infrastructure virtuelle? Il exprime en fait une peur réelle : que l'infrastructure d'identité entière de l'organisation est consolidée sur une plateforme hyperviseur qu'ils ne peuvent pas contrôler. C'est une préoccupation légitime.

Mais il traite le symptôme, pas le problème.

Le problème n'est pas « on a besoin d'un DC physique ». Le problème c'est « on a 40+ personnes avec les droits Domain Admin, chacun convaincu que son coin de l'infrastructure est séparé de celui de tout le monde, et on n'a pas de stratégie de redondance unifiée ».

C'est du security theater. C'est des silos qui se font passer pour de la segmentation.

Voici ce que je vois :

Quarante-trois Domain Admins. Pas Tier 0, pas surveillés comme un groupe. Chacun a « leurs » DCs, « leurs » applications, « leur » morceau de l'organisation. Ils ne se parlent pas. Ils ne coordonnent pas. Ils ne pensent définitivement pas que leurs erreurs affectent quelqu'un d'autre.

Certains d'entre eux dorment. Ne protégeant pas leurs credentials. Ne surveillant pas leurs DCs. Ne watchant pas pour du lateral movement.

J'ai des credentials du compromis SCCM (tu te souviens de l'article tiering?). Ça m'a donné local admin sur plein de serveurs, incluant quelques serveurs d'application « tier 1 ». Un de ces serveurs a une scheduled task qui roule sous un service account. Ce service account a des droits pour réinitialiser les passwords sur les comptes « tier 1 » admin.

J'escalade à tier 1. Maintenant j'ai des credentials pour des comptes qui sont dans un security group qui a des permissions delegate sur un couple de DCs. Pas Domain Admin, mais close.

J'utilise ces credentials pour demander un service principal name sur un des tier 1 DCs. L'ACL du DC est permissive parce que la personne qui gère « ce DC » a décidé que c'était plus facile de grant des droits larges aux tier 1 admins.

Maintenant j'ai un compte kerberoastable. Je craque le password en quarante-cinq minutes. Ce compte est un membre d'un groupe qui a des droits « administratifs » sur un DC différent. Pas le même DC, mais l'autre admin qui gère ce DC a grant des droits au groupe parce qu'il fait confiance à « l'équipe ».

Maintenant je suis sur un DC différent, géré par un Domain Admin différent, dans une unité organisationnelle différente, qui pensait qu'il était indépendant.

Je répète ceci cinq fois. Chaque fois, je suis escalading via les silos. Chaque fois, la confiance mal placée d'un DA différent envers « l'équipe » me donne l'étape suivante.

Au moment où j'atteins un DC qui a des droits de replication sans restriction, j'ai un chemin via sept comptes DA différents, chacun convaincu que son coin est sûr.

Je forge un golden ticket. Domain Admin. Full access.

Je check le système de backup. Ils font le backup de la forêt entière vers un NAS qui est « géré par IT ». Je check le NAS. Il a une web interface exposée au réseau. Je passe une heure à trouver des backups d'il y a six mois. J'extrais le fichier NTDS.DIT. J'ai chaque password hash dans l'environnement.

Je remets tout back. Je ne touche rien d'autre. Je pars juste avec des credentials domain admin et les password hashes pour quarante-trois DAs.

La prochaine fois qu'il y a un incident, ils vont trouver que le breach est arrivé il y a six mois. Ils vont être confus à propos du chemin d'attaque. Ils vont blâmer l'infrastructure virtuelle.

Ils vont probablement décider qu'ils ont besoin d'un DC physique.

Si tu es un défenseur, voici ce qui vient d'arriver.

L'erreur d'architecture

Ce n'est pas un problème de virtualisation. C'est un problème de trust boundary.

L'organisation a 43 Domain Admins. Chacun pense que son DC est séparé. Chacun a grant des permissions à « l'équipe » parce qu'ils travaillent dans la même organisation. Mais il n'y a pas de trust boundary clair. Il n'y a pas d'isolation entre les DCs.

L'erreur n'était pas de virtualiser les DCs. L'erreur était de penser qu'avoir « plusieurs personnes qui gèrent plusieurs DCs » c'est la même chose qu'avoir de la defense in depth.

Ce n'est pas le cas.

Ce qu'ils devraient faire

  1. Consolide les droits Domain Admin. Tu n'en as pas besoin de 43. Tu en as besoin de peut-être 5-7, partagés à travers la forêt entière, avec MFA et auditing sur chaque action. Pas « mon DC » et « ton DC ». Une forêt. Une équipe. Un audit trail.
  2. Implémente une stratégie d'accès DC. Si tu virtualises, fine. Mais implémente une procédure de cold-start, des snapshots versionnés, et un plan de récupération qui ne dépend pas de « un serveur qui ne s'arrête pas ».
  3. Monitoring unifié. Chaque DC, chaque credential, chaque permission change. Pas « chaque admin watch son propre DC ». Une solution de monitoring. Un système d'alerte. Un plan de réponse à incident.
  4. Enforcement de trust boundary. Si des admins différents gèrent des systèmes différents, c'est fine. Mais fais-le explicite. Enforce la séparation. Ne grant pas des permissions « équipe » qui blur les lignes.
  5. Tiering de credential. Pas « tier 1 admins ont des droits vers tier 1 servers ». Tier 0 c'est la forêt. Tier 1 c'est tout ce qui est en dessous. Les admins ne devraient pas avoir à la fois tier 0 et tier 1 access. Jamais.

L'infrastructure virtuelle n'est pas le problème. Les silos qui se font passer pour l'indépendance le sont.

Le principe de fermeture

Quand tu as 43 Domain Admins, chacun pensant que leur coin est indépendant, tu n'as pas 43 systèmes isolés. Tu as un système avec 43 différentes personnes qui le poke, chacun convaincu que leurs pokes n'affectent personne d'autre.

C'est pas de la redondance. C'est une défaillance qui attend de se produire.

La plupart des organisations avec cette structure vont finalement expérimenter un compromis qui touche la forêt entière. Quand ça arrive, ils vont chercher un single point of failure à blâmer.

Ils ne vont pas en trouver un, parce que le problème c'est les 43 points de confiance séparés, chacun assumant que les autres gardent leur coin sûr.

Hiro out.