Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION

[mmiller at hick.org (mmiller at hick.org)]

On Wed, Feb 16, 2005 at 12:09:46PM -0500, eip wrote:
> The OLE/IE automation that ALLAIN was talking about can be found here:
>
> http://www.securiteam.com/securityreviews/6S0030ABPE.html
>
> Basically they use IE to go and fetch pages from one of there servers. The
> pages they control tell the client what to do. The reason they use IE is so
> that they can bypass client side firewalls/IPSs. I think SecurityFriday
> initially found this techinique and present it at BlackHat
> (http://www.securityfriday.com/tools/IEen.html) a few years ago. They have a
> program called IE'en. It allows you to remotely watch and/or control
> someones Internet Explorer. It is kind of like an Internet Explorer sniffer
> of sorts.

Ah, okay.  I remember reading about it now.  While the technique
certainly has its uses as a polling remote command execution type system
(and allows for more complicated things depending on how indepth you
choose to go), it is not applicable to building a stream-based
connection that you can use for tunneling data between the target
machine and the attacker (as would be required for an interactive
command shell or for meterpreter).  I think that sort of thing is
outside of the scope of their implementation, though, so it's not fair
to claim it as a weakness in their design.

You could certainly build a payload that integrates a solution like
this, but I believe most HIPS products have gotten wise to the use of
CreateRemoteThread as a vector for code injection into another process.
If not, they are behind the times :).  Also, the act of executing a 
hidden instance of internet explorer is not very steathly either, and
under most circumstances a HIPS implementation would be right to warn
a user about what is happening, though I'm not aware of any that
currently do such a thing.  The primary problem that one
would run into when implementing a payload that uses the technique
outlined in the URL you provided is the size of the payload.  The basic
steps that would be required are:

First stage (in the context of the exploited process):

  - Execute internet explorer with StartupInfo.wShowWindow set to
    SW_HIDE (CreateProcess)
  - Allocate memory in the context of the internet explorer process
    (VirtualAllocEx)
  - Write the contents of your second stage payload (which must be
    included in the first stage) to the allocated address
    (WriteProcessMemory)
  - Create a thread in the context of the internet explorer process
    to execute the second stage
    (CreateRemoteThread)

Second stage (in the context of internet explorer):

  You can do one of three things at this stage.  You can either create an
  instance of an object that implements the IActiveScript interface,
  create an instance of an object that implements the IWebBrowser or
  IWebBrowser2 interface, or create an instance of an object that
  implements that Internet Explorer's OLE automation interface (don't
  have it handy).  All three implementations require a non-trivial
  amount of code that is likely to produce a very large second stage.
  Furthermore, your second stage either needs to be implemented in
  position-independent C++ or in position-independent assembly.

It seems to me that, while this technique does indeed have its merits,
its actual implementation would require a rather large payload that
would most likely not be usable in most exploit scenarios.  Given the
requirement that the request be sent from a trusted process, it is not
possible to implement a small first stage payload that downloads the
larger second stage via a small HTTP request.

Note that the authors of the paper used a trusted application to run
their VBS application and thus did not need to go through the hassale 
of implementing the above solution (as would be required for a true
payload implementation).