Un autre jour, un autre dollar. Et sinon ça, au moins un peu de mischief.

J'ai trouvé une porte ouverte sur le bureau de Johnny. Admin local sur une workstation Tier 2. C'est le genre de foothold qui prend cinq minutes à transformer en quelque chose d'utile.

Je charge PowerShell. Les modules Microsoft natifs. Get-ADUser, Get-ADGroup, Get-ADComputer. Si tu sais les bonnes requêtes, AD est un livre ouvert. La plupart des places ne font pas d'alertes sur les cmdlets natifs parce que tout le monde les utilise pour faire de l'administration légitime. Je suis juste un admin de plus avec une console PowerShell.

Je cherche des credentials. Spécifiquement, des credentials qui traversent les tiers. La plupart des workstations Tier 2 sont assez verrouillées que de passer directement à Tier 1 c'est dur. Mais les admins sont paresseux. Certains d'entre eux gardent une credential runas pour un compte Tier supérieur sur la workstation qu'ils utilisent le plus. C'est contre toute politique. C'est aussi partout.

J'en trouve une. Johnny_t1. Compte Tier 1.

Je l'utilise. Je passe au segment Tier 1. Johnny_t1 est admin sur quelque chose. Laisse-moi vérifier quoi.

SCCM.

Configuration Manager. L'infrastructure qui gère les patches, les déploiements, les configurations, les politiques. Johnny_t1 est admin sur le serveur SCCM lui-même.

Laisse-moi penser à ce que SCCM peut faire.

J'énumère les collections. Je regarde ce que SCCM gère réellement.

Certification Authorities. Contrôleurs de domaine. Toute l'infrastructure Tier 0 se trouve dans la portée de gestion de SCCM.

SCCM peut pousser des packages. SCCM peut modifier les configurations. SCCM peut déployer des politiques qui ouvrent l'inscription sur les modèles de certificats. SCCM peut installer des logiciels sur les DC et les AC. SCCM peut modifier les services au démarrage. SCCM peut déployer une backdoor sur chaque système qu'il gère.

Je ne dois pas choisir dix attaques. J'en ai besoin que d'une.

Je crée un package. Le package exécute une seule commande sur tous les contrôleurs de domaine : net localgroup Administrators Hiro /add. SCCM le déploie. Vingt minutes plus tard, je suis admin local sur chaque DC de la forêt. Je m'ajoute au groupe Domain Admins. Je suis permanent. Je suis partout. Je possède tout l'environnement.

Le modèle de tiering dit que SCCM est de l'infrastructure Tier 1. L'accès admin de SCCM à Tier 0 est juste une partie de la façon dont SCCM fonctionne. L'accès est attendu, contrôlé, surveillé.

Sauf que ce n'est pas le cas, parce que personne ne traite SCCM comme si c'était Tier 0. Parce que la documentation l'appelle Tier 1.

Le modèle de tiering se trompe.

Comment ça arrive vraiment

Le modèle de tiering définit trois tiers :

  • Tier 0 : Contrôleurs de domaine, AC, infrastructure d'identité, n'importe quoi qui peut modifier l'annuaire ou émettre des credentials.
  • Tier 1 : Serveurs et services qui supportent Tier 0. Serveurs de gestion, infrastructure de sauvegarde, hyperviseurs, n'importe quoi qui peut administrer les systèmes Tier 0.
  • Tier 2 : Workstations utilisateurs, n'importe quoi qui n'administre pas directement Tier 0 ou 1.

SCCM, par définition, administre les systèmes Tier 0. La documentation Microsoft est explicite : aie une instance SCCM séparée pour chaque tier. Un SCCM gérant les systèmes Tier 0. Un gérant Tier 1. Un gérant Tier 2. Chacun isolé. Chacun avec ses propres admins. Aucune traversée.

Très peu d'organisations font ça.

La raison c'est le surcoût opérationnel. Une instance SCCM séparée par tier veut dire des serveurs séparés, une infrastructure séparée, des équipes d'admins séparées, des calendriers de patch séparés, des politiques séparées. Ça double ou triple ton empreinte SCCM. Le coût est substantiel. La plupart des organisations classifient SCCM comme infrastructure Tier 1, roulent une instance unifiée unique gérant tout, et acceptent le risque.

Puis elles se font breacher de la façon que Hiro a breached cet environnement, et réalisent que le surcoût opérationnel aurait été moins cher que la réponse à incident.

La documentation sur le tiering a une réponse. La plupart des organisations ont décidé de ne pas l'implémenter.

Le même problème s'applique à :

  • Intune et Endpoint Manager. Gèrent chaque appareil. Peuvent pousser des politiques qui modifient l'inscription, émettent des certificats, ouvrent les contrôles d'accès. Tier 1? Non. Tier 0 équivalent.
  • Entra Connect (anciennement Azure AD Connect). Synchronise l'identité entre l'AD on-premises et Entra ID. Possède des credentials avec les droits de réplication d'annuaire. Tier 1? Non. Tier 0 équivalent.
  • Infrastructure de sauvegarde. Peut faire une restauration bare-metal de n'importe quel système, incluant les contrôleurs de domaine. Tier 1? Non. Tier 0 équivalent.
  • Hyperviseurs. Peuvent approvisionner, snapshotter, restaurer et modifier les systèmes Tier 0 à volonté. Tier 1? Non. Tier 0 équivalent.

Tous ceux-ci sont classifiés comme Tier 1 ou « infrastructure gérée » parce que tu ne peux pas opérationnellement les isoler par tier. Tous ont un accès administratif sans restriction aux systèmes Tier 0. La documentation sur le tiering les appelle Tier 1 et n'a puis pas de réponse pour la contradiction du contrôle d'accès.

La plupart des organisations savent que SCCM est important. Elles restreignent l'accès admin SCCM plus soigneusement qu'elles ne restreignent la plupart des autres rôles Tier 1. Mais elles ne le restreignent pas comme si c'était Tier 0, parce que la documentation l'appelle Tier 1.

Et après quelqu'un trouve un compte Tier 1 avec des credentials sur une workstation Tier 2, et la partie est finie.

Ce que tu manques probablement

Regarde tes admins SCCM maintenant. Combien sont-ils? Combien ont un accès admin permanent en comparaison d'accès d'urgence break-glass? Combien de ces comptes s'authentifient avec les mêmes workstations, navigateurs et pratiques que les admins Tier 1 réguliers?

Maintenant regarde tes admins hyperviseur. Tes admins d'infrastructure de sauvegarde. Tes comptes de service Entra Connect. Tes admins Intune.

La plupart des organisations ont cinq à dix personnes avec des credentials qui accordent un accès administratif sans restriction aux systèmes Tier 0 via ces outils classifiés Tier 1. Et la plupart de ces credentials se trouvent sur des workstations où un seul compromis les amène à un attaquant.

Le modèle de tiering dit que c'est correct parce que les credentials sont Tier 1, les workstations sont Tier 2, et elles sont dans des segments différents.

Ce n'est pas correct. C'est comme ça que l'article commence.

Pour conclure

Le modèle de tiering est utile. Le modèle de séparer les systèmes par leur criticité et appliquer les contrôles d'accès en conséquence est solide.

La documentation sur SCCM est aussi solide : aie une instance SCCM séparée pour chaque tier.

Le problème c'est ce qui arrive après. La plupart des organisations lisent cette documentation, reconnaissent le surcoût opérationnel, et décident de rouler une instance SCCM unifiée simple à la place. Le coût d'une infrastructure SCCM séparée semble élevé. Le risque d'une brèche semble abstrait.

L'attaque de Hiro renverse ce calcul.

SCCM, Intune, Entra Connect, infrastructure de sauvegarde, hyperviseurs. Tous peuvent faire n'importe quoi qu'un vrai contrôleur de domaine peut faire. Tous ont de la documentation pour être traités comme équivalent Tier 0. La plupart des organisations lisent cette documentation et font un compromis de toute façon, parce que le coût opérationnel est réel et la brèche semble improbable.

Hiro n'a pas besoin de la documentation pour savoir quels outils comptent. Il a juste besoin de trouver un chemin vers l'un d'eux, et le chemin existe parce que tu as décidé que le surcoût opérationnel n'en valait pas la peine.

Le modèle de tiering a une réponse. Tu as choisi de ne pas l'implémenter.