InstallUtil-Missbrauch erkennen: Code hinter Microsoft-Signatur

Anwendungssteuerung wie AppLocker oder WDAC blockiert unbekannte Programme - aber ein von Microsoft signiertes Bordmittel gilt als vertrauenswürdig. Diese Lücke nutzen Angreifer mit Signed Binary Proxy Execution: Ein legitimes, signiertes Programm führt den eigentlichen Schadcode aus. InstallUtil.exe, das .NET-Installationswerkzeug, ist einer dieser Wege. Verwandte Bordmittel behandelt die Serie bereits mit dem Msiexec-Missbrauch; dieser Beitrag nimmt InstallUtil in den Blick und bleibt auf der Verteidigerseite.

Was der Angreifer tut

Der Missbrauch von InstallUtil läuft - auf der Ebene des Prinzips, nicht als Anleitung - in wenigen Mustern ab:

• Ein Assembly vorbereiten. Der Schadcode wird als .NET-Assembly gebaut, dessen Uninstall-Methode die eigentliche Aktion enthält.
• Über InstallUtil starten. InstallUtil.exe wird mit den Schaltern für Logfile und Deinstallation aufgerufen und ruft dabei die Uninstall-Methode des Assemblys auf.
• Signatur erben. Weil InstallUtil von Microsoft signiert ist, läuft der Code unter dem Schutz eines vertrauenswürdigen Programms - die Anwendungssteuerung greift nicht.
• Unauffällig bleiben. Das Assembly liegt oft in einem Temp- oder Benutzer-Ordner, und der Aufruf geht im normalen Rauschen signierter Microsoft-Prozesse leicht unter.

Für die Erkennung ist entscheidend: Nicht InstallUtil selbst ist das Signal, sondern der Kontext - die verräterischen Schalter, der Pfad des Assemblys und der aufrufende Prozess. Genau daran setzen die Regeln an.

Welche Logquellen die Technik zeigt

• Prozess-Telemetrie zuerst. Event 4688 zeigt InstallUtil.exe samt vollständiger Befehlszeile und übergeordnetem Prozess - also die Schalter, den Assembly-Pfad und die Herkunft. Die wichtigste Quelle.
• Eltern-Kind-Beziehung. Entscheidend ist, wer InstallUtil aufruft; ein Start aus cmd, PowerShell, einem Skript-Host oder Office ist ein starkes Signal und steht in der Prozess-Telemetrie.
• Datei-Telemetrie. Das vorherige Ablegen des Assemblys in Temp oder AppData zeigt sich im Datei-Log und ergänzt die Prozesszeile.
• Werkzeug-Kontext. InstallUtil ist ein mitgeliefertes .NET-Werkzeug; Grundlagen zum Missbrauch solcher signierten Bordmittel unter Living off the Land.

Das Muster im Log

Drei Signale tragen. Das erste ist InstallUtil mit den Schaltern für Logfile und Deinstallation, die den Uninstall-Trick verraten. Das zweite ist InstallUtil mit einem Assembly-Pfad in einem Temp- oder Benutzer-Verzeichnis. Das dritte ist InstallUtil, das von einem ungewöhnlichen Elternprozess wie cmd, PowerShell oder Office gestartet wird. Legitime Treffer stammen aus Softwareinstallationen und Entwickler- oder Build-Umgebungen, die InstallUtil regulär nutzen. Auffällig wird es, wenn die Uninstall-Schalter auftauchen, das Assembly aus einem Download-Ordner kommt oder der Aufruf aus einer Skript- oder Office-Umgebung stammt. Der Blick auf Schalter, Pfad und Elternprozess trennt den Alltag vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und nehmen die drei Signale: die Uninstall-Schalter, das Assembly aus einem temporären Verzeichnis und den ungewöhnlichen Elternprozess. Alle drei werten die Prozess-Telemetrie aus.

1. InstallUtil mit Uninstall-Schaltern aufgerufen (T1218.004). InstallUtil mit /logfile= und /LogToConsole=false. Die Regel steht auf level: high.

title: InstallUtil mit Uninstall-Schaltern aufgerufen
id: 4c8a2e51-7b36-4d94-a5f2-3d9c6b1e8a47
status: experimental
description: |
  Erkennt den Aufruf von InstallUtil.exe mit den Schaltern /logfile= und /U sowie /LogToConsole=false.
  Angreifer nutzen diese Kombination, um ueber die Uninstall-Methode eines .NET-Assemblys beliebigen
  Code auszufuehren und so die Anwendungssteuerung zu umgehen (InstallUtil, eine Signed-Binary-Proxy-
  Execution). Diese Schalterkombination ist im Normalbetrieb ungewoehnlich.
references:
  - https://attack.mitre.org/techniques/T1218/004/
author: blue-team.net
tags:
  - attack.stealth
  - attack.t1218.004
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\InstallUtil.exe'
  sel_flags:
    CommandLine|contains:
      - '/logfile='
      - '/LogToConsole=false'
  condition: sel_img and sel_flags
falsepositives:
  - Einzelne Softwareinstallationen nutzen InstallUtil regulaer - bekannte Installer und Assemblys als Baseline ausnehmen
level: high

2. InstallUtil lädt Assembly aus temporärem Verzeichnis (T1218.004). InstallUtil mit einem Pfad in Temp, AppData, Public, ProgramData oder Downloads. Ebenfalls level: high.

title: InstallUtil laedt Assembly aus temporaerem Verzeichnis
id: 7e3b9c24-5a81-4f63-b2d7-8c4e6a1f9b52
status: experimental
description: |
  Erkennt InstallUtil.exe mit einem Assembly-Pfad in einem temporaeren oder Benutzer-Verzeichnis (Temp,
  AppData, Public, ProgramData, Downloads). Angreifer legen das auszufuehrende .NET-Assembly an einem
  solchen Ort ab und starten es ueber InstallUtil, um die Anwendungssteuerung zu umgehen (InstallUtil).
  Ein Assembly aus einem solchen Pfad ist im Normalbetrieb ungewoehnlich.
references:
  - https://attack.mitre.org/techniques/T1218/004/
author: blue-team.net
tags:
  - attack.stealth
  - attack.t1218.004
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\InstallUtil.exe'
  sel_loc:
    CommandLine|contains:
      - '\Temp\'
      - '\AppData\'
      - '\Public\'
      - '\ProgramData\'
      - '\Downloads\'
  condition: sel_img and sel_loc
falsepositives:
  - Installer entpacken Assemblys nach Temp und rufen InstallUtil auf - bekannte Faelle nach Pfad und Host als Baseline ausnehmen
level: high

3. InstallUtil durch ungewöhnlichen Elternprozess gestartet (T1218.004). InstallUtil als Kind von cmd, PowerShell, einem Skript-Host, MSHTA oder Office. Die Regel steht auf level: medium.

title: InstallUtil durch ungewoehnlichen Elternprozess gestartet
id: 1a9e6c37-4d82-4b73-9f25-7c3d8e4a2b61
status: experimental
description: |
  Erkennt den Start von InstallUtil.exe durch einen ungewoehnlichen Elternprozess wie cmd, PowerShell,
  WScript, MSHTA oder ein Office-Programm. InstallUtil wird regulaer von Setup-Routinen aufgerufen; ein
  Start aus einer Skript- oder Office-Umgebung deutet auf Proxy-Ausfuehrung von Code hin (InstallUtil).
references:
  - https://attack.mitre.org/techniques/T1218/004/
author: blue-team.net
tags:
  - attack.stealth
  - attack.t1218.004
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\InstallUtil.exe'
  sel_parent:
    ParentImage|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\winword.exe'
      - '\excel.exe'
  condition: sel_img and sel_parent
falsepositives:
  - Entwickler- und Build-Umgebungen rufen InstallUtil aus Skripten auf - bekannte Hosts und Skripte als Baseline ausnehmen
level: medium

Härtung: der Angriff, der ins Leere läuft

• InstallUtil einhegen. Mit AppLocker oder WDAC den Start von InstallUtil.exe auf die Konten und Hosts beschränken, die es wirklich brauchen - signierte Bordmittel gehören in jede Positivliste mit Bedacht.
• Ausführung aus Temp sperren. Das Starten von Assemblys und Programmen aus Temp- und Benutzer-Verzeichnissen per Richtlinie unterbinden.
• Kommandozeile protokollieren. Die Prozess-Befehlszeile (Event 4688 mit Command-Line-Auditing oder Sysmon) zuverlässig erfassen - ohne sie bleiben die verräterischen Schalter unsichtbar.
• Gezielt überwachen. InstallUtil mit Uninstall-Schaltern, Assemblys aus Temp und ungewöhnliche Elternprozesse als feste Erkennungen führen und mit anderen Signed-Binary-Proxy-Wegen wie dem Msiexec-Missbrauch zusammen betrachten.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem isolierten System mit aktivem Sysmon und Command-Line-Auditing - mit einem harmlosen Test-Assembly:

• Für Regel 1 ein harmloses Test-Assembly mit InstallUtil und den Schaltern /logfile= und /LogToConsole=false aufrufen und prüfen, dass Event 4688 die Befehlszeile zeigt.
• Für Regel 2 das Test-Assembly aus einem Temp-Pfad starten und prüfen, dass die Regel greift.
• Für Regel 3 InstallUtil aus einer Testumgebung heraus über cmd oder PowerShell starten und kontrollieren, dass die Eltern-Kind-Regel den Treffer meldet.
• Breiter wird der Test mit den Fällen zu T1218.004 aus Atomic Red Team.

Fehlalarme und Tuning

• Softwareinstallation. Setup-Routinen nutzen InstallUtil regulär und entpacken Assemblys nach Temp. Bekannte Installer, Pfade und Assemblys als Baseline ausnehmen, bevor die Regeln scharf geschaltet werden.
• Entwicklung und Build. Auf Entwicklerrechnern und Buildservern ist InstallUtil aus Skripten üblich. Diese Hosts und Skripte gezielt behandeln.
• Schalter entscheiden. InstallUtil allein ist Alltag; die Kombination aus /logfile= und /LogToConsole=false mit einem Assembly aus Temp ist es nicht - danach priorisieren.
• Kette schlägt Einzelzeile. InstallUtil aus einer Skript- oder Office-Umgebung zusammen mit einem frisch abgelegten Assembly ist weit aussagekräftiger als ein Treffer allein - die Korrelation schärft die Bewertung.

Fazit

InstallUtil ist einer der Wege, auf denen ein signiertes Microsoft-Werkzeug fremden Code ausführt und so die Anwendungssteuerung umgeht. Die verlässlichen Signale sind die Uninstall-Schalter /logfile= und /LogToConsole=false, ein Assembly aus einem temporären Verzeichnis und ein ungewöhnlicher Elternprozess. Die wirksamste Härtung ist das Einhegen von InstallUtil per Anwendungssteuerung, zusammen mit einem zuverlässigen Protokoll der Befehlszeile. Einen verwandten Signed-Binary-Proxy-Weg zeigt der Msiexec-Missbrauch; die Grundlagen zum Missbrauch signierter Bordmittel das Living off the Land. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Stealth.