Detecting Accessibility Feature, IFEO and Shim Persistence

Several Windows features let one executable launch or modify another, and attackers reuse them for persistence. Replacing sethc.exe or utilman.exe, or setting an IFEO Debugger value, gives SYSTEM-level access from the logon screen. Installing a shim database or setting AppInit_DLLs causes a payload to load into other processes. All of them leave specific registry and file artifacts.

Signals at a Glance

IFEO and Accessibility Binaries

The logon-screen backdoor takes two forms: replace the accessibility binary with cmd.exe, or point an IFEO Debugger value at it so that Windows launches the debugger instead. Both give a SYSTEM shell from the lock screen with five presses of Shift. The same Debugger mechanism, and the newer SilentProcessExit key, can also hijack any other process name. Detect the registry writes first:

title: IFEO Debugger Or SilentProcessExit Monitor Set
logsource:
  product: windows
  category: registry_set
detection:
  ifeo:
    TargetObject|contains: '\Image File Execution Options\'
    TargetObject|endswith:
      - '\Debugger'
      - '\GlobalFlag'
  spe:
    TargetObject|contains: '\SilentProcessExit\'
    TargetObject|endswith: '\MonitorProcess'
  condition: ifeo or spe
level: high
# tune/validate: some application debugging tools set GlobalFlag; allowlist by writer and image.

Then cover the file replacement path and the resulting process lineage, which is the point where the backdoor is actually used:

// KQL: accessibility binaries tampered with, or a shell spawned from the logon screen
let accBins = dynamic(["sethc.exe","utilman.exe","osk.exe","narrator.exe","magnify.exe","displayswitch.exe","atbroker.exe"]);
union
( DeviceFileEvents
  | where FileName in~ (accBins) and FolderPath has @"\Windows\System32"
  | where ActionType in ("FileCreated","FileModified","FileRenamed")
  | where InitiatingProcessFileName !in~ ("TiWorker.exe","TrustedInstaller.exe","wuauclt.exe","msiexec.exe")
  | project Timestamp, DeviceName, Signal="binary_changed", FileName, InitiatingProcessFileName ),
( DeviceProcessEvents
  | where InitiatingProcessFileName in~ ("winlogon.exe","utilman.exe","atbroker.exe")
  | where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe","wscript.exe","mshta.exe")
  | project Timestamp, DeviceName, Signal="shell_from_logon_screen", FileName, InitiatingProcessFileName )
| order by Timestamp desc
// tune/validate: accessibility tooling and assistive suites may spawn helpers; review before alerting.

Shims and AppInit_DLLs

Application compatibility shims are loaded from a custom shim database (SDB) registered with sdbinst.exe. A malicious SDB can inject a DLL into a target application every time it starts. AppInit_DLLs, which loads a DLL into every process that loads user32.dll, is disabled when Secure Boot is on but still appears on older or relaxed systems.

• Alert on sdbinst.exe execution at all, and on new keys under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB and \Custom. Legitimate use is very rare outside compatibility engineering teams.
• Look for new .sdb files in C:\Windows\AppPatch\Custom and its 64-bit subfolder.
• Alert on non-empty AppInit_DLLs under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows, paying attention to LoadAppInit_DLLs and the WOW6432Node counterpart.
• Reduce the exposure: enable Secure Boot, and restrict write access to System32 and the IFEO key with protections that stop standard tooling from tampering.