This changes the x86 version to the (10 bytes) larger variant that can
handle full 32-bit jumps which is necesary for maximum compatibility
within the framwork.
Additionally, numeric literals are expressed in hex for compatibility
with the keystone assembler allowing these files to be compatitble with
external tools.
This stager looks for proxy credentials in windows protected storage. If it finds proxy credentials, it will use them to connect back. If it does not find credentials, it will do the same as stager_reverse_http.
Works on:
- Windows Server 2003
- Windows XP
- Internet Explorer versions 4 to 6
This will make copy-pasta less painful in the future. There's still the
problem of reverse_https_proxy being very similar, but the logic in how
it gets generated in the module is more than i want to tackle right now
The HttpOpenRequest function from WinINet requires the
INTERNET_FLAG_KEEP_CONNECTION flag to communicate through an
authenticated proxy.
From MSDN ( http://tinyurl.com/chwt86j ):
"Uses keep-alive semantics, if available, for the connection. This
flag is required for Microsoft Network (MSN), NT LAN Manager (NTLM),
and other types of authentication."
Without this flag, the HTTP stager will fail when faced with a proxy
that requires authentication. The Windows HTTPS stager does not have
this problem.
For HTTP Meterpreter to communicate through an authenticated proxy a
separate patch will need to be made to the Meterpreter source code.
This is at line 1125 of source/common/core.c in the Meterpreter source
code.
My motivation for this request is for windows/dllinject/reverse_http
to download a DLL even when faced with an authenticated proxy. These
changes accomplish this.
Test environment:
I staged a SmoothWall device with the Advanced Proxy Web Add-on. I
enabled Integrated Windows Authentication with a W2K3 DC. I verified
the HTTP stager authenticated to and communicated through the proxy
by watching the proxy access.log
ESI is not clobbered; no need to clear EDX as only DL is filled before and
it is overwritten before use.
Shellcodes in ruby modules not regenerated, but I guess you want to
regenerate them again anyway :-)
Those stagers will encrypt the initial stage with a 128-bit RC4 key and
the stage length with a XOR key. Both keys are embedded in the stager.
This should provide good evasion capabilities in addition to some
protection against MITM reversing (if the stager is sent a different
route, like in an executable on an USB key).
Note that, from a cryptanalyst's standpoint, it is a bad idea to reuse the
same stager (or stagers with the same RC4 and XOR keys) more than once
since an identical key will result in an identical keystream and make
correlation attacks easy. But I doubt that matters in practice.
Also note that since communication after the initial statging is not
encrypted, these stagers should be used in combination with additional
encryption support in the payloads (like Meterpreter).
Provided as a block to be included into stagers and/or decoder stubs.
Also included is a test shellcode that can be used for verifying that the
algorithm is compatible to Ruby's OpenSSL RC4 algorithm.
Spencer McIntyre