jymcheong/autottpTactiques, techniques et procédures automatisées
Tactiques, Techniques & Procédures automatisées. Rejouer manuellement des séquences complexes pour des tests de régression, des évaluations de produits, générer des données pour les chercheurs, etc., peut être fastidieux. J'ai eu l'idée de faciliter le scripting d'Empire (ou de tout framework/produit/boîte à outils offrant des API comme Metasploit (RPC), Cobalt-Strike, etc.) en utilisant un IDE comme Visual Studio Code (ou équivalent). J'ai donc commencé à concevoir AutoTTP. Ceci est encore en cours de développement. Testé avec Empire 2.2.
Youtube - Aperçu et plongée approfondie dans les techniques sélectionnées
Dans mon cas, les tactiques sont organisées selon mon modèle de cycle de vie d'attaque. Il existe d'autres modèles comme le Kill-Chain de Lockheed Martin, le cycle de vie d'attaque de Mandiant et ATT&CK de Mitre. Quel que soit le modèle, une « tactique » regroupe essentiellement des techniques, par exemple, l'exécution de code / l'exécution d'une charge utile peut être réalisée de nombreuses façons :
J'utilise « Phase » pour regrouper les « tactiques » pertinentes. Si vous regardez l'arborescence source, la structure des dossiers reflète la colonne des tactiques de la matrice. La matrice mentionne également les contrôles correspondants pour chaque tactique offensive. Comment ces phases sont-elles apparues ?
Le diagramme de Venn au milieu du cycle rouge provient du document de Dartmouth College « Three Tenets for Secure Cyber-Physical System Design and Assessment ». Il définit les conditions nécessaires et suffisantes, ou simplement les exigences de toute attaque physique/logique réussie. J'ai ajouté l'anneau rouge (phases) autour du diagramme de Venn pour illustrer les flux offensifs typiques qui mènent finalement à un impact sur la confidentialité, l'intégrité des informations, ainsi que la disponibilité ou la sécurité du système s'il est lié au cyber-physique (pensez aux infrastructures d'information critiques).
Un attaquant peut commencer à la phase 1 et passer directement à la phase 4, par exemple, des identifiants d'administration par défaut sur une page d'administration exposée publiquement. Il n'a pas besoin d'être linéaire (phase 1->2->3->4). Après l'infiltration initiale, il pourrait avoir effectué une collecte d'informations interne (reconnaissance) avant d'élever ses privilèges sur la première machine, puis de lancer une commande à distance vers une autre machine cible sur le même réseau. Pour la machine victime suivante, c'est une phase 2 : livraison et exécution réussies de la charge utile qui permettent à l'attaquant de prendre le contrôle de cette machine supplémentaire.
Le fichier de gauche est un script de procédure, celui de droite est un script de technique. Remarquez que le script de procédure n'est pas encombré de trop de détails propres à Empire, la plupart des détails étant encapsulés dans le script de technique. L'écriture de scripts de procédure doit se concentrer sur la séquence des techniques en utilisant les informations des actifs, par exemple, nom d'hôte/IP, à quel email envoyer la charge utile, quelle technique de charge utile, etc.
L'exemple « l'utilisateur est-il admin ? » se compose en fait de plusieurs étapes, car il y a au moins 3 possibilités comme indiqué dans les commentaires du script. Nous pouvons bien sûr créer des « macros » personnalisées dans Empire, Metasploit, etc., mais cela devient étroitement intégré à un framework/produit particulier. Nous voulons profiter des outils existants et organiser des techniques réutilisables en modules afin de pouvoir les mixer et les assortir au niveau procédural (c'est-à-dire l'automatisation).
J'ai profité des modules bien structurés d'Empire pour créer une classe d'auto-complétion en Python. Au lieu de taper le nom complet du module (ex. powershell/situational_awareness...), utilisez simplement les capacités d'auto-complétion de l'IDE.
Pour chaque module, il y a des options (pour la plupart, sinon tous les frameworks). Le problème avec Empire est qu'une fois que vous l'exécutez en mode REST/headless (j'y reviendrai plus tard), il n'y a PAS de console pour voir les options du module. Dans la classe d'aide à l'auto-complétion, chaque module a une sous-classe options. Les options obligatoires sont préfixées comme indiqué ci-dessus, nous pouvons donc les renseigner avec des valeurs avant d'appeler un module.
La description de chaque module est également incluse dans la documentation de la classe Python et s'affichera au survol de la classe. Comme il y a 276 modules (au moment d'Empire 2.1), cette classe d'aide nécessitera un peu de scripting pour être créée ! Source : https://gist.github.com/jymcheong/22c2eede978c8eb694945e3347c20c6b
Avec des IDE comme Visual Studio Code (ou équivalent), on peut profiter de la surveillance des variables de débogage, parcourir le script pas à pas, ou même modifier le script pendant le débogage/parcours après avoir connu la structure des valeurs de retour. Les documentations des API REST sont disponibles pour Empire, mais parfois on ne connaît pas exactement les valeurs de retour avant d'exécuter le module. Pour cette raison, cela mène au sujet suivant.
Même si nous voulons tout faire dans l'IDE, vous aurez besoin d'une console. L'auteur de DeathStar, le savait déjà en développant ce script qui automatise la prise de contrôle d'un administrateur de domaine avec Empire. J'ai emprunté son idée mais adapté son approche de threading pour Empire 2.1, car son approche ne fonctionnait pas avec la fonction refactorisée start_restful_api. Source : https://gist.github.com/jymcheong/6a7668ecf73c29dd1d234d1c76ef438c
Il n'est PAS nécessaire de modifier le script d'Empire car Empire 2.2 dispose d'un gestionnaire de boucle de commande en mode REST. Cependant, n'interagissez PAS avec un agent tout en utilisant l'API pour obtenir le résultat d'un agent.
Shout outz à @radioboyQ pour son EmpireAPIWrapper, @allfro & @Mikaayenson pour pymetasploit, et à @byt3bl33d3r, MTFBWU.
