This series of posts are not meant to be the latest and greatest of our creations, just some details about popular scenarios in our library that we think might be of some interest for the people out there. Some of these will be kept high level and in others, we will go into greater technical details. We’ll always try to be as clear as possible on how we implement our philosophy “Think Bad, Do Good” by creating techniques that mimic the same TTPs followed by threat actors while keeping things safe for our customers.
Application whitelisting is a common technique used to prevent execution of unknown or potentially malicious applications. However, this technique can be bypassed if not implemented correctly. There are certain applications that are commonly whitelisted that allow other programs to be executed and appear as that application. One such application is the InstallUtil binary found in the .NET framework.
At AttackIQ, we developed the arbitrary code execution through installutil scenario that mimics this technique in an attempt to bypass application whitelisting or blacklisting technologies. Executing this scenario will determine if the application whitelisting technology present on the target machine is properly configured to stop abuse of the InstallUtil executable.
In the MITRE ATT&CK matrix, bypassing application whitelisting is categorized as Defense Evasion and Execution.
A popular whitelist bypassing technique was founded by subTee, and uses the InstallUtil binary found within the .NET framework (version 1.1 and up). This tool is supposed to be used to install or uninstall system resources required for the application to run correctly. However, it can be be used to execute any code found within the install or uninstall functions within the executable. The code within this executable will be executed as the installutil process, and will appear in a process monitoring program, such as task manager, as ‘installutil.exe’.
The C# code of the executable should look something similar to the following:
public class Program
public static void Main()
// Generic code execution
Console.WriteLine(“I am a normal program!”);
public class Sample : System.Configuration.Install.Installer
public override void Uninstall(System.Collections.IDictionary savedState)
// malicious code here
There is another tool found in the .NET framework called csc.exe, which can be used to compile an executable from C# code. This means that an attacker doesn’t necessarily need to download a compiled executable to the target computer, but can instead download the source code and compile it on the target computer.
Most application whitelists will not allow an executable such as the one we created to run, as seen below. In this example, we use AppLocker and configure it to only allow signed executables to run.
However, we know a way around this! We can bypass this security control by abusing the InstallUtil binary. The following command will allow us to execute the uninstallation code found within our executable:
- Installutil.exe /U compiled.exe
You can see here that using the installutil executable has allowed us to execute the code found within the uninstall function of our executable.
If we take a look at the list of processes in the task manager, you will notice that our executable does not show up on the list. Instead it shows as installutil.exe. We have managed to successfully bypass AppLocker, the whitelisting technology used in this example.
Mitigation and Detection
The application whitelist bypassing technique discussed above can be mitigated by denying execution of the InstallUtil binary.
With AppLocker, we create a rule that will deny execution of the installutil.exe. Keep in mind that there can be multiple versions of the .NET framework on any one machine, which means that there can be multiple versions of the binary. All versions of the InstallUtil executable should be denied. Implementing this rule gives us the following:
It is also quite simple to focus on detection of threats such as these. Most whitelisting applications can be configured to detect and log upon a rule violation, instead of denying program execution. For AppLocker, it is as simple as changing it from Deny to Audit mode. Audit mode will allow the programs to execute, but will create a warning that is viewable in Event Viewer.
It should also be noted that there is a similar technique that uses msbuild.exe instead of installutil.exe. This executable is found in the same directory as installutil.exe, so the mitigation and detection strategies are the same.
At AttackIQ we are dedicated to ensuring that our customers are able to validate that their security controls are configured as optimally as possible. We created this scenario to allow customers to validate that their current application whitelisting technology is properly configured to stop these kind of attacks. It was also intended to raise concerns over using default configurations for tools such as these, where the defaults do not cover ‘safe’ applications that can be abused in this fashion. We implore you to go beyond the defaults, and dedicate time configuring your security tools to handle lesser known threats such as the one discussed here.
For our existing customers, we urge you to run this scenario and see how well you are currently able to mitigate a threat such as this.