You may recall that when we use Metasploit encoders to
obfuscate on Meterpreter stages,
we were able to drastically reduce the number of detections which were
being triggered by antivirus scanners on virus total.
IDS and network‑based antivirus solutions might analyze network
packets in an attempt to match known malicious byte sequences similar
to how an antivirus scanner might attempt to match byte sequences
inside a file being written to disk.
When Meterpreter stages connect to the Metasploit handler,
the handler sends back the payload and a few extensions.
As these files are being downloaded by the stager,
they might get scanned and blocked if a malicious artifact is observed
during communication by a network security system.
The Metasploit encoders, which we used when evading antivirus on
disk, can also be used to encode the payload and extensions
before sending them back to the stager.
This can be done by setting the enable stage encoder option to true
and specifying the encoder we want to use with the stage encoder
option when configuring our Metasploit handler.
This works exactly the same way as it does when encoding stages.
The payload is read from disk by the handler, the small stub
of shellcode which triggers the reflective loader is added
in the payload's DOS header.
The payload is then encoded and a decoder stub is
added in front of the encoded payload.
This data is then sent back over the network and any signature‑based
detections will no longer match since the data is obfuscated.
Let's now take a closer look at why encoding the payload and extensions may be
required when using Meterpreter in a secure environment.
I have configured an HTTP proxy on the Windows machine
which will be our victim system.
Proxy servers are commonly used in environments that want to
control user's web browsing activities.
They can be used to blacklist certain websites based on
categorization. A company may, for example,
prevent HTTP traffic to websites hosting social media services.
Proxy service can also be used to prevent downloads
of potentially dangerous files,
which may compromise the internal network if the files were
to be executed on an internal system.
Finally,
a proxy server can communicate with an ICAP server using the ICAP protocol.
The ICAP server can then process the request, and for example, run it
through an antivirus scan in an attempt to detect malware.
The proxy which I have configured is a Squid proxy which leverages the ICAP
protocol to interface with the open source ClamAV antivirus.
I have disabled the antivirus on the victim's machine to
avoid any interference, and we will be reusing the shellcode
runner which we wrote previously.
The Metasploit handler has already been started and has not been configured
with the enable stage encoder option which means that the payload will be
sent back to the stager unencoded. I have a terminal window open on the
proxy server which is tailing the ICAP server logs in which an alert would
surface If ClamAV detects something. Let's now place a breakpoint on the
line of code where we execute the stager and go ahead and launch our
shellcode runner.
Once the breakpoint has been hit,
let's switch to the assembly mode and step into the call.
Let's now place a breakpoint on the right instruction which transfers
execution into the payload, and check the address which we are about to
return to which is stored on the stack.
If we inspect this memory location,
you will notice that we did not receive our payload and that there appears
to be html tags inside the response from our handler.
Looking closer reveals that ClamAV detected a virus.
If you go to our handler,
you will notice that it did indeed send the payload back, but
evidently the stager never received it because it was detected and
blocked whilst traversing the network.
We can also review the ICAP server logs to see that
the detection has indeed occurred.
Let's now stop the debugger and reconfigure our handler so that it
encodes the payload before sending it over the network.
We can do this by setting the enable staging coder option to true and
specifying the encoder to use by setting the stage encoder option
followed by the name of the encoder we want to use.
We will now launch our shellcode runner one more time until we reach
the final right instruction as we did previously.
(Working) This time, however,
you will notice that we do not have html tags in memory and a
message telling us that the request was blocked because of
malicious browsing activity as it did previously.
If we step into this code,
you will find that we are, in fact, stepping inside Zutto
Dekiru's decoder stub, which will decode the payload, and
once decoding is finished,
it will fall through into the original payload and trigger the
little stub of shellcode inside the DOS header,
which will trigger the reflective loader and call DLL main,
which will complete the initialization.
Bear in mind that all subsequently loaded modules and the
extensions will also be encoded using the specified encoder. In
this case, since Zutto Dekiru's decoder stub is polymorphic and the
X all key used is randomly generated,
it would be very hard to develop a reliable signature.
If we check the ICAP server's log file,
we can see that no detection has occurred, and if
we check our Metasploit handler,
we will find a fully functional Meterpreter shell.