The technique relies on the methods used to interact and control environment variables, said enSilo senior security researcher Yotam Gottesman.

Windows environment variables are a set of temporary settings specific to each Windows process and end up inherited by their child processes, which can read and write their values.

Unknown to the vast majority of users is there are a class of system-wide environment variables that apply to the entire Windows operating system.

These include details like the user’s current username, the PC’s domain, and file paths for various folders such as the Windows OS, AppData, user profile, and so on.

This set of environment variables end up stored in the Windows Registry, which makes them automatically persistent across reboots and can also end up modified by any user via “set” or “setx” commands.

On top of that, because of the way Windows is built, there are special apps when launched by regular users, execute processes with higher privileges (Task Manager, Disk Cleanup — known as UAC bypass, Event Viewer — known as UAC bypass).

When a user launches one of these apps, Windows UAC trusts its execution by default and does not show a warning.

Crooks can use modified environment variables to spawn malicious child processes under the legitimate app and execute an attack. Windows UAC will stay quiet while the attack runs with elevated privileges because UAC trusts the parent process.

In one example, an attacker can create a copy of the C:/Windows folder and modify the system-wide environment variable to point to the wrong Windows OS folder. This setting activates after a system reboot and allows the attacker to load malicious DLLs on the system.

This doesn’t mean the attacker has hijacked the OS, but when other legitimate apps need to load a system DLL, they’ll be pointed to the wrong location, where the attacker can easily modify and replace files without security products warning the user, the researcher said.

In another similar attack, it is possible to trick Windows into loading the same C:/Windows folder from a local network folder, meaning the malicious DLLs don’t even have to be stored on the same filesystem.

In his examples, Gottesman was able to load mmc.exe, the Windows management console with elevated privileges under svchost.exe, meanwhile loading a malicious DLL from the attacker’s C:/copied/Windows folder. This was done with no UAC warning and with elevated privileges.

Gottesman notified Microsoft, but the company classified this as a UAC bypass issue, and not an elevation of privileges flaw. Microsoft doesn’t consider UAC bypass a security flaw, meaning it won’t get patched with the utmost urgency but will eventually be dealt with. Proof-of-concept code is available on GitHub.