opened
Ug0Security
username_0
Little issue this morning while trying the new "is_known_pipename"

It seems that i've (it) broke the payload selection system

![image](https://cloud.githubusercontent.com/assets/28728543/26575345/1d132ba6-4525-11e7-8e36-fc633fe12f86.png)

![image](https://cloud.githubusercontent.com/assets/28728543/26575460/a0e0952c-4525-11e7-9bf4-bb53b2a90055.png)


As you can see proposed payloads are wrong (ms08-067 is obviously for windows  and same problem is_known_pipename )

I've try to update the framework, reboot the vm nothing seems to get this of this.

Kali 2.0 with msf fully updated i guess.
broken payload selection system
issue
created
busterb
username_1
Kali 2.0? Please update to Kali Rolling 2017.01 or later. Kali 2.0 has been dead for a long time.

Also, Kali Rolling do not appear to ship this exploit yet, so I'd advise just waiting until Kali packages the latest Metasploit framework release. I double-checked and cannot reproduce this issue with latest Kali or omnibus nightly package. Sounds like you might have a bit of a Frankenstein locally?
comment
created
Ug0Security
username_0
sorry for my mistake, i work on a Kali Linux 64 bit VBox  2016.2 
So msf is preinstalled and i've updated it.

i've added the exploit manually from exploit-db this morning , i also tried some previous version of the exploit yesterday (copied from github) . Yesterday everthing was fine, now i've add the exploit from exploit-db the system seems to be broken

For some reason the payloads suggestion changed to another packs which are still incorrect (of course as the system seems broken on my install)

![image](https://cloud.githubusercontent.com/assets/28728543/26582602/191a0e44-4542-11e7-8755-6975ac9c246a.png)
comment
created
busterb
username_1
the latest version of the exploit needs a lot of library changes from metasploit to work. You can't just drop it in without carefully extracting all of the extra pieces too, which is definitely going to invalidate the warranty :). I'd recommend waiting or grabbing the latest omnibus package.
comment
closed
busterb
username_1
issue
created
busterb
username_1
Also, the exploit from exploit-db trails what's in Framework by quite a bit. We can't support grabbing stuff from there after it's already in the tree.
comment
created
Ug0Security
username_0
Ok, i guess i'll go to 2017.1 meanwhile :)
and i understand for the support of course.

Just to share i manage to reproduce the issue on Kali Linux 32 bit VBox PAE 2016.2 but whatever, thx for fast answer
comment
created
busterb
username_1
If you can give some steps I can reproduce, can certainly reopen and take a look at it. I have an up-to-date 2017.1 box with v4.14.21-dev ready to go.
comment
created
Ug0Security
username_0
Here the steps i've made this morning

1- add exploit from exploit-db (https://www.exploit-db.com/exploits/42084/)
2- reload_all metasploit
3- use exploit/yourpath/is_known_pipename
4- set payload 'TAB TAB' 
5- use exploit/windows/smb/ms08-067_netapi 
6- set payload 'TAB TAB'

Here the proof on two vm with both Arch x86 and x64

![image](https://cloud.githubusercontent.com/assets/28728543/26584969/042d8282-454b-11e7-8e9a-92e22895dd0e.png)

![image](https://cloud.githubusercontent.com/assets/28728543/26585051/4b0b7af6-454b-11e7-9c25-5345ad78a547.png)

it seems to me that i've reproduce the issue on 2017.1 without installing new exploit just reproduce steps 3 to 6 (Solaris Exploit - Windows Payload ?)

![__www_download_gg__capture](https://cloud.githubusercontent.com/assets/28728543/26585659/088a84e0-454d-11e7-9e85-b76e8714392b.PNG)

Is this the normal behaviour ?
comment
created
Ug0Security
username_0
Same issue on Armitage, same steps 3 to 6 the to first are useless.

It seems that once you selected an exploit and autocomplete the payload
The next exploit you'll choose will have same payloads.

Tell me if you more info and if you managed to reproduce
comment
created
busterb
username_1
Ah, interesting. This doesn't have anything to do with downloading from exploitdb, it seems the payload values get cached between module switches, so it shows the wrong set on the second exploit module every time.
comment
reopened
busterb
username_1
Little issue this morning while trying the new "is_known_pipename"

It seems that i've (it) broke the payload selection system

![image](https://cloud.githubusercontent.com/assets/28728543/26575345/1d132ba6-4525-11e7-8e36-fc633fe12f86.png)

![image](https://cloud.githubusercontent.com/assets/28728543/26575460/a0e0952c-4525-11e7-9bf4-bb53b2a90055.png)


As you can see proposed payloads are wrong (ms08-067 is obviously for windows  and same problem is_known_pipename )

I've try to update the framework, reboot the vm nothing seems to get rid of this.

Kali 2.0 with msf fully updated i guess.
broken payload selection system
issue
created
shawndeckerr
username_2
Noticed the same issue when dealing with exploit/windows/smb/ms17_010_eternalblue as well. 
After using the eternalblue exploit, I used exploit/windows/smb/psexec but at this point, 'set payload <TAB><TAB>' (autocomplete) will only display windows/x64/ payloads. 
However, 'show payloads' will show genuinely available payloads so you could workaround with that in the interim.
I'm using newly installed Kali 2017.1 with updates installed 3 days ago. Metasploit Framework version is 4.14.22-dev.
comment
closed
busterb
username_1
issue