Some vulnerabilities are found with grinding, systematic effort. This one was found by accident, while its discoverer — a researcher writing on SCRT’s blog.scrt.ch — was sifting through Process Monitor data collected for a completely different project. On a whim, he ran the standard filters for DLL search-order hijacking, the forensic equivalent of shaking a vending machine, and out popped something better: an executable called CompatTelRunner.exe, running as NT AUTHORITY\SYSTEM, launching PowerShell without bothering to specify where PowerShell actually lives.
When a program calls an executable by name alone, Windows goes looking for it, following a predictable search order — and, among other things, checking each folder listed in the PATH environment variable. If an attacker can drop a bogus powershell.exe into a PATH folder that Windows checks before the real one, Windows will obediently run the impostor. In this case, the impostor would run with SYSTEM privileges, roughly the employee-of-the-month parking spot of Windows privilege levels.
The give-aways were in the parent process’s command line — compattelrunner.exe -m:appraiser.dll -f:DoScheduledTelemetryRun — and in the stack, where the CreateProcessW call traced back to a function named PowerShellMatchingPlugin inside acmigration.dll. The keywords appraiser and ScheduledTelemetry pointed straight at Task Scheduler, and a quick Get-ScheduledTask query confirmed two suspects under \Microsoft\Windows\Application Experience\: one called MareBackup (description: “Gathers Win32 application data for App Backup scenario”) and one called Microsoft Compatibility Appraiser Exp. In total, Process Monitor had logged 13 “Process Create” events for powershell.exe. The actual command being launched was thrillingly banal: powershell.exe -ExecutionPolicy Restricted -Command Write-Host ‘Final result: 1’; — SYSTEM-level power, summoned to print the number one.
The catch, and the catch behind the catch
There is a wrinkle that trims the exploit’s wardrobe considerably. Unlike a classic “Ghost DLL hijack,” where LoadLibrary trudges through every PATH entry because the target file doesn’t exist, the real powershell.exe does exist, so it will be found eventually. The hijack only works if a writable, weakly permissioned folder is prepended to the system PATH — inserted ahead of the default PowerShell folder — rather than appended. Python used to be famous for doing exactly this with insecure defaults, though its installer has since been fixed, so that particular avenue is closed.
Assuming such a folder exists, though, the next question is whether a low-privileged user can actually fire the task. The researcher peeked at the offending function in Ghidra (which politely declined to reconstruct the command line, revealing only that the process is created with the CREATE_NO_WINDOW flag) and then tried starting both tasks manually. Microsoft Compatibility Appraiser Exp answered with “access denied.” MareBackup, charmingly, just started.
Why? Checking the access-control lists — via his own tool, PrivescCheck, or simply by running icacls on the scheduled task’s XML definition file — shows that BUILTIN\Users holds full control over the task. “‘So, that means I can modify the scheduled task as a low-privileged user and achieve LPE? That’s an 0-day!’” the researcher writes, voicing the reader’s thought — and immediately shooting it down. Editing the file achieves nothing: a checksum stored in the registry is verified when tasks load, and every Schedule service RPC procedure insists on administrator privileges, with the sole exception of enabling and disabling tasks. So no zero-day — just the perfectly supported feature of ordinary users being allowed to poke a SYSTEM-grade task awake.
Because MareBackup is only a telemetry chore — not system-critical — the payload doesn’t need to preserve anything. The researcher chose his stated favorite: duplicating the SYSTEM token (which conveniently carries SeTcbPrivilege), swapping its session to the target user’s, and spawning cmd.exe on their desktop — a command prompt that answers to SYSTEM, gift-wrapped for a non-admin.
The post lists the handful of PowerShell commands needed to audit and trigger the whole thing: read the system PATH from the registry, check the task exists, enable it if needed, and Start-ScheduledTask. The one thing to actually pay attention to, the researcher notes, is simply whether any PATH folder with weak permissions sits before the default PowerShell path. And in the demonstration video, the user is literally named “Admin” and sits in the Administrators group — but under medium integrity, because User Account Control is enabled, meaning the PowerShell process has no admin rights. HARDWARE WARNING LIGHTS OFF: that’s not a typo — the demo is engineered to prove even a member of Administrators, slumming it without elevated privileges, can pull the lever.