Paths containing environment variables can cause false-positives to occur, e.g. `%SystemRoot%\system32\WindowsPowerShell\v1.0\`. `Find-PathHijack` will believe this is a relative path and will report it as hijackable if the current directory is writeable.
The 'Install-ServiceBinary' function fails on an edge case where the
service's file permission does not include the 'Modify' permission but
does include the 'Write' permission
(https://technet.microsoft.com/en-au/library/dd349321(v=ws.10).aspx). In
this scenario, renaming the original service file for backup purposes
will result in 'Access Denied' message. Fixing this requires that the
file be copied to service.exe.bak instead of renamed to service.exe.bak.
Pester tests to the function 'Test-ServiceDaclPermission' were added in
order to increase confidence in its reliability. In general, my
intention was to replace the current functionality of the service
management functions such as Invoke-ServiceStart, to not use blindly
'sc.exe start' but rather consult with the DACL permissions and base the
decision on that. Unforunately, further investigation lead me to the
conclusion that retrieval of the service's DACL permissions requires
that an additional DACL permission (RC) be set. This may lead to an edge
case that could miss a potential privilege escalation condition and
thereby the original idea was discarded. Nonetheless,
'Test-ServiceDaclPermission' can be used for less critical tasks.
Therefore, a 'CanRestart' property was added to the output of the
service enumeration functions such as 'Get-ServiceUnquoted' as I think
that it will add value to redteamers/pentesters by helping them
prioritise which service should be abused for escalation of privileges.
Services that can be restarted by a low privileged user will probably be
prioritised first. Additionally, manual checking whether the vulnerable
service can be restarted would not be required in most cases.
HarmJ0y