Overview
The Hijackable Paths check identifies folders in the system PATH environment variable that have weak permissions allowing non-privileged users to write files. This creates a DLL hijacking and executable planting opportunity, as Windows searches PATH folders when loading DLLs or executing programs without full paths.If you can write to a folder in the system PATH, you can potentially execute code when any user runs a command that triggers a search in that PATH location.
How It Works
SharpUp performs the following checks:- Reads the system PATH from
HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment - Splits PATH into individual folder paths (separated by semicolons)
- Checks each folder for write/modify permissions for the current user
- Reports folders where the user has write access
Technical Details
Example Output
- These folders are in the system PATH
- Current user can write to them
- Placing executables here will allow them to be run without full paths
- Placing DLLs here may allow DLL hijacking
Exploitation
Method 1: Binary Planting
Method 2: DLL Hijacking via PATH
Method 3: Persistence
Method 4: Service Hijacking
Remediation
1
Identify Writable PATH Folders
2
Secure Folder Permissions
3
Remove Unnecessary PATH Entries
4
Move Folders to Protected Locations
If tools are needed, move them to protected locations:
5
Verify Fix
Detection
Defensive Monitoring
Detection Strategies
- File System Monitoring
- Process Monitoring
- Permission Auditing
- Monitor file creation/modification in PATH folders
- Alert on new executables or DLLs in PATH
- Track who creates files in PATH folders
- Baseline known-good files and alert on changes
Real-World Scenarios
Scenario 1: Developer Tools Folder
Scenario 1: Developer Tools Folder
Context: IT team added
C:\DevTools to system PATH for convenient access. Developers have modify rights.Risk:- Any developer can plant malicious executables
- Affects all users on the system
- Persistence survives reboots
- Move to Program Files with proper permissions
- Use user PATH instead of system PATH
- Implement AppLocker to whitelist executables
Scenario 2: Legacy Application Path
Scenario 2: Legacy Application Path
Context: Old application installer added folder to PATH with weak permissions.Attack Path:
- Attacker gets standard user access
- Plants malicious
systeminfo.exein writable PATH folder - Administrator runs PowerShell script that calls
systeminfo - Malicious version executes with administrator privileges
Scenario 3: Script Folder in PATH
Scenario 3: Script Folder in PATH
Context:
C:\Scripts in system PATH for convenience, Users group has write access.Impact:- Any user can add malicious scripts
- Common script names can be hijacked (backup.bat, update.ps1)
- Automated tasks may execute malicious scripts
- Privilege escalation when admin runs affected scripts
Advanced Exploitation
DLL Search Order Hijacking
Prevention Best Practices
Minimize PATH Entries
Only include necessary folders in system PATH. Remove legacy entries.
Secure Permissions
PATH folders should only be writable by Administrators and SYSTEM.
Use Program Files
Place all shared tools in Program Files with default protected permissions.
User vs System PATH
Use user PATH for user-specific tools, not system PATH.
Hardening Script
Related Checks
Process DLL Hijack
Check for writable DLLs loaded by privileged processes
Registry Autoruns
Find modifiable autorun binaries
Unquoted Service Path
Identify unquoted service paths
Remediation Guide
Comprehensive remediation guidance
References
Microsoft Docs
Dynamic-Link Library Search Order
MITRE ATT&CK
T1574.007 - Hijack Execution Flow: Path Interception by PATH Environment Variable