After having showed you how my Basic Process Manipulation Tool Kit can be used to bypass Software Restriction Policies, I wanted to follow this with a post showing how SRP whitelisting can prevent this. However, while preparing this new post, I got an idea how I could bypass SRP whitelists (under certain conditions), but I’ve no idea how to prevent this. I finally decided to post this without a solution, maybe you’ll come up with one.
With a SRP whitelist, starting a program is denied by default:
As an administrator, you’ve to explicitly specify the programs that are allowed to be executed by your users (if there are many programs, maintaining this whitelist becomes time consuming). Because of this whitelist, tools like gpdisable or bpmtk can’t be executed to disable SRP. However, if I can execute these tools without starting a new process, SRP will not block them …
Applications with embedded scripting can also be used to manipulate processes. For example, the scripting features of Microsoft Office allow you to call the system APIs I’ve been using in my bpmtk. It’s often not easy (even impossible) to convert a C program to VBscript, but I’ve a workaround.
First, we adapt our C program from an EXE to a DLL (entrypoint DllMain in stead of main), because VBscript can load a DLL.
We’ll use Excel’s scripting features. I’ve created an Excel spreadsheet that embeds a DLL that can be executed with a mouse-click:
The MyDLL dialog is displayed by the embedded DLL.
The DoIt button starts this Sub:
DoIt will create a temporary file (in the user’s temporary file folder), write the embedded DLL to it (DumpFile), and then load the DLL (LoadLibrary).
Generating the temporary filename:
Writing the embedded DLL to the temporary file:
Each DumpFileX sub writes bytes to the temporary file (the DLL is embedded in these subs by including the hex dump in strings). It’s necessary to split this over several subs, because of the sub size limitation.
Once the DLL is stored in the temporary file, we call LoadLibrary to load our library in the Excel process. And this executes our code inside the Excel process. Because of this, SRP will not deny it, and our code can disable SRP.
Creating temporary files and loading libraries is normal behavior for programs, SRP will not block this. Even most HIPS will not block this, because loading a library is not the same as injecting a DLL (injecting a DLL is loading a library inside another process). The only thing that might be considered abnormal by the HIPS, is that a temporary file is mapped into memory, but there are also legitimate programs that do this.
SRP has an option to whitelist DLLs, but then you’re facing the huge task of identifying and specifying all DLLs your programs use!
If you implement a SRP whitelist because you absolutely want to control the programs executed by your users, take some time to reflect on your users and the scripting capabilities of your whitelisted applications. And if you really have to prevent the technique I show here, you’ll have to find another solution than SRP whitelists. Unfortunately, I’ve not found one yet… If you’ve an idea, post a comment (banning applications with embedded scripting or disabling scripting is not an option).