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

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

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

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