Ok, I opened Win10 in VB on another machine and was able to get to my Apache2 page and download the exploit. But, in lesson 70, we changed the exploit name to windows/meterpreter/reverse_https
Although I shut off Windows Defender (it was flagging it), I still didn’t get any connection on my Kali machine. The LPORT and LHOST were set correctly, and it was waiting. I’m wondering if it’s because the name was so different - rev_https to reverse_https, and adding windows/ instead of go/
Of course, I tried all of those names, and msf told me they were not valid. It would only accept windows/meterpreter/reverse_https.
How exactly does the parsing of the name work on msf? That whole parsing thing about programming method we learned in lesson 69 doesn’t apply to msf?
Yes only windows/meterpreter/reverse_https will work as it is the name of the handler payloads. Can you try other types of payloads? E.g. reverse_tcp/reverse_http on both backdoor as well as on msfconsole.
Let me know if you need anything else,
I tried reverse_http (#14), but although I was able to download it onto the VMware Windows 7 machine, it doesn’t seem to run - at least, not that I can see. I gave it permission, and tried running it from the web browser, command line, and Explorer. Each time, I had Process Explorer running, and it didn’t show that it was running.
Also, of course, the Kali msf is just patiently waiting for it, like a jilted bride.
I also tried #16, but it couldn’t generate the executable. I’m not sure why.
So, I’m at a standstill here. Any thoughts would be appreciated.
Yay! After trying a bunch of things, I installed Sandboxie and ran Firefox through that. I downloaded the reverse_http exploit into the Sandboxed window, and I was able to run it.
So, VMware and Virtualbox versions of Windows 7 & 10 didn’t work, but my actual Windows 10 installation, with a Sandboxie version of Firefox, did the trick.