It was October 31, 2014. We were running a Red Team exercise against our environment, it was the first engagement we had conducted since deploying our then Bit9 App whitelisting software. Which was kicking our asses. We had to learn to completely retool. Dropping arbitrary unsigned, unapproved binaries was NOT going to work..
So, in an effort to try to circumvent the whitelisting we started enumerating all default .NET binaries on the system we were on. We had proved earlier that year, this might actually be a useful angle for attack. Details here: Application Whitelist Bypass Using IEExec .
For each binary, we asked the question.... How could I get this binary to execute my code... We were looking in:
The default path on Window 7.
After a couple hours trolling MSDN we worked our way alphabetically through the list of Assemblies. We landed on InstallUtil.exe
InstallUtil.exe on MSDN
Now we needed to find a sample or understand HOW InstallUtil triggers execution... No real luck so we decided to Reverse the Assembly.
We used a .NET tool called ILSpy, you can also use dnSPy.
The first path from the args input passed to a Method call occurs on line 18.
This is important, cause we want to know what we can control or influence to get our assembly to execute. We needed to know what InstallUtil.exe is looking for. We can trace the arguments as they pass through ManagedInstallerClass.InstallHelper().
For sake of brevity... We learned that we can influence InstallUtil.exe by crafting an Assembly that gets ingested by InstallUtil.exe and executed. If you continue to read/work through the Assembly. You will find that you need to decorate a class with the attribute
This lead to some really interesting behavior. We discovered, we could execute this file in our environment, EVEN if we explicitly banned that file. This can be execute by any normal user and does not require any additional privileges to execute.
This was a real gem for sure. We used the utility InstallUtil.exe to complete our mission and about a week and a half later, I finally had some time to report to the vendor. I posted a question to Bit9 in their User Exchange.
I won't share all the details of my original post, but the Carbon Black [CB] User Exchange is a fantastic way to share configuration data, Threat Intel and its a huge asset for CB customers and still is.
CB engineering immediately reached out to me and began digging into the internals of what caused this behavior, and it was subsequently fixed in later releases of their product.
Carbon Black (Bit9 when I was growing up ;-) . Has formal disclosure mechanism in place and they are really great to work with. Reporting Security Vulnerabilities
If you want to test this against your environment, here is the original gist:
Shellcode via InstallUtil
Later we would write a full blown PE Loader for Mimikatz in InstallUtil
Mimikatz Inside InstallUtil
Here are some screen shots of my original dialogue / disclosure:
What does this all mean, and why am I posting this?
1. You should be aware of InstallUtil.exe as a mechanism to launch unapproved binaries.
2. When you find something, working with the vendor directly helps everyone be prepared.
3. Never stop being curious and investigating ways to adapt on an engagement.
4. InstallUtil has been seen in the wild example: Operation Cloud Hopper
5. This bypass, affects AppLocker as well as other Whitelisting tools. Not Device Guard though.
6. .NET visibility is weak for a defender perspective, and its easy for an attacker to hide here.
7. App Whitelisting, even in audit mode allows you to track unsigned binaries as they move around your fleet. For example, once we knew the hash, we could hunt where else it had landed.
I hope this was some helpful context on InstallUtil.exe and its history.