Recently I published a Proof of Concept that showed it was possible to launch unauthorized processes with both AppSense Application Manager and RES Workspace Manager.

Although I didn’t test Microsoft Applocker I have no doubt at all that we couldn’t bypass it.

I have named my Proof of Concept the XLSploit because I am using Excel as a trampoline. I choose Excel because this is generally a trusted process and VBA offers access to the Windows API that is needed.

After publishing the XLSploit I have talked to both RES and AppSense and not that they both have a response to my Proof of Concept, I consider it safe to tell a little more about how it works.

If you are merely interested in stopping the XLSploit, please scroll down to the end of the article.

How does it work?
From a trusted process we launch another copy of any trusted process (the Host Process) using the CreateProcess API. In my case I am launching a second instance of Excel from Excel.

In the dwCreationFlags parameter I specify the CREATE_SUSPENDED Process Flag. This will start the process but it will halt after loading ntdll.dll and before executing the Loader Routine. We can see this in Process Explorer, the process is highlighted in gray which indicates it’s in suspended state:

Now we load the process that we actually want to launch (the Target Process), but instead of calling the CreateProcess API we load it in memory as a binary file.

You may have guessed the idea by now: we are going to “replace” the suspended process in memory with the contents we read from disk.

This means we first need to get the address of the PEB (Process Environment Block) using the GetThreadContext API. The PEB Address is in the EBX field of the retrieved CONTEXT structure.

Using the ReadProcessMemory API we read the Image Base Address from the PEB and unmap it from the Host Process.

Using the IMAGE_DOS_HEADER, IMAGE_NT_HEADERS we can analyze the target process and copy it’s contents to the memory space of the Host Process.

Depending on the OS we need to do some fixups such as base relocations, account for Side By Side manifests and MUI resources.

After that we set the Thread Context using the SetThreadContext API to the entry point of the Target Process and resume the process using the ResumeThread API.

After resuming we seem to have a second instance of Excel.exe:

Even the Window Title shows Excel:

Even Process Explorer shows that we are running Excel:

Is it an Excel Exploit?
No! We could use any trusted process for this exploit that offers us access to the Windows API. The convenience of VBA in Office is that it allows us full access to the Windows API.

Is it a Windows Exploit?
No, I don’t think so. The Windows security model protects you from the outside (think other computers) and from other users. It does not protect you from yourself; you have permissions to open, debug, kill, do anything with your own processes.

Is it malware?
The XLSploit is not malware, it doesn’t damage your system in any way. However the code does things that are typically associated with malware. Therefore your Virus Scanner should at least find it suspicious. The strange thing is that if I place similar code in an executable or DLL, all Virus Scanners alert. But when used from VBA most Virus Scanners seem to allow it.

What it does not do
Using this method we can successfully launch unauthorized processes, however we do not gain additional privileges (aka privilege escalation). If you are a standard user, you still will not have permissions to delete system folders and files. It could of course be a first step towards that but we would need other exploits for it.

How to stop this Exploit?
First of all: you should set Office Macro Security to High and prevent users from changing it. I know this probably breaks all applications you use, so you should really put pressure on your vendors and have them sign their macro’s. Or as an alternative, self sign them.

Secondly: Implement A Virus Scanner that uses the Office AntiVirus API to scan documents and macro’s. Most Home versions of AV products seem to have this while Enterprise products often do not. Perhaps because of performance reasons.

For RES Workspace Manager see: Q203322 HOWTO: How to prevent malicious Microsoft Office macros and here.

For AppSense Application Manager see: AppSense Blog