Méthodologies de pentesting Active Directory
Je voudrais poser des questions sur les étapes et les méthodologies de pentesting Active Directory. J'ai utilisé des outils comme responder, powerview, pingcastle et mimikatz, mais il y a peut-être d'autres méthodes qui sont utiles.
Dans la plupart des scénarios, les cibles de forêt Windows Server sont renforcées assez bien, mais généralement en raison de l'existence d'un EDR et/ou NIPS qui empêche l'accès à l'entrée initiale.
Le concept global des tests Active Directory, comme vous le dites, consiste à étendre l'accès * après * que ce point d'entrée initial, ou prise de contact, soit prouvé.
Le livre, Mastering Kali Linux for Advanced Penetration Testing, 3rd Edition, est une excellente ressource sur ce que vous demandez - peaufinez dans son chapitre intitulé Action on the Objective and Lateral Movement.
Le Hacker Playbook 3: Guide pratique des tests de pénétration, édition Red Team - est également une excellente ressource pour certaines techniques de base ainsi que des démonstrations sur la façon ou l'endroit où les faire évoluer.
Vous constaterez que chaque conférence sur la cybersécurité a quelques cours de formation qui enseignent spécifiquement les tests Active Directory ou certaines variations (ou même un sous-ensemble, par exemple, il y avait même une classe juste sur mimikatz et rien d'autre). Beaucoup de ces cours ont leur propre méthodologie, mais les méthodes sont toujours les mêmes: avoir accès, garder l'accès et étendre l'accès.
Pour y accéder, vous aurez besoin d'un scénario Pre-ATT & CK soigneusement planifié avec une série (ou chaîne) de tactiques, chacune appuyée par une ou plusieurs techniques sous-jacentes. Comme je suis sûr que ce n'est pas ce que vous demandez, je vais continuer.
Afin de maintenir l'accès, vous aurez besoin de ce scénario Pre-ATT & CK pour résister à l'épreuve du temps, et s'il utilise des charges utiles reverse-https/etc qui se connectent à vos gestionnaires distants, alors tout cela ne devra pas se démarquer. Bien sûr, certains scénarios pourraient positionner C2 à l'intérieur du réseau, par exemple, des démons ARP, ou des canaux nommés MS-RPC, ou toute sorte de canal secret. Cependant, d'autres se cachent à la vue, comme la façade de domaine ou la fourche Empire de BC-SECURITY, où des évasions telles que celles pour JA3/S (un détecteur populaire en 2019) , sont disponibles.
Souvent, cela implique de trouver des ordinateurs (c'est-à-dire des objets informatiques AD) qui ne sont pas dans Sites (un concept AD) car ils peuvent également manquer d'une pile EDR complète ou avoir d'autres exceptions. Le personnel informatique et de cybersécurité ne semble pas savoir que l'ordinateur est là et que l'AV ou les bases ne sont pas installées ou ne fonctionnent pas correctement. Recherchez également les chevauchements dans les domaines et les forêts Windows Server. Vous devez explorer ou connaître le ou les environnements cibles.
Le livre, Advanced Infrastructure Penetration Testing, contient un chapitre entier dédié à l'exploitation d'Active Directory. La section sur l'analyse SPN est unique en ce qu'elle simplifie une grande partie de la reconnaissance AD interne avec une seule commande PowerShell: setspn -Q */*. Vous pourriez ne pas obtenir ces données de cette manière exacte (car cela pourrait déclencher une détection immédiatement - ou même beaucoup plus tard, elles pourraient être découvertes lors d'une opération de chasse), mais vous devrez savoir comment analyser et comprendre . Les données SPN sont un Active Directory ciblant la mine d'or.
Les fruits bas dans un Active Directory sont généralement les comptes SharePoint même lorsque vous ne ciblez pas les sites SharePoint (parfois SharePoint a été remplacé mais les comptes hérités restent!). C'est là que les techniques entourant l'outil BloodHound peuvent être mises au point.
Encore mieux sont les installations isolées ou anormales de IIS trouvées via SPN ou tout autre moyen. Tout moyen de débarquer une charge utile sur un serveur IIS pourrait révéler des apppools menant à des pivots cachés via des identifiants qui ne sont généralement pas découverts autrement. Une commande pour ce faire (ainsi que de travailler avec apppools en général) se trouve dans le livre, Internet Information Services (IIS) 7.0 Administrator's Pocket Consultant dans la section sur l'utilisation des pools d'applications: [drive:]\windows\system32\inetsrv\appcmd list apppool <AppPoolName> /text:*
Les services MS-SQL Server se trouvent également dans SPN, et les services qui leur sont liés (par exemple, SAP ECC) peuvent également être visibles. Je me souviens des outils PentUp PowerUpSQL et PowerSAP, mais il y a des centaines de ces projets alors qu'il y a 2 ans il n'y en avait qu'une dizaine. Je pense que vous commencez à comprendre que la raison pour laquelle il n'existe pas de test de plume Active Directory unique (ou un organigramme facile à suivre) est parce que tout dépend des environnements cibles.
Jouez avec les modules PowerShell spécifiques à l'administration de chacun de ces services forestiers Microsoft Server, comme les applications ci-dessus, mais souvent plus proches de l'implémentation. Par exemple, Get-Webconfig et Get-ApplicationHost, mais il y en a d'innombrables autres. MS Exchange Server en a beaucoup, faites attention cependant! Il est également possible de rechercher les outils fournis avec ces services, par exemple, le Centre d'administration Exchange dispose d'outils GUI, mais il dispose également d'un portail Web (essayez les adresses IP et le /ecp URI pour les trouver).
Il y a aussi des outils ponctuels qui pourraient me manquer et qui méritent d'être mentionnés, tels que Vibe . Il y a vraiment beaucoup de façons d'écorcher ce chat. Une armée de pros de la cybersécurité ne manquerait jamais d'idées. Azure AD va changer les choses mais ouvrira probablement de nouvelles portes. Continuez simplement à le tester et obtenez-en la valeur que vous souhaitez.