InstallUtil is a command line utility that installs and uninstalls resources by running installer components specified in .NET binaries. It may be digitally signed by Microsoft and lives in the .NET directories under C:\Windows, in the Framework and Framework64 folders. MITRE ATT&CK tracks its abuse as T1218.004, InstallUtil, in the Stealth tactic, on Windows.
How attackers use it
MITRE explains that InstallUtil can be used to proxy execution of code through a trusted Windows utility. It can also bypass application control by using an attribute inside the binary, RunInstaller, that marks the class to be executed. The assembly does not need to look like a normal program. The tool simply finds the decorated class and runs it.
The point for defenders: the process that appears in the logs is a signed Microsoft binary from a .NET directory, and the interesting content is in a file you may never have seen before.
Why this is easy to miss
Allow lists often trust the .NET directories. Signature checks pass because InstallUtil itself is genuine. A rule that only asks whether the running binary is signed will say yes.
What gives it away is the argument. Legitimate use points InstallUtil at installers your own teams built or bought. Abuse points it at an assembly in a user writable folder, or at one that was created moments before.
How to detect it
The MITRE strategy looks for InstallUtil.exe running from .NET framework directories with arguments naming non-standard or attacker-supplied assemblies, especially when followed by suspicious child process creation or script execution. It also suggests correlating newly created binaries that appear before the InstallUtil call, and comparing command lines with historical baselines.
To put that into practice:
- Collect process creation events with command lines (Sysmon event ID 1 or Security event 4688).
- Collect file creation events (Sysmon event ID 11) so you can link a new assembly to the run that follows.
- Record which assemblies InstallUtil normally loads in your environment, then alert on new paths.
How to reduce the risk
- Use application control to block execution of InstallUtil.exe if it is not required.
- Remove or disable it where it is not needed. MITRE says it may not be necessary in your environment at all.
On developer and build machines it may be needed. Scope the block to the machines that do not need it.
Check your own environment
- Which machines have a real reason to run InstallUtil.exe?
- Is it blocked on ordinary user laptops and on servers that have no .NET installer workflow?
- Do you log command lines for process creation everywhere?
This read-only PowerShell command lists copies of InstallUtil.exe in the .NET Framework directories on a Windows host:
Get-ChildItem C:\Windows\Microsoft.NET -Recurse -Filter InstallUtil.exe -ErrorAction SilentlyContinue | Select-Object FullName
Where to start
Check build and developer machines first, since that is where InstallUtil has a real job. Everywhere else, a block through application control is usually safe. For the machines that keep it, log command lines and file creation together so that an assembly written to disk and run within minutes stands out.
Quick check
What detail inside a .NET binary lets InstallUtil run its code?
A class decorated with the RunInstaller attribute, which InstallUtil executes.
Why is the argument more telling than the binary name?
The binary is genuine and signed, so only the path and timing of the assembly it is pointed at separate normal use from abuse.
Sources
- MITRE ATT&CK, T1218.004: https://attack.mitre.org/techniques/T1218/004
