metasploit-framework October 2011 archive
Main Archive Page > Month Archives  > metasploit-framework archives
metasploit-framework: Re: [framework] Meterpreter Reverse HTTP(s

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

From: Sherif El-Deeb <archeldeeb_at_nospam>
Date: Wed Oct 05 2011 - 15:53:07 GMT
To: Enis Sahin <enis.c.sahin@gmail.com>

Sorry, I meant "metsvc"-like reverse_https that is not staged.

On Wed, Oct 5, 2011 at 6:18 PM, Sherif El-Deeb <archeldeeb@gmail.com> wrote:

> <+1
> It would be great having a single metsrv-like reverse_https for those
> tricky situations.
> On Oct 5, 2011 5:35 PM, "Enis Sahin" <enis.c.sahin@gmail.com> 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.
> >
> > Thanks.
> > Enis
> >
> > On 4 October 2011 13:15, Enis Sahin <enis.c.sahin@gmail.com> wrote:
> >
> >> An update on my inquiries for the BUG#4928 (Reverse HTTP(s) payload
> >> connection problems upon sessions establishment).
> >>
> >> The second stage may be getting blocked by the web gateway/proxy. For
> those
> >> who are facing the same connection issues, check out the packet capture
> >> carefully from the client machine. We've first noticed that second stage
> was
> >> getting blocked due to user policy on downloading executables, after the
> >> policy was set accordingly we saw that proxy was sending 403 forbidden
> due
> >> to malicious software/virus while trying to receive the second stage of
> the
> >> payload.
> >>
> >> Reminds me.. Try harder :D
> >>
> >>
> >> Enis
> >>
> >> --
> >> 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