InstallUtil Proxy Execution

InstallUtil.exe is a signed command-line utility that ships with the .NET Framework. Its legitimate purpose is to install and uninstall server resources by executing the installer components inside a .NET assembly. Attackers abuse the way it invokes those installer hooks: when InstallUtil processes an assembly, it calls the methods decorated as installers — and an attacker can put their payload there, sometimes guarded by attributes so the code runs only under InstallUtil and not when the assembly is double-clicked.

The technique is attractive because the malicious code executes inside a Microsoft-signed process, bypassing application allow-listing that trusts the binary, and because the trigger path differs from normal execution — sandboxes and analysts that just run the dropped .exe may see nothing, while InstallUtil runs the hidden installer logic. Analysts encounter it during execution and defense-evasion phases, with InstallUtil pointed at a .exe or .dll in a user-writable directory.

How it works

The attacker drops a .NET assembly whose installer hook (a class deriving from System.Configuration.Install.Installer with [RunInstaller(true)]) contains the payload, then runs:

InstallUtil.exe /logfile= /LogToConsole=false /U C:\Users\Public\svc.exe

The /U (uninstall) and logging-suppression flags are the canonical abuse pattern: they make InstallUtil invoke the assembly's Uninstall method — where the loader lives — while staying quiet. Because the malicious logic sits in installer/uninstaller hooks rather than Main(), executing the file normally is benign; only InstallUtil triggers it.

The recognisable indicators are InstallUtil.exe with /logfile= and /U (or /LogToConsole=false) pointed at an assembly in %TEMP%, %APPDATA%, \Public\, or Downloads — a combination that has nothing to do with installing a legitimately deployed service.

Detection & analysis

Static analysis:

• Load the referenced assembly in a .NET decompiler and inspect the installer surface: classes deriving from Installer, the [RunInstaller(true)] attribute, and overridden Install/Uninstall methods. Payloads that appear only in those hooks (and not in Main) are the tell — this is a deliberate evasion pattern.
• Triage the command line for /U, /logfile= (often empty), and /LogToConsole=false paired with an assembly in a user-writable path. Look inside the assembly for P/Invoke (VirtualAlloc, CreateThread), base64/hex blobs, or AMSI/ETW patching strings.

Dynamic analysis:

• In a sandbox, run the sample through InstallUtil, not standalone — otherwise the installer-hook payload never fires. Watch for executable memory allocation, process injection, child processes, and outbound C2 connections originating from InstallUtil.exe.
• Inspect the parent/child tree. Benign InstallUtil runs during software deployment from installers or admin scripts. Malicious instances are commonly spawned by powershell.exe, cmd.exe, Office apps, or wscript.exe, with the target assembly written moments earlier.

Detection rule hint:

Alert on Sysmon Event ID 1 where Image ends with \InstallUtil.exe AND the command line contains /U or /logfile= or /LogToConsole=false AND references an assembly outside standard install directories (under \AppData\, \Temp\, \Users\Public\, \Downloads\). Correlate with Event ID 11 (file create of the assembly just before execution) and Event ID 3 (network connection) from the same PID, and flag any case where the parent is a script host or Office application.