Recently, Component Object Model (COM) has come back in a big way, particularly with regards to it being used for persistence and lateral movement. In this blog we will run through how it can also can be used for limited process migration and JavaScript injection within Internet Explorer. We will then finish with how this was put together in our new PowerShell library Invoke-PowerThIEf and run through some situations it can aid you, the red team, in.
Earlier this year I became aware of a technique that involved Junction Folders/CLSID that had been leaked in the Vault 7 dump. It was when I began looking at further applications of these that I also learned about the Component Object Model (COM) ability to interact with and automate Internet Explorer. This, of course, is not a new discovery; a lot of the functionality is well documented on sites like CodeProject. However, it hadn’t been organised into a library that would aid the red team workflow.
This formed the basis of my talk “COM and the PowerThIEf” at SteelCon in Sheffield on 7th July 2018. The slides for the talk can be found at:
The talk itself is here:
Getting up to speed with COM
Before we dive into this, if you are not familiar with COM then I would highly recommend the following resources. These are a selection of some of the recent excellent talks & blog posts on the subject that I would recommend if you want to know more.
- COM in 60 Seconds by James Forshaw – https://vimeo.com/214856542
- Windows Archaeology by Casey Smith & Matt Nelson – https://www.youtube.com/watch?v=3gz1QmiMhss
- Lateral Movement using Excel Application and DCOM by Matt Nelson – https://enigma0x3.net/2017/09/11/lateral-movement-using-excel-application-and-dcom/
Junction Folders
I first came across the Junction Folders/CLSID technique mentioned above in one of b33f’s excellent Patreon videos. As I understand it, this was first used as a method for persistence, in that if you name a folder in the format CLSID.{<CLSID>} then when you navigate to that folder, explorer will perform a lookup in the registry upon the CLSID and then run whatever COM Server has been registered. As part of his DefCon 25 WorkShop (which is worth a read, hosted at https://github.com/FuzzySecurity/DefCon25) he released a tool called Hook-InProcServer that enabled you to build the registry structure required to be used for a COM Hijack or for the JunctionFolders/CLSID technique. These were both being used as a Persistence mechanism and I began wondering if this might be possible to use as a means of Process Migration, at least into explorer.exe.
Step one was to find if it was possible to programmatically navigate to one of the configured folders and – yes – it turns out that it is. In order to be able to navigate, we first need to gain access to any running instances of explorer. Windows makes this easy via the ShellWindows object:
Enumerating the Item property upon this object lists all the current running instances of Explorer and Internet Explorer (I must admit I thought this was curious behaviour). ShellWindows is identified by the CLSID “{9BA05972-F6A8-11CF-A442-00A0C90A8F39}”; the following PowerShell demonstrates activating it.
$shellWinGuid = [System.Guid]::Parse("{9BA05972-F6A8-11CF-A442-00A0C90A8F39}")
$typeShwin = [System.Type]::GetTypeFromCLSID($shellWinGuid)
$shwin = [System.Activator]::CreateInstance($typeShwin)
The objects returned by indexing the .Item collection will be different based upon if it is an explorer and IE instance. An easy check is using the FullName which exists on both and has the name of the application, as shown here.
$fileName = [System.IO.Path]::GetFileNameWithoutExtension($shWin[0].FullName);
if ($fileName.ToLower().Equals("iexplore"))
{
// Do your IE stuff here
}
This article (https://www.thewindowsclub.com/the-secret-behind-the-windows-7-godmode) from 2010 not only contains the Vault7 technique but also shows that it is possible to navigate to a CLSID using the syntax shell:::{CLSID}. Assuming that we have at least one IE window open, we are able to index the ShellWindows.Item object in order to gain access to that window (e.g. to gain access to the first IE window, use $shWin[0].Item). This will provide us an object that represents that instance of IE and is of a type called IWebBrowser2. Looking further into this type, we find in the documentation that it has a method called Navigate2. (https://msdn.microsoft.com/en-us/library/aa752134(v=vs.85).aspx). The remarks on the MSDN page for this method state that it was added to extend the Navigate method in order to “allow for shell integration”.
The following code will activate ShellWindows, assuming the first window is an IE instance (this is a proof of concept) and will then attempt to navigate to the Control Panel via the CLSID for Control Panel (which can be found in the registry).
$shellWinGuid = [System.Guid]::Parse("{9BA05972-F6A8-11CF-A442-00A0C90A8F39}")
$typeShwin = [System.Type]::GetTypeFromCLSID($shellWinGuid)
$shwin = [System.Activator]::CreateInstance($typeShwin)
$shWin[0].Navigate2("shell:::{ED7BA470-8E54-465E-825C-99712043E01C}", 2048)
/*
CLSID must be in the format "shell::{CLSID}"
Second param 2048 is BrowserNavConstants value for navOpenInNewTab:
https://msdn.microsoft.com/en-us/library/dd565688(v=vs.85).aspx
Further ideas on what payloads you may be able to use:
*/
The following animation shows what happens when this code is run:
Control Panel being navigated to via CLSID ID:
We can then see via a trace from Process Monitor that IE has looked up the CLSID and then navigated to it, eventually opening it up in explorer, which involved launching the DLL within the InProcServer registry key. If we create our own registry keys we then have a method of asking IE (or Explorer) to load a DLL for us all from the comfort of another process. We don’t always want network connections going out from Word.exe, do we? In the case of IE the DLL must be x64. There are methods of configuring the registry entries to execute script; I suggest that you look at subTee’s or bohop’s excellent work for further information.
JavaScript
Once a reference is obtained to an Internet Explorer window it is then possible to access the DOM of that instance. As expected, you then have full access to the page and browser. You can view and edit HTML, inject JavaScript, navigate to other tabs and show/hide the window, for example. The following code snippet demonstrates how it is possible to inject and execute JavaScript:
The difference this time is that we actually have to locate the eval method on the DOM window before being able to call it. This requires using .NET’s Reflection API to locate and Invoke the method.
The following shows what happens this code is run.
Where is this all going?
Well, despite the programming constructs and some of the techniques being well documented, there didn’t appear to be a library out there which brought it all together in order to help a red team in the following situations:
- The target is using a password manager, e.g. LastPass where key-logging is ineffective.
- The user is logged into an application and we want to be able to log them out without having to clear all browser history and cookies.
- The target application is in a background tab and can‘t wait for user to switch tabs. We need to view or get HTML from that page.
- We want to view a site from the targets IP address, without the target being aware.
This led to me writing the PowerThIEf library which is now hosted at https://github.com/nettitude/Invoke-PowerThIEf.
The functionality included in the initial release is as follows:
- DumpHtml: Retrieves HTML from the DOM, can use some selectors (but not jQuery style – yet).
- ExecPayload: Uses the migrate technique from earlier to launch a payload DLL in IE.
- HookLoginForms: Steals credentials by hooking the login form and monitoring for new windows.
- InvokeJS : Executes JavaScript in the window of your choice.
- ListUrls: Lists the urls of all currently opened tabs/windows.
- Navigate: Navigate to another URL.
- NewBackgroundTab: Creates a new tab in the background.
- Show/HideWindow: Shows or Hides a browsing window.
Examples of usage and functionality include:
Extracting HTML from a page:
Logging the user out, in order to capture credentials:
Using the junction folders to trigger a PoshC2 payload:
Capturing credentials in transit entered via LastPass:
Usage
The latest Invoke-PowerThIEf documentation can be found at:
Roadmap
Further functionality is planned in the future and will include
- Screenshot: Screenshot all the browser windows.
- CookieThIEf: Steal cookies (session cookies).
- Refactor DOM event handling: Developing Complex C# wrapped in Powershell is not ideal.
- Pure C# Module
- Support for .Net 2.0-3.5
GitHub: 
