From: Roberts, Scott (scottroberts@hersheys.com)
Date: Mon Jul 18 2005 - 13:56:11 EDT
Win32_bind initiates a connection with the target machine an establishes an
Administrator terminal session.
Win32_reverse tells the target machine to start an outgoing session to your
attach machine, which has a port listening, and then gives you an
Administrator terminal session.
Win32_reverse has a huge advantage in that many Win32_bind sessions may fail
because firewall rules don't allow incoming connections except over
specified ports (and usually not ports used for remote shell). Since
Win32_reverse has the session start from the inside and tunnel out to the
attacking machine it's much less likely do be blocked, since many firewall
Admins don't block outgoing traffic as well as they block incoming traffic
(this may be a bad idea, but this isn't the right list to discuss that).
Hope that helps,
Scott
-----Original Message-----
From: Stephane Auger [mailto:sauger@pre2post.com]
Sent: Monday, July 18, 2005 9:33 AM
To: pen-test@securityfocus.com
Subject: RE: Pen Test help
What does win32_reverse and win32_bind do, anyway?
-----Original Message-----
From: H D Moore [mailto:sflist@digitaloffense.net]
Sent: July 17, 2005 11:35 PM
To: pen-test@securityfocus.com
Subject: Re: Pen Test help
On Sunday 17 July 2005 14:32, Juda Barnes wrote:
> Anyway the machine have 53/tcp open port so if I will have the
> right exploit I will be able to bind to 53 the shell
That won't work. To bind on top of another service under Windows you have to
specify the local address in the bind() call. The metasploit win32_bind
payloads do not do this, so it will end up binding a shell to
some random TCP port instead.
Your best bet is to put your attacking system outside of a firewall and use
the win32_reverse payloads instead (25, 80, 443, etc).
> msf iis50_webdav_ntdll(win32_exec) > check [*] Server does not appear
> to be vulnerable Well I tried most of the framework exploits none of
> them work.
Are you sure that the system is vulnerable to anything? The metasploit check
seems to disagree with the Nessus scan results, are you using an older
version of Nessus?
-HD
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:36 EDT