Metasploit mailing list archives
Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION
From: eip at tampabay.rr.com (eip)
Date: Wed, 16 Feb 2005 14:58:52 -0500
While this may not make a good payload it is something that you could do once you have command line access to the system. Many times I hear how the command line of a Win32 system is not as powerful as a *NIX system, but those people have not explored WMI, ADSI or any of the other things that MS has by default in any of it's OS's. Once you have command line access you could easy write this type of VBscript/Jscript to control IE. I would be interested in seeing some of the rootkits from rootkit.com make it into some type of DLL injected payload. It would be nice to be completely stealth once a system has been compromised. To be able to hide the connection, process, etc. would be great. eip ----- Original Message ----- From: <mmiller at hick.org> To: "eip" <eip at tampabay.rr.com> Cc: "ALLAIN Yann" <Yann.Allain at accorservices.com>; "H D Moore" <hdm at metasploit.com>; <framework at metasploit.com> Sent: Wednesday, February 16, 2005 1:05 PM Subject: Re: [framework] Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION
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).
Current thread:
- Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION ALLAIN Yann (Feb 16)
- Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION mmiller at hick.org (Feb 16)
- Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION eip (Feb 16)
- Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION mmiller at hick.org (Feb 16)
- Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION eip (Feb 16)
- Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION mmiller at hick.org (Feb 16)
- Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION eip (Feb 16)
- Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION mmiller at hick.org (Feb 16)
- Idea for a new payload : Manipulate Internet Explorer with OLE AUTOMATION mmiller at hick.org (Feb 17)