Gevaren — AppCompat & Shim-laag (UAC zonder admin)

A1Persistent shim-flag per user, geen admin

Wat het is

De registry-key HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers bevat per binary een REG_SZ-waarde van het formaat "C:\path\to.exe" = "RUNASINVOKER". Bij elke launch van die binary leest AppInfo.dll de waarde uit en past hem toe — ook na herstart, ook bij andere user-sessies van dezelfde profile.

Waarom kan een non-admin user dit?

HKCU is de user-eigen registry-hive. De Layers-key is daar standaard schrijfbaar voor de user zelf — bij Microsofts ontwerp uitgangspunt dat "een user mag zijn eigen apps compatibel maken". Er is geen UAC-prompt, geen elevation, geen logging-by-default.

Schade-scenario

Een aanvaller met initial-access binnen een user-account zet RUNASINVOKER op %LOCALAPPDATA%\evil.exe. Bij elke launch wordt de UAC-prompt onderdrukt — ook al vraagt het manifest om elevation. De aanval overleeft reboots, profile-roaming en zelfs het wissen van browser-cache. De user weet niets, de IT-afdeling ziet niets in standaard-monitoring.

Defensieve maatregelen

• GPO: Turn off Application Compatibility Engine (Computer Configuration → Administrative Templates → Windows Components → Application Compatibility) — nucleaire optie
• AppLocker / WDAC met script- en EXE-whitelist op getekende paths
• Sysmon-regel die registry-writes op *AppCompatFlags\Layers* blokkeert of alarmeert

Detectie-mechanisme

Sysmon EID 12 (registry key create/delete) en EID 13 (registry value set), gefilterd op TargetObject matching HKU\*\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\*. Defender ATP signaleert dit als Suspicious AppCompat shim registration wanneer ATP-EDR-sensor aanstaat.

A2Custom Shim Database installeren zonder admin

Wat het is

Een Shim Database (.sdb) is een binair bestand met gedragsregels die Windows op één of meer binaries kan toepassen. Het commando sdbinst.exe -q evil.sdb registreert zo'n database. Sinds Windows 10 1607 kan dit per user, waarbij de entries verschijnen in HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB en ...\Custom.

Waarom kan een non-admin user dit?

Microsoft heeft de per-user-route bewust open gelaten zodat applicaties uit de Store of click-to-run-installers shims kunnen meebrengen zonder de hele machine te raken. sdbinst.exe zelf vraagt geen elevation voor per-user-installatie.

Schade-scenario

Een aanvaller distribueert een .sdb die op notepad.exe een InjectDll-flag plaatst met pad naar %APPDATA%\Roaming\evil.dll. Zodra de user notepad opent, wordt de DLL geladen in een legitieme proces-context. Defender ziet alleen een normale notepad.exe. De DLL kan vervolgens credentials lezen, browser-data exporteren, of als C2-beacon dienen. Vergelijkbare gedragsregels: RedirectShortcut, VirtualRegistry, DisableNXShowUI.

Defensieve maatregelen

• AppLocker-blokregel op sdbinst.exe voor alle non-admin users
• Periodieke audit op HKCU\...\AppCompatFlags\InstalledSDB en ...\Custom — nieuwe entries onderzoeken
• WDAC-policy die alleen Microsoft-getekende SDB-bestanden toestaat

Detectie-mechanisme

Sysmon EID 1 (process create) waarbij parent niet msiexec.exe of een legitieme installer is en command-line bevat sdbinst. Sysmon EID 13 op InstalledSDB- en Custom-keys. Defender ATP heeft een Application Shim installation-detectie sinds 2023.

A3Ad-hoc gedragsmodificatie per process via env-var

Wat het is

De omgevingsvariabele __COMPAT_LAYER kan per proces worden gezet en bevat een of meer shim-flags, gescheiden door spaties. Voorbeelden: RunAsInvoker, RunAsHighest, WinXPSP3, Win7RTM, Win8RTM, Installer, Telemetry. Sommige flags onderdrukken UAC, andere liegen over de OS-versie tegenover de applicatie.

Waarom kan een non-admin user dit?

Environment variables zijn per definitie user-controlled. Er is geen mechanisme om een user te beletten een env-var te zetten vóór het starten van een proces — dat zou de hele scripting-economie breken.

Schade-scenario

Een aanvaller start evil.exe met __COMPAT_LAYER=WinXPSP3. De binary "ziet" een XP SP3-OS en activeert een code-path met een bekende kwetsbaarheid die op XP wel werkte maar op Windows 11 normaal gepatcht is. Resultaat: oude exploits worden bruikbaar op moderne systemen via OS-version-spoofing. Alternatief: RunAsInvoker onderdrukt UAC zonder dat er een registry-trace achterblijft.

Defensieve maatregelen

• GPO: Turn off Application Compatibility Engine (zelfde als A1)
• Sysmon command-line-logging met env-var-capture (sinds Sysmon 13)
• EDR-regels die proces-starts met __COMPAT_LAYER= in command-line of environment markeren

Detectie-mechanisme

Sysmon EID 1 met CommandLine of process-environment bevattend __COMPAT_LAYER=. Defender ATP Advanced Hunting: DeviceProcessEvents | where ProcessCommandLine contains "__COMPAT_LAYER".

A4Defensie-readiness van het endpoint

Wat het is

Dit testkader is geen aanval, maar een readiness-check: wat is de detectie-capaciteit van het endpoint zelf? De test inventariseert de aanwezigheid en status van Sysmon, Defender Real-Time-Protection, Behavior Monitoring, Tamper Protection, AMSI, PowerShell ScriptBlockLogging (EID 4104) en ModuleLogging (EID 4103).

Awareness-punt

Zonder PowerShell ScriptBlockLogging is shim-misuse via PowerShell-scripts vrijwel onzichtbaar. De aanvaller schrijft de Layers-key, installeert de SDB, of zet de env-var — allemaal één-regel-PowerShell. Zonder logging is er geen artefact achteraf. Tamper Protection moet aan staan — anders kan zelfs Defender per script worden uitgeschakeld voorafgaand aan de aanval.

Defensie-checklist (7 items)

• Sysmon geïnstalleerd met productie-config (SwiftOnSecurity- of Olaf Hartong-baseline)
• Defender Real-Time-Protection actief op alle endpoints
• Defender Tamper Protection aan (voorkomt uitschakelen via script)
• AMSI geïntegreerd met EDR-product en niet bypassed
• PowerShell ScriptBlockLogging aan via GPO (Computer Configuration → Administrative Templates → Windows Components → PowerShell → Turn on PowerShell Script Block Logging)
• Windows Event Forwarding ingesteld naar centrale SIEM (Splunk, Sentinel, Elastic)
• Audit-policy compleet: registry-writes, process-creation met command-line, sysmon-channel forward

A5Forensisch onderzoek naar oude shim-aanvallen

Wat het is

Een audit-mechanisme dat bestaande shim-entries in HKCU en HKLM Layers, InstalledSDB en Custom dumpt. Doel: detecteren of er ooit een shim-aanval heeft plaatsgevonden waarvan de artefacten nog steeds aanwezig zijn.

Schade-scenario

Een succesvolle shim-attack van 6 maanden terug zit nog steeds in de user-registry. De aanvaller is allang weg, maar de RUNASINVOKER-flag op %LOCALAPPDATA%\foo.exe is nooit opgeruimd. Niemand heeft het ooit gemerkt omdat baseline-monitoring ontbrak. Volgende keer dat de aanvaller terugkomt, hoeft hij alleen foo.exe te activeren — de persistence is nog intact.

Defensieve maatregelen

• Baseline-snapshot van Layers, InstalledSDB en Custom per endpoint na uitrol
• Scheduled task die wekelijks de huidige state vergelijkt met baseline en delta's rapporteert
• Bij elke wisseling van eigenaar of profile-migratie: forensische sweep

Detectie-mechanisme

PowerShell-scheduled-task die de drie registry-keys dumpt en hash-vergelijkt met baseline. Verschil → alert naar SIEM. Voor Defender ATP-omgevingen: Advanced Hunting-query met DeviceRegistryEvents over een periode van 90 dagen.