Weak File/Folder Permissions
Last updated
Was this helpful?
Last updated
Was this helpful?
If we discover a Task that run with SYSTEM or highest privileges than our current user, the Task can be triggered, and If we have write permissions over the folder or the file (i.e binary or script) used by this task, then we can use it to escalate our privileges.
Given sufficient permissions over a task's file (binary or scripts), swapping it with our own binary enables us to gain code execution as the user configured to run this task.
To identify weaknesses in task file permissions, we can take the following steps: retrieve a complete list of all task binary files, retrieve their permissions, identify interesting permissions referring our controlled user.
We may use the following PowerShell command to make this enumeration
If we find an interesting ACL over a task binary, before replacing it, we want to check the task's trigger and RunAs user.
Alternatively, we can use Get-ModifiableScheduledTaskFile
from .
In case you have write permissions over the Task folder from wich a binary is executed, we can write our DLL in, and then hijack the DLL search order. Here is the default DLL search order in windows (in safe mode which is the default):
The executable directory.
The system directory.
The 16-bit system directory.
The Windows directory.
The current directory.
The directories that are listed in the PATH environment variable.
We can enumerate permissive task folders by using the following PowerShell command
In procomon, specify this three filters (edit the your_service_name.exe with the found binary you found):
DLL hijacking can be applied in many other cases, but this section focuses solely on Scheduled Tasks. For a more comprehensive approach, please refer to .
If we find a writable task folder, we first want to exfiltrate its service binary to a local windows machine. On this controlled computer, download to monitor for missing or hijackable DLLs.