Detecting Writable PATH and Service Directory Privilege Escalation

PATH interception (T1574.007) plants an executable in a writable directory that appears in the system PATH ahead of the legitimate location, or where a command is not found at all. When a privileged process or script later runs that bare command name, it executes the plant. A close relative is replacing a service executable in a directory users can write (T1574.010). Both are configuration weaknesses you can audit, and both leave a file-write and an execution event.

Signals at a Glance

Auditing PATH and Service Directories

Most of the value is in finding writable entries before an attacker does. The script below checks each directory in the machine PATH for write-capable rights granted to broad groups; run the same logic against the directories that hold service binaries:

$paths = [Environment]::GetEnvironmentVariable('Path','Machine') -split ';' | Where-Object { $_ -and (Test-Path $_) }
foreach ($p in $paths) {
  (Get-Acl $p).Access | Where-Object {
    $_.AccessControlType -eq 'Allow' -and
    $_.IdentityReference -match 'Users|Everyone|Authenticated Users' -and
    $_.FileSystemRights -match 'Write|Modify|FullControl|CreateFiles'
  } | ForEach-Object {
    [pscustomobject]@{ PathEntry = $p; Identity = $_.IdentityReference; Rights = $_.FileSystemRights }
  }
}
# tune/validate: the common offenders are runtime installs such as C:\Python or Ruby placed at the drive root.

Catching Planted Binaries

Interception works by placing a file that masquerades as a common tool, so look for well-known Windows tool names running from anywhere other than the Windows directories. This also catches generic masquerading, and a hit from a service context is high confidence:

// Microsoft Defender (KQL) - system tools executing from outside Windows directories
DeviceProcessEvents
| where FileName in~ ("ipconfig.exe","whoami.exe","net.exe","net1.exe","tasklist.exe",
                      "systeminfo.exe","netstat.exe","hostname.exe","wmic.exe","sc.exe")
| where FolderPath !startswith @"C:\Windows\System32"
  and FolderPath !startswith @"C:\Windows\SysWOW64"
  and FolderPath !startswith @"C:\Windows\WinSxS"
| project Timestamp, DeviceName, AccountName, FolderPath, FileName, ProcessCommandLine,
          InitiatingProcessFileName
// tune/validate: some portable tools ship their own copies; allowlist by hash.

• Alert on any change to the Machine PATH value. It changes rarely, and installers are the only routine cause.
• On Linux the same weakness is a writable directory early in a cron job’s PATH or a script that calls commands by bare name as root. Audit cron files and sudo secure_path for writable entries.
• Remove user-write permission from PATH directories and service folders as a baseline control; then monitor for ACL changes with file-system auditing.
• Prefer absolute paths in scripts and scheduled actions that run with elevated privileges.