|Main Archive Page > Month Archives > metasploit-framework archives|
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.
On 4 October 2011 13:15, Enis Sahin <firstname.lastname@example.org> 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
> Reminds me.. Try harder :D
> http://www.enissahin.com | http://twitter.com/enis_sahin