Re: Meterpreter Reverse HTTP(s) Payloads after last update

[Enis Sahin <enis.c.sahin () gmail com>]

Got it to work right after my last email but postponed an update since we
were still working on the project. Apparently my Metasploit installation
was broken after all the meddling I've done.

Here are the things to look for if you are getting "unknown command" errors
upon session creation:

1) Check that metsrv.dll is getting past the Web Gateway. If not, you have
to modify it to make it undetectable.
2) Set up the listener with your external IP or Domain Name if you are
using a port-forwarded set-up. Metsrv tries to connect to the IP you gave
to the listener once it gets downloaded.
3) Payload explicitly uses the word meterpreter in the user-agent field.
Your communication might get blocked by the proxy if you leave it at the
default.**

Good hunting.
Enis


On 1 November 2011 16:25, Enis Sahin <enis.c.sahin () gmail com> wrote:

> OK, after a little more testing here's what I came up with. We wrestled
> with the metsrv.dll a little and finally got it past the gateway AV. But
> when I executed the first command I received the familiar "unknown command"
> error. So I tried our modified dll in a LAN environment and got the same
> error.
>
> Finally to understand if we broke the dll or not we used the original
> metsrv.dll in the same LAN environment and received "unkown command" error
> here too. As it is, reverse_http meterpreter payload (stdapi) is not
> working for us even in a LAN environment.
>
> If anyone else has this working in either a LAN environment or over the
> Internet, I'd appreciate some feedback.
>
> Thanks.
> Enis
>
> On 8 October 2011 09:52, HD Moore <hdm () metasploit com> wrote:
>
> > On 10/5/2011 9:32 AM, Enis Sahin wrote:
> > > Well, not many seem to be interested in the subject but I'd like to make
> > > one final request/recommendation on the issue of reverse HTTP(s)
> > payloads.
> > > Staged payloads are used to evade AV detection but in HTTP tunneled
> > > scenarios where a Web Gateway with AV capabilities exits using staged
> > > payloads make us go through two layers of AV (one in local, one in web
> > > gateway). Plus SSL inspection is used in some infrastructures thus
> > > utilizing HTTPS connections to download the second stage doesn't improve
> > > the outcome.
> > >
> > > If HD is following these posts I'd like to request a sinlge stage
> > > reverse HTTP(s) payload to be considered for the future versions. It is
> > > easier to use different encodings and packers for local AV evasion and
> > > test against local agents. Finding a combination of a delivery method
> > > which bypasses local AV and a second stage which bypasses web gateway AV
> > > detection is significantly harder. It seems like it would make more
> > > sense to battle on one front and use a single stage in such scenarios.
> >
> > Its pretty easy to make an inline stage out of what we have today and
> > the handle will go straight to the session if a connection comes in with
> > /CONN as the prefix. The current process just uses stage1 to download
> > stage2 (the entire DLL plus prefix) into RWX memory and executes it.
> > Theoretically, all you have to do is patch the host/url/id values into
> > the stage2 and treat it as a giant payload. Adding support for this to
> > the framework would be nice though and I'll try to work it in soon.
> > Thanks for the feedback
> >
> > -HD
> > _______________________________________________
> > https://mail.metasploit.com/mailman/listinfo/framework
>
>
>
> --
> http://www.enissahin.com | http://twitter.com/enis_sahin


-- 
http://www.enissahin.com | http://twitter.com/enis_sahin

_______________________________________________
https://mail.metasploit.com/mailman/listinfo/framework