Kurzfassung: Mit Image File Execution Options (IFEO) laesst sich ein "Debugger" hinterlegen, der anstelle eines Programms startet. Angreifer nutzen das doppelt: als allgemeine Persistenz und als Sticky-Keys-Hintertuer, bei der am Anmeldebildschirm statt sethc.exe oder utilman.exe eine Shell als SYSTEM startet - ganz ohne Anmeldung. Die Erkennung setzt an drei Stellen an: dem IFEO-Debugger-Eintrag, demselben Eintrag auf einem Bedienhilfe-Programm und der Shell, die aus winlogon oder einer Bedienhilfe startet. Drei sigma-cli-validierte Sigma-Regeln, Härtung und der Test im Lab. Serie "Angriff erkennen".
Nach den Registry-Run-Keys und dem neuen Konto als Hintertür folgt eine besonders elegante Persistenz, die zugleich Rechte ausweitet: der missbrauchte Debugger-Mechanismus von Windows. Unter Image File Execution Options kann man zu jedem Programm einen Debugger hinterlegen - eigentlich für Entwickler gedacht, die ein Programm beim Start automatisch im Debugger öffnen wollen. Windows startet dann statt des Programms den eingetragenen Debugger und übergibt ihm das Programm. Genau das macht sich ein Angreifer zunutze: Er trägt als Debugger eine Shell ein. Die bekannteste Form ist die Sticky-Keys-Hintertür, bei der am gesperrten Bildschirm eine SYSTEM-Shell erscheint. Der Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.
Einordnung in ATT&CK: Zwei verwandte Unterpunkte von Event Triggered Execution: Image File Execution Options Injection (T1546.012) und Accessibility Features (T1546.008). MITRE führt beide in der Taktik Persistence (TA0003) und zugleich in Privilege Escalation (TA0004), weil der Debugger im Kontext des Zielprozesses startet - bei den Bedienhilfen als SYSTEM.
Was der Angreifer tut
Der Missbrauch des Debugger-Mechanismus läuft auf der Ebene des Prinzips, nicht als Anleitung, in wenigen Varianten ab:
- IFEO-Debugger setzen. Unter Image File Execution Options bekommt ein Programm einen Debugger-Wert, der auf eine Shell oder die Nutzlast zeigt. Beim Start des Programms läuft stattdessen der Debugger.
- Die Sticky-Keys-Variante. Als Ziel dient eine Bedienhilfe wie sethc.exe (fünfmal Umschalt) oder utilman.exe (Windows+U). Der Debugger wird cmd.exe - und am Anmeldebildschirm öffnet sich eine Shell als SYSTEM, ohne Anmeldung.
- Die SilentProcessExit-Variante. Statt des Debuggers wird ein MonitorProcess hinterlegt, der startet, wenn sich ein Zielprozess beendet - dasselbe Ziel über einen anderen Schlüssel.
- Bleiben und zurückkehren. Der Eintrag übersteht den Neustart; die Hintertür steht bei jedem Start des Zielprogramms oder am Anmeldebildschirm bereit.
Für die Erkennung ist entscheidend: Das Setzen dieser Schlüssel ist nativ protokolliert, und eine Shell, die aus einer Bedienhilfe oder aus winlogon startet, ist ein lautes, eindeutiges Signal.
Welche Logquellen die Technik zeigt
- Registry-Änderung. Sysmon Event 13 meldet das Setzen des Debugger- oder MonitorProcess-Werts samt Schlüssel und Inhalt - die wichtigste Quelle für beide Varianten.
- Prozess-Telemetrie. Event 4688 und Sysmon Event 1 zeigen die Shell, die am Anmeldebildschirm als Kind von winlogon.exe oder einer Bedienhilfe startet - das Verhalten, wenn die Hintertür ausgelöst wird.
- Die Eltern-Kind-Beziehung. Dieselben Quellen machen die auffällige Kette sichtbar: sethc.exe oder utilman.exe als Elternprozess einer cmd ist im Normalbetrieb unmöglich.
- Die nachgelagerte Aktion. Was aus der SYSTEM-Shell folgt, zeigt die Endpunkt-Telemetrie, siehe Sysmon einrichten.
Das Muster im Log
Das klarste Signal ist der Registry-Eintrag selbst: ein Debugger-Wert unter Image File Execution Options, besonders auf einer Bedienhilfe wie sethc.exe oder utilman.exe. Für diese Programme gibt es keinen legitimen Debugger - der Eintrag ist praktisch immer bösartig. Dazu kommt das Verhalten: eine cmd oder PowerShell, die als Kind von winlogon.exe oder einer Bedienhilfe startet, gehört in keinen Normalbetrieb und deutet auf eine ausgelöste Hintertür am Anmeldebildschirm. Das dritte Signal ist der allgemeine IFEO-Debugger oder ein SilentProcessExit-MonitorProcess, der auf eine Shell, ein Nutzerverzeichnis oder einen codierten Befehl zeigt. Ein regulärer Debugger-Eintrag stammt von einem Entwicklungswerkzeug und zeigt auf einen bekannten Debugger. Wie immer trennt der Blick auf Ziel, Wert und Elternprozess den Alltag vom Angriff.
Drei Sigma-Regeln
Die Regeln sind mit sigma-cli geprüft. Die erste nimmt den allgemeinen IFEO-Debugger, die zweite denselben Eintrag auf einer Bedienhilfe, die dritte das Verhalten am Anmeldebildschirm. Die zweite und dritte sind die spezifischsten.
1. IFEO-Debugger oder SilentProcessExit-Monitor (T1546.012). Das Setzen eines Debugger- oder MonitorProcess-Werts - das breite Signal. Die Regel steht auf level: high.
title: IFEO-Debugger oder SilentProcessExit-Monitor gesetzt
id: 7b2c9e41-4a37-4d18-9f03-6a4c7e2b85d3
status: experimental
description: |
Erkennt das Setzen eines Debugger-Werts unter Image File Execution Options oder eines
MonitorProcess unter SilentProcessExit. Beide Mechanismen starten ein frei waehlbares Programm,
wenn ein Zielprozess startet (Debugger) oder sich beendet (SilentProcessExit) - ein verstecktes,
dauerhaftes Mittel zur Persistenz und Rechteausweitung. Ein regulaerer Debugger-Eintrag ist selten
und stammt von Entwicklungswerkzeugen.
references:
- https://attack.mitre.org/techniques/T1546/012/
author: blue-team.net
tags:
- attack.persistence
- attack.privilege-escalation
- attack.t1546.012
logsource:
product: windows
category: registry_set
detection:
sel_debugger:
TargetObject|contains: '\Image File Execution Options\'
TargetObject|endswith: '\Debugger'
sel_silent:
TargetObject|contains: '\SilentProcessExit\'
TargetObject|endswith: '\MonitorProcess'
condition: sel_debugger or sel_silent
falsepositives:
- Entwicklungs- und Debugging-Werkzeuge setzen vereinzelt Debugger-Eintraege; bekannte Faelle als Baseline ausnehmen
level: high
2. IFEO-Debugger auf einer Bedienhilfe (T1546.008). Ein Debugger-Eintrag auf sethc, utilman und Co. - die klassische Sticky-Keys-Hintertür, praktisch immer bösartig. Ebenfalls level: high.
title: IFEO-Debugger auf einem Bedienhilfe-Programm
id: 9d3e7f22-5a48-4c27-8e71-2b6a4c1d95e5
status: experimental
description: |
Erkennt einen IFEO-Debugger-Eintrag fuer eines der Windows-Bedienhilfe-Programme (sethc, utilman,
osk, Narrator, Magnify, DisplaySwitch, AtBroker). Das ist die klassische Sticky-Keys-Hintertuer:
Statt des Bedienhilfe-Programms startet am Anmeldebildschirm ein hinterlegter Befehl - haeufig eine
Shell als SYSTEM. Fuer diese Programme gibt es keinen legitimen Debugger.
references:
- https://attack.mitre.org/techniques/T1546/008/
author: blue-team.net
tags:
- attack.persistence
- attack.privilege-escalation
- attack.t1546.008
- attack.t1546.012
logsource:
product: windows
category: registry_set
detection:
sel_ifeo:
TargetObject|contains: '\Image File Execution Options\'
sel_acc:
TargetObject|contains:
- '\sethc.exe'
- '\utilman.exe'
- '\osk.exe'
- '\Narrator.exe'
- '\Magnify.exe'
- '\DisplaySwitch.exe'
- '\AtBroker.exe'
condition: sel_ifeo and sel_acc
falsepositives:
- Keine bekannten; ein Debugger auf diesen Programmen ist praktisch immer boesartig
level: high
3. Shell aus Bedienhilfe oder winlogon (T1546.008). Eine cmd oder PowerShell als Kind von winlogon oder einer Bedienhilfe - das Verhaltenssignal der ausgelösten Hintertür. Ebenfalls level: high.
title: Bedienhilfe-Programm oder winlogon startet eine Shell
id: 2a7c9e15-6b37-4d26-b803-5f1a8c3e47d8
status: experimental
description: |
Erkennt eine Shell oder PowerShell, deren Elternprozess winlogon.exe oder ein Bedienhilfe-Programm
(sethc, utilman, osk, Narrator, Magnify, DisplaySwitch, AtBroker) ist. Wird eine Sticky-Keys- oder
Utilman-Hintertuer ausgeloest, startet der hinterlegte Befehl am Anmeldebildschirm als Kind dieser
Prozesse - als SYSTEM. Das ist das verhaltensbasierte Gegenstueck zum Registry-Eintrag.
references:
- https://attack.mitre.org/techniques/T1546/008/
author: blue-team.net
tags:
- attack.persistence
- attack.privilege-escalation
- attack.t1546.008
logsource:
product: windows
category: process_creation
detection:
sel_parent:
ParentImage|endswith:
- '\winlogon.exe'
- '\sethc.exe'
- '\utilman.exe'
- '\osk.exe'
- '\Narrator.exe'
- '\Magnify.exe'
- '\DisplaySwitch.exe'
- '\AtBroker.exe'
sel_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
condition: sel_parent and sel_child
falsepositives:
- Sehr selten; einzelne Verwaltungsaktionen am Anmeldebildschirm - bekannte Faelle nach Host und Konto ausnehmen
level: high
Härtung: der Angriff, der ins Leere läuft
- IFEO überwachen und einschränken. Den Schlüssel Image File Execution Options auf Debugger-Werte überwachen und das Schreiben auf wenige Konten begrenzen; Werkzeuge wie Autoruns zeigen vorhandene Einträge.
- Bedienhilfen absichern. Die Integrität von sethc.exe, utilman.exe und den übrigen Bedienhilfen prüfen und jeden Debugger-Eintrag darauf sofort alarmieren.
- Netzwerkanmeldung am Sperrbildschirm begrenzen. Den physischen und den RDP-Zugang zum Anmeldebildschirm kontrollieren, damit eine Sticky-Keys-Hintertür nicht aus der Ferne nutzbar ist.
- Verhaltensregel scharf schalten. Eine Shell als Kind von winlogon oder einer Bedienhilfe sollte immer alarmieren - das ist die zuverlässigste Einzelregel.
Der Test
Die Erkennung lässt sich im Lab gefahrlos prüfen, auf isolierten Systemen mit aktivem Sysmon:
- Für Regel 1 und 2 testweise unter Image File Execution Options für ein harmloses Programm (oder für sethc.exe) einen Debugger-Wert setzen. Sysmon Event 13 muss den Schlüssel und den Wert zeigen; danach wieder entfernen.
- Für Regel 3 den Eintrag auslösen, indem das Zielprogramm gestartet wird. Die Shell muss als Kind der Bedienhilfe bzw. von winlogon in Event 4688 erscheinen.
- Breiter wird der Test mit den Fällen zu T1546.008 und T1546.012 aus Atomic Red Team.
Fehlalarme und Tuning
- Entwicklungswerkzeuge. Debugger und Profiler setzen vereinzelt legitime IFEO-Einträge. Für Regel 1 die bekannten Werkzeuge und Zielprogramme als Baseline ausnehmen.
- Bedienhilfen sind eindeutig. Regel 2 braucht kaum Tuning - ein Debugger auf einer Bedienhilfe hat keinen legitimen Grund und gehört zu den hochprioren Alarmen.
- Verwaltung am Sperrbildschirm. Sehr selten startet die Administration etwas über winlogon. Für Regel 3 die wenigen bekannten Fälle nach Host und Konto dokumentieren.
- Korrelation schlägt Einzelregel. Wer den Registry-Eintrag und die spätere Shell als Kette betrachtet, trennt Entwicklungswerkzeug und echten Angriff zuverlässiger als jede Einzelregel.
Fazit
Der Debugger-Mechanismus von Windows ist eine elegante Hintertür: Ein Eintrag unter Image File Execution Options genügt, um beim Start eines Programms eigenen Code auszuführen - bei den Bedienhilfen sogar als SYSTEM am Anmeldebildschirm. Die verlässlichen Signale sind der Debugger- oder MonitorProcess-Eintrag, derselbe Eintrag auf einer Bedienhilfe und die Shell, die aus winlogon oder einer Bedienhilfe startet. Die wirksamste Härtung überwacht IFEO, sichert die Bedienhilfen und begrenzt den Zugang zum Sperrbildschirm. Als Nächstes und zum Abschluss der Persistenz-Reihe folgen die BITS-Jobs. Verwandt sind die Registry-Run-Keys und das neue Konto als Hintertür. Weitere Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Persistence.